Re: Discussion of 6.1 for LC June

On 2008-03-25 21:49:46 -0400, Johnathan Nightingale wrote:

>> 	<p>To derive a human-readable name from an AAC, user agents
>> 	MUST use the first of the following fields that is human-readable:</p>
>> 	
>> 	<olist>
>> 	<item>the Subject's Common Name (CN) attribute;</item>
> ...
>>
>> 	<item>the Subject's Organizational Unit (OU) attribute, in
>> 	combination with its Location (L) attribute;</item>
>> 	<item>the Subject's Organization (O) attribute.</item>
>> 	</olist>
>
> This seems like the inverse of intended order.  To take Sierra Nevada 
> Brewing's EV certificate as an example (https://www.sierranevada.com/):

ok, in that case I simply misread Yngve's mail -- I had understood
"in order of priority" to be "most important first"; happy to turn
that around.

> Accordingly, it seems to me that the order should be O, then CN,
> and honestly I'd leave OU out of it, but feel free to slot it in
> somewhere if you think it appropriate.

I don't actually care either way, but would like to hear from Yngve
before dropping that one.

>> 	<p>All Augmented Assurance Certificates MUST include
>> 	information that lets this algorithm terminate successfully,
>> 	i.e., return human-readable information.</p>

> I don't think we have it in our scope to offer normative language on how CAs 
> issue certificates, (nor would we want to, I suspect) 

In general, I'd agree.  However, I do think it's appropriate to
spell out fundamental assumptions in terms of conformance clauses,
e.g. in this case.

> so this should probably read in terms of our own internal
> definition.  E.g.

>        <p>By definition, an Augmented Assurance Certificate will include
>        information that lets this algorithm terminate successfully, i.e.
>        return human-readable information.</p>

> (Possibly with appropriate tweaks to our definitions section, as well).

The trouble I have with this is that we have users or site
administrators possibly designating trust roots as being AA / EV.

So it is presumably worth spelling out a requirement on those who
generate certificates that they want to market to these
administrators as being EV certificates.  Of course, we can also add
the implementation flip side, e.g.:

    If the algorithm does not lead to human-readable information,
    user agents MAY consider a certificate to be a usual validated
    certificate, not an Augmented Assurance certificate, even if it
    chains up to a <termref
    def="id-augmented-qualified">AA-qualified</termref> trust root.

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

Received on Wednesday, 26 March 2008 08:26:31 UTC