Re: Odd/bad sentence in 5.4.1

Thomas Roessler wrote:
> I'll look into reviving Relaxed Path Validation and linking to it
> from the error part.  Stay tuned.

Will do.

> 
> (ACTION-414)
> 
>>> The text that Stephen spotted is the flip side: *If* there are
>>> validity checks, then please do them thoroughly and treat
>>> expiration as the hard error.  If you don't do the validity
>>> checks, then don't bother with expiry checks.
> 
>> If a certificate is expired, or not yet valid, a sensible UA
>> won't bother asking about revocation (modulo the corner-case)
>> because there's no guarantee of an answer. So no status check
>> need be performed for that certificate.
> 
>> With the current text, if the UA ever checked status for any
>> cert, then its supposed to consider all not-yet-valid and expired
>> certs to be revoked.
> 
>> So, even if we stick with the current intent, wordsmithing will be
>> needed. (But let's thrash on the intent first.)
> 
> So, to get the intent clear: If UA would do validation check during
> the certificate's validity period, then it must consider an invalid
> certificate as a hard error.  Does that make sense in your view?  Or
> are you suggesting a different approach?

Your wording's unclear there though, so I'm not sure. I think the
following are true:

- If a relying party does certificate status checking and finds that
a certificate is revoked, then that's a hard error.

- If the current time is outside the certificate validity period (or
that of a superior ca cert on the path) AND the relying party is
not doing relaxed path validation, then the certificate is invalid,
and that's a hard error.

- If an RP is doing relaxed path validation, then it can ignore
the current time when considering notBefore and notAfter fields.

I'd be open to allowing non-overlapping validity periods in cert
paths when doing relaxed path validation, but there's probably no
point if the underlying crypto APIs already insist on some overlap.
(Which I think is the case, can't recall really.)

S.

Received on Friday, 4 April 2008 14:29:32 UTC