Re: authmeth-16 TLS issues

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Roger Harrison writes:
>> 3.1.5. Server Identity Check
>>
>> Why are the checks to perform ordered?  The order seems irrelevant
>> since there is no fail and don't check anything else step.
>
> There is some preference in the order. Typically, the original value of
> the reference identity is the most authoritative information available
> to the client regarding the server's identity and thus is preferred over
> other forms of that identity to which it can be mapped.  I believe the
> intent behind this preference is adequately implied with the text in
> step 2 indicating that only secure mappings should be used.

No - I cannot find anything in the draft which will behave differently
if the client chooses to disobey the specified ordering of the check.
What's the point of making a certain behaviour an error if that
behaviour is indistinguishable from the correct behaviour?

Which is why I asked/suggested:

>> If the reason is that clients can derive a security factor or something
>> from which identity was used, please mention that.
>>
>> But if so, I wonder a bit about CN vs. subjectAltName.  If the CN is an
>> exact match and the subjectAltName is either a wildcard match or matches
>> via a derived name, the CN would be a more reliable match and should be
>> done first.  Or...?
>
> I don't understand all of the history behind this, but the use of
> subjectName appears to be deprecated widely.  The RFC on secure HTTP
> (I don't have the RFC # handy) explicitly deprecates using subjectName
> and favors the use of subjectAltName.

s/subjectName/commonName/.

I don't see how that affects the argument above, though.  If the
implementation supports checking CN or subjectName at all and that is
more precise than the subjectAltName, then that is still the best match.
Of course fit could just be that I guessed wrong the reason to have an
ordering.

I don't see a reason in RFC 2818 for the ordering either.

> In speaking with the certificate
> expert in Novell's security team in preparation to rewrite the server
> identity check section, I received the same feedback. If you'd like me
> to track down specifics on the reasoning, I could do so.

I have no objection to deprecating cn or subjectName or whatever,
it's the logic of what [authmeth] does about it I can't figure out.

>> 3.1.5.1. Comparison of DNS Names
>>
>> > If the reference identity is an internationalized domain name,
>> > conforming implementations MUST convert it to the ASCII Compatible
>> > Encoding (ACE) format as specified in section 4 of RFC 3490 [RFC3490]
>> > before comparison with subjectAltName values of type dNSName.
>>
>> Only for subjectAltName:dNSName, not for CN?
>>
>> If that's deliberate and certificate CNs may not contain
>> internationalized domain name, I suggest this is mentioned explicitly.
>
> The text in step 3 says that the comparison [of the commonName value of
> the RDN from the subjectName] is performed using the [rules for]
> comparison of DNS names in section 3.1.5.1.  I assumed that if the CN
> value was an IDN that the IDN rules would take effect as part of the
> check. Perhaps we need to say something about how to tell if the CN
> value is an IDN as well?  I'm not familiar with how one determines the
> difference. Do you know?

Not a clue.

-- 
Hallvard