[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ldapv2-schema and CA Certificates
Yuriy:
I agree with you. Self-issued seems more appropriate to me. When I
hear the term "self-signed", I interpret it to mean signed using a
private key whose companion public key is the subject public key. I
think the term "self-issued' should be used in the text.
-----Original Message-----
From: Yuriy Dzambasow [SMTP:ydzambasow@spyrus.com]
Sent: Friday, August 14, 1998 10:03 AM
To: Santosh Chokhani; 'Dave Horvath'; Larry Layten
Cc: ietf-pkix@imc.org; 'kpcm'
Subject: 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