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

To: "Denis Pinkas" <Denis.Pinkas@xxxxxxxx>, "Santosh Chokhani" <chokhani@xxxxxxxxxxxx>
Subject: RE: Signer certificate discovery for CRLs
From: "Stefan Santesson" <stefans@xxxxxxxxxxxxx>
Date: Fri, 15 Oct 2004 12:10:13 +0100
Cc: "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: AcSyC2L0BmowgKG9SGKYMovSqsAkiAAmrfgA
Thread-topic: Signer certificate discovery for CRLs
Denis,

Unfortunately I fail to understand your questions, issues and requests.

It would be very useful if you could explain how current mechanisms can
be used in a simple and straightforward manner to discover CRL signer
certificates in ALL the use cases discussed, mainly re-keyed CA and
indirect CRLs.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Denis Pinkas
> Sent: den 14 oktober 2004 17:13
> To: Santosh Chokhani
> Cc: 'pkix'
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Santosh,
> 
> > 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?
> 
> 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
> 
> > That is my point.
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> > Sent: Thursday, October 14, 2004 6:22 AM
> > To: Santosh Chokhani
> > Cc: 'pkix'
> > Subject: Re: Signer certificate discovery for CRLs
> >
> >
> > 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
> >
> >
> >
> >>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: owner-ietf-pkix@xxxxxxxxxxxx
> >>[mailto:owner-ietf-pkix@xxxxxxxxxxxx] 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,
> >>
> >>
> >>>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
> >>>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?cACe
r
> >>>>>t
> >>>>>i
> >>>>
> >>>fi
> >>>
> >>>
> >>>
> >>>>ca
> >>>>
> >>>>
> >>>>
> >>>>>>te
> >>>>>>,crossCertificatePair
> >>>>>
>
>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertif
i
> >>>>>c
> >>>>>a
> >>>>
> >>>te
> >>>
> >>>
> >>>
> >>>>;b
> >>>>
> >>>>
> >>>>
> >>>>>>in
> >>>>>>ary,crossCertificatePair;binary
> >>>>>
>
>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIss
u
> >>>>>e
> >>>>>d
> >>>>
> >>>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: questions about draft-ietf-pkix-certstore-http-08
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