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

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 13 Jul 2005 11:32:29 +0100

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: Wed, 13 Jul 2005 07:50:23 -0400

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,

to
X.509's
favor
There
order
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.

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

6.3.
revocation
6.3.3
the
> > 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".
> 
to
> > 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.
> >
step.
update
certificate
> > i.e. the latest captured CRL) will be used if more than one "valid" 
> > CRLs are found in the local cache.
> 
the
CRL
key
certification
say
target
to
X.509's
favor
There
order
that
extension,
indicates

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 13 Jul 2005 08:21:39 -0400

David Cooper,

I do not have any objection on this if we have this as technical requirement
in 6.3 or punt in the Security Considerations section, but saying that there
is a WG consensus is mis-characterization.

-----Original Message-----

David,

to
X.509's
favor
There
order
that

Stefan Santesson

6.3.
revocation
6.3.3
the
to
step.
update
certificate
the
CRL
key
certification
say
target
to
X.509's
favor
There
order
that
extension,
indicates