RE: ldapv2-schema and CA Certificates

[Santosh Chokhani <chokhani@xxxxxxxxxxxx>]

Larry:

Thanks for bringing the thread back in focus.

I also agree that we should define something that accommodates both
points of view.

I also agree with what Dave Horvath has suggested.  The following are my
thoughts.  They are in line with what Dave has said.

In order to support both positions, the interoperability burden can be
put on the client.

I propose the following language (be it in X.509, ldap or some other
place)

START OF SUGGESTED TEXT

"The infrastructure components (namely the authority, repository or a
directory) may populate certificates issued to an authority in the
caCertificate, in the forward component of the crossCertificatePair
attribute, or both attributes of the subject authority's directory
entry.  The clients should be designed to retrieve certificates from
both of these attributes in order to develop certificate paths.

However, in order to make the path development efficient, it is
recommended that the certificates issued to the authorities in the same
PKI domain as that of the issuing authority be stored in the
caCertificate attribute.  Similarly, the certificates issued to the
authorities in the PKI domain(s) other than that of the issuing
authority should be stored in the appropriate component of the
crossCertificatePair attribute.

Self-signed certificates may be stored in either or both attributes.
However, when an authority rekeys itself and issues two self-signed
certificate (one to certify the current public key with the new private
key and another to certify the new public key with the current private
key), these two certificates should be stored in the authority's
crossCertificatePair attribute."

END OF SUGGESTED TEXT

Suggestion are welcome in the area of whether two cross certificates
pairs should be created.  In that scenario the forward and reverse
certificates will flip flop in the two attribute values.

If Sharon has preference for treating the self-signed certificate
differently, we can revise the text accordingly.

We should also include the following definition of a self-signed
certificate.

" A self-signed certificate is the one in which the issuer DN = subject
DN and issuer alternate name = subject alternate name (if one extension
is present, other must be present).  The subject public key in a
self-signed certificate may or may not be the companion of the private
key used to sign the certificate" 

	-----Original Message-----
	From:	Dave Horvath [SMTP:dave@chromatix.com]
	Sent:	Thursday, August 13, 1998 8:14 PM
	To:	Larry Layten
	Cc:	ietf-pkix@imc.org; 'kpcm'
	Subject:	Re: ldapv2-schema and CA Certificates

	All,

	I don't think we are too far apart if we make the following
assumptions
	and support the conclusion listed below.

		1) Entrust-enabled products currently use
non-hierarchical
		(bi-lateral) cross  certification. (Sharon is this
correct?)
		I also note that Entegrity implemented to the
ldapv2-spec
		so we will need concurrence from them.

		2) Other communities such as DOD use a hierarchical
		CA model at this time.


	We propose we modify the X.509 defect report and ldap-v2 spec to
place
	all hierarchical CA certificates in the cACertificate attribute
of that
	particular CA's entry.  Self signed CA certificates shall also
be placed
	in the cACertificate attribute.

	The non-hierarchical (bi-lateral) CA's certificates shall be
placed in
	the crossCertificatePair attribute.   When DOD implements cross
	certification, it will then start populating the
crossCertificatePair
	attribute.  When Entrust implements a hierarchical model, the
	hierarchical CA's certificates shall be placed in the
cACertificate
	attribute.

	This approach allows all parties to do business the way they
have been.


	Regards,
		Dave Horvath, Pete Peterson

	Larry Layten wrote:
	> 
	> I am sorry that I brought up "political issues".
	> 
	> Perhaps someone out there could summarize the pros and cons
	> of each approach.
	> 
	> Maybe someone could propose a way that a structure could
	> be built that would incorporate both approaches, allowing for
	> interoperability between the approaches based upon a mapping
	> to the appropriate method and programming for both.
	> 
	> Non-flamming responses only please! My mailbox is full :-)
	> Larry
	> 

	-- 
	               ================================================

	      _/_/_/                   David J. Horvath
	   _/      _/                  
	  _/       _/                  Chromatix, Inc. 
	 _/           _/  _/           10451 Twin Rivers Road, Suite 265
	_/            _/_/             Columbia, MD 21044
	 _/     _/   _/_/  Phone:  (301) 596-8466  |
http://www.chromatix.com
	  _/_/_/   _/   _/ Fax:    (410) 997-4306  |  dave@chromatix.com