[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


Stefan,


Denis,



Thanks for spending considerable time to comment on this draft.



The typo is noted and will be fixed.


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


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.
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. 


A certificate is always authoritative to identify the correct CRL for
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

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.
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: 

The CRL DP extension is defined as:

   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. 


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.
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.


Section 6.3 of RFC 3280 is dealing with CRL validation and the
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. 


This draft only introduces a new way to point to locate certificates
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

perspective that specific requirements on CRL path building are outside
the scope of this draft.
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.

   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.


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.

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 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.

     Implementers should always take the steps of validating the
     retrieved data to ensure that the data is properly formed.
Indeed, more could be said about indirect CRLs, so if you want to add some more text, please do it. 

Denis


Stefan Santesson
Program Manager - Standards Liaison
Windows Security



-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx


[mailto:owner-ietf-pkix@xxxxxxxxxxxx]


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