Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 15 Feb 2005 18:29:39 -0000

Comments in-line;
(Some stuff deleted to keep volume down)

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> 
> What about the following sentences picked from the document:
> 
>     Standardized methods of finding the certificate of the CRL issuer
are
>     currently available either though an accessible directory location
or
>     through use of the Subject Information Access extension in
>     intermediary CA certificates.  These methods are however not
>     generally applicable, and they do not provide a generic solution
to
>     the problem.
> 
> This is true only if indirect CRLs are being used, but the wording
> "indirect
> CRL" is absent from these lines.

[Stefan] Even if it was true ONLY for indirect CRL's, text would be
correct. But even more, this is NOT ONLY true for indirect CRL's. For
example, it is also true if your current CA infrastructure and its CA
certificates (which may be valid for another 5-20 years), don't include
a SIA extension. AIA in CRL's can be added to the infrastructure without
reissuing CA certificates, SIA can't. This is just 1 example. There are
more.

> 
> > It is an optional mechanism to be used
> > by those who whish to use it to find the CRL signer cert.
> 
>   ... which is really motivated when indirect CRLs are being used, but
> otherwise is not and the draft does not say it.
> 

[Stefan] Because it is not useful only for indirect CRLs.

> > I think the motivation for allowing this extension in CRLs is
> > sufficiently stated in the document.
> 
> It is not. In addition, adding an extension does not make sense unless
you
> tell how it should be used.
> 

[Stefan] What is unclear for you?

> > Nothing you suggest is changing the
> > technical outline of the specified solution.
> 
> In this case, the processing of this new extension may be explained
and
> this
> is not the case at this time.
> 

[Stefan] What is missing?

<stuff deleted>
> 
> >> The problem is that neither the abstract nor the introduction of
this
> >> draft is limiting the scope to indirect CRLs only.
> 
> > [Stefan] That is because the scope of AIA in CRLs is not limited to
> > indirect CRLs.
> 
>    .. but this extension does not add anything, if SIA used.
> 

[Stefan] Yes it does. It offers direct lookup of the CRL issuer cert and
indicates that the CRL Issuer certificate actually IS available for
download, while SIA only offers pointer to location where the CRL issuer
cert MAY be found among other unrelated certificates, 1) if it is
present and 2) if the client is capable of finding it.

> 
> > [Stefan] This is incorrect. The data in each DP of the CDP will tell
the
> > RP whether the DP points to an indirect CRL.
> 
>     DistributionPoint ::= SEQUENCE {
>          distributionPoint       [0]     DistributionPointName
OPTIONAL,
>          reasons                 [1]     ReasonFlags OPTIONAL,
>          cRLIssuer               [2]     GeneralNames OPTIONAL }
> 
>     DistributionPointName ::= CHOICE {
>          fullName                [0]     GeneralNames,
>          nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
> 
> Which field are you talking about ?

[Stefan] cRLIssuer

> 
> >> The draft should thus address the two scenarios (i.e. an IDP is or
is
> >> not present) and for direct CRLs there is no "superiority" of the
new
> >> extension.
> 
> > [Stefan] I don't see the point with that. The use of the AIA
extension
> > in CRL is not different for indirect or direct CRLs.
> 
> With direct CRLs, there does not need to be any AIA extension, if the
SIA
> extension in CA certificates is present. This is not said and should
be
> said.

[Stefan] I don't see any purpose in saying that. This standard simply
recognizes the usefulness of allowing the already existing and deployed
AIA extension logic, not only in certificates, but also in CRLs. It is
not authoritative with regard to where and when this solution should or
should not be deployed.

The profile recognizes that there are other ways to build CRL paths.
This should be enough.

---

From: Tom Gindin <[email-masked]>
Date: Wed, 23 Feb 2005 07:15:10 -0500

Stefan:

      I take a position between you and Denis here.  There are certainly
use cases for this extension other than indirect CRL.  However, I think the
other use cases are rarer than indirect CRL.  Here are the ones I see:
      The subject certificate has an AIA extension containing a URI for a
CRL, but no descriptor for a CA certificate.
      The subject certificate has a distribution point containing a URI
Distribution Point Name, and no AIA extension.
      In the case where the subject certificate has no CRL information,
this extension appears to be useful only if the CRL can be found without
assistance but the signing certificate cannot.  In what cases other than
CRL caching and indirect CRL does that frequently occur in your experience?
In the case of CRL caching, why isn't the signing certificate also cached?
      The case where the subject certificate contains a DN Distribution
Point Name seems to work out in a very similar way to the case where it has
no CRL information.

            Tom Gindin

                      "Stefan                                                                                                          
                      Santesson"               To:       "Denis Pinkas" <[email-masked]>                                        
                      <stefans@microsof        cc:       "Russ Housley" <[email-masked]>, "pkix" <[email-masked]>             
                      t.com>                   Subject:  RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt                                  
                      Sent by:                                                                                                         
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      

                      02/15/2005 01:29                                                                                                 
                      PM                                                                                                               

Comments in-line;

Stefan Santesson

are
or
to

you

and

<stuff deleted>
this

the
OPTIONAL,

[Stefan] cRLIssuer

is
new
extension
SIA
be

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 24 Feb 2005 15:58:38 +0100

Stefan,

This is a waiting response. No response from me does not mean that I agree 
with your arguments.

Since SCVP-17 was issued, I simply spent the time I had to comment on 
SCVP-17 and thus I have no more time available for this draft for the moment.

In general, I can say that, for the time being, we are still not in agreement.

Denis