Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attrib utes

From: "Kurn, David" <[email-masked]>
Date: Wed, 16 Sep 1998 15:22:03 -0700

I still think the use of "domain" is very confusing, and should be removed
from the text.

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Wednesday, September 16, 1998 2:23 PM
To: [email-masked]
Subject: Storage of CA Certificates in LDAP and X.500 Directory
Attributes

Based on the pkix co-chair request, Sharon and I jointly propose the
following text:

"The cACertificate attribute of a CA's directory entry shall be used to
store certificates issued to this CA by CAs in the same domain as this
CA.  If there are any self-issued certificates and they require
publication, the caCertificate attribute shall be used to store them.

The forward elements of the crossCertificatePair attribute of a CA's
directory entry shall be used to store all certificates issued to this
CA, which are not self-issued.  Optionally, the reverse elements of the
crossCertificatePair attribute, of a CA's directory entry may contain a
subset of certificates issued by this CA to other CAs.  When both the
forward and the reverse elements are present in a single attribute
value, issuer name in one certificate shall match the subject name in
the other and vice versa, and the subject public key in one certificate
shall be capable of verifying the digital signature on the other
certificate and vice versa.  When a reverse element is present, the
forward element value and the reverse element value need not be stored
in the same attribute value; in other words, they can be stored in
either a single attribute value or two attribute values.

In the case of V3 certificates, none of the above CA certificates shall
include a basicConstraints extension with the cA value set to FALSE.

The definition of domain is purely a matter of local policy.

Santosh Chokhani
CygnaCom Solutions, Inc.
7927 Jones Branch Drive, Suite 100 West
McLean, VA. 22102
(703) 848-0883 (voice)
(703) 848-0960 (fax)
[email-masked]
http://www.cygnacom.com

---

From: "Kurn, David" <[email-masked]>
Date: Thu, 17 Sep 1998 08:43:54 -0700

I think the actual choice of word here is not the issue.  You can call it
"Kingdom", but the flaw in the specification persists, since the last
sentence implies that the word has a definition that depends upon the
personal interpretation of the implementor.  This doesn't make for portable
programs.

I think the reason the specification needs the word is so that the spec can
give guidance about when to put a cross-cert in one bucket or in another
bucket.  And this, if I follow the recent conversations, has to do with
advice about how to do path development. (I'm stepping out on shaky ground
here).

*IF* we wish to say to those writing path evaluation programs:
  "You should look in the first bucket (caCertificates) first, and then in
the second bucket"
then we can give some guidance about how to populate the two buckets, which
could in effect would say:

You should put certificates in the appropriate bucket according to your
expectation about how to optimize the path development given that clients
will look in the caCertificates first.  Your choice will affect efficiency,
not correctness.

I go back to something I remember from learning about Object-Oriented
programming .... don't ask "what is it", but rather "what does it do".

David Kurn
Compaq Computer Corp

-----Original Message-----
From: bgmiller [mailto:[email-masked]]
Sent: Wednesday, September 16, 1998 7:27 PM
To: [email-masked]
Subject: Re: Storage of CA Certificates in LDAP and X.500 Directory
Attributes

Paul Hoffman / IMC wrote:

> I agree with David. The word "domain" has a specific meaning in the IETF,
> and this definition doesn't match it. Could you use "realm" instead? Or
are
> there better words?

How about "scope"?

---

From: Sharon Boeyen <[email-masked]>
Date: Thu, 17 Sep 1998 12:23:15 -0400

I'm flexible on the term and have passed that on to Santosh (awaiting his
reply).  I see nothing wrong with scope or realm and am open to suggestion.
I agree that it would be good to select a term that doesn't have a
predefined meaning in the IETF. 
It is important to keep the definition of the specific criteria for its use
as a local matter so this mechanism can be used in different environments
with different criteria for the 'hints' provided by the CA to relying
parties, regardless of whether relying parties choose to examine those hints
or not. That, we've been in agreement on thoughout this debate, but I'm
quite agreeable to a different 'less loaded' term.

> ----------
> From: 	bgmiller[SMTP:[email-masked]]
> Sent: 	September 16, 1998 10:26 PM
> To: 	[email-masked]