[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...



At 12:12 PM 2/16/98 -0500, you wrote:
>Hi All,
>
>I appreciate all the recent feedback on this topic; this is what a
>mailing list is all about!  Since, however, this seems to be the last
>remaining issue for PKIX-CMP, it would be great if we could wrap up this
>definition and get the draft submitted (CMP has been on hold for weeks
>now while we debated the definition of cross-certification, which is
>unfortunate, given that this is such a small part of the whole
>draft...).
>
>As far as I can tell, the following proposal is sensitive to all the
>e-mails (both public and private) that I've seen.
>
>"cross-certification:  Any process that results in the creation of a
>cross-certificate.  For the purposes of this standard, the following
>terms are defined.  A "CA-certificate" is any certificate in which both
>the subject and issuer are CAs.  A "cross-certificate" is a
>CA-certificate in which the subject CA and the issuer CA are distinct
>and  SubjectPublicKeyInfo contains a verification key (i.e., the
>certificate has been issued for the subject CA's signing key pair).
>When it is necessary to distinguish more finely, the following terms may
>be used:  a cross-certificate is called an "inter-domain
>cross-certificate" if the subject and issuer CAs belong to different
>administrative domains; it is called an "intra-domain cross-certificate"
>otherwise.  (Note:  in many environments the term "cross-certificate",
>unless further qualified, will be understood to be synonymous with
>"inter-domain cross-certificate" as defined above.).  Issuance of
>cross-certificates may be, but is not necessarily, mutual; that is, two
>CAs may issue cross-certificates for each other."
>
>
>Some comments.
>
>1) The first sentence addresses those who were concerned that the
>previous definition of cross-certification mandated a request from the
>subject CA and a response from the issuer CA.  This now makes it clear
>that the so-called "spontaneous" decision by the issuer still
>constitutes "cross-certification".
>
>2) The definition of "CA-certificate" aligns with that given in X.509.
>The definition of "cross-certificate" is slightly more restrictive in
>that a self-signed certificate is explicitly *not* a cross-certificate,
>but I believe this would correspond with everyone's understanding and
>use of the term today.
>
>3) The note at the end addresses those who feel that cross-certification
>applies only to CAs in different administrative domains.  This note
>makes it clear that such will be the common interpretation without
>completely closing the door to other possible interpretations.
>
>4) I recognize that some wanted to drop the term cross-certificate (or
>cross-certification) completely and move to something else (such as
>CA-certificate or one of the other candidates).  However, the following
>two reasons might be offered for keeping "cross-certificate" in these
>documents.
>
>- For better or worse, rightly or wrongly, the industry (including the
>media) has adopted the term "cross-certificate".  It is true that
>different people often mean different things when they use it.  However,
>it seems much more sensible to define the term than to, at this late
>stage, try to introduce a new term that no one is familiar with.  It's a
>bit like "certificate", or "signature", or a number of other terms; I'm
>not sure we have the luxury of choosing names for these concepts any
>more, but we *can* define what PKIX means when they are used in PKIX
>documents.
>
>- Again, for better or worse, rightly or wrongly, the X.500 Directory
>standard defines attributes called "ca-certificate" and
>"cross-certificate".  If PKIX takes what we all intuitively think of as
>a cross-certificate and calls it a CA-certificate, where would such a
>thing likely be put in the Directory (despite any warnings we might put
>in that the two terms are unrelated)?  If PKIX calls it some new name,
>where would it be put?  All this would really accomplish would be to
>complicate path-finding procedures unnecessarily.  I fail to see much
>value in taking what people think of as a cross-certificate, calling it
>a CA-certificate, and then encouraging Directory users to put it in the
>cross-certificate attribute rather than the ca-certificate attribute...

The problem I have is that what you claim "people think of as a
cross-certificate" is not at all, not even a little bit, what I think of as
a cross-certificate.  I think a cross-certificate is a cross-certificate
pair.   No more and no less.  And X.509 (June 1997 version) never uses
"cross-certificate" except as a part of cross-certificate pair (unless
there is some mysterious new amendment I've never seen that changes
everything, and at this point I don't care about further amendments to X.509),

Moreover, it seems to me that the meaning of the term "CA-certificate" is
pretty obvious, and the term defined in X.509 as: "A certificate for one CA
issued by another CA" and is used 19 times in X.509.  And to my reading,
where X.509 says "CA-certificate" or "CA certificate"  you would have PKIX
say "cross-certificate."  I have a really hard time with that.  I think
that it's confusing as hell.

I favor using cross-certificate as equivalent to cross-certificate pair,
and CA -certificate, as it us used in X.509, for any certificate, as
anything that is not an end-entity certificate.

This may cause problems with drafts of X.500 I've never seen.  It seems to
me that the thing to do is to make X.500 attributes align with X.509
terminology.

But to have PKIX use the term "cross-certificate" where X.509 apparently
always uses "CA-certificate" would be a spectacularly confusing choice.
Regards,

Bill Burr