Re: Discussion of 6.1 for LC June

Thomas Roessler wrote:
> 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".

Well, the 2818 text there is unclear about whether/how wildcards
match when in CNs; the last sentence talks about "Names" in the
context of dNSName but says nothing about CN values (which to
a purist, are not "Names" but component(s) thereof;-).

Anyway, I guess whatever browsers actually do is the right thing
to follow with CN wildcards. Do they behave the same or not? If
so, what do they allow? (e.g. "www*.*.com" "w*w.*i*.com" "www.*.*")
This was discussed at the last PKIX meeting where the WG decided
(wrongly IMO) not to further specify this, but to leave it to
some future update to 2818 (and a similar SIP document, and one
for RADIUS/Diameter,...).

S.

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

Received on Wednesday, 26 March 2008 11:50:03 UTC