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

From: Denis Pinkas <[email-masked]>
Date: Mon, 07 Feb 2005 15:19:25 +0100

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: Peter Sylvester <[email-masked]>
Date: Tue, 8 Feb 2005 19:33:12 +0100 (MET)

- The abstract says that the defined extension has the same syntax
  as for certificats.
  This seems slightly misleading for me since the texts also defines
  data formats, and does not reuse the existing id-ad-caIssuers.
  
- The id-ad-caIssuers definition in 3280 defines the usage of ftp, http,
  ldap (but fails together with operationl protocols to completely
  define the data formats for http and ftp. 

  I am not sure that p7c in the current text is really intended to have
  another mime encapsulation (as mentioned by D.C.), but if so, what
  would this be good for?

- Shouldn't the data format be met into an updated operational
  protocols? This would also allow to say a little bit more
  about what an http client is supposed to implement as a minimal
  profile for http. 

- It doesn't seem extremely useful to me to have several different
  formats to access to certificat list via http, on for certificats
  in general (done by Peter Gutmann's text) and another in this
  text.

- Using a suffix .cer or .p7c to determine the content type behind
  an http uri seems not ok to me, for this AFAIK, http uses mime types.

- Yes, I know, we might end with a debate whether a list of certs
  can be provided best as:
 
  - SEQUENCE OF Certificate
  - a p7c cert only PKCS7/CMS file
  - a mime multipart containing several individual certificats
  - same result as with ldap...

  Well, so be it, ==> 'n' mime types (defined with their file suffix)
  a an http client can set a list of acceptable mime types, and the server
  must return the data in that way. Using undefined length encoding, 
  the first and the second simply mean to encode a fixed prefix and suffix,
  the third is a bit more complicated, etc. 

Peter

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 8 Feb 2005 19:38:50 -0000

Peter,

Thanks for the comments.

Comments in-line;

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: Peter Sylvester [mailto:[email-masked]]
> Sent: den 8 februari 2005 19:33
> To: [email-masked]; Stefan Santesson
> Cc: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> 
> 

[Stefan] AIA in Certificates and in CRLs share the same ASN.1 syntax
even if we choose to populate the extension with different data. I think
that is perfectly fine and true for many extensions. I.e. when you use
an extension to serve purpose A you may fill that extension with
different parameters and data than if the extension serve purpose B. Yet
the same extension OID is maintained for both cases and the same syntax
is used.

>   define the data formats for http and ftp.

[Stefan] This is the initial suggestion but it is debatable. We started
with the minimum set to see whether there was a strong need for anything
else that was not included in version 0. Do you see a strong reason to
expand the proposed set of schemas? If yes, then why?

>   another mime encapsulation (as mentioned by D.C.), but if so, what

[Stefan] Hopefully this has been sorted out in recent exchange on the
topic. 

>   about what an http client is supposed to implement as a minimal

[Stefan] What we ant to do is to describe what is already widely
deployed for AIA. This is what the text tries to capture. If the text
fails to do that, then we are more than happy to receive suggested
improvements to the text.

>   in general (done by Peter Gutmann's text) and another in this

[Stefan] This is the fine balance. We want to limit the set as much as
possible but still support current deployments that have been deployed
in conformity with RFC 3280 in good faith. There is simply too much use
of the .p7c file format to ignore it and declare it non-conformant.
There is also the aspect of efficiency, where the p7c format may reveal
a complete chain.

>   an http uri seems not ok to me, for this AFAIK, http uses mime
types.

[Stefan] I think/hope this one has been sorted out.

>   the third is a bit more complicated, etc.

[Stefan] We all agree that the information is stored in raw format and
that MIME encoding is an issue for the transport protocol. Is there
anything more to say about this?

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 9 Feb 2005 12:29:33 +0100 (MET)

Stefan, thanks for the answer,

basically I see that there were no conceptual differences, and
only some misunderstandings caused by the wordings.
 
> the same extension OID is maintained for both cases and the same syntax

It seems that with the clarification concerning the MIME encoding, my
remarks does not have no longer a good ground. 

Nevertheless, I think that it important that when the same accessMethod 
oid is used, then the retrieval and presentation(encoding) of the data pointed 
to by the URI should be the same independantly of whether the access method 
is used in an AIA or a SIA of a certificate or a CRL or whather else beast.  

> expand the proposed set of schemas? If yes, then why?

This issue is not orthogonal:

- The operational protocols are not complete, only single certs can be
  retrieved with http and ftp, since there is no other spec., only some
  undocumented practice.

- I am not sure whether FTP is really a necessary goal, in any case, the
  protocol is difficult to implement or to be profiled, etc. 

I suggest that either in 3280 or in operational protocols one should clarify
the data format with multiple certificates, define the mime types etc.
(In the mean time you can put an appendix in the AIA text to remind this,
 this was done with the SIA in 3161 at some time).

In a normative way one should reference operational protocols, and, maybe
profile it, i.e. saying the ftp is not recommended, in whatever way
you want it. Or, clients SHOULD support ldap AND http, and MUST support 
one of them at least? ..

> [Stefan] Hopefully this has been sorted out in recent exchange on the

Yes. 

> improvements to the text.

I'd say, not for AIA, but for whatever 'accessMethod' to uris that have certs
or lists of certs. 

You are not exactly responding to the question: There is something in
between TCP and the data. One can just name this thingy 'http', but still 
there are many options to mention, should a 'lightweight' client be able 
to follow redirections etc. A discussion similar to the SAML/SOAP to http
binding seems useful as an update for the operational protocols. 
example: What returns should be permitted, etc, redirects allowed, 
chunked encoding?, ... ==> all this should be in the operationl protocols. 

> of the .p7c file format to ignore it and declare it non-conformant.

I don't want to declar the p7c non conformant, on the contrary, it is
simple to implement in the server, and in cas of CMS implementations on
the client side, the parsing comes for free, whilst with ...

> There is also the aspect of efficiency, where the p7c format may reveal
The certs are a SET, I don't see exactly what you mean, but since
we are not in disagreement about the usefulness of the 'type' ...

> [Stefan] I think/hope this one has been sorted out.

Yes. but needs to be corrected in the text. 

> anything more to say about this?

Since I think that this is an isseu for the operational protocols ... :-)

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 11 Feb 2005 13:27:56 +0100 (MET)

Denis, 

It seems not only to me that you are trying to discuss a topic
which is out of scope for this document. 

This document describes how to put a pointer to a repository
at some particular place, not more. 
 
Assuming that you would have made some top
down search through a CA that issued 1000 sub cas etc, you
may end with something that has the required structure to
validate the CRL. It just takes you some more time.

Or, the AIA gives you a hint about what might be best to
test first, not more, not less? It is not really better
or worse than a SIA, or an implicit directory name, or
whatever.

Whether this list of certs that you obtain validates 
according to the same trust anchor is a problem that exists 
independantly of how you obtained the cert (path) that signed a 
crl, you are describing this as

 "it is never required to secure the protocol to query CRLs"

Do you want this in the security section:

   The "pointer" obtained from the AIA extension and the resulting
   certificates do not indicate anything about the validity of the
   CRL. Thus, the same techniques to validate the CRL must
   be applied independantly how the information (i.e. a list
   of potentially validating certs) is obtained.

You MAY say that this URI is not sufficient so a valid CRL cannot be
determined at all by starting at that point and limiting the search
in an inappropriate way. 

I may have overlooked something, in this case TIA for teaching :-)

Peter

---

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 28 Feb 2005 11:56:39 -0000

Denis,

No problem, take your time.

My understanding is that you have not requested any technical changes to
the document.

Your comments seems to have in common that you would like the document
to state that AIA in CRLs only applies to indirect CRLs. However, such
limitation was not imposed on the scope of this work when accepted by
PKIX and I personally strongly object to it.

I think it is your job (whenever you have time) to seek consensus for
your opinion to impose such limitation on this draft.

Stefan Santesson
 
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: den 24 februari 2005 15:59
> To: Stefan Santesson
> Cc: Russ Housley; pkix
> Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> 
> 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
> 
> 
> > Comments in-line;
> > (Some stuff deleted to keep volume down)
> >
> > Stefan Santesson
> >>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
> >>    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.
> >
> >
> >
> >
>