Re: ACTION-580: Consider 5.1.2 cleanup

Excellent. Looks good to me. 





From:   Thomas Roessler <tlr@w3.org>
To:     WSC WG public <public-wsc-wg@w3.org>
Date:   05/05/2009 07:53 AM
Subject:        ACTION-580: Consider 5.1.2 cleanup
Sent by:        public-wsc-wg-request@w3.org



Current text marked as quoted...

> Some trust anchors adhere to documented broadly accepted practices 
> (e.g. [EVTLSCERT]) that involve some level of guarantee that 
> certificates chaining up to those roots embody augmented assurance 
> and can therefore be treated more favorably in terms of the primary 
> security indicators.
>

 >>> Add:

We call such certificates "augmented assurance certificates".

[Definition: An Augmented Assurance Certificate (AAC) is a public key 
certificate where the issuer asserts that the subject entity has been 
authenticated by means of some process that adheres to the 
requirements of an augmented assurance specification supported by the 
Web user agent. The certificate chain for such a certificate MUST be 
validated up to a trust root that is recognized as augmented assurance 
qualified by the user agent.]

> Web user agents MUST establish that a trust anchor is [Definition: 
> augmented assurance qualified ] through some out of band mechanism 
> consistent with the relevant underlying augmented assurance 
> specification.

 >>> Change to:

This specification does not define what an "augmented assurance 
qualified trust root" is, except to note that this designation is made 
by user agents through an out of band mechanism consistent with the 
relevant underlying augmented assurance specification.

> Marking a trust anchor as augmented assurance qualified is a 
> security-critical step and most often will involve the use of some 
> application-specific out-of-band mechanism.
>

> Implementations MUST NOT enable users to designate trust roots as 
> augmented assurance qualified as part of a different interaction. In 
> particular, the notions of an augmented assurance qualified trust 
> root and aninteractively accepted trust root are mutually exclusive.
>

> In addition to the out of band designation process described above, 
> the trust anchor, and possibly all certificates in a path chaining 
> up to such a trust anchor may need to be specially marked, e.g. 
> through the use of specific policy object identifiers.
>

> The specific marking mechanisms to be used and the special treatment 
> to be afforded to such certificates are out of scope of this 
> document, but will typically be covered by the underlying augmented 
> assurance specification. Web user agent implementors determine the 
> set of such standards that they support and the associated special 
> treatment to apply, other than as outlined below, where we impose 
> some consistency requirements on the handling of this type of 
> certificate.

 >>> The previous definition of AAC was here; moved up.

> To derive a human-readable subject name from an AAC, user agents 
> MUST use the Subject field's Organization (O) attribute.
>

> If the certificate's Subject field does not have an Organization 
> attribute, then user agents MUST NOT consider the certificate as an 
> augmented assurance certificate, even if it chains up to an 
> augmented assurance qualifiedtrust root. User agents MAY consider 
> such a certificate as an ordinary validated certificate.
>

> Note: Should certificates arise in the future that provide strong 
> assurance of the holder's identity, but do not include an 
> organization attribute, then user agents can make use of the 
> additional assurance level and identity information without 
> violating this specification. Such future certificates could, for 
> example, include high assurance certificates for individuals.
>

--
Thomas Roessler, W3C  <tlr@w3.org>