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

From: "Denis Pinkas" <[email-masked]>
Date: Thu, 21 Jul 2005 15:28:59 +0100

Santosh,

It does no make sense to have a complex model that is even not described 
in an I-D, wheras the solution stands in two lines.

But you are probably right on one point : I also wonder if the WG chairs 
and AD intend to support the promulgation of this model.

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

"the indirect CRL being the trust anchor itself" would completely change 
the model since you would add local trust conditions for CRLs, in addition 
to the trust conditions for the certificates.

"certificate issued by the trust anchor that is used to build the certificate 
certification path" would be another case of trust conditions: 
beware, you are entering the zillion cases zone.

Denis

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