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

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

Denis,

Thanks for your effort to explain.

Yes I remember when you posted this a while back. I'll try to explain
what I mean.

We agree that IF you mandate that the CRL issuer has a certificate
issued by the CA which issued the target certificate (the certificate
being checked for validation), which is your case a), then you have a
strong binding between the cert and the CRL. It's not a direct
cryptographic binding between the certificate and the CRL object, but a
cryptographically secured attestation of the relation ship between the
CA and the CRL Issuer (which is good enough).

What I mean though, and we seem to agree on, is that you loose that
level cryptographic binding when you don't enforce strong path
relationship between the CRL path and the cert path.

But that problem lies with X.509 (and possibly with RFC 3280), and not
this draft. 

I will shortly get back on comments on your text proposals based on that
view.

>Stefan Santesson
>Program Manager - Standards Liaison
>Windows Security
 
> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> 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