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

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

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