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

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Russ,

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

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

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

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

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

> Russ