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

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 7 Feb 2005 14:56:27 -0000

Denis,

It is obvious that you base your objections on the assumption that a CRL
issuer cert MUST be issued by the CA issuing the validated subject cert.

But you also admit that this is what you think the stand should say but
do not say (at least not explicitly).

Quote from your text: "This is not explicitly stated in RFC 3280 for CRL
issuers, but it is for OCSP responders"

I guess it will be useless to get into details before we have sorted out
this major cause of disagreement. But since even you admit that there is
no such requirement in RFC 3280 (nor X.509), I'm not sure what there is
to discuss.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: den 7 februari 2005 06:19
> To: Stefan Santesson; Russ Housley
> Cc: pkix
> Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> 
> Comments on <draft-ietf-pkix-crlaia-00.txt>
> 
> 1. The title and the scope of the document are not in accordance with
the
> content of the document. The document is not simply defining a new
> extension
> that may help to find out a CRL, but is defining a new way to verify
that
> a
> CRL is correct.
> 
> 
> 2. The new way to verify that a CRL is correct is not aligned with the
> current documents.
> 
> According to RFC 3280, page 7, a CRL issuer is an "optional system to
> which
> a CA delegates the publication of certificate revocation lists".
> 
> This means that the CA is responsible of the CRL issuance but may
delegate
> the publication to another entity, while being still legally
responsible
> of
> the issuance of the CRLs.
> 
> The CRL distribution points extension, defined in section 4.2.1.14 of
RFC
> 3280, is the means for the CA to designate the appropriate CRL Issuer.
> When
> the CA is not the CRL issuer, then the cRLIssuer field MUST be present
and
> contain the Name of the CRL issuer. This field has the syntax
> GeneralNames.
> 
> GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
> 
> GeneralName ::= CHOICE {
>       otherName                       [0]     AnotherName,
>       rfc822Name                      [1]     IA5String,
>       dNSName                         [2]     IA5String,
>       x400Address                     [3]     ORAddress,
>       directoryName                   [4]     Name,
>       ediPartyName                    [5]     EDIPartyName,
>       uniformResourceIdentifier       [6]     IA5String,
>       iPAddress                       [7]     OCTET STRING,
>       registeredID                    [8]     OBJECT IDENTIFIER }
> 
> Since a name is only unambiguous when certified by a CA (two CAs can
> certify
> two different entities but might use the same name for each of them),
the
> straightforward rule to make sure that the name is unambiguous is to
use a
> certificate for that name that has been issued by the CA which has
> designated the CRL Issuer.
> 
> This is not explicitly stated in RFC 3280 for CRL issuers, but it is
for
> OCSP responderx which play a similar function. In page 3 of RFC 2560
we
> have:
> 
> All definitive response messages SHALL be digitally signed. The key
>     used to sign the response MUST belong to one of the following:
> 
>     -- (...)
>     -- (...)
>     -- a CA Designated Responder (Authorized Responder) who holds a
>        *specially marked certificate issued directly by the CA*,
> indicating
>        that the responder may issue OCSP responses for that CA.
> 
> This means that the CRL Issuer must have a *specially marked
certificate
> issued directly by the CA*, indicating that the CRL isssuer may issue
CRLs
> for that CA.
> 
> Having said this, many portions of the text are not acceptable. Only a
few
> examples will be given hereafter.
> 
> 
> 3. The abstract is misleading. The text states:
> "The CRL extension provides a means of discovering and retrieving CRL
> issuer
> certificates." It should say :"The CRL extension provides an
additional
> means of discovering and retrieving CRL issuer certificates."
> 
> 
> 4. The introduction is misleading. The text states:
> 
> " CRL validation is also specified in RFC 3280, which involves the
> constructions of a valid certification path for the CRL issuer".
> 
> There is no concept of "construction of valid certification path for
the
> CRL
> issuer". There is however the concept of a certification path which is
a
> chain of certificates from a "certificate-to-be-tested" up to one of
the
> root keys trusted under the validation policy. For each certificate of
the
> certification path, it must be tested that it is not revoked. As said
> above,
> the CRL issuer is designated by the CA and thus there is the need to
> locate,
> get and verify the CRL issuer certificate that has been issued by the
CA.
> 
> For each certificate of the certification path, there may be the need
to
> capture just ONE CRL issuer certificate and no more.
> 
> The next sentences are inappropriate as well and should be deleted.
> 
> 
> 5. The introduction states:
> 
>     "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 text is biased and is incorrect. SIA is equally applicable and
also
> provides a generic solution to the problem. It has simply to do with
using
> an extension which points downwards or upwards.
> 
> The key point is that the certification path (as described in RFC
3280)
> needs first to be build. Once it is built, and only once this is done,
the
> question is whether or not all certificates of the path are not
revoked.
> This means that it is possible to look up in every certificate of the
> certification path and find out the extensions which are present.
There is
> no superiority to the new proposed extension, if SIA is populated.
> 
> 
> 6. The introduction states:
> 
>     This document provides a straightforward and generic solution to
the
>     CRL issuer certification path building problem by permitting use
of
>     the Authority Information Access extension in CRLs, enabling a CRL
>     checking application to use the same access method
(id-ad-caIssuers)
>     to locate the certificate of the CRL issuer and, if necessary,
>     complete the CRL issuer certification path building to an
appropriate
>     trust anchor.
> 
> Based on the previous arguments, this text is incorrect as well since
> there
> is no "CRL issuer certification path building problem".
> 
> Major changes to this document are required to go any further. Until
an
> agreement can be reached on the previous issues, it does not make
sense to
> discuss the remaining of the document.
> 
> Denis
> 
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Public-Key Infrastructure (X.509)
> Working Group of the IETF.
> >
> > 	Title		: Internet X.509 Public Key
> Infrastructure Authority
> > 			  Information Access CRL Extension
> > 	Author(s)	: S. Santesson, R. Housley
> > 	Filename	: draft-ietf-pkix-crlaia-00.txt
> > 	Pages		: 7
> > 	Date		: 2005-1-26
> >
> > This document updates RFC 3280 by defining the Authority Information
> >    Access Certificate Revocation Lists (CRL) extension.  RFC 3280
> >    defines the Authority Information Access certificate extension
using
> >    the same syntax.  The CRL extension provides a means of
discovering
> >    and retrieving CRL issuer certificates.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt
>

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 10 Feb 2005 14:30:31 +0100

Stefan,

There is a major security issue here.

> no such requirement in RFC 3280 (nor X.509), I'm not sure what there is

The security considerations section needs to be discussed.

The current text is:

      Implementers should take into account the possible existence of
      multiple unrelated CAs and CRL issuers with the same name.  As
      means of reducing problems and security issues related to issuer
      name collisions, CA names SHOULD be formed in a way that reduce the
      likelihood of name collisions.

The SHOULD in the previous sentence does not solve the problem, since this 
cannot be prevented. The text should explain how to have a secure system 
even in the case of a name collision, i.e. two CAs pick the same name to 
designate a CRL issuer but that name now relates to two different entities.

      Implementations validating CRLs
      MUST ensure that the certification path of the target certificate
      and the CRL issuer certification path used to validate the target
      certificate, terminate at the same trust anchor.

This sentence does not solve the problem. The only way to solve the problem 
is, for relying parties, to be able to know unambiguously which CA is 
allowed to certify the CRL issuer name. It cannot be "any CA" in a 
certification tree.

Since the syntax of the cRLIssuer contained in DistributionPoint does not 
permit to place any other information than a name, it cannot designate the 
CA allowed to certify the CRL issuer name, hence there needs to be a fixed 
rule to be known by all relying parties.

The fixed rule I proposed mimics the conditions of the OCSP responder, i.e.

  "The CRL Issuer must have a specially marked certificate issued
   directly by the CA, indicating that the CRL issuer may issue CRLs".

Can there be another rule which guarantes that there is no ambiguity about 
the right CRL issuer bearing the name contained in cRLIssuer ? The answer is 
no, ... unless you demonstrate the contrary.

Note: remember that the CA cannot know in advanced which trust anchor(s) 
will be placed in the validation policies used by relying parties.

Denis