[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Signer certificate discovery for CRLs

To: "Denis Pinkas" <Denis.Pinkas@xxxxxxxx>
Subject: RE: Signer certificate discovery for CRLs
From: "Stefan Santesson" <stefans@xxxxxxxxxxxxx>
Date: Wed, 13 Oct 2004 15:50:35 +0100
Cc: "Santosh Chokhani" <chokhani@xxxxxxxxxxxx>, "pkix" <ietf-pkix@xxxxxxx>
List-archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-id: <ietf-pkix.imc.org>
List-unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
Sender: owner-ietf-pkix@xxxxxxxxxxxx
Thread-index: AcSxMcaBU9SpU9I/RlSGMkvdDwkWtwAAfG7A
Thread-topic: Signer certificate discovery for CRLs
Denis,

I'm not sure what you mean.
I conclude that I agree with Santosh.

The debate is still open... Feel free to express your opinion.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> Sent: den 13 oktober 2004 16:34
> To: Stefan Santesson
> Cc: Santosh Chokhani; pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> Stefan,
> 
> You are making a conclusion without letting me the time to respond.
> I will need more time to look at the pictures (and understand them).
> 
> For the time being, I am still reluctant to accept
"yet-another-method".
> We already have too many.
> 
> > Santosh,
> >
> > I conclude that we are in complete and total agreement.
> > The question is how to go about this.
> 
> > Could we do this amendment to RFC 3280 in its next revision?
> > It would hopefully just be a minor change.
> 
> This is exactly what I feared.
> 
> We usually end-up with a "minor change" in an extension without saying
> cleary how and when it shall/should be used.
> 
> I still have in mind that:
> 
>   1) a certification path must first be constructed,
>   2) then the revocation checking of that path must be done.
> 
> This means that information about CRL issuers certificates locations
may
> certainly be found in that chain. If not, I would like an example.
> 
> Denis
> 
> 
> > It would not change the definition of AIA just add that it can be
used
> also as CRL extension and list eventual restrictions and guidance for
use
> with CRLs.
> >
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> >
> >
> >>-----Original Message-----
> >>From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> >>On Behalf Of Santosh Chokhani
> >>Sent: den 13 oktober 2004 04:33
> >>To: 'pkix'
> >>Subject: RE: Signer certificate discovery for CRLs
> >>
> >>
> >>Stefan:
> >>
> >>In terms of certificate discovery, your proposal for AIA in CRL is
more
> >>robust.  The whole idea of self-issued key rollover certificates and
> then
> >>using the new key to issue CRL is fraught with security problems.  A
> >>secure
> >>solution would be one where the new key is certified by the parent
CA.
> In
> >>that case to obtain the new certificate, you could use AIA in CRL.
> >>
> >>As to indirect CRL, your proposal is a good one.  The CRL DP in
> >>certificate
> >>in question points to the indirect CRL.  You get that CRL.  The AIA
in
> CRL
> >>gets you started for the indirect CRL issuer certification path and
you
> >>are
> >>in business.
> >>
> >>-----Original Message-----
> >>From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> >>On
> >>Behalf Of Stefan Santesson
> >>Sent: Tuesday, October 12, 2004 7:30 PM
> >>To: David A. Cooper
> >>Cc: pkix
> >>Subject: RE: Signer certificate discovery for CRLs
> >>
> >>
> >>
> >>David,
> >>
> >>Thanks for the clarifications, they make sense.
> >>I did misread your pictures.
> >>
> >>So can we conclude that for a re-keyed CA in accordance with RFC
3280,
> >>either the CRL issuer certificate itself, or the location of the CRL
> >>issuer
> >>certificate, will be clearly identified/available for the validating
> party
> >>in some cases, but not in others?
> >>
> >>Can we also conclude that there is no real discovery solution for
> indirect
> >>CRLs?
> >>
> >>Do you then agree then that it could be appropriate to allow AIA as
a
> CRL
> >>extension to facilitate discovery of CRL signer certificate?
> >>
> >>Stefan Santesson
> >>Microsoft Security Center of Excellence (SCOE)
> >>
> >>________________________________________
> >>From: David A. Cooper [mailto:david.cooper@xxxxxxxx]
> >>Sent: den 12 oktober 2004 21:14
> >>To: Stefan Santesson
> >>Cc: pkix
> >>Subject: Re: Signer certificate discovery for CRLs
> >>
> >>Stefan,
> >>
> >>I believe that you are misinterpreting the figures.  They really do
> >>represent three different cases, not three different certification
paths
> >>that have been constructed through the same PKI architecture.
> >>
> >>In figure 1, CA 1 has generated self-issued key rollover
certificates.
> >>The
> >>Root CA has issued a certificate to CA 1's new key, but not its old
key
> >>(either the Root CA never issued a certificate to CA 1's old key or
that
> >>certificate has expired).
> >>
> >>In figure 2, CA 2 has also generated self-issued key rollover
> >>certificates.
> >>The Root CA has issued a certificate to CA 2's old key, but not its
new
> >>key.
> >>
> >>In figure 3, when CA 3 performed key rollover, it requested a new CA
> >>certificate from the Root CA.  CA 3 did not generated self-issued
key
> >>rollover certificates.
> >>
> >>Of course, another realistic scenario would be one in which a CA
> generated
> >>self-issued key rollover certificates upon key rollover and then had
the
> >>Root CA issue a CA certificate to its new key.  In this case, as you
> >>suggest, any of the certification paths from figures 1, 2, or 3
could be
> >>constructed.
> >>
> >>As for the contents of the AIA extension, here is what I have
specified
> in
> >>the "X.509 Certificate and CRL Extensions Profile for the Common
> Policy":
> >>
> >>The authorityInfoAccess extension uses URIs for two purposes. When
the
> >>id-ad-caIssuers access method is used, the access location specifies
> where
> >>certificates issued to the issuer of the certificate may be found.
If
> LDAP
> >>is used, the URI must include the DN of the entry containing the
> relevant
> >>certificates and specify the directory attribute in which the
> certificates
> >>are located. If the directory in which the certificates are stored
> expects
> >>the "binary" option to be specified, then the attribute type must be
> >>followed by ";binary" in the URI. If HTTP is used, the URI must
point to
> a
> >>file that has an extension of ".p7c" that contains a certs-only CMS
> >>message
> >>(see RFC 2633). The CMS message should include all certificates
issued
> to
> >>the issuer of this certificate, but must at least contain all
> certificates
> >>issued to the issuer of this certificate in which the subject public
key
> >>may
> >>be used to verify the signature on this certificate. .... For a
> >>certificate
> >>issued by "Good CA", some examples of URIs that may appear as the
access
> >>location in an authorityInfoAccess extension when the
id-ad-caIssuers
> >>access
> >>method is used are:
>
>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACerti
fi
> ca
> >>te
> >>,crossCertificatePair
>
>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertifica
te
> ;b
> >>in
> >>ary,crossCertificatePair;binary
>
>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssued
To
> Go
> >>od
> >>CA.p7c
> >>For both LDAP and HTTP, the URI provides the exact location where
> >>information is to be located, so there is no requirement for the
relying
> >>party to try to figure out where information is located.
> >>
> >>The HTTP URI points to a certs-only CMS message that includes all
> >>certificates issued to the CA identified in the issuer field of the
> >>certificate.
> >>
> >>The LDAP URI points to the cACertificate and crossCertificatePair
> >>attributes
> >>of the directory entry of the CA identified in the issuer field of
the
> >>certificate.  These two attributes together hold all of the
certificates
> >>issued to the CA:  the cACertificate attribute holds the CA's self-
> issued
> >>certificates and the crossCertificatePair attribute holds the
> >>cross-certificates issued to the CA by other CAs.
> >>
> >>Dave
> >>
> >>
> >>Stefan Santesson wrote:
> >>
> >>David,
> >>
> >>Thanks for these good thoughts and very useful scenarios.
> >>
> >>I have some comments and questions on this.
> >>
> >>First of all we can conclude that in some scenarios (figure 1) where
a
> >>self
> >>issued certificate is inserted into the path, you are likely to find
the
> >>CRL
> >>issuer cert in the path. (given that the new CA have a common key
and
> >>certificate for cert signing and CRL signing).
> >>
> >>Figure 1, 2 and 3 describe the same case. It is just describing
> different
> >>path building strategies. An application that has access locally to
all
> >>chaining options may however still choose path 2 for the certs and
path
> 1
> >>for the CRL independent of each other (which I think figure 3 tries
to
> >>describe)
> >>
> >>Another comment is the structure of AIA extensions. The use I'm
familiar
> >>with doesn't use AIA to describe a directory entry where it is left
to
> the
> >>validation application logic to be intelligent enough to find
> appropriate
> >>certificate data from the directory. The model I'm familiar with is
when
> >>the
> >>AIA URL explicitly identifies the exact location of the appropriate
CA
> >>certificate file, relieving the validation software from complex
> >>information
> >>queries. If just location of explicit certificate files are
identified
> >>through AIA, the presence of an AIA may not help finding the CRL
signer
> >>cert
> >>if this is different from the CA certificate. This is also the
problem
> >>with
> >>Denis proposal.
> >>
> >>I think we share the basic conclusion that the ability to locate the
CRL
> >>signer certificate directly through the CRL could be very useful. At
> least
> >>in the case of indirect CRL but it could also be proven very useful
in
> CA
> >>re-keying scenarios.
> >>
> >>The easiest solution would probably be to allow AIA to be used in
its
> >>current shape and structure as a CRL extension (MUST NOT be
critical).
> It
> >>would present a very clear and uncomplicated logic to certificate
> >>validating
> >>applications in many cases.
> >>
> >>Stefan Santesson
> >>Microsoft Security Center of Excellence (SCOE)
> >>
> >>________________________________________
> >>From: David A. Cooper [mailto:david.cooper@xxxxxxxx]
> >>Sent: den 7 oktober 2004 18:35
> >>To: Stefan Santesson
> >>Cc: pkix
> >>Subject: Re: Signer certificate discovery for CRLs
> >>
> >>Stefan,
> >>
> >>I think what you are proposing is a good idea.  In most cases, path
> >>discovery algorithms assume that both the trust anchor (or trust
> anchors)
> >>and the end entity certificate are provided as input.  In this case,
one
> >>may
> >>need to construct a certification path without a priori access to
the
> end
> >>entity certificate (the one with the subject public key
corresponding to
> >>the
> >>CRL signing key).  Including an AIA extension (or some other
pointer) in
> >>the
> >>CRL would provide the relying party with a simple way to obtain the
end
> >>entity certificate for the CRL signing key's certification path. On
the
> >>other hand, I believe that a relying party should be able to
construct
> the
> >>certification path even without an AIA extension in the CRL, so long
as
> it
> >>is not an indirect CRL.  Attached is a drawing of the three basic
> >>scenarios
> >>that I expect a relying party may encounter:
> >>
> >>In each of these scenarios, the CA has performed key rollover and is
> only
> >>signing CRLs with its new key.  The diagrams would look similar,
> however,
> >>if
> >>the CA simply choose to use different keys to sign certificates and
CRLs
> >>for
> >>some other reason.
> >>
> >>If the PKI architecture resembled figure 1, then the certification
path
> >>for
> >>the CRL signing key would just be a subset of the certification path
for
> >>the
> >>EE certificate, so no addition path discovery would be needed.
> >>
> >>If the PKI architecture resembled figure 1, then it would be
necessary
> to
> >>obtain the new-signed-with-old self-issued certificate.  In building
the
> >>certification path to the EE certificate, however, the relying party
> will
> >>obtain the certificates pointed to by the AIA extension in the EE
> >>certificate.  This AIA extension will point to a location containing
all
> >>certificates issued to CA 2, which would include both the
certificate
> >>issued
> >>by the Root to CA 2 and CA 2's self-issued certificate.  So, even
though
> >>the
> >>self-issued certificate would not be part of the certification path
to
> the
> >>EE certificate, it would be downloaded by the relying party during
the
> >>construction of that certification path.  (Yes, there are circular
> >>dependency issues in figure 2, but that is another issue.)
> >>
> >>A similar situation would happen if the PKI architecture resembled
> figure
> >>3.  The AIA extension in the EE certificate would point to a
location
> >>containing certificates issued to CA 3.  When the relying party
> downloaded
> >>these certificates, it would obtain both of the certificates issued
by
> the
> >>Root to CA 3 and so again would have the certificate needed to
validate
> >>the
> >>CRL signing key.
> >>
> >>In the case of an indirect CRL, things may not work as well.  If
> indirect
> >>CRLs were used, and the PKI architecture resembled figures 2 or 3
> >>(replacing
> >>"New Key" with a different CA), then the set of certificates pointed
to
> by
> >>the AIA extension in the EE certificate would not include the
> certificate
> >>of
> >>the CRL signer.  One could find this certificate by building in the
> >>reverse
> >>direction and using the SIA extension, but that may not be the most
> >>convenient solution.
> >>
> >>So, when indirect CRLs are being used, it seems that it would be
very
> >>useful
> >>to have a pointer in the CRL to the CRL signing certificate.  When
the
> CRL
> >>is not indirect, the need for this pointer does not seem to be as
clear,
> >>but
> >>I can't see any harm in including it.
> >>
> >>Dave
> >>
> >>Stefan Santesson wrote:
> >>All,
> >>
> >>I'm interested in the opinion from members on this list about
discovery
> of
> >>CRL signer's certificate in non directory centric environments.
> >>
> >>The problem is the following.
> >>
> >>The relying party (RP) needs to check validity of a certificate and
> finds
> >>a
> >>CDP extension with a URL to the CRL. The RP retrieves this CRL which
in
> >>this
> >>particular case is either signed by another key of the CA (re-keyed
CA)
> or
> >>another entity (indirect CRL).
> >>
> >>In this case the relying party needs to obtain the certificate of
the
> CRL
> >>signer which may NOT be part of the original chain. In a directory
> centric
> >>solution this is retrieved from the directory, but what if such
> directory
> >>is
> >>not available or accessible.
> >>
> >>The RP have thus no hint where to find the CRL issuers certificate
> unless
> >>the RP already have possession of it by some other means.
> >>
> >>Is seems that CRLs would need an AIA extension with the option to
point
> to
> >>the location of the signers certificate in the same manner as is
> possible
> >>for certificates.
> >>
> >>Maybe AIA should be defined as both cert and CRL extension and not
only
> >>certificate extension as today.
> >>
> >>Thoughts and comments?
> >>
> >>Stefan Santesson
> >>Microsoft Security Center of Excellence (SCOE)
> >>
> >>
> >
> >
> >
>
Follow-Ups:
- Re: Signer certificate discovery for CRLs
  - From: Denis Pinkas
Prev by Date: Re: Signer certificate discovery for CRLs
Next by Date: Re: Signer certificate discovery for CRLs
Previous by thread: Re: Signer certificate discovery for CRLs
Next by thread: Re: Signer certificate discovery for CRLs
Index(es):
- Date
- Thread