Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in section 6.3

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 18 Jul 2005 18:21:34 +0100

Santosh,

I'm not concerned with direct CRLs here since they are issued by the
target CA. Having said that, I do of course agree that one must not
accept an alternate path to a direct CRL even if CRL issuer name match
the name of the issuing CA.

Within this thread I'm only concerned with indirect CRLs and for those I
currently think we should be more restrictive than your algorithm
suggests.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 18 juli 2005 09:11
> To: 'pkix'
> Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in
> section 6.3
> 
> 
> Stefan,
> 
> One more time: the solution is air-tight for direct CRL.
> 
> For indirect CRL, we can tighten the solution by further profiling or
> restricting the standard. So, we can do what we want.
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Monday, July 18, 2005 12:05 PM
> To: Santosh Chokhani; pkix
> Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in
> section 6.3
> 
> 
> When I last reviewed your algorithm it required the CRL issuer cert to
be
> issued by any CA in the target cert path. My current thinking is to be
> even
> more restrictive.
> 
> Either to require the CRL issuer cert to be issued explicitly by the
> target
> CA or maybe also by its parent CA, but not by any CA further up in the
> path.
> 
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Santosh Chokhani
> > Sent: den 13 juli 2005 04:50
> > To: 'pkix'
> > Subject: RE: 3280bis: CRL validation: what is wrong and/or missing
in
> > section 6.3
> >
> >
> > Stefan,
> >
> > How is this different from my proposal for matching the two
> certification
> > path?
> >
> > Also, this will not overly constrain indirect CRL issuer.
> >
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On
> > Behalf Of Stefan Santesson
> > Sent: Wednesday, July 13, 2005 6:32 AM
> > To: David A. Cooper; Denis Pinkas
> > Cc: pkix
> > Subject: RE: 3280bis: CRL validation: what is wrong and/or missing
in
> > section 6.3
> >
> >
> >
> > David,
> >
> > I agree with your comments.
> >
> > However on the following:
> >
> > > Even though X.509 requires that names be unambiguous, there does
> seem
> > to
> > > be consensus within the PKIX WG that 3280bis should impose some
> > > restrictions of the certification path used to validate a CRL in
> order
> > > to address the concern that a name collision might occur despite
> > X.509's
> > > prohibition.  However, at the moment, WG consensus seems to be in
> > favor
> > > of only requiring that the certification path for the CRL use the
> same
> > > trust anchor as the certification path for the corresponding CRL.
> > There
> > > is language about this in the security considerations section.  In
> > order
> > > for 3280bis to be even more restrictive, it would need to be shown
> > that
> > > there is WG consensus in favor of imposing such restrictions.
> >
> > I would like to add my vote to be more restrictive than just
> terminating
> > at
> > the same root.
> >
> > I think the path processing complexity would be much simpler if the
> CRL
> > issuer certificate had to be issued by the CA that issued the target
> > certificate (the target CA). It would also eliminate potential name
> > collision problems.
> >
> > Perhaps we need to also consider allowing the parent of the target
CA
> to
> > issue the CRL issuer cert but I see no reason to allow the CRL
issuer
> cert
> > to be issued by a CA that is not in the target cert path or by a CA
> higher
> > in the target cert path.
> >
> >
> > Stefan Santesson
> > Program Manager, Standards Liaison
> > Windows Security
> >
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On Behalf Of David A. Cooper
> > > Sent: den 11 juli 2005 19:42
> > > To: Denis Pinkas
> > > Cc: pkix
> > > Subject: Re: 3280bis: CRL validation: what is wrong and/or missing
> in
> > > section 6.3
> > >
> > >
> > > Denis Pinkas wrote:
> > >
> > > >
> > > > 3280bis: CRL validation: what is wrong and/or missing in section
> > 6.3.
> > > >
> > > > 1. The very first sentence states:
> > > >
> > > > " This section describes the steps necessary to determine if a
> > > >   certificate is revoked or on hold status when CRLs are the
> > revocation
> > > >   mechanism used by the certificate issuer".
> > > >
> > > > a) This section should describe the steps necessary to determine
> > > >   if the revocation status of the certification path* is :
> REVOKED,
> > > >   NOT_REVOKED or UNKNOWN, instead of simply determine if the
> > > >   *target certificate* is REVOKED. So the sentence is incorrect.
> > >
> > > The algorithm in section 6.3 is used to determine the status of a
> > > particular certificate, not a certification path, so the text is
> > > correct.  However, as part of certification path validation,
section
> > > 6.1.3, step (a)(3) states that, for each certificate in the path,
> one
> > > must verify that the certificate is not revoked or on hold, and it
> > > indicates that if status is determined using CRLs that section 6.3
> > > indicates how the status can be determined.
> > >
> > > > b) The current text mentions the return of the "on hold" status.
> > > >   However since CRLreason is not mentioned as an output
parameter
> > > >   of the algorithm, this may not be the case (the only algorithm
> > > >   output is currently the revocation status of the certificate).
> > >
> > > The variable cert_status is output from the algorithm.  In section
> > 6.3.3
> > > steps (i) and (j), the value of cert_status is set to the value
from
> > the
> > > reason code CRL entry extension if the certificate is found to be
> > > revoked and the reason code extension is present.
> > >
> > > > 2. The text states: " Conforming implementations that support
CRLs
> > > > are not required to implement this algorithm, but they MUST be
> > > > functionally equivalent to the external behavior resulting from
> this
> > > > procedure".
> > >
> > > If you believe that this sentence and some of text quoted below
need
> > to
> > > be more precisely worded, please provide text for consideration.
> > >
> > > > This sentence is incorrect since the algorithm would mandate the
> > > > support of many certificate extensions, CRL extensions and CRL
> entry
> > > > extensions that conforming relying party applications are NOT
> > > > REQUIRED to support. The current algorithm has many errors in it
> > > > cannot be easily simplified, if less than "all options" are
> > > > supported by a relying party.
> > > >
> > > > 3. The text states: "This algorithm assumes that all of the
needed
> > > > CRLs are available in a local cache".
> > > >
> > > > This sentence is incorrect, because it may happen that the
"right"
> > > > or a "current" CRL is  unavailable and thus absent; in such a
case
> > > > the algorithm terminates with "UNDETERMINED" or "UNKNOWN".
> > >
> > > I don't understand what you mean by incorrect, the sentence states
> an
> > > assumption, not a fact.
> > >
> > > > 4. The text states:
> > > >
> > > > "This algorithm begins by assuming the certificate is not
> revoked."
> > > >
> > > > This sentence is incorrect, the algorithm should begin by
assuming
> > > > the status of the certificate is "UNDETERMINED" or "UNKNOWN".
> > >
> > > cert_status is initialized to UNREVOKED.  If the status cannot be
> > > determined, cert_status gets changed to UNDETERMINED as the final
> > step.
> > >
> > > > 5. The text states, [omitting what is relevant to delta CRLs]
> > > >
> > > > "(a)  Update the local CRL cache by obtaining a complete CRL [ ]
:
> > > >
> > > >         (1)  If the current time is after the value of the CRL
> next
> > > >         update field, then do one of the following :
> > > >
> > > >            (i) [ ].
> > > >
> > > >            (ii)  Update the local CRL cache with a current
> complete
> > > >            CRL, verify that the current time is before the next
> > update
> > > >            value in the new CRL, [ ]".
> > > >
> > > > This is incorrect. If the "current" CRL cannot be found, then it
> is
> > > > still possible to use an older CRL to demonstrate that the
> > certificate
> > > > was REVOKED. Of course, when using an older CRL it is not
possible
> > > > to demonstrate that the certificate was NOT_REVOKED.
> > >
> > > Section 6.3 states "Further, if the next update time of a CRL has
> > > passed, the algorithm assumes a mechanism to fetch a current CRL
and
> > > place it in the local CRL cache."  So, while the scenario you
> describe
> > > could happen, section 6.3 states that the algorithm does not
address
> > > this scenario.
> > >
> > > > 6. The current algorithm cannot make sure that an emergency CRL
(
> > > > i.e. the latest captured CRL) will be used if more than one
> "valid"
> > > > CRLs are found in the local cache.
> > >
> > > True.  As long as untrusted mechanisms are used to distribute
CRLs,
> > the
> > > relying party cannot ensure that it has the latest CRL.
> > >
> > > > 7. The text states:
> > > >
> > > >   (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).
> > > >
> > > > The text is unclear about what is meant by :" validate the
> > certification
> > > > path for the complete CRL issuer". In order to solve the problem
> of
> > > > identical CRL Issuer names or identical CA names, it is needed
to
> > say
> > > > that the certification path that has been used to validate the
> > target
> > > > certificate MUST also be used.
> > >
> > > Would you like for step (f) to say that the validation should be
> > > performed as specified in section 6.1 and/or section 6.2?
> > >
> > > Even though X.509 requires that names be unambiguous, there does
> seem
> > to
> > > be consensus within the PKIX WG that 3280bis should impose some
> > > restrictions of the certification path used to validate a CRL in
> order
> > > to address the concern that a name collision might occur despite
> > X.509's
> > > prohibition.  However, at the moment, WG consensus seems to be in
> > favor
> > > of only requiring that the certification path for the CRL use the
> same
> > > trust anchor as the certification path for the corresponding CRL.
> > There
> > > is language about this in the security considerations section.  In
> > order
> > > for 3280bis to be even more restrictive, it would need to be shown
> > that
> > > there is WG consensus in favor of imposing such restrictions.
> > >
> > > > 8. There is no handling of the Certificate Issuer CRL entry
> > extension,
> > > > when present, which may lead to incorrect results.
> > >
> > > Section 6.3.3, steps (i) and (j) refer to section 5.3.4, which
> > indicates
> > > how to process this extension.
> >
> 
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 18 Jul 2005 16:48:16 -0400

Stefan,

The algorithm is trying to be faithful to the standard.  If the standard can
be profiled and constrained further, so can the algorithm.  That is trivial.
I am proposing an approach and not simply a point solution.

That said, I would at least add to your profile, the indirect CRL being the
trust anchor itself or a certificate issued by the trust anchor that is used
to build the certificate certification path.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Monday, July 18, 2005 1:22 PM
To: Santosh Chokhani; pkix
Subject: RE: 3280bis: CRL validation: what is wrong and/or missing in
section 6.3

Santosh,

I'm not concerned with direct CRLs here since they are issued by the target
CA. Having said that, I do of course agree that one must not accept an
alternate path to a direct CRL even if CRL issuer name match the name of the
issuing CA.

Within this thread I'm only concerned with indirect CRLs and for those I
currently think we should be more restrictive than your algorithm suggests.

Stefan Santesson

be
> even more restrictive.
> target CA or maybe also by its parent CA, but not by any CA further up 
> in the path.
> 
> 
> Stefan Santesson
in
in
CA
issuer
section
parameter
from
CRLs
need
needed
"right"
case
assuming
possible
and
address
(
CRLs,
complete
issuer's
public
to