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

To: "'pkix'" <ietf-pkix@xxxxxxx>
Subject: RE: Signer certificate discovery for CRLs
From: "Santosh Chokhani" <chokhani@xxxxxxxxxxxx>
Date: Thu, 14 Oct 2004 03:53:13 -0400
Importance: Normal
In-reply-to: <0C3042E92D8A714783E2C44AB9936E1D0152BC77@EUR-MSG-03.europe.corp.microsoft.com>
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
Stefan:

I agree that the change does not warrant change in OID and should not impact
others.

-----Original Message-----
From: Stefan Santesson [mailto:stefans@xxxxxxxxxxxxx] 
Sent: Thursday, October 14, 2004 3:40 AM
To: Wen-Cheng Wang; Santosh Chokhani; pkix
Subject: RE: Signer certificate discovery for CRLs


Wen-Cheng,

Thanks for bringing this up. Yes, this has also crossed my mind and we will
have to find the appropriate course on this matter.

I'm personally divided but I kind of like to keep the current OID since we
have a lot of current code and logic that successfully use the
id-ad-caIssuers to retrieve certificates for chain-building, which is the
case both for certificate chains for certs and CRLs. So I see no major
change in the use of the OID, just a fractional expansion of scope.

So currently I lean towards adding the minor expansion of scope to the
current id-ad-caIssuers OID instead of creating a new one. But that is not
yet a mature opinion.

I think the time to deal with this problem is best after deciding whether we
want to do AIA for CRLs in the first place. I'm positive that we can find a
good solution.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Wen-Cheng Wang
> Sent: den 14 oktober 2004 04:09
> To: Stefan Santesson; Santosh Chokhani; pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Stefan,
> 
> I think it is a good idea to include AIA extension in CRL to aid RP in 
> finding CRL issuer certificates.
> 
> However, I am concerning about the accessMethod OID to be used. 
> Currently, RFC 3280 only define id-ad-caIssuers OID, which is intended 
> to aid RP in finding CA certificates. Since a CRL issuer might not be 
> a CA, the name and definition of the id-ad-caIssuers OID need to be 
> changed (or extended).
> 
> In addition, the definition of the id-ad-caIssuers accessMethod is 
> very vague. I think this is a chance to clarify it. I suggest that 
> when doing this amendment the following things should be
> clarified:
> 
>    1. What will be retrieved from the acceesLocation if it is an URI?
>            I believe that the current practice is that an issuer 
> certificate
>            or a list of issuer certificates (in PKCS#7 format) will be
>            retrieved if the acceesLocation is an HTTP or FTP URI.
>            But it is not clear what will be retrieved if the 
> acceesLocation
>            is an LDAP URI?
>    2. What will be the MIME type of the retrieved object?
> 
> Since id-ad-caIssuers is not a proper name for the the accessMethod 
> OID, I suggest that th name be changed to id-ad-issuerCertificates 
> (and of course the definition should also be changed).
> 
> Wen-Cheng Wang
> 
> 
> ----- Original Message -----
> From: "Stefan Santesson" <stefans@xxxxxxxxxxxxx>
> To: "Santosh Chokhani" <chokhani@xxxxxxxxxxxx>; "pkix"
<ietf-pkix@xxxxxxx>
> Sent: Wednesday, October 13, 2004 9:44 PM
> Subject: RE: Signer certificate discovery for CRLs
> 
> 
> 
> 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.
> 
> 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?cACertifi
ca
> > te
> > ,crossCertificatePair
> >
>
ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertificate
;b
> > in
> > ary,crossCertificatePair;binary
> >
>
http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssuedTo
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)
> >
> >
>
References:
- RE: Signer certificate discovery for CRLs
  - From: Stefan Santesson
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