Re: Discussion of 6.1 for LC June

On 2008-03-26 11:12:23 +0000, Stephen Farrell wrote:

> No. IA5String could be used to encode "Example Inc." Can't recall
> whether that still in use with current certs or not (the specs do
> encourage CAs to use UTF8, but I'm not sure if they're
> complying). Essentially I don't think there's any general way to
> know you've a DNS name in a CN. However, in our context, we can
> compare against the authority part of the URL the UA just
> de-referenced. So I'd say that if the authority part of the URL
> and the CN part of the cert match (exactly, case insensitive,
> modulo wildcards in the CN value) then you've got a DNS name in
> the CN. Might need to tweak that to cater for HTTP re-directs and
> I dunno if use of CNAME DNS RR's could be a glitch or not. I
> think if we did that we may also be the first ones to write down
> DNS wildcard matching rules for CN, e.g. would we like www.*.com
> to be a match for loads of stuff, but that's (IIRC) different
> from RFC 2818 which deals with wildcard matching for dNSName alt
> names.

Well, RFC 2818 defines the matching in 3.1, Server Identity:

   If a subjectAltName extension of type dNSName is present, that
   MUST be used as the identity. Otherwise, the (most specific)
   Common Name field in the Subject field of the certificate MUST be
   used. Although the use of the Common Name is existing practice,
   it is deprecated and Certification Authorities are encouraged to
   use the dNSName instead.

(Silent on how to distinguish between a useful-for-matching CN from
a human readable one.)

   Matching is performed using the matching rules specified by
   [RFC2459].  If more than one identity of a given type is present
   in the certificate (e.g., more than one dNSName name, a match in
   any one of the set is considered acceptable.) Names may contain
   the wildcard character * which is considered to match any single
   domain name component or component fragment. E.g., *.a.com
   matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com
   but not bar.com.

I guess all this suggests that "matches preferred domain name syntax
with wildcard" is the criterion for non-human-readable CNs, and the
criteria for OU, L, and O are "is present".

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

> Are there still certs around with "L=Internet" ? I guess they shouldn't
> crop up here, but just wanted to check.

Hopefully not for augmented assurance, which is what we're caring
about in this section, on the theory that subject information in
domain validated certificates is basically worthless.

>> 	<p>All Augmented Assurance Certificates MUST include
>> 	information that lets this algorithm terminate successfully,
>> 	i.e., return human-readable information.</p>
>> 	
>> Then, in 6.1, change
>>
>> 	"the Subject field's Organization attribute, if present"
>>
>> to:
>>
>> 	"human-readable information about the certificate subject,
>> 	derived as specified in <specref ref="sec-evcert"/>."
>>
>> I'm tentatively making these changes to the editor's draft.
>>
>> 1. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Mar/0142.html
>>
>> Regards,
>
>

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

Received on Wednesday, 26 March 2008 11:37:22 UTC