Subject: RE: Comments on <draft-ietf-pkix-crlaia-00.txt>

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 11 Apr 2005 15:28:05 +0100

Denis,

Thanks for spending considerable time to comment on this draft.
The typo is noted and will be fixed.

Some generic comments before we go into the specific text proposals:

You point out some well known issues related to the lack of absolute
cryptographic binding between CRL and certificates where the certificate
and CRL is not signed by the same key.

A certificate is always authoritative to identify the correct CRL for
its validation. But since the certificate is signed before the latest
CRL that validates it, the certificate can't cryptographically bind
(e.g. hash) the CRL but needs to identify it by verifiable attributes
such as issuer name and storage location.

This issue is however NOT introduced by this draft. It is simply a
generic issue with RFC 3280/X.509, especially for indirect CRLs

In this context I really can't see the difference between scenario A and
scenario B. It seems to me that the same validation principles apply to
both scenarios.

Section 6.3 of RFC 3280 is dealing with CRL validation and the
requirement to validate the CRL through a valid certificate path.

This draft only introduces a new way to point to locate certificates
that can be helpful in building this path. It seems to me from that
perspective that specific requirements on CRL path building are outside
the scope of this draft.

>Stefan Santesson
>Program Manager - Standards Liaison
>Windows Security
 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Denis Pinkas
> Sent: den 11 april 2005 00:59
> To: Stefan Santesson; Russ Housley
> Cc: pkix
> Subject: Comments on <draft-ietf-pkix-crlaia-00.txt>
> 
> 
> Stefan and Russ,
> 
> It took me several hours to write this long e-mail, hence for the
delay
> (in addition to the time for shooting a few "big five" with my
camera).
> 
> This e-mail identifies several security issues, which are not
currently
> mentionned in the security considerations section. It finally proposes
a
> rewritting of the introduction and provides a strawman for a new
security
> considerations section (see the proposal at the end of this e-mail).
> 
> Let us consider two different scenarios where this new extension would
be
> considered.
> 
> Scenario A: The relying party does not trust any CRL issuer in
particular
> and will simply use the CRL Issuer designated by the Certificate
Issuer by
> means of the CRL DP extension.
> 
> Scenario B: The relying party trusts at least a specific CRL issuer
and
> will
> get the CRLs from that CRL Issuer and then will make sure that the
> information contained in them matches with the designation of the
> Certificate Issuer.
> 
> SCENARIO A
> 
> In scenario A, the relying party will use the CRL DP from the target
> certificate to get the CRL and then will make sure that the CRL that
has
> been retrieved from that location is signed by the right CRL Issuer.
> 
> The CRL DP extension is defined as:
> 
>     DistributionPoint ::= SEQUENCE {
>          distributionPoint       [0]     DistributionPointName
OPTIONAL,
>          reasons                 [1]     ReasonFlags OPTIONAL,
>          cRLIssuer               [2]     GeneralNames OPTIONAL }
> 
> At least the distributionPoint field shall be present. It is supposed
it
> contains a general name of type URI, which is a pointer to the current
CRL
> for the associated reasons and will be issued by the associated
cRLIssuer.
> 
> The CRL itself shall contain an IDP (Issuing Distribution Point).
> 
> The IDP extension is defined as:
> 
>     issuingDistributionPoint ::= SEQUENCE {
>          distributionPoint          [0] DistributionPointName
OPTIONAL,
>          onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
>          onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
>          onlySomeReasons            [3] ReasonFlags OPTIONAL,
>          indirectCRL                [4] BOOLEAN DEFAULT FALSE,
>          onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
> 
> A necessary but insufficient condition is that the distributionPoint
field
> from the IDP extension shall be equal to the distributionPoint field
from
> the CRL DP extension.
> 
> This is insufficient since a URL like
URL=http://corppki/crl/extranet.crl
> could be used by accident by two different CAs, or a CA under the same
> root
> key could maliciously use that URL or a different and re-route all
packets
> to an address where that CRL is made available.
> 
> This means that the tupple CRL DP extension from certificates and the
IDP
> extension from CRLs even if then match are insufficient to make sure
that
> it
> is the right CRL that has been retrieved. This is "normal" until some
> cryptographic checksums are used to make sure that this is the right
> information.
> 
> Any CA, trusted under a root key, could use an IDP extension in a CRL
> matching the IDP extension from another true CRL and unless other
tests
> are
> performed, would fool relying parties.
> 
> This is the major reason why the current document in its current form
is
> dangerous to be published. It incorporates verification concepts which
are
> missing major security issues. The security consideration section
attempts
> to tackle the issue but it misses the point.
> 
> The major problem is not the definition of this new extension that
could
> provide untrusted but "useful" information, but the concepts behind
path
> construction.
> 
> SCENARIO B
> 
> In scenario B, the relying party contacts the location of a trusted
CRL
> Issuer and wants to verify that the retrieved CRL is correctly signed.
> 
> Suppose that the retrieved CRL contains the newly defined extension
which
> specifies one or more accessLocation fields that contains references
to CA
> certificates superior to the CRL containing this extension.
> 
> Let us consider that one accessLocation field contains the following
URL:
> http://corppki/aia/certificates.crt
> 
> The relying party will access this URL to retrieve some CA
certificates.
> Nothing at this point would prevent a network attack so that access to
> this
> URL is re-routed to another location. The question is how the relying
> party
> can figure out and what kind of tests it should make. The draft is
silent
> about this.
> 
> It does not help the end-user to define new extensions if at the same
time
> there are no explanations or guidance to tell how are they should be
used
> in
> order to build a secure system.
> 
> Let us suppose that the information retrieved is just "useful"
> certificates
> at this time (i.e. untrusted).
> 
> In order to build a path, a relying party needs to make sure of the
name
> of
> the CRL Issuer, which means not simply knowing the DN of the CRL
issuer
> but
> also all the other DNs from the upper CAs up to a root key. This kind
of
> assumption or explanations is currently missing in the draft.
> 
> Scenario B would be correctly supported if the text would mention two
> points:
> 
>     1) the location of the "trusted CRL Issuer" must be locally known,
>     2) the name of the "trusted CRL Issuer" must be locally known,
>        which means not simply knowing the DN of the CRL issuer,
>        but also all the other DNs from the upper CAs up to a root key.
> 
> Using the "useful" certificates that would be retrieved using that new
> extension, the relying party would then build a certification path to
> validate the retrieved CRL. Additional details, described nowhere,
should
> be
> given so that it can be sure that it is a CRL Issuer and not a CA, etc
...
> 
> Then the relying party knows that he got a correct indirect CRL and
has to
> make sure that the name of the CA is present. Additional details would
be
> needed to explain name matching taking into account that two CAs could
be
> given the same DN by two different CAs.
> 
> 
> CONCLUSION:
> 
> I see two ways to progress:
> 
>     a) "avoid" the problem *now* and leave it for later. This means
>        saying that this extension may provide useful information that
>        still needs to be verified to be trusted. The security
>        considerations section would tackle the issue but not provide
>        the full answer.
> 
>     b) address the issue and say how to handle CRLs when they are not
> signed
>        by the CA.
> 
> In case of a), that is the easiest *temporary* solution, I would
propose
> to
> rewrite the introduction in the following way :
> 
>     RFC 3280 [PKIX1] specifies the validation of certification paths.
>     One aspect involves the determination that a certificate has not
been
>     revoked, and one revocation checking mechanism is the Certificate
>     Revocation List (CRL). Checking a CRL when the CRL is signed by
the
>     key of the Issuing CA is straightforward, but not necessarily
>     otherwise.
> 
>     There are several legitimate scenarios where the certificate of
the
>     CRL issuer is not present, or easily discovered.
> 
>     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.
> 
>     Directory lookup requires presence and access to a directory.  The
>     Subject Information Access extension supports building
certification
>     paths top-down (in the direction from the trust anchor to the CRL
>     issuer), which will succeed if certificates include an appropriate
>     Subject Information Access extension. Additional methods allowing
>     the building of certification paths bottom-up to validate CRLs
>     may be useful as well. This is the topic of this document.
> 
>     RFC 3280 [PKIX1] has provided for bottom-up discovery of
>     certification paths through the Authority Information Access
>     extension, where the id-ad-caIssuers access method may specify one
or
>     more accessLocation fields that contain references to CA
certificates
>     superior to the certificate containing this extension.
> 
>     This document permits 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 complete the certification path building to an
>     appropriate trust anchor.
> 
>     This extension may be used in the case when indirect CRLs are
used,
>     when the certification Authority (CA) that issued the CRL
certificate
>     changes its certificate signing key, or when the CA employs
separate
>     keys for certificate signing and CRL signing.
> 
> A typo would need to be corrected in section 2: change
> AuthotiyInfoAccessSyntax into AuthorityInfoAccessSyntax.
> 
> Section 3 about Security Considerations would need to be changed.
> Hereafter is a proposal:
> 
> 3  Security Considerations
> 
>       Implementers should take into account the possible existence of
>       multiple unrelated CAs and CRL issuers with the same DN, as well
>       as the possibility for some trusted CAs (i.e. trusted to issue
>       their own certificates and associated revocation status
information
>       but not trusted not handle revocation information from other
CAs)
>       to purposely use URLs or CRL DPs identical to some CRL DPs from
>       other CAs and at the same time mounting a re-routing attack.
> 
>       This means that finding a CA certificate at the location
indicated
>       by this new extension is insufficient to make sure that it is
the
>       right one, and by consequence that the CRL where this extension
>       has been found is also the right one.
> 
>       When the CRL contains the indirectCRL boolean set to TRUE, then
the
>       relying party should locally know the URL of the CRL issuer(s)
that
>       it directly trusts and also the associated name of the trusted
CRL
>       issuer, which means not simply knowing the DN of the CRL issuer,
>       but also all the other DNs of the upper CAs up to a root key
(since
>       two CAs might be given the same DN by two different CAs).
> 
>       When the CRL is a direct CRL, then relying parties shall make
sure
>       that the certificate of the CRL issuer has been issued by the
same
>       CA that has issued the target certificate.
> 
>       Implementers should always take the steps of validating the
>       retrieved data to ensure that the data is properly formed.
> 
> Of course, much more could be said and an informative annex would be
quite
> useful.
> 
> In case of b), more work would need to be done.
> 
> Denis
>

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 14 Apr 2005 10:09:54 +0200

Stefan,

> The typo is noted and will be fixed.

Thank you so much, for accepting to correct the typo. :-|

> and CRL is not signed by the same key.

Not really. It is indeed possible to have an absolute cryptographic binding 
between CRL and certificates where the certificate and CRL is not signed by 
the same key, but the key point is that proposed extension is *not* the 
means to provide such a binding (and you agree with this further down in 
this e-mail).

The proposed extension is simply a means to find a possible certificate 
candidates, but not a means to make sure that the candidate is acceptable.

> its validation. 

While this is true in general, this is not always true. When indirect CRLs 
are used, a directly trusted CRL Issuer may be used. For other cases, your 
statement is correct.

 > But since the certificate is signed before the latest

As you say, only issuer name or location may be used. Location cannot be 
used as this has been demonstrated in the previous e-mail, since a network 
attack could be performed. So only the issuer name can be used. Let us look, 
how:

    DistributionPoint ::= SEQUENCE {
         distributionPoint       [0]     DistributionPointName OPTIONAL,
         reasons                 [1]     ReasonFlags OPTIONAL,
         cRLIssuer               [2]     GeneralNames OPTIONAL }

Secure binding may be obtained using cRLIssuer where

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

with

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 }

where    Name ::= CHOICE {
      RDNSequence }

RFC 3280 states:

   " If the certificate issuer is not the CRL Issuer, then the cRLIssuer
     field MUST be present and contain the Name of the CRL issuer".

A name is uniquely assigned to an entity, only if the name of the CA which 
has allocated it is known. Recursively, the DN of that CA is uniquely 
assigned to an entity, only if the DN of the CA which has allocated that DN 
it is known. This process ends up until the trust anchor that has issued the 
first CA certificate of the certification path is known.

> scenario B. It seems to me that the same validation principles apply to

Not exactly. From what is said above, it can be said that cRLIssuer DN has 
been uniquely assigned to that entity, if it is known that this DN has been 
issued by the CA that has issued the target certificate. This is scenario A 
which means that the trust conditions from the relying party are simple and 
well known.

The problem is that with scenario B, no document provides the trust 
conditions to be used by the relying party and that there can be many 
different trust conditions, some of them may be secure, while some of them 
may be insecure depending upon the context.

This is why it is important to make a difference between scenario A and B.

> requirement to validate the CRL through a valid certificate path.

  ... but that section is lacking of further details that would allow two 
different imlplementations to end up with the same result.

> that can be helpful in building this path. 

At least one sentence of which we both agree !
It should be copied and pasted in the abstract.

 > It seems to me from that

Since scenario B has so many possible options, it is not possible to cover 
all of them and the intent is not to describe and prescribe all of them. 
However, scenarion A is much simpler and may be described.

I have many problems with the current introduction. I am restating my 
previous proposal for a revised introduction along the lines that "this 
draft only introduces a new way to point to locate certificates that can be 
helpful in building this path". If you have problems with that text, please 
propose revisions to it. If you can live with it, then we are solved with 
the introduction.

    RFC 3280 [PKIX1] specifies the validation of certification paths.
    One aspect involves the determination that a certificate has not been
    revoked, and one revocation checking mechanism is the Certificate
    Revocation List (CRL). Checking a CRL when the CRL is signed by the
    key of the Issuing CA is straightforward, but not necessarily
    otherwise.

    There are several legitimate scenarios where the certificate of the
    CRL issuer is not present, or easily discovered.

    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.

    Subject Information Access extension supports building certification

    RFC 3280 [PKIX1] has provided for bottom-up discovery of
    certification paths through the Authority Information Access
    extension, where the id-ad-caIssuers access method may specify one or
    more accessLocation fields that contain references to CA certificates
    superior to the certificate containing this extension.

    This extension may be used in the case when indirect CRLs are used,
    when the certification Authority (CA) that issued the CRL certificate
    changes its certificate signing key, or when the CA employs separate
    keys for certificate signing and CRL signing.

Now the security considerations section still contains incorrect text.
I have revised my previous proposal. If you have problems with that text,
please propose revisions to it. If you can live with it, then we are
solved with section 3.

      Implementers should take into account the possible existence of
      multiple unrelated CAs and CRL issuers with the same DN, as well
      as the possibility for some trusted CAs (i.e. trusted to issue
      their own certificates and associated revocation status information
      but not trusted not handle revocation information from other CAs)
      to purposely use URLs or CRL DPs identical to some CRL DPs from
      other CAs and at the same time mounting a re-routing attack.

      This means that finding a CA certificate at the location indicated
      by this new extension is insufficient to make sure that it is the
      right one, and by consequence that the CRL where this extension
      has been found is also the right one.

      When the CRL is a direct CRL, relying parties shall make sure
      that the certificate of the CRL issuer has been issued by the same
      CA that has issued the target certificate.

      When the CRL contains the indirectCRL boolean set to TRUE,
      relying parties should locally know the URL of the CRL issuer(s)
      that they directly trust and use local trust conditions to make
      sure that the CRL that has been retrieved has indeed be issued
      by a directly trusted CRL Issuer. In particular, care should be taken
      in case two CAs would be using the same DN for two different CAs.

Indeed, more could be said about indirect CRLs, so if you want to add some 
more text, please do it.

Denis