Subject: RE: Signer certificate discovery for CRLs

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 13 Oct 2004 01:33:13 +0100

Santosh,

It seams that we are in agreement regarding AIA in CRLs.

I agree that crypto binding between certificate issuer and CRL is a
useful and important feature for the purpose you mention. Just applying
name matching seems a bit week and could in worst case increase the
vulnerability for attacks thanks to poor implementations or miss
configuration errors.

It would actually be easier to process than path comparison rules but
have the drawback of introducing a new extension. Let's consider that
closer.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 7 oktober 2004 18:44
> To: [email-masked]
> Subject: RE: Signer certificate discovery for CRLs
> 
> 
> Stefan and Denis:
> 
> I have reviewed Denis's examples.  They do not seem clear to me.  But,
for
> both re-key and indirect case (there are several such as assigning a
sub
> CA
> or another CA in the PKI domain that is not in any certificate's
> certification path), what Stefan has suggested for CRL is a good idea.
> 
> I assume that we all realize that having an AIA is not crypto binding.
> 
> Separately, while preparing for PKIX, I have had this idea for crypto
> binding the certificate signer and CRL signer.  This could be in lieu
of
> certification path matching algorithm.  A CRL can contain a
non-critical
> extension which is a SEQUENCE or SET of key identifier (formed using
hash
> scheme recommended by 3280) of the CAs' certificate signing keys.  A
key
> identifier is included if the certificate signed using that key can be
> included in that CRL.  Now, the relying party only needs to match the
AKID
> of the certificate with one of the values in this extension.
> 
> Please note that this check is a substitute for path matching.  IDP
> discipline must still be observed in order to maintain security.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Denis Pinkas
> Sent: Thursday, October 07, 2004 10:42 AM
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> 
> Stefan,
> 
> > 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.
> 
> You mean: "In these cases ..." since there are two cases.  :-)
> 
>  > 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.
> 
> I suppose that a candidate certification path has been successfully
built,
> but not yet validated as far as certificate revocation status is
> concerned.
> 
> In the first case (re-keyed CA), there may be multiple sub-cases, so
you
> would have to be more specific to explain the scenario you have in
mind.
> 
> In the second case (indirect CRL, no re-keyed CA), let us use a simple
> example.
> 
> A chain of certificates has been built with:
> leaf certificate / CA Cert 1 / CA Cert 2 / ...
> 
> In the chain of certificates, if CA Cert 1 (issued by CA 2) includes
an
> AIA
> extension with an AccessDescription id-ad-caIssuers, then the location
of
> a
> repository that may contain CRL issuer certificates may be known: if
CA 2
> postes the certificate designating the CRL issuer in that repository,
then
> the problem is solved.
> 
> " [FROM RFC 3280] The accessLocation field specifies the location of
the
> information. The retrieval mechanism may be implied by the
accessMethod or
> specified by accessLocation. When id-ad-caIssuers appears as
accessMethod,
> the accessLocation field describes the referenced description server
and
> the
> 
> access protocol to obtain the referenced description."
> 
> In the chain of certificates, if CA Cert 2 (issued by CA 3) includes
an
> Subject Information Access (SIA) extension with an AccessDescription
> id-ad-caRepository, then the location of a repository that may contain
CRL
> issuer certificates may be known: if CA 2 postes the certificate
> designating
> 
> the CRL issuer in that repository, then the problem is also solved.
> 
> Even if these extensions are scarcely (not yet ?) used for that
purpose, I
> do not think it would be desirable to introduce a third way.
> 
> Denis
> 
> 
> 
> > Thoughts and comments?
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> >
> >
> 
>

---

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 13 Oct 2004 01:38:36 +0100

Denis,

I think my reply to David Cooper also cover your mail and need not to be
repeated.

I don't agree to your conclusion. Just because current available methods
(e.g. use of AIA in certificates) may provide sufficient functionality
in some cases does not make a good rationale for not applying a better
and simpler solution that actually works in all situations.

Stefan Santesson

> On Behalf Of Denis Pinkas
> Sent: den 7 oktober 2004 16:42
> To: Stefan Santesson
> Cc: [email-masked]
discovery
> > of CRL signer's certificate in non directory centric environments.
> >
signed
> > by another key of the CA (re-keyed CA) or another entity (indirect
CRL).
the
> > centric solution this is retrieved from the directory, but what if
such
> > directory is not available or accessible.
> >
point
> > to the location of the signers certificate in the same manner as is
> > possible for certificates.
> >
only
> > certificate extension as today.
> 
built,
you
mind.
an
of
CA 2
then
the
accessMethod or
accessMethod,
and
an
CRL
> Even if these extensions are scarcely (not yet ?) used for that
purpose,
> I do not think it would be desirable to introduce a third way.
> 
> Denis
> 
> 
> 
> > Thoughts and comments?
> >
> > Stefan Santesson

---

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 13 Oct 2004 18:07:05 +0100

I think David Cooper has done a prime good job on that in his postings to the list.
 
I also think Santosh has made good effort to justify the need, especially for indirect CRLs.
 
Tell me what you miss and I'll try to fill in.
 
Stefan Santesson

________________________________

From: Denis Pinkas [mailto:[email-masked]]
Sent: Wed 10/13/2004 5:01 PM
To: Stefan Santesson
Cc: Santosh Chokhani; pkix
Subject: Re: Signer certificate discovery for CRLs

Stefan,

> I'm not sure what you mean.

For the time being, I would like that you provide an example where, when
using the current extensions that are defined in RFC 3280, it will NOT be
possible to locate a CRL Issuer certificate.

If you are able to provide that example, then it would justify the need for
an extension at least for one case. Then we can see what that case is.

I am awaiting that example.

Denis

> I conclude that I agree with Santosh.
>
> The debate is still open... Feel free to express your opinion.
>
> Stefan Santesson
>>From: Denis Pinkas [mailto:[email-masked]]
>>Sent: den 13 oktober 2004 16:34
>>To: Stefan Santesson
>>Cc: Santosh Chokhani; pkix
>>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
>>>>Sent: den 13 oktober 2004 04:33
>>>>To: 'pkix'
>>>>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.
>>>>
>>>>Behalf Of Stefan Santesson
>>>>Sent: Tuesday, October 12, 2004 7:30 PM
>>>>To: David A. Cooper
>>>>Cc: pkix
>>>>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
>>>>________________________________________
>>>>From: David A. Cooper [mailto:[email-masked]]
>>>>Sent: den 12 oktober 2004 21:14
>>>>To: Stefan Santesson
>>>>Cc: pkix
>>>>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
>>>>________________________________________
>>>>From: David A. Cooper [mailto:[email-masked]]
>>>>Sent: den 7 oktober 2004 18:35
>>>>To: Stefan Santesson
>>>>Cc: pkix
>>>>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,
>>>>
>>>>CRL signer's certificate in non directory centric environments.
>>>>
>>finds
>>>>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).
>>>>
>>>>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.
>>>>
>>unless
>>>>the RP already have possession of it by some other means.
>>>>
>>to
>>>>the location of the signers certificate in the same manner as is
>>>
>>possible
>>
>>>>for certificates.
>>>>

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 14 Oct 2004 09:15:23 +0100

Santosh,

I agree to these examples. I only have 1 comment.

MS-CAPI is not constrained to use chain building from leaf to Root
through AIA but it has the capacity to do so. However MS-CAPI has
limited possibilities to find the CRL issuer cert unless it is the one
used to sign the cert checked for revocation, much because there is no
straightforward solution to this problem (as your examples illustrate).

I think this is generally true also for other products in the market
place. It would be interesting to hear other vendors view on this
though.

Stefan Santesson

> Sent: den 13 oktober 2004 23:51
> To: 'pkix'
> Denis:
> Two examples are very simple: one for direct CRL Issuer and one for
> Indirect
> CRL Issuer.
> 
> Let us make the following assumptions that Stefan was making:
> 
> 1.  You are directory challenged; and
> 2.  You use AIA to develop the path; and
> 3.  You develop the path from the end entity to trust anchor.
> 
> From what I know of MS CAPI, these are reasonable
assumptions/constraints.
> 
> Now the examples.
> 
> Example 1: Direct CRL Issuer
> 
> The certificate trust path is:
> Root --> CA1 --> CA 2, old key --> Denis
> 
> The CRL trust path is:
> Root --> CA1 --> CA 2, new key --> CRL
> 
> (Note: We do not do self-issued certificate since there is no simple,
> secure
> way to check their revocation status).
> 
> Now, with AIA in CRL, finding the CA2, new key certificate is
> straightforward.  How would you find it if you do no deal with SIA et.
al.
> 
> Example 2: Indirect CRL Issuer
> 
> The certificate trust path is:
> Root --> CA1 --> CA 2 --> Denis
> (Note: Denis's certificate points to CRL DP of an indirect CRL issued
by
> CAI.
> 
> The CRL trust path is:
> Root --> CAI --> CRL
> 
> Now, with AIA in CRL, finding the CAI certificate is straightforward.
How
> would you find it if you do no deal with SIA et. al.
> 
> In addition to the need cited above, please note that the extension
> semantics does not change, it does not hinder any interoperability,
and it
> does not break any backward compatibility.  So, what if I wanted to
use
> this
> extension in the CRL.  It does no harm to other relying parties.
> 
> On
> Behalf Of Denis Pinkas
> Sent: Wednesday, October 13, 2004 11:01 AM
> To: Stefan Santesson
> If you are able to provide that example, then it would justify the
need
> >>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).
> >>
> >>>Could we do this amendment to RFC 3280 in its next revision? It
would
> >>>hopefully just be a minor change.
> >>
> >>>>secure solution would be one where the new key is certified by the
> >>>>parent
> >>>
> > CA.
> >
> >>In
> >>
> >>>>certificate in question points to the indirect CRL.  You get that
> >>>>CRL.  The AIA
> >>>
> > in
> >
> >>CRL
> >>
> >>>>issuer certificate, will be clearly identified/available for the
> >>>>validating
> >>>
> >>party
> >>
> >>>>certificates. The Root CA has issued a certificate to CA 2's old
> >>>>key, but not its
> >>>
> > new
> >
> >>>>key.
> >>>>
> >>>>message (see RFC 2633). The CMS message should include all
> >>>>certificates
> >>>
> > issued
> >
> >>to
> >>
> >>>>certificate issued by "Good CA", some examples of URIs that may
> >>>>appear as the
> >>>
> > access
> >
> >>>>attributes of the directory entry of the CA identified in the
issuer
> >>>>field of
> >>>>information queries. If just location of explicit certificate
files
> >>>>validating applications in many cases.
> >>>>
> >>>>Stefan Santesson
> >>>>scenarios that I expect a relying party may encounter:
> >>>>
> >>>>(replacing "New Key" with a different CA), then the set of
> >>>>certificates pointed
> >>>
> > to
> >
> >>by
> >>
> >>>>reverse direction and using the SIA extension, but that may not be
> >>>>the most convenient solution.
> >>>>

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 22 Oct 2004 16:16:01 +0200

This is a repost of the message sent to the list on October 20.
This message was too long and thus has not been broadcasted to the list.

Since Stefan was copied, he got the message and has already provided one 
answer to it.

=========================================================================

Stefan,

[Stefan]

To save you from excessive discussions on a topic you don't really care
about, I concentrate on the one major problem with SIA that you missed
my point on:

1) How can the RP know what certificate's SIA it would use to find
these CRL signer cert?

You just picked the right certificate in my example since I gave that
information in the example. But the RP don't know that path, it only knows 
the path of the EE cert and the name of the CRL issuer!

[Denis]

This is sufficient to find out the right certificate once you know
where the CA places the certificates that it has issued.

[Stefan]

So.. This is NOT the point.

I'll try to explain. Take again an example.

The following is known to the RP:
1) Cert path:  EE_Cert -> CA_1 -> Root_CA_1
2) CRL issued by CRL_Issuer_B

This is NOT known to the RP.
CRL path: CRL -> CRL_Issuer_B -> Intermediary_CA_X - Root_CA_Y

[Denis]

I do not agree with that case.

The question is "who can nominate a CRL issuer ?".

A given CA_X can issue a certificate to CA_Y either allowing it to :

  - only issue certificates (keyCertSign bit set),
  - or both issue certificates and CRLs (cRLSign bit set also set).

In the former case, the CA_X will nominate one or more CRL Issuers, and CA_Y 
will need to contract with one (or more) of them.

Going back to the example above this means that CRL_Issuer_B must have a 
certificate from CA_1. It cannot have a certificate from Intermediary_CA_X, 
unless specific and different relationships would apply to CRL Issuers and 
such details have never been detailed in RFC 3280 (some proprietary models 
have adopted some very specific rules, but they are not covered by RFC 3280).

This discussion highlights the fact that the determination of the CRL Issuer 
is not precise enough in RC 3280 and due to this lack of precision, it seems 
that some people are make their own interpretation, which will lead to a 
lack of interoperability.

RFC 3280 states on page 48:

    Whenever the CRL issuer is not the CA
    that issued the certificates, the CRL is referred to as an indirect
    CRL.

"CRL issuer" is defined as "an optional system to which a CA delegates the 
             publication of certificate revocation lists";

This is vague. How is the delegation really performed from a RP point of view ?

RFC 3280 States:

    If the certificate issuer is not the CRL
    issuer, then the cRLIssuer field MUST be present and contain the Name
    of the CRL issuer.

A name is ambiguous unless it relates to some CA, whose name can also be 
trusted up to a root key. The question is thus who can issue a certificate 
for that name ? RFC 3280 does not tell.

Section 6.3 from RFC 3280 states:

6.3.3  CRL Processing

    This algorithm begins by assuming the certificate is not revoked.
    The algorithm checks one or more CRLs until either the certificate
    status is determined to be revoked or sufficient CRLs have been
    checked to cover all reason codes.

    (...)

       (1)  If the DP includes cRLIssuer, then verify that the issuer
       field in the complete CRL matches cRLIssuer in the DP and that
       the complete CRL contains an issuing distribution point
       extension with the indrectCRL boolean asserted.

The text does not say explicitly how the match is obtained.

 From the above explanations, I am considering the case where a given CA_X 
has issued a certificate to CA_Y either allowing it to :

  - only issue certificates (keyCertSign bit set),
  - or both issue certificates and CRLs (cRLSign bit set also set).

This means that the CA which has nominated CA_Y is the only one allowed to 
nominate CRL Issuers that CA_Y can use. Any other case would imply a model 
that is not described (and thus not supported) in RFC 3280.

So the discussion is now taking quite a new dimension.

Denis

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 27 Oct 2004 15:25:48 +0200 (MEST)

There is also the AuthorityKeyIdentifier extension in a CRL.

---

From: [email-masked]
Date: Wed, 27 Oct 2004 16:35:39 +0200

Peter,

with issuerSerial in the AKI extension you only identify the certificate to
verify the signature of e. g. the CRL. But, as far as I understood the
discussion, the question is where can I find this certificate.

Regards

Thomas

> -----Ursprüngliche Nachricht-----
> Von: Peter Sylvester [mailto:[email-masked]]
> Gesendet: Mittwoch, 27. Oktober 2004 16:19
> An: [email-masked]; [email-masked]
> Cc: [email-masked]
> Betreff: RE: Signer certificate discovery for CRLs
> 
> 
> 
> 
> SMIME seems to work with an information that just has
> 'issuername+serialnumber' to point to th certificate
> that is used for signing. 
> 
> A similar information can be made available in the
> AuthorityKeyIdentifier, i.e. point to a cert that
> has a key that has signed the cert or crl. 
> 
> What is missing here:
> 
> -  A generic way to map this value to some repository request? 
> -  To indicate an explicit mapping (at a near place)?  
> 
> I also do not really remember that the id-ad-caRepository
> SIA extension had been actually proposed in 2000, it simply
> appeared in part1-new-03. 
> 
> 
>

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 27 Oct 2004 16:46:03 +0200 (MEST)

> > -  To indicate an explicit mapping (at a near place)?  

.. i.e. a mapping from URI to URL