Subject: RE: Signer certificate discovery for CRLs

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 18 Oct 2004 17:53:37 +0100

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
the 
>> 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!

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

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

To find the CRL Issuer cert, the RP need to look in the SIA of
Intermediary_CA_X certificate, right?

But how can the RP do that when it doesn't know the CRL path. THE RP HAS
NO KNOWLEDGE ABOUTH THE FACT THAT Intermediary_CA_X IS THE CA ABOVE THE
CRL SIGNER CERT. In fact the RP has no means to find out, except through
exhaustive search from all its trusted roots.

Here, AIA in the CRL solves the issue, SIA doesn't.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Denis Pinkas
> Sent: den 18 oktober 2004 16:58
> To: Santosh Chokhani; Stefan Santesson
> Cc: 'pkix'
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Santosh and Stefan,
> 
> Now we get to the point that there exists one solution, while the
thread
> started saying that there was no other solution.
> 
> We can now start to discuss the advantages and disadvantages of the
two
> solutions.
> 
> However, we have to provide a fair view.
> 
> For the time being, you have only considered the disadvantages of the
> *current* solution, i.e. using SIA. It would be fair that you also
> consider
> its advantages and that we take the time to have a fair comparison.
> 
> > The SIA can be used to find the certificate, but it leads to the
> exponential
> > growth in the search base in the case of indirect CRL.
> 
> This is an argument about disadvantages. However this argument is
> incorrect:
> there is no exponential grow. A CA nominates an authority either as :
> 
>   1 - "CA issuer + CRL issuer"
>   2 - "CA issuer only", or
>   3 - "CRL Issuer only"
> 
> Once the path is constructed, if every CA certificate includes the SIA
> extension, then this is straightforward.
> 
> > Also, I do not think SIA is that well supported.
> 
> I could say that the new proposal is not "that well supported" but
this
> would be an argument leading nowhere. :-|
> 
> The SIA extension is very useful and we should make our best efforts
so
> that
> it will be more and more supported. Providing "yet another way" is not
> going
> to lead in that direction. :-(
> 
> > Thus, we need to consider the commercial realities and permit a
simple
> and
> > elegant approach of using AIA to prime the pump (so to speak) to
start
> the
> > CRL signer path development.
> 
> SIA was not present in RFC 2459. It has been introduced in RFC 3280
and
> this
> is a good point. It should be generalized in order to support
> interoperability. Going down from trust points to leaf certificates
allow
> to
> cover any case.
> 
> The answers to Stefan follow:
> 
> > -----Original Message-----
> > From: Stefan Santesson [mailto:[email-masked]]
> > Sent: Monday, October 18, 2004 8:19 AM
> > To: Denis Pinkas
> > Cc: Santosh Chokhani; pkix
> > Subject: RE: Signer certificate discovery for CRLs
> >
> >
> > Thanks Denis,
> >
> > I now finally understand your SIA alternative.
> >
> > There are some major problems with it though.
> 
> > 1) How can the RP know what certificate's SIA it would use to find
the
> 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!
> 
> This is sufficient to find out the right certificate once you know
where
> the
> CA places the certificates that it has issued.
> 
> > 2) And even if RP knew the path beforehand, finding THE one CRL
signer
> > certificate from a CRL AIA is much more direct and efficient than
> finding
> > among all issued certificates from a CA the 1 out of x issued
> certificates
> > that is the CRL Issuer cert.
> 
> Usually a CA issues a small number of CA certificates and CRL
> certificates.
> So this is not a problem.
> 
> > 3) Using SIA in the examples requires available directories and
> directory
> > enabled clients. How do you solve the problem if either of these is
not
> > available?
> 
> It could work as well with HTTP using the recent draft that has been
> proposed.
> 
> > Do you seriously suggest that use of SIA is a better and more
effective
> way
> > to address this problem or are you just pointing out the fact that
there
> are
> > SOME cases where use of SIA may work in theory?
> 
> I rather believe that your question was:
> 
> "Do you suggest that use of SIA is a better and more effective way to
> address this problem or are you just pointing out the fact that there
are
> SOME cases where use of SIA may work ?
> 
> SIA is certainly better and shoud be generalized to ease path
contruction,
> not only for CRL issuers but also for CAs.
> 
> SIA may work in ALL cases, unless you provide an example where it
cannot.
> 
> Now I have spent quite a lot of time on that topic (on which I am
> personally
> NOT interested), but since I have been asked by the Security Area
Director
> to provide details I needed to respond.
> 
> I will not be able to sustain the same level of discussions in the
next
> coming days. In particular, I will not be in my office tomorrow. So
you
> have
> plenty of time to consider pros and cons for both approaches and do
not
> take
> silence as approval.
> 
> Denis
> 
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> >
> >
> >>-----Original Message-----
> >>From: Denis Pinkas [mailto:[email-masked]]
> >>Sent: den 18 oktober 2004 12:28
> >>To: Stefan Santesson
> >>Cc: Santosh Chokhani; pkix
> >>Subject: Re: Signer certificate discovery for CRLs
> >>
> >>Stefan,
> >>
> >>
> >>>Denis,
> >>
> >>>If I get you right you mean that one can always successfully use
AIA
> >>
> > and
> >
> >>>SIA in certs to solve discovery of CRL signer cert.
> >>>Others on this list (me included) don't understand how. It would
> >>>therefore be useful if you told us.
> >>>
> >>>I'll try to explain the problem from my perspective one more time.
> >>
> >>Thanks.
> >>
> >>
> >>>Note: "->" in these examples means "issued by"
> >>
> >>Fine.
> >>
> >>
> >>>Case 1 - indirect CRL:
> >>>
> >>>Cert path is:  EE_Cert -> CA_1 -> Root-CA
> >>>CRL path for EE_Cert is:  CRL -> CRL_Issuer_B -> Root-CA
> >>
> >>This means Root-CA has nominated CA_1 and a CRL_Issuer_B and that
CA_1
> >
> > has
> >
> >>chosen to use CRL_Issuer_B for revocation checking for some
> >
> > certificates.
> >
> >>>Scenario:
> >>>Relying party has access to the cert path, discovers the CRL
through
> >>
> > CDP
> >
> >>>in EE_Cert.
> >>
> >>If there is no attack on the objects stored at the CRL DP, the CRL
> >
> > Issuer
> >
> >>from that CRL is CRL_Issuer_B. Now the relying party needs to get
the
> >>certificate isued by Root-CA for CRL_Issuer_B. If Root-CA has
included
> >
> > a
> >
> >>SIA
> >>extension in his self-signed certificate, then using that extension
> >
> > allows
> >
> >>to get the CRL_Issuer_B certificate issued by the Root-CA.
> >>
> >> > The RP searches the location specified in SIA through
> >>
> >>>id-ad-caRepository in the CA_1 cert but finds nothing useful since
> >>>revocation is subordinated to another entity (CRL_Issuer_B)
> >>
> >>Correct, but looking in Root-CA allows to find something useful, if
> >
> > the
> >
> >>self-signed certificate includes a SIA extension.
> >>
> >>
> >>>In this case, the problem could be solved if an AIA in the CRL
> >>
> > indicated
> >
> >>>the access location of the CRL Issuer cert.
> >>
> >>This would be an *alternative* way.
> >>
> >>
> >>>Case 2 - re-keyed CA.
> >>>
> >>>Cert path is:  EE_Cert -> CA_1(old key) -> Root-CA
> >>>CRL path for EE_Cert is:  CRL -> CA_1(new key) -> Root-CA
> >>
> >>This means that the EE_Cert chain has been created with CA_1(old
key)
> >
> > and
> >
> >>that the CRL issuer that was originaly used when the EE_Cert was
> >
> > created
> >
> >>has
> >>been changed and a new CRL Issuer got a certificate under CA_1(new
> >
> > key)
> >
> >>and
> >>is now the legitimate CRL issuer for the CRL DP originally
mentionned
> >
> > in
> >
> >>the
> >>EE_Cert.
> >>
> >>
> >>>The 2 CA_1 certificates above (old key and new key) are issued to
> >>>different subject keys belonging to the same CA (same name). The
> >>>cert CA_1(old key) was issued before creation of cert CA_1(new
> >>
> > key)
> >
> >>>and have thus no reference to CA_1(new key) in its SIA
> >>>
> >>>Scenario:
> >>>RP discovers the CRL for the EE_Cert through the CDP but doesn't
> >>
> > possess
> >
> >>>the CRL issuer cert. The RP client searches the SIA of the CA_1(old
> >>
> > key)
> >
> >>>but finds no direct reference to the CRL signer cert. Since the RP
> >>>client has no access to a directory where the CRL signer cert could
> >>
> > be
> >
> >>>found through directory lookup, cert validation fails.
> >>
> >>Correct, but looking in Root-CA allows to find something useful, if
> >
> > the
> >
> >>self-signed certificate includes a SIA extension.
> >>
> >>
> >>>In this scenario the problem could be solved through an AIA in the
> >>
> > CRL.
> >
> >>This would be an *alternative* way.
> >>
> >>Denis
> >>
> >>
> >>>
> >>>
> >>>Stefan Santesson
> >>>Microsoft Security Center of Excellence (SCOE)
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Denis Pinkas [mailto:[email-masked]]
> >>>>Sent: den 15 oktober 2004 17:30
> >>>>To: Stefan Santesson
> >>>>Cc: Santosh Chokhani; pkix
> >>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>
> >>>>Stefan,
> >>>>
> >>>>
> >>>>
> >>>>>Denis,
> >>>>
> >>>>>Unfortunately I fail to understand your questions, issues and
> >>>>
> >>>requests.
> >>>
> >>>
> >>>>The sentence below demonstrates that you understand the issue.
> >>>>
> >>>>
> >>>>
> >>>>>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.
> >>>>
> >>>>You are also reversing the question. Using your terms, my question
> >>>
> >>>would
> >>>
> >>>
> >>>>be:
> >>>>
> >>>>"It would be very useful if you could explain how current
mechanisms
> >>>>CANNOT be used in a simple and straightforward manner to discover
> >>>>CRL
> >>>
> > signer
> >
> >>>>certificates in ONE or MORE the use cases discussed, mainly
re-keyed
> >>>
> >>>CA
> >>>
> >>>
> >>>>and
> >>>>indirect CRLs."
> >>>>
> >>>>Denis
> >>>>
> >>>>
> >>>>
> >>>>>Stefan Santesson
> >>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: [email-masked]
> >>>>>
> >>>>>[mailto:[email-masked]]
> >>>>>
> >>>>>
> >>>>>
> >>>>>>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:[email-masked]]
> >>>>>>>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: [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,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>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:[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?c
A
> >>>>>>>
> > C
> >
> >>>e
> >>>
> >>>
> >>>>>r
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>t
> >>>>>>>>>>>i
> >>>>>>>>>>
> >>>>>>>>>fi
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>ca
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>te
> >>>>>>>>>>>>,crossCertificatePair
> >>>>>>>>>>>
>
>>>>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACer
t
> >>>>>>>
> > i
> >
> >>>f
> >>>
> >>>
> >>>>>i
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>c
> >>>>>>>>>>>a
> >>>>>>>>>>
> >>>>>>>>>te
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>;b
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>in
> >>>>>>>>>>>>ary,crossCertificatePair;binary
> >>>>>>>>>>>
>
>>>>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certs
I
> >>>>>>>
> > s
> >
> >>>s
> >>>
> >>>
> >>>>>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:[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: Steve Hanna <[email-masked]>
Date: Mon, 18 Oct 2004 13:59:54 -0400

This is a classic case of building cert paths forward
(from EE to trust anchor) vs. building reverse (from
trust anchor to EE). In a hierarchy, building forward
is usually best. In a more complex topology, building
reverse or meeting in the middle can be better. See
our paper in the NDSS 2001 proceedings.

The first step in a forward build is to find certificates
that have the EE as the subject. Then you build from there
toward the TA. AIA helps with that. The first step in a
reverse build is to find certificates that have the TA as
the issuer. Then you build toward the EE. SIA helps with that.
So both SIA and AIA are useful.

Given that most PKIs are hierarchies today, building
reverse will often be most useful. That's why you
should put an AIA in CRLs. It helps find the CRL issuer's
certificate(s). Even in complex topologies, it will often
be useful to have the AIA (to meet in the middle) and
I can't see how it would hurt.

Thanks,

Steve