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

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

Comments in line;


Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 
> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> Sent: den 28 april 2005 19:12
> To: Stefan Santesson; Russ Housley
> Cc: pkix
> Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
> 
> 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.
> 
[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;

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



> > which involves the constructions of a valid certification path for
the
> > CRL issuer.
> 
> There is no such a statement in RFC 3280.
> 
[Stefan] See above

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

[Stefan] Again - look in section 6.3.3 
> 
> > 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).
> 
[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.

/Stefan

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