headers
Warwick Ford | 1 Jan 1998 21:57
Picon
Favicon

Re: Dave's Critical Proposal

Dave:

At 02:35 PM 12/31/97 -0500, David P. Kemp wrote:
>Warwick (and Bob),
>  You are correct; I did not make a distinction between "recognize"
>and "support".  A hypothetical implementation might recognize a particular
>extension but not, for some reason, claim for compliance purposes to
>support it.  Would the following rule be more suitable?
>
>  "If an implementation claims PKIX-compliant support for a particular
>   extension, where the scope of "support" is specified in the
>   extension definition, then when processing that extension the value
>   of the critical flag SHALL be ignored."
>
>
>In the case of certificatePolicies, "recognize" or "support" means that
>the application must support both the certificatePolicies extension
>{ id-ce 32 } itself and at least one of the policies (specified by
>the policyIdentifier field) contained in the extension.

No, I don't think this solves the whole problem.  I think John is right in
pointing out a design weakness in X.509, with respect to the definition of
the Certificate Policies extension.  Fact of the matter is that "Critical
Certificate Policies" extension and "Noncritical Certificate Policies"
extension really should be two different extension types, since they have
quite different semantics.  Use of the criticality indicator to signify
different behaviour is not a good thing.

In fact, there is an even bigger problem ... I have run across scenarios
where you might want to have both a "Critical Certificate Policies"
(Continue reading)

Permalink | Reply | 0 comments |
headers
mmyers | 3 Jan 1998 20:22
Picon
Favicon

Re: OCSP Change Request

Steve,

At 12:56 PM 12/31/97 +0000, Stephen Farrell wrote:
>Hi Mike,
>
>> >1. The standard response message should include a MessageId field. This
>> >allows the client to reference a response previously received which
>> >contains a path deemed unacceptable by the OCSP client. Note that this
>> >does not affect caching of responses. (A HREF would also suffice.)
>>
>> A MessageId field sounds like a useful request extension.  It would however
>> predictably extend the complexity of an OCSP server such it must maintain
>> this state information in addition to, for example, nonce information.
>
>I agree that MessageId is a request extension, but would like it to
>be a standard part of the response. I can see that it introduces some
>state into a server which supports the request extension, however,
>that statefulness is required in order to produce a "next" path
>for the same request.

Would it be sufficient for your needs that MessageID be present in the
response if present in the request?

>
>> >2. The standard response should include the base64 encoding of the entire
>> >path and set of CRLs used to verify the certificate. There is very little
>> >overhead involved as the OCSP server must possess all the relevant
>> >items.
>>
>> I agree the OCSP server may have this information on hand, but its
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dwight Arthur | 4 Jan 1998 22:47
Picon

Re: NO SUBJECT

On trust and cross certification:

I believe that there is a persistent misperception among technologists
in this field that an RP will trust someone because of the
certificate(s) that person can produce. On the contrary I would suggest
that in many cases the RP represents an enterprise that causes a
certificate to be granted because of a pre-existing relationship of
trust. In other words, trust leads to certificates, certificates do not
lead to trust.

If my enterprise operates a system which we have agreed to make
accessible to you, it is because we already have some reason to trust
you, such as a contractual relationship with your employer, or
collateral that you have deposited with us, or maybe a line of credit
that you have identified and we have verified.

The certificate plays an important role: it allows my system to validate
your identity at the time that you access it, and allows you to create
"digital signatures" as lasting verifiable indications that you commit
yourself and/or your enterprise to various transactions. In order to
achieve these benefits without the overhead and expense of personally
issuing certificates to everyone I trust, I will rely in some cases on
CAs operated by others to issue the certificates. To be able to validate
these certificates, I may require some relationship with the external CA
that may require cross-certification (although there may be other
simpler ways such as bilateral exchange of keys).

BUT IN NO CASE does the fact that I cross certify an external CA make me
willing to trust any and all certs issued by that CA. All it does is
that when I receive a signature from someone I am inclined to trust, it
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alan_Buffett | 5 Jan 1998 03:57
Picon

(unknown)

Alan Buffett
01/04/98 09:57 PM

subscribe
Permalink | Reply | 0 comments |
headers
Warwick Ford | 5 Jan 1998 14:09
Picon
Favicon

Re: NO SUBJECT

Dwight:

In my score-keeping on the terminology issue, I have thus far seen support
for at least two totally different interpretations of the term
"cross-certification", then several different shades of meaning beyond that.

I would contend that "cross-certification" is NOT a well-defined term and
suggest we move to (and clearly define) more precise terms such as
"CA-certification" and "inter-domain certification".  I was giving the list
another few days after the break to make sure that all inputs are in,
before making a concrete proposal.

Regards,
Warwick

At 04:47 PM 1/4/98 -0500, Dwight Arthur wrote:
>On trust and cross certification:
>
>I believe that there is a persistent misperception among technologists
>in this field that an RP will trust someone because of the
>certificate(s) that person can produce. On the contrary I would suggest
>that in many cases the RP represents an enterprise that causes a
>certificate to be granted because of a pre-existing relationship of
>trust. In other words, trust leads to certificates, certificates do not
>lead to trust.
>
>If my enterprise operates a system which we have agreed to make
>accessible to you, it is because we already have some reason to trust
>you, such as a contractual relationship with your employer, or
>collateral that you have deposited with us, or maybe a line of credit
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gina DePlanche | 5 Jan 1998 15:58

X509 newcomer

        Hi!

        I work for a router company and I am researching using X509
certificates in our box.  I am just starting to learn about X.509
certificates. I have read the draft draft-ietf-pkix-ipki-part1-06.txt.
I have the ITU-T recommendation for X509 and Amendment 4.

        I have a couple of questions I was hoping someone on this list
could answer.

        1. The draft states it is part of a multipart standard.
What/where are the other parts? Are there any other specifications for
using certificates?

        2. Are there any white papers/drafts/specs/books out there that I can
read which would give me an understanding of the operational procedures
for using X509 certificates?

        3. Any other information a beginner should know?

        Thank you very much for any information you can provide.

        - Gina

--
Gina M. DePlanche               |       OpenROUTE Networks, Inc.
gmd <at> openroute.com               |       A subsidiary of Proteon, Inc.
(508) 898-2800 x2541            |       9 Technology Drive, Westborough, MA
Fax: (508) 836-5347             |       01581-1799  MailStop #23
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Jueneman | 5 Jan 1998 17:55
Picon
Favicon

Re: PKIX Part 1: more clarity needed on AltNames

Paul, I think that the only reasonable vieww would be to assume that the CA
is binding the public key to the gestalt, i.e., the totality,  of all of the
attributes contained in the certificate, including the DN and any alt names.
 If we start trying to pick apart different meanings for this, that and the
other attrbute when used in combination with other attributes, the
combinatoric explosion of semantic possibilities will quickly become
impossible to deal with.

So I believe that the CA is certifying each name individually, AND as a
group. Remember, it is perfectly possible, meaningful, and correct, for the
CA to issue multiple certificates to the same DN, and/or the same alt name,
for various purposes.

What the legal implications of a digital signature issued by
"groupmailbox <at> foo.com" might be would be a different issue.

Bob

>
>>My guess would be that
>>the CA is vouching for the binding between each name in a certificate
>>and the remaining contents of the certificate.
>
>Each name individually, or as a group? "The rest of this cert applies to
>either the DN xxx,yyy or the email address foo <at> bar.com" or "The rest of
>this cert applies to DN xxx,yyy, but only when also thought of as
>foo <at> bar.com"?
>
>>It's probably a
>>distinction without a difference to ask whether the CA is vouching for
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bob Jueneman | 5 Jan 1998 21:52
Picon
Favicon

Re: NO SUBJECT

Warwick,

I certainly agree with the need to clarify the terminology.

To my way of thinking, one of the most important distinctions between an
interdomain cross-certificate and an "ordinary" certificate lies in the
potential one-to-many relationship of the subject to the issuer that
significantly complicates the certificate retrieval mechanism, by requiring
both bottom-up and top-down processing.

Since I may not have a correct understanding of the model, let me at least
describe what I am envisioning:

A stand-alone, hierarchical domain exists that consists of a top-level CA,
one or more subordinate CAs whose certificates are either signed by the
top-level CA or by a higher-level subordinate CA, and a multiplicity of
end-user's whose certificates are signed by a subordinate CA.

Although not absolutely necessary, I am envisioning that the public key of
the top-level CA will be incorporated in a self-signed certificate for
compatibility of distribution as well as to allow the inclusion of various
attributes (e.g., expiration dates, DNs, etc.) in a standard form.

Given an end-user's certificate, it is possible to at least identify the
name of the issuing CA by looking at the issuerName field of the end-user's
certificate. Hopefully the location of that certificate can also be derived,
at least indirectly if not directly.  By applying this mechanism
recursively, it is possible to climb the chain of certificates up to the
top-level CA, whose self-signed certificate serves as a 'stopper" to stop
the search.  If the top-level CA's public key is included in the cache of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Warwick Ford | 6 Jan 1998 01:43
Picon
Favicon

Re: NO SUBJECT

Bob:

This is another interesting (and unquestionably useful) view on the meaning
of "cross-certification".  It is different to what I had been referring to
as "inter-domain certification" because, to my mind, inter-domain
certification might end up with a hierarchical structure or might not.

It is now clear that there are at least 3 quite different problems being
addressed, all of them being declared as the "cross-certification" problem,
but that there is no "cross-certification" panacea.  I therefore suggest we
retire the term "cross-certification" for the moment and focus on the
various problems and the characteristics of their solutions.

I believe the "problems" identified thus far are:

(a) The mechanical problem of having one CA issue a cert for another CA
(regardless of domain, PKI structure, etc.).  This is the problem solved by
the CMP CrossCert transaction or similar enrollment protocols.  As pointed
out by Denis Pinkas, this is probably best called "CA-certification" for
consistency with the X.509 term "CA-certificate".

(b) The problem of establishing a link between two domains (typically two
organizations) whereby a CA in one domain issues a certificate for the
cert-signing key of a CA in another domain.  This raises the issues of
assessment of trustworthiness, establishment of binding agreements,
liability apportionment, X.509 protection mechanisms such as name
constraints and policy-mapping, transitivity (on to further domains), etc.
(I have been using the term "inter-domain certification" for this.)

(c) The problem of finding a cert chain given that, in the general case,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Moore | 6 Jan 1998 03:02
Picon

Re: NO SUBJECT

I am not sure why things have to be made more complicated than needed.

A) First Separate out the technical issues from the policy issues.
B) Address the technical issues here, leave the policy issues for the
policy/business decisions.

With the above, cross certification at least with the current standard
is straight forward.
All of the discussed uses of cross-certificates are ok, it all depends
on the policy under which the cross-certificate is certified.

So
1. Leave the technical definition as is
2. Let the certificate policy make statements about the rules and
meanings of any cross-certificate.
Let the policy have flexibility to support what people what to put
labels on such as inter-domain certification or other terms.

> -----Original Message-----
> From: Warwick Ford [SMTP:wford <at> VERISIGN.COM]
> Sent: Tuesday, January 06, 1998 10:44 AM
> To:   IETF-PKIX <at> LISTS.TANDEM.COM
> Subject:      Re: [IETF-PKIX] NO SUBJECT
>
> Bob:
>
> This is another interesting (and unquestionably useful) view on the
> meaning
> of "cross-certification".  It is different to what I had been
> referring to
(Continue reading)

Permalink | Reply | 0 comments |

Gmane