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

From: Denis Pinkas <[email-masked]>
Date: Mon, 11 Apr 2005 09:59:28 +0200

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: Russ Housley <[email-masked]>
Date: Thu, 14 Apr 2005 11:57:35 -0400

Denis:

When a certificate issuer is using Indirect CRLs, the CRLDP identifies the 
CRL issuer.  In this situation, the cRLIssuer field in the CRLDP identifies 
the signer of the forthcoming CRLs.  So, in your Scenario A, the CRL Issuer 
is explicitly identified in the CRLDP.  However, the CRL Issuer's 
certificate is not necessarily available from the information in the 
CRLDP.  Thus, the CRL AIA allows the certificate user to obtain it.  In 
this situation the verification must make sure that the cRLIssuer in the 
CRLDP must match the subject/subjectAltName in the certificate that is 
fetched via the CRL AIA.

In my view, this scenario validates the need for this document.

Russ

>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 
>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.
>
>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.
>
>matching the IDP extension from another true CRL and unless other tests 
>are performed, would fool relying parties.
>
>provide untrusted but “useful” information, but the concepts behind 
>path construction.
>
>SCENARIO B
>
>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.
>
>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.
>
>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 ...
>
>In case of a), that is the easiest *temporary* solution, I would propose 
>to rewrite the introduction in the following way :
>

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 15 Apr 2005 09:12:03 +0200

Russ,

> When a certificate issuer is using Indirect CRLs, the CRLDP identifies 
> the CRL issuer.  

To correct the language, "a certificate issuer is not using Indirect CRLs" 
but "a certificate issuer may nominate a CRL Issuer which issues Indirect CRLs".

This sentence also depends upon the content of the CRL DP.

 > In this situation, the cRLIssuer field in the CRLDP
> identifies the signer of the forthcoming CRLs.  So, in your Scenario A, 
> the CRL Issuer is explicitly identified in the CRLDP.  However, the CRL 
> Issuer's certificate is not necessarily available from the information 
> in the CRLDP.  Thus, the CRL AIA allows the certificate user to obtain 
> it.  

Not exactly, but "the CRL AIA allows the certificate user to obtain an 
address that the certificate user can query to obtain information that may 
or may not be the right one".

> In this situation the verification must make sure that the 
> cRLIssuer in the CRLDP must match the subject/subjectAltName in the 
> certificate that is fetched via the CRL AIA.

This is exactly the kind of information that is currently lacking in the 
document, with in addition how this assurance can be obtained.

> In my view, this scenario validates the need for this document.

I am not challening the usefulness (I would not use the term "need") of this 
document, since I am proposing text changes to the document.

Please take a look at my text proposals.

Denis

>> 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
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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
>>
>> 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.
>>
>> 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.
>>
>> 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:
>>
>> In case of a), that is the easiest *temporary* solution, I would 
>> propose to rewrite the introduction in the following way :
>>
>> Of course, much more could be said and an informative annex would be 
>> quite useful.
>>