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

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

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