Subject: RE: Signer certificate discovery for CRLs

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

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:[email-masked]]
> 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: [email-masked]
[mailto:[email-masked]]
> >>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: [email-masked]
[mailto:[email-masked]]
> >>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:[email-masked]]
> >>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:[email-masked]]
> >>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)
> >>
> >>
> >
> >
> >
>

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 13 Oct 2004 17:01:10 +0200

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 13 Oct 2004 17:51:21 -0400

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.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Wednesday, October 13, 2004 11:01 AM
To: Stefan Santesson
Cc: Santosh Chokhani; pkix
Subject: Re: Signer certificate discovery for CRLs

Stefan,

Denis

>>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
>>>
> the
> 
>>>>information queries. If just location of explicit certificate files 
>>>>are
>>>
> identified
> 
>>>>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: Thu, 14 Oct 2004 12:21:37 +0200

Santosh,

You misread my request. I said:

"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."

Maybe I would have needed to be clearer and say :

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

The examples you provide below do not fulfil this request.

The assumption is that there exists a path to be tested for revocation 
checking (and that it does not matter to know which way it has been 
constructed).

I am not saying that using AIA in CRL might not be useful, but I am still 
lacking the demonstration that there would be no other way.

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 14 Oct 2004 09:10:09 -0400

Denis:

With the three assumptions/constraints I provided, how would you locate the
CRL issuer certificate for the two examples using 3280 extensions and
without putting AIA in the CRL?

That is my point.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, October 14, 2004 6:22 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Signer certificate discovery for CRLs

Santosh,

Denis

> Denis:
> 
> Two examples are very simple: one for direct CRL Issuer and one for 
> Indirect CRL Issuer.
> 
> (Note: We do not do self-issued certificate since there is no simple, 
> secure way to check their revocation status).
> 
> (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.
> 
> 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.
> 
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
>>>>Could we do this amendment to RFC 3280 in its next revision? It 
>>>>would hopefully just be a minor change.
>>>
>>>We usually end-up with a "minor change" in an extension without 
>>>saying cleary how and when it shall/should be used.
>>>
>>>>>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
>>>
>>>
>>>>>either the CRL issuer certificate itself, or the location of the 
>>>>>CRL issuer certificate, will be clearly identified/available for 
>>>>>the validating
>>>>
>>>party
>>>
>>>
>>>>>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.
>>>>>
>>>>>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.
>>>>>
>>>>>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
>>>
>>>
>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACer
>>>>t
>>>>i
>>>
>>fi
>>
>>
>>>ca
>>>
>>>
>>>>>te
>>>>>,crossCertificatePair
>>>>
>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertifi
>>>>c
>>>>a
>>>
>>te
>>
>>
>>>;b
>>>
>>>
>>>>>in
>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssu
>>>>e
>>>>d
>>>
>>To
>>
>>
>>>Go
>>>
>>>
>>>>>od
>>>>>CA.p7c
>>>>>attributes of the directory entry of the CA identified in the 
>>>>>issuer field of
>>>>
>>the
>>
>>

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 14 Oct 2004 17:12:38 +0200

Santosh,

> without putting AIA in the CRL?

As far as I understand, the three assumptions are:

1.  You are directory challenged; and
     [I do not understand what this means]
2.  You use AIA to develop the path; and
     [It does not matter]
3.  You develop the path from the end entity to trust anchor
     [Could also be the contrary].

If this is not correct, thus please correct.

Then my request is: "using ANY OF the current extensions that are defined in 
RFC 3280", which includes SIA.

In your explanations  you said :
"if you do no deal with SIA et. al"

This last assumption is neither part of the three assumptions and does not 
conform to my request.

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 14 Oct 2004 16:37:07 -0400

Denis:

By directory challenged, I mean you do not use LDAP client or DAP or DSP to
query for certificate.

The basic point is that if AIA or local store are the primary ways to obtain
certificates, since the CRL issuer certificate is not in any payload, AIA in
CRL helps obtain that certificate and start the path development process for
the CRL certification path.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, October 14, 2004 11:13 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Signer certificate discovery for CRLs

Santosh,

> With the three assumptions/constraints I provided, how would you 
> locate the CRL issuer certificate for the two examples using 3280 
> extensions and without putting AIA in the CRL?

Denis

> "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."
> 
> "For the time being, I would like that you provide an example where, 
> when using ANY OF the current extensions that are defined in RFC 3280, 
> it will NOT be possible to locate a CRL Issuer certificate."
> 
>>>>I
>>>>>I conclude that we are in complete and total agreement. The 
>>>>>question is how to go about this.
>>>>

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 15 Oct 2004 08:45:27 +0200

Santosh,

You are still trying to avoid to respond to my request. So my temporary 
conclusion is that you have NOT demonstrated that your proposal is really 
necessary and it is thus "yet-another-method".

> By directory challenged, I mean you do not use LDAP client or DAP or DSP to

RFC 3280. Page 46:

    The accessLocation
    field is defined as a GeneralName, which can take several forms.
    Where the information is available via http, ftp, or ldap,
    accessLocation MUST be a uniformResourceIdentifier.  Where the
    information is available via the Directory Access Protocol (DAP),
    accessLocation MUST be a directoryName.

It is thus perfectly allowed and valid to use DAP or ldap.

> certificates, 

No. Local store is of no use. AIA is one possibility, while the other one is 
SIA.

> since the CRL issuer certificate is not in any payload, AIA in

No. You can use AIA or SIA in CA certificates, or AIA in leaf certificate.

Denis

>>>From what I know of MS CAPI, these are reasonable
>>
>>>assumptions/constraints.
>>>
>>>Now the examples.
>>>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 15 Oct 2004 05:37:38 -0400

Denis:

1.  This is a good mechanism to start building the path for CRL signer.  If
you have a better alternative for directory challenged environments, please
tell us.  Absent you showing that there is a mechanism for directory
challenged environments that is as simple and that works, we can not have a
fruitful dialog.

2.  Adding AIA to CRL does not impact interoperability, security or backward
compatibility adversely.

As to your argument, we could have used it few years back and not added AIA
to the certificates either.

-----Original Message-----
From: Denis Pinks [mailto:[email-masked]] 
Sent: Friday, October 15, 2004 2:45 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Signer certificate discovery for CRLs

Santosh,

> By directory challenged, I mean you do not use LDAP client or DAP or
> DSP to query for certificate.

RFC 3280. Page 46:

    The accessLocation

> The basic point is that if AIA or local store are the primary ways to
> obtain certificates,

SIA.

> since the CRL issuer certificate is not in any payload, AIA in CRL
> helps obtain that certificate and start the path development process 
> for the CRL certification path.

Denis

>>I am not saying that using AIA in CRL might not be useful, but I am 
>>still lacking the demonstration that there would be no other way.
>>
>>Denis
>>
>>
>>
>>
>>>Denis:
>>>
>>>For the time being, I would like that you provide an example where,
>>>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 believe that you are misinterpreting the figures.  They really 
>>>>>>>do represent three different cases, not three different 
>>>>>>>certification
>>>>>>
>>>>paths
>>>>
>>>>
>>>>
>>>>
>>>>>>>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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cAC
>>>>>>e
>>>>>>r
>>>>>>t
>>>>>>i
>>>>>
>>>>fi
>>>>
>>>>
>>>>
>>>>
>>>>>ca
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>te
>>>>>>>,crossCertificatePair
>>>>>>
>>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACerti
>>>>>>f
>>>>>>i
>>>>>>c
>>>>>>a
>>>>>
>>>>te
>>>>
>>>>
>>>>
>>>>
>>>>>;b
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>in
>>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIs
>>>>>>s
>>>>>>u
>>>>>>e
>>>>>>d
>>>>>
>>>>To
>>>>
>>>>
>>>>
>>>>
>>>>>Go
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>od
>>>>>>>CA.p7c
>>>>>>>certificates issued to the CA identified in the issuer field of 
>>>>>>>the certificate.
>>>>>>>
>>>>>>>information queries. If just location of explicit certificate 
>>>>>>>files are
>>>>>>
>>>>identified
>>>>
>>>>
>>>>
>>>>
>>>>>>>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)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>construction of that certification path.  (Yes, there are
>>>>>>>circular dependency issues in figure 2, but that is another 
>>>>>>>issue.)
>>>>>>>
>>>>>>>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.
>>>>>>>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 15 Oct 2004 05:38:07 -0400

Denis:

-----Original Message-----
From: Denis Pinks [mailto:[email-masked]] 
Sent: Friday, October 15, 2004 2:45 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Signer certificate discovery for CRLs

Santosh,

RFC 3280. Page 46:

    The accessLocation

SIA.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 15 Oct 2004 13:59:19 +0200

Santosh,

> Denis:
> 
> 1.  This is a good mechanism to start building the path for CRL signer. 

"There are none so deaf as those who will not hear".

This is not the point.

> If you have a better alternative for directory challenged environments, 

Your definition of "directory challenged environment" is:
"not use LDAP client or DAP or DSP to query for certificate"

I still wonder why you are making this restriction since LDAP is one of the 
only two methods that are supported in RFC 3280 to fetch certificates.

If I understand you correctly, for whatever reason (which one ?), you only 
want to use HTTP. Then I would think the solution would be to use the 
following draft: draft-ietf-pkix-certstore-http-08 and make sure that it 
will be usable with the current AIA and SIA extensions to fetch CRL issuers 
certificates.

> challenged environments that is as simple and that works, we can not have a

Please, do not reverse the question.

> 2.  Adding AIA to CRL does not impact interoperability, security or backward

It adds complexity with "still-another-extension" in CRLs and still another 
method for revocation checking.

> to the certificates either.

  ... but you didn't. This last argument does not make sense.

Denis

---

From: Russ Housley <[email-masked]>
Date: Fri, 15 Oct 2004 14:50:17 -0400

Denis:

>I still wonder why you are making this restriction since LDAP is one of 
>the only two methods that are supported in RFC 3280 to fetch certificates.

This is simply not true.  When a GeneralName is used, the URI schemes ftp, 
http, and ldap are explicitly discussed for fetching certificates.  When a 
GeneralName is rfc822name, email is discussed.  And, the mailtoURI scheme 
is discussed for fetching CRLs.

The Directory Access Protocol (DAP) is also discussed.

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 15 Oct 2004 14:55:14 -0400

Denis:

>will be usable with the current AIA and SIA extensions to fetch CRL 
>issuers certificates.

RFC 3280 specifies the inclusion of AIA and SIA in certificates.  It is not 
specified for the inclusion in CRLs.  I believe that the proposal is to 
write a specification for using AIA in CRLs.

The problem has been stated, and a proposed solution has been stated.  If 
you do not think the problem really exists, please explain why this is the 
case.  If you have another way to solve the stated problem, please share it.

Russ

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 15 Oct 2004 16:52:24 -0400

Denis:

See my responses in-line in [SC].

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Friday, October 15, 2004 7:59 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Signer certificate discovery for CRLs

Santosh,

This is not the point.

[SC: Please tell me how you would find the CRL signer path.]

[It is common for some of the commercial environments to use local
certificate stores and caches and AIA and not use directories.  I am trying
to help meet their need.]

[The basic point is not the transport protocol. The point is that the
relying party does not interface to a directory or repository.  That is why
certstore I-D is not applicable.]

> challenged environments that is as simple and that works, we can not 
> have a fruitful dialog.

[We have defined a mechanism that has all the properties IETF espouses.  If
you have an alternative state so.]

> 2.  Adding AIA to CRL does not impact interoperability, security or
> backward compatibility adversely.

[No, it does not.  If the client process AIA, it can also process this to
start the CRL signer path building.  It is optional, just like AIA in
certificates.  Compliant clients need not use this mechanism if they can
find the CRL signer certificate using other means]

> As to your argument, we could have used it few years back and not
> added AIA to the certificates either.

[It is basically saying "if the AIA can be offered an alternative to obtain
CA certificate, it can also be offered to obtain the CRL signer
certificate"]

Denis

>>This last assumption is neither part of the three assumptions and does
>>not conform to my request.
>>
>>Denis
>>
>>
>>
>>>That is my point.
>>>
>>>when using ANY OF the current extensions that are defined in RFC 
>>>3280, it will NOT be possible to locate a CRL Issuer certificate."
>>>
>>>The assumption is that there exists a path to be tested for
>>>revocation checking (and that it does not matter to know which way it 
>>>has been constructed).
>>>
>>>>(Note: We do not do self-issued certificate since there is no
>>>>simple, secure way to check their revocation status).
>>>>
>>>>(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
>>>>>>>>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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>certificate in question points to the indirect CRL.  You get 
>>>>>>>>that CRL.  The AIA
>>>>>>>
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>CRL
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>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.
>>>>>>>>
>>>>>>>>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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>would present a very clear and uncomplicated logic to
>>>>>>>>certificate validating applications in many cases.
>>>>>>>>
>>>>>>>>Stefan Santesson
>>>>>>>>is not an indirect CRL.  Attached is a drawing of the three
>>>>>>>>basic scenarios that I expect a relying party may encounter:
>>>>>>>>
>>>>>>>>obtain the certificates pointed to by the AIA extension in the
>>>>>>>>EE certificate.  This AIA extension will point to a location 
>>>>>>>>containing
>>>>>>>
>>>>>all
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 18 Oct 2004 10:04:28 +0200

Russ,

>> If I understand you correctly, for whatever reason (which one ?), you 
>> only want to use HTTP. Then I would think the solution would be to use 
>> the following draft: draft-ietf-pkix-certstore-http-08 and make sure 
>> that it will be usable with the current AIA and SIA extensions to 
>> fetch CRL issuers certificates.

> RFC 3280 specifies the inclusion of AIA and SIA in certificates.  It is 
> not specified for the inclusion in CRLs.  I believe that the proposal is 
> to write a specification for using AIA in CRLs.

> The problem has been stated, and a proposed solution has been stated.

> If you do not think the problem really exists, please explain why this 
> is the case.  If you have another way to solve the stated problem, 
> please share it.

One solution to the problem is to place an SIA extension in root 
certificates (i.e. self-signed certificates trusted under a validation 
policy) and in every CA certificate. This is also a very useful way to build 
a certification path "going down".

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 18 Oct 2004 10:04:33 +0200

Russ,

> Denis:
> 
>> I still wonder why you are making this restriction since LDAP is one 
>> of the only two methods that are supported in RFC 3280 to fetch 
>> certificates.
> 
> 
> This is simply not true.  When a GeneralName is used, the URI schemes 
> ftp, http, and ldap are explicitly discussed for fetching certificates.  
> When a GeneralName is rfc822name, email is discussed.  And, the 
> mailtoURI scheme is discussed for fetching CRLs.
> 

OK. DAP and LDAP.

Denis