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

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 24 Feb 2005 06:57:58 -0000

Tom,

I'm sorry. I have read your e-mail repeatedly but failed to understand
what you try to say.

Example:
>       The subject certificate has an AIA extension containing a URI
for a
> CRL, but no descriptor for a CA certificate.

This is not what we are talking about. AIA in a cert does not point to a
CRL. We are discussing AIA in a CRL pointing to the CRL issuer cert.

Can you clarify your issues?

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]]
> Sent: den 23 februari 2005 13:15
> To: Stefan Santesson
> Cc: Denis Pinkas; Russ Housley; pkix
> Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> 
>       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;
> (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: Fri, 25 Feb 2005 08:39:28 -0500

Stefan:

        The "certstore" draft (currently 
draft-ietf-pkix-certstore-http-08) defines an access descriptor for CRL's 
(id-ad-http-crls), which would go in the AIA or SIA extension.  If the 
subject certificate's AIA extension also contained a similar descriptor 
for the CA certificate (using id-ad-http-certs), and that descriptor used 
the Name or SHash attribute, you would be able to retrieve the CRL signing 
certificate for CRL's which weren't indirect CRL's.  However, if no such 
descriptor existed, or if one which did exist used the SKIDHash attribute, 
you would not be able to retrieve the CRL signing certificate without 
using AIA in the CRL.  IMO this is a valid use case in which an AIA is 
needed within the CRL.
        A Distribution Point name containing a URI works similarly.  If 
the RP is handed the subject and issuer certificates by the signer, it can 
use the DPName to retrieve the CRL, but it cannot necessarily get the CRL 
signing certificate unless there is an AIA in the CRL. 

                Tom Gindin

"Stefan Santesson" <[email-masked]>
02/24/2005 01:57 AM
 
        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     "Denis Pinkas" <[email-masked]>, "Russ Housley" 
<[email-masked]>, "pkix" <[email-masked]>
        Subject:        RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt

Tom,

for a

Stefan Santesson
 
certainly
think
for a
URI
information,
without
than
cached?
Distribution
it
Pinkas"
Housley"
issuer
location
include
without
are
but
unless
to
and
issuer
tell
or
the
deployed
or