Re: Discussion of 6.1 for LC June

Thomas Roessler wrote:
> On 2008-03-21 07:51:53 -0400, Mary Ellen Zurko wrote:
> Instead, I'd propose to say this instead, also based on Yngve's
> message as quoted in [1]:
> 
> 	<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/):

CN = www.sierranevada.com
OU = Terms of use at www.verisign.com/rpa (c)05
OU = SNB
O = Sierra Nevada Brewing Co.
L = Chico
ST = California
C = US

This is typical of the AA certs out there, another example (QuoVadis - 
https://www.quovadis.bm/):

CN = www.quovadis.bm
OU = Web Services
O = QuoVadis Limited
L = Hamilton
ST = Pembroke
C = BM

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.

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

Cheers,

Johnathan

Received on Wednesday, 26 March 2008 01:50:59 UTC