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

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

Stefan,

I made the e-mail shorter. Your main arguments are the following:

==========================================================================

[Stefan] But it has to provide a warning to something that is introduced
by the standard. This standard does not introduce the concept of CRL
signature checking or CRL issuer certificate validation, so that is
clearly out of scope. More about that below;

[Denis] See below the last answer and also my arguments in the 
soon-to-be-posted answer to Russ.

==========================================================================

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

[Stefan] In fact it is.

RFC 3280, Section 6.3.3 CRL processing - on page 85:

    (f)  Obtain and validate the certification path for the complete CRL
    issuer.  If a key usage extension is present in the CRL issuer's
    certificate, verify that the cRLSign bit is set.

    (g)  Validate the signature on the complete CRL using the public key
    validated in step (f).

[Denis] The text does not say how to obtain and validate the certification 
path for the complete (???) CRL issuer. The text is not clear enough so that 
two implementors only looking at this sentence will provide interoperable 
implementations.

==========================================================================

[Stefan] It is my hope that the provided responses here can help
convince you to change your mind about that. If it doesn't I still argue
that the place to specify requirements and security considerations for
CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft.

[Denis] I can agree with your last sentence, ... which means that it should 
not be in the main body of the document. In the security considerations 
section, text is free and we shall at the very minimum warn implementers and 
we should provide some guidance. When the same certification path (i.e. the 
path used to validate the target certificate) is used, then there is no 
security issue: this should be said. For all other cases, there MAY be 
problems: this should also be said. It is as simple as that.

Denis

---

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

Denis:

RFC 3280 does not tell an implementor how for locate certificates for any 
certification path construction.  There are several extensions that provide 
pointers that may help an implementation, but other approaches to obtaining 
the same certificates are always permitted.  I would fully expect an 
implementation to check any local cache before accessing a repository.

The CRL AIA extension fits this pattern.  A method for locating a 
certificate is provided, but any other mechanism for locating the same 
certificate is acceptable.

Russ

>path for the complete (???) CRL issuer. The text is not clear enough so 
>that two implementors only looking at this sentence will provide 
>interoperable implementations.
>
>[Denis] I can agree with your last sentence, ... which means that it 
>should not be in the main body of the document. In the security 
>considerations section, text is free and we shall at the very minimum warn 
>implementers and we should provide some guidance. When the same 
>certification path (i.e. the path used to validate the target certificate) 
>is used, then there is no security issue: this should be said. For all 
>other cases, there MAY be problems: this should also be said. It is as 
>simple as that.
>
>Denis
>

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 10 May 2005 08:59:36 +0200

Russ,

Your statement below is correct, but does not answer to any of my 
questions/issues. In particular, the last one. I am still awaiting your 
responses.

Denis

> Denis:
> 
> RFC 3280 does not tell an implementor how for locate certificates for 
> any certification path construction.  There are several extensions that 
> provide pointers that may help an implementation, but other approaches 
> to obtaining the same certificates are always permitted.  I would fully 
> expect an implementation to check any local cache before accessing a 
> repository.
> 
>> [Denis] The text does not say how to obtain and validate the 
>> certification path for the complete (???) CRL issuer. The text is not 
>> clear enough so that two implementors only looking at this sentence 
>> will provide interoperable implementations.
>>
>> considerations section, text is free and we shall at the very minimum 
>> warn implementers and we should provide some guidance. When the same 
>> certification path (i.e. the path used to validate the target 
>> certificate) is used, then there is no security issue: this should be 
>> said. For all other cases, there MAY be problems: this should also be 
>> said. It is as simple as that.
>>
>> Denis
>>
> 
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 10 May 2005 14:57:33 -0400

The document already says that the CA and the CRL issuer need to terminate 
at the same trust anchor.  This is the important point.  I disagree that 
there is anything else that ought to be said in the security considerations.

Russ

At 02:59 AM 5/10/2005, Denis Pinkas wrote:
>>certification path construction.  There are several extensions that 
>>provide pointers that may help an implementation, but other approaches to 
>>obtaining the same certificates are always permitted.  I would fully 
>>>clear enough so that two implementors only looking at this sentence will 
>>>provide interoperable implementations.
>>>

---

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

Russ,

Since Tim has now made the call at the WG level, please consider this 
message as an answer to the call: the current security considerations 
section is not acceptable.

  > The document already says that the CA and the CRL issuer need to
  > terminate at the same trust anchor.  This is the important point.
  > I disagree that there is anything else that ought to be said in the
  > security considerations.

This statement still does not answer to the point I raised, but
I will nevertheless answer to your statement.

The same trust anchor is not a *sufficient* condition. The same node in the
certification tree is the necessary condition. This implies, of course, the
same trust anchor, but since two CRL issuers located at different nodes
(i.e. certified by different CAS) might have the same CRL issuer name, this
condition is insufficient to solve the issue.

May I recall an extract from the security considerations section of an
approved draft that will be published soon as RFC 4043 ? (this is the
permanent-identifier document):

      Subject names in certificates are chosen by the issuing CA and are
      mandated to be unique for each CA; so there can be no name collision
      between subject names from the same CA.  Such a name may be an end-
      entity name when the certificate is a leaf certificate, or a CA name,
      when it is a CA certificate.

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

      Additional checks need to be done, e.g., to check if the public key
      values of the two CAs which have issued the certificates to be
      compared are identical or if the sequence of CA names in the
      certification path from the trust anchor to the CA are identical.

      (...)

      The certification of different CAs with the same DN by different CAs
      has other negative consequences in various parts of the PKI, notably
      rendering the IssuerAndSerialNumber structure in [RFC3852] section
      10.2.4 ambiguous.

It speaks for itself, as it applies to CRL Issuers as well. Some parts of
it should indeed be copied and pasted in the security considerations section
of the current proposed draft.

When the certification path used to validate the target certificate is
also used to validate the CRL Issuer certificate, then there is no security
issue: this should be said in the security considerations section.

What about the other cases ? The other cases belong to the category of
indirect CRLs. Depending on the local validation policy checks done or not
done there may be security issues.

Denis

  >> questions/issues. In particular, the last one. I am still awaiting
  >> your responses.
  >>
  >> Denis
  >>
  >>> Denis:
  >>> any certification path construction.  There are several extensions
  >>> that provide pointers that may help an implementation, but other
  >>> approaches to obtaining the same certificates are always permitted.
  >>> I would fully expect an implementation to check any local cache
  >>> before accessing a repository.
  >>> certificate is provided, but any other mechanism for locating the
  >>> same certificate is acceptable.
  >>> Russ
  >>>
  >>>> Stefan,
  >>>>
  >>>> certification path for the complete (???) CRL issuer. The text is
  >>>> not clear enough so that two implementors only looking at this
  >>>> sentence will provide interoperable implementations.
  >>>>
  >>>>
  >>>> considerations section, text is free and we shall at the very
  >>>> minimum warn implementers and we should provide some guidance. When
  >>>> the same certification path (i.e. the path used to validate the
  >>>> target certificate) is used, then there is no security issue: this
  >>>> should be said. For all other cases, there MAY be problems: this
  >>>> should also be said. It is as simple as that.
  >>>>
  >>>> Denis
  >>>
  >>
  >>
  >
  >

---

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

Denis:

Finally!  We now uncover the actual point of disagreement.

You say:

When policies, procedures, and practices are followed, I do not believe 
that two different CRL issuers that are subordinate to the same trust 
anchor can legitimately have the same name.  As I said yesterday, I am 
willing to add text to the Security Considerations section to state 
this.  I am even willing to state that certificate users should not include 
trust anchors that do not have policies, procedures, and practices that 
would prevent such name collisions.

Russ

---

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

Russ,

 > Finally!  We now uncover the actual point of disagreement.

I would hope, but I am still unsure.

  >> The same trust anchor is not a *sufficient* condition. The same node
  >> in the certification tree is the necessary condition. This implies, of
  >> course, the same trust anchor, but since two CRL issuers located at
  >> different nodes (i.e. certified by different CAS) might have the
  >> same CRL issuer name, this condition is insufficient to solve the
  >> issue.

 > anchor can legitimately have the same name.

You have certainly heard of the name "Eurostar". That name was originally
used by a French truck company, and the French-British railways anyway
made accidentally a name collision with it.

We can hope that this does not happen again, but we cannot make sure it
already happened. We need to build a secure PKI, not a "nearly secure"
PKI and there ARE solutions to make it fully secure.

I also know there are current solutions which are NOT fully secure.
The goal of our group is to say how to make it secure.

 > As I said yesterday, I am
 > this.

As mentioned above, this is untrue in general.

 > I am even willing to state that certificate users should not
 > include trust anchors that do not have policies, procedures, and
 > practices that would prevent such name collisions.

This is impossible to state since the certification tree may be growing
and thus you cannot make sure that you have explored all the tree.

See my detailed response to Stefan from a few minutes ago on what needs to 
be covered in the security considerations section.

Denis

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 13 May 2005 10:38:59 +0200

> made accidentally a name collision with it.

Isn't the source of this problem the fact that as long as nothing 
cryptographically binds to it, it's very hard to be completely sure we 
got the right certificate ?

So why not solve that and expand the way we link to the CRL issuer to 
allow the use a ESSCertID ?