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

From: Denis Pinkas <[email-masked]>
Date: Mon, 09 May 2005 15:07:42 +0200

Russ,

 > Here is a quote from RFC 3280.  To me, it is clear that a CRL issuer has
 > a certificate.

True, a CRL issuer (that is different from the CA that has issued the target
certificate) has a certificate. So we both strongly agree on this this. :-)

 > Obviously, all certificates need to be validated, which
 > includes certification path construction and certification path validation.

When a sentence starts with "Obviously", it means that it is not so obvious.
:-|

The real question is whether the CRL issuer certificate has to be verified
using rules (i.e. a validation policy) which are independent from the
certification path construction of the target certificate. RFC 3280 does not
provide a crystal clear answer to that question.

If the rules are different, then you MAY end up with a security issue (see
my previous explanations). The current "recommendations" that are in the
security considerations section do NOT solve this issue in the general case.

If the rules are the same, i.e. the path used to validate the certification
path from the certificate are also used, then there is no security issue.

I do not think it would be good to hide this issue in the proposed draft.
Anyway, the current "recommendations" do NOT solve the issue and are thus 
not acceptable and so this section cannot stand as it is.

Denis

 > 5.1.1.3  signatureValue
 >
 >    The signatureValue field contains a digital signature computed upon
 >    the ASN.1 DER encoded tbsCertList.  The ASN.1 DER encoded tbsCertList
 >    is used as the input to the signature function.  This signature value
 >    is encoded as a BIT STRING and included in the CRL signatureValue
 >    field.  The details of this process are specified for each of the
 >    supported algorithms in [PKIXALGS].
 >
 >    CAs that are also CRL issuers MAY use one private key to digitally
 >    sign certificates and CRLs, or MAY use separate private keys to
 >    digitally sign certificates and CRLs.  When separate private keys are
 >    employed, each of the public keys associated with these private keys
 >    is placed in a separate certificate, one with the keyCertSign bit set
 >    in the key usage extension, and one with the cRLSign bit set in the
 >    key usage extension (section 4.2.1.3).  When separate private keys
 >    are employed, certificates issued by the CA contain one authority key
 >    identifier, and the corresponding CRLs contain a different authority
 >    key identifier.  The use of separate CA certificates for validation
 >    of certificate signatures and CRL signatures can offer improved
 >    security characteristics; however, it imposes a burden on
 >    applications, and it might limit interoperability.  Many applications
 >    construct a certification path, and then validate the certification
 >    path (section 6).  CRL checking in turn requires a separate
 >    certification path to be constructed and validated for the CA's CRL
 >    signature validation certificate.  Applications that perform CRL
 >    checking MUST support certification path validation when certificates
 >    and CRLs are digitally signed with the same CA private key.  These
 >    applications SHOULD support certification path validation when
 >    certificates and CRLs are digitally signed with different CA private
 >    keys.
 >
 > Russ
 >
 > At 01:12 PM 4/28/2005, Denis Pinkas wrote:
 >
 >> Stefan and Russ,
 >>
 >>> Denis,
 >>
 >>
 >>> Russ and I have taken a thorough look at your text proposal and we have
 >>> edited a counter proposal where we try to meet your needs as much as
 >>> possible without compromising what we think is the core purpose of the
 >>> draft (to enable certificate discovery bottom-up).
 >>
 >>
 >>> The conclusion is that we suggest changes to the introduction section
 >>> but we keep the old security considerations intact.
 >>
 >>
 >> I would suggest that a merge would need to be done between the "old"
 >> security considerations section and the "new" one.
 >>
 >> The "old" security considerations section is mentionning a solution
 >> which does NOT suppress the problem, but minimize the risk only in
 >> case the CAs are really "honest".
 >>
 >> The old" security considerations section does not provide a solution
 >> in case the name collsion between two CRL issuer name is deliberate,
 >> whereas the "new" security considerations section provides a secure
 >> solution in one case and clearly mentions that all other cases are
 >> dependant about "zillions" of *local* trust conditions which cannot
 >> all be standardized.
 >>
 >> The main purpose of a security considerations section is to provide
 >> the adequate warnings and solutions when they exist and not to hide
 >> the problems.
 >>
 >>> That is not because
 >>> we necessarily disagree with all of the statements in your proposal, but
 >>> in the cases we don't, we still think it is out of scope for this work.
 >>
 >>
 >> This is clearly within the scope of a security considerations section.
 >>
 >>> The new introduction proposal based on your input is:
 >>> --------------------------------------------------------------
 >>> 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).  CRL validation is also specified in RFC 3280,
 >>
 >>
 >> I would love this last sentence to be true but the reality is that:
 >> "CRL validation is NOT specified in RFC 3280". :-(
 >>
 >>> which involves the constructions of a valid certification path for the
 >>> CRL issuer.
 >>
 >>
 >> There is no such a statement in RFC 3280.
 >>
 >>> Building a CRL issuer certification path from the signer of
 >>
 >>
 >> There is no notion of "CRL issuer certification path" in RFC 3280.
 >> The primary requirement is to make sure that the CRL issuer designated
 >> by the CA is indeed the right one. In some (but not all) cases, I mean
 >> among the zillion of cases, there MAY be a need to construct a CRL
 >> issuer certification path.
 >>
 >>> the CRL to a trust anchor is straightforward when the certificate of the
 >>> CRL issuer is present in the certification path associated with the
 >>> target certificate, but it can be complex in other situations.
 >>
 >>
 >> From the comments above, you can see that I cannot agree with the
 >> above revised text. The remaining of the text is acceptable in
 >> general, but could possibly be slightly revised to be more in
 >> continuation with the changes there are needed above (i.e. it is not
 >> cast in concrete).
 >>
 >> Denis
 >>
 >>> There are several legitimate scenarios where the certificate of the CRL
 >>> issuer is not present, or easily discovered, from the target
 >>> certification path.  This can be the case when indirect CRLs are used,
 >>> when the certification Authority (CA) that issued the target certificate
 >>> changes its certificate signing key, or when the CA employs separate
 >>> keys for certificate signing and CRL signing.
 >>> Methods of finding the certificate of the CRL issuer are currently
 >>> available, such as though an accessible directory location or through
 >>> use of the Subject Information Access extension in intermediary CA
 >>> certificates.
 >>> Directory lookup requires existence and access to a directory that has
 >>> been populated with all of the necessary certificates.  The Subject
 >>> Information Access extension, which supports building the CRL issuer
 >>> certification path top-down (in the direction from the trust anchor to
 >>> the CRL issuer), requires that some certificates in the CRL issuer
 >>> certification path includes an appropriate Subject Information Access
 >>> extension.
 >>> RFC 3280 [PKIX1] provides 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 reference CA certificates associated with the certificate
 >>> containing this extension.
 >>> This document enables the use of the Authority Information Access
 >>> extension in CRLs, enabling a CRL checking application to use the access
 >>> method (id-ad-caIssuers) to locate certificates that may be useful in
 >>> the construction of a valid CRL issuer certification path to an
 >>> appropriate trust anchor.
 >>>
 >>> Stefan Santesson
 >>> Program Manager, Standards Liaison
 >>> Windows Security
 >>>
 >>>
 >>>> -----Original Message-----
 >>>> From: Denis Pinkas [mailto:[email-masked]]
 >>>> Sent: den 18 april 2005 13:41
 >>>> To: Stefan Santesson
 >>>> Cc: Russ Housley; pkix
 >>>> Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
 >>>>
 >>>> Stefan,
 >>>>
 >>>>
 >>>>> Denis,
 >>>>
 >>>>
 >>>>> I will come back and comment on your text proposals, but before
 >>>>
 >>> that,
 >>>
 >>>> > a few questions/comments:
 >>>>
 >>>>
 >>>>> <snip>
 >>>>
 >>>>
 >>>>>>> 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).
 >>>>
 >>>>
 >>>>> We agree that this extension does not add to the concept of
 >>>>> cryptographic binding. But how do you mean it can be done?
 >>>>
 >>>>
 >>>> Would this mean that you believed this could not be done ? :-)
 >>>>
 >>>> I already provided the information, but since at that time you were
 >>>> focussing on another issue, you probably missed the point.
 >>>>
 >>>> I would encourage you to read again that thread, but I will provide a
 >>>> short
 >>>> reply here to your question.
 >>>>
 >>>> This can be done using cRLIssuer from the CRL DP. cRLIssuer contains
 >>>
 >>> the
 >>>
 >>>> DN
 >>>> of the CRL Issuer and we all know that CAs are free to assign the DNs
 >>>
 >>> they
 >>>
 >>>> wish. The next point is for a verifier to make sure that the DN which
 >>>> identifies the CRL Issuer (in the CRL DP) is indeed the one that was
 >>>
 >>> meant
 >>>
 >>>> by the CA. The CRL must be issued by a CRL Issuer that has the same
 >>>
 >>> DN.
 >>>
 >>>> The
 >>>> CRL Issuer will have a certificate issued by a CA.
 >>>>
 >>>> Case a): the CA that has issued that certificate is the same as the CA
 >>>> that
 >>>> has issued the target certificate (which contains the hereabove
 >>>
 >>> mentionned
 >>>
 >>>> CRL DP). This is easy to check for a verifier since the verifier must
 >>>> first
 >>>> build the certification path and then test the revocation status of
 >>>
 >>> every
 >>>
 >>>> element of the path. So the verifier knows the validated sequence of
 >>>
 >>> DNs
 >>>
 >>>> starting from a self-signed certificate. It must then use the same
 >>>> sequence
 >>>> of DNs to validate the CRL Issuer certificate.
 >>>>
 >>>> This is a general rule which does not require any extra local trust
 >>>> information.
 >>>>
 >>>> Case b) : the CA that has issued that certificate is NOT the same as
 >>>
 >>> the
 >>>
 >>>> CA
 >>>> that has issued the target certificate. This case requires extra
 >>>
 >>> *0local*
 >>>
 >>>> trust information. There are many such trust conditions possible and
 >>>
 >>> thus
 >>>
 >>>> this cannot be defined in general. Cases a) and b) are thus not
 >>>
 >>> equivalent
 >>>
 >>>> and have to be distinguished.
 >>>>
 >>>>
 >>>>> <snip>
 >>>>
 >>>>
 >>>>>>> This draft only introduces a new way 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.
 >>>>>
 >>>>>
 >>>>> Good, then I suggest that we leave unrelated topics out of this
 >>>>
 >>> draft
 >>>
 >>>>> and focus on the issues that are related to this limited scope.
 >>>>
 >>>>
 >>>> This is what I did in my proposal, except that we need to have a
 >>>
 >>> security
 >>>
 >>>> considerations section and the goal of that section is not to hide
 >>>> problems
 >>>> but to correctly warn users. Thus why an informatiove annex on the
 >>>
 >>> topics
 >>>
 >>>> mentionned in the security considerations section would be quite
 >>>
 >>> useful.
 >>>
 >>>> In fact, its content would be along the lines of the explanations
 >>>
 >>> which
 >>>
 >>>> are
 >>>> just above.
 >>>>
 >>>> I hope this e-mail will help us to progress.
 >>>>
 >>>> Denis
 >>>>
 >>>>
 >>>>> Stefan Santesson
 >>>>> Program Manager - Standards Liaison
 >>>>> Windows Security
 >>>>
 >>
 >>
 >
 >

---

From: Russ Housley <[email-masked]>
Date: Mon, 09 May 2005 11:30:44 -0400

Denis:

Yes, it is OBVIOUS that the CRL issuer certificate needs to be validated.

You say that it is not clear what validation policy needs to be used, but 
this is completely irrelevant to the discussion of the CRL AIA 
extension.  This extension aid in certification path construction, not the 
validation of the path once it is constructed.

There are many factors which need to be considered in the validation of the 
CRL issue certificate.  The values of the key usage extension and the 
certificate policies extension are two that jump to mind.  There are 
probably more if I spend the time to consider each possible scenario.

In my opinion, this document is ready for WG Last Call.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 10 May 2005 09:00:55 +0200

Russ,

> You say that it is not clear what validation policy needs to be used, 
> but this is completely irrelevant to the discussion of the CRL AIA 
> extension.  This extension aid in certification path construction, not 
> the validation of the path once it is constructed.

Not exactly, it could "help" finding a wrong path !

> There are many factors which need to be considered in the validation of 
> the CRL issue certificate.  The values of the key usage extension and 
> the certificate policies extension are two that jump to mind.  There are 

One simple rule would allow no security problem at all and I wonder why you 
have so much resistance to mention it.

> In my opinion, this document is ready for WG Last Call.

As an editor of the draft, I may understand your position; but it is up the 
the PKIX chairs to decide whether or not the document is ready for WG last call.

Once again the current Security Considerations section is not acceptable.
In particular it contains a "MUST" statement that cannot be placed in such a 
section and which is in addition fully wrong.

Hereabove is the last one from draft 01:

3  Security Considerations

      Implementers should take into account the possible existence of
      multiple unrelated CAs and CRL issuers with the same name.  As
      means of reducing problems and security issues related to issuer
      name collisions, CA names SHOULD be formed in a way that reduce the
      likelihood of name collisions.  Implementations validating CRLs
      MUST ensure that the certification path of the target certificate
      and the CRL issuer certification path used to validate the target
      certificate, terminate at the same trust anchor.

      Implementers should be aware of risks involved if the Authority
      Information Access extensions of corrupted CRLs contain links to
      malicious code.  Implementers should always take the steps of
      validating the retrieved data to ensure that the data is properly
      formed.

Hereafter is a "minimalist" rewriting of this section, if we take the choice 
to mention the issue, but not to provide any secure solution (mentioning 
insecure or insufficient solutions is not appropriate). Two sentences have 
thus been deleted.

3  Security Considerations

      Implementers should take into account the possible existence of
      multiple unrelated CAs and CRL issuers with the same name.

      Implementers should be aware of risks involved if the Authority
      Information Access extensions of corrupted CRLs contain links to
      malicious code.  Implementers should always take the steps of
      validating the retrieved data to ensure that the data is properly
      formed.

Denis

>> Anyway, the current "recommendations" do NOT solve the issue and are 
>> thus not acceptable and so this section cannot stand as it is.
>>
>> Denis
>>
>> > 5.1.1.3  signatureValue
>> >

---

From: Russ Housley <[email-masked]>
Date: Tue, 10 May 2005 15:26:38 -0400

>Not exactly, it could "help" finding a wrong path !

Not likely.  The signer of the CRL is providing a pointer to their own 
certificate.  Path construction to locate a parent of that certificate 
through a complex PKI might include paths that are acceptable and paths 
that are unacceptable, but the certificate that contains the public key 
needed to validate the signature on the CRL is clearly needed.

>>the CRL issue certificate.  The values of the key usage extension and the 
>One simple rule would allow no security problem at all and I wonder why 
>you have so much resistance to mention it.

We have that rule:  The CA certificate and the CRL Issuer certificate must 
validate back to the same trust anchor.

>As an editor of the draft, I may understand your position; but it is up 
>the the PKIX chairs to decide whether or not the document is ready for WG 
>last call.

Correct.  I included this sentence for the WG chairs.  I hope they will 
agree with me, and that they will issue WG Last Call for this document.

>Once again the current Security Considerations section is not acceptable.

To you...  No one else is advocating this change.  I continue to believe 
that requiring the CA certificate and the CRL Issuer certificate to 
validate back to the same trust anchor resolves your concern.  I am willing 
to add a few words to the security considerations about name collisions (my 
co-author may disagree), but I am not willing to use "MUST" or "SHOULD" in 
those words.  There is absolutely nothing that a client can do to determine 
deal with name collisions that are subordinate to the same trust anchor.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 12 May 2005 11:42:33 +0200

Russ,

 >>> extension.  This extension aid in certification path construction,
 >>> not the validation of the path once it is constructed.

 > needed to validate the signature on the CRL is clearly needed.

The problem is to know if a CRL that has been fetched "somewhere" is 
adequate for the target certificate. It is not to validate a CRL that has 
been fetched "somewhere".

 >>> There are many factors which need to be considered in the validation
 >>> of the CRL issue certificate.  The values of the key usage extension
 >>> and the certificate policies extension are two that jump to mind.
 >>> There are probably more if I spend the time to consider each possible
 >>> scenario.

 >> One simple rule would allow no security problem at all and I wonder
 >> why you have so much resistance to mention it.

 > We have that rule:  The CA certificate and the CRL Issuer certificate
 > must validate back to the same trust anchor.

As explained in a just posted e-mail this rule is insufficient and thus
insecure.

 >> As an editor of the draft, I may understand your position; but it is
 >> up the the PKIX chairs to decide whether or not the document is ready
 >> for WG last call.

 > validate back to the same trust anchor resolves your concern.

It does not.

 > I am
 > willing to add a few words to the security considerations about name
 > collisions (my co-author may disagree), but I am not willing to use
 > "MUST" or "SHOULD" in those words.

We agree that "MUST" or "SHOULD" should not be used in the security
considerations section.

 > There is absolutely nothing that a
 > client can do to determine deal with name collisions that are
 > subordinate to the same trust anchor.

This last statement is wrong. Please look again at the security
considerations section of "Permanent Identifier". As an example:

    "Since a name is only unique towards its superior CA, unless some
     naming constraints are being used, a name would only be guaranteed to
     be globally unique when considered to include a sequence of all the
     names of the superior CAs".

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 12 May 2005 11:45:16 +0200

Please correct this typo:

AccessDescription specifying id-ad-caIssuers as the acessMethod
                                                      ^^

              Denis

---

From: Russ Housley <[email-masked]>
Date: Thu, 12 May 2005 10:56:46 -0400

>been fetched "somewhere".

You continue to miss the whole point of this document.

The certificate user has already obtained the CRL, but needs the 
certificate of the CRL issuer in order to validate the signature on the 
CRL.  That is the scope of this document.  You keep trying to make it 
something else.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 13 May 2005 09:59:20 +0200

Russ,

 >> adequate for the target certificate. It is not to validate a CRL that
 >> has been fetched "somewhere".

 > You continue to miss the whole point of this document.

I do not think so.

 > The certificate user has already obtained the CRL, but needs the
                                              ^^^^
it is not "the" CRL since it is only "a" CRL. If you got a network attack
when fetching the CRL from the CRL DP you may get something wrong. So at
this time you still do not know what is *the* right CRL.

 > CRL.  That is the scope of this document.

Not exacly. You are not sure to get "the" CA certificate of the CRL issuer,
but only "a" certificate that bears the appropriate DN in the subject DN.
but collisions in subject DNs may happen accidently or deliberately.

 > You keep trying to make it something else.

The distinction between "the" and "a" is pretty important.

Denis

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 May 2005 15:34:56 -0400

Denis:

>The distinction between "the CRL" and "a CRL" is pretty important.

So we have identified another are where we disagree.  The CRL AIA extension 
applies to a CRL that the certificate user has already selected.

Russ