[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ldapv2-schema and CA Certificates
Santosh,
I agree with your proposed text. However, I am concerned about the
definition of self-signed certificate as it is described below.
To me, self-signed means just that: the companion private key is used to
sign the certificate. However, I do recognize the need for "self-signed"
certificates as you describe below to support concepts such as rekey, or key
rollover. May I recommend the term "self-issued" certificate? To me this
makes more sense if the definition is subject DN = issuer DN. We can then
say self-signed really does mean that the private companion key was used to
sign the certificate.
Also, I believe within a PKI that supports dual certificates (one for
signature applications, and one for key exchange applications), a CA may
issue its own key exchange certificate top support encrypted communications
with its clients. In this case, there is a chance that the subject DN and
issuer DN in the key exchange certificate may be the same. I would not call
this certificate a self-signed certificate, but rather a self-issued
certificate.
In summary, I am proposing the following definitions:
Self-Issued Certificate - A self-issued certificate is 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-issued certificate may or may not be the companion of the
private key used to sign the certificate.
Self-Signed Certificate - A self-signed certificate is 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 MUST always be the companion of the private
key used to sign the certificate.
Given these definitions, all self-signed certificates are self-issued
certificates. But not all self-issued certificates are self-signed
certificates. Thoughts?? Comments?? Stones?? Rocks?? Arrows?? Other
pointed or blunt objects??
Yuriy
-----Original Message-----
From: Santosh Chokhani [mailto:chokhani@cygnacom.com]
Sent: Friday, August 14, 1998 9:16 AM
To: 'Dave Horvath'; Larry Layten
Cc: ietf-pkix@imc.org; 'kpcm'
Subject: RE: ldapv2-schema and CA Certificates
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