W3C home > Mailing lists > Public > public-wsc-wg@w3.org > April 2008

Re: Odd/bad sentence in 5.4.1

From: Thomas Roessler <tlr@w3.org>
Date: Tue, 15 Apr 2008 21:24:18 +0200
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: 'W3 Work Group' <public-wsc-wg@w3.org>
Message-ID: <20080415192417.GQ345@iCoaster.does-not-exist.org>

I have re-added relaxed path validation to the editor's draft

Relevant pieces of text:

- http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-evcert

  User agents MUST NOT use Relaxed Path Validation to validate paths
  that lead to an AA-qualified trust root. Instead, Basic Path
  Validation MUST be used.
- http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-validated-certificates

  User agents MAY use Relaxed Path Validation for certificate paths
  that chain up to a locally configured trust anchor which is not

- http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-pathval

  (not copying that text here)
- http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors

  When, for a TLS-protected HTTP connection, the certificate
  presented is found to have been expired, error signalling of class
  danger (6.4.4 Danger Messages) MUST be used. Note that user agents
  that apply Relaxed Path Validation to non-AA certificates will
  never detect this error condition for such certificates.

I'll put this on the agenda for tomorrow, which I'll circulate

Thomas Roessler, W3C  <tlr@w3.org>

On 2008-04-04 15:29:00 +0100, Stephen Farrell wrote:
> From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
> To: Stephen Farrell <stephen.farrell@cs.tcd.ie>,
> 	'W3 Work Group' <public-wsc-wg@w3.org>
> Date: Fri, 04 Apr 2008 15:29:00 +0100
> Subject: Re: Odd/bad sentence in 5.4.1
> List-Id: <public-wsc-wg.w3.org>
> X-Spam-Level: 
> Authentication-Results: mx.google.com; spf=pass (google.com: domain of public-wsc-wg-request@listhub.w3.org
> 	designates as permitted sender) smtp.mail=public-wsc-wg-request@listhub.w3.org
> Archived-At: <http://www.w3.org/mid/47F63B2C.90201@cs.tcd.ie>
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6
> 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 Tuesday, 15 April 2008 19:24:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:21 UTC