|
> 3.1. Sequencing of the StartTLS Operation > > This header name seems poor, sections 3.1.* describe much more than > sequencing. It's mostly 3.1.1 which talks about that ‑ except that the > actions described in sections 3.1.* should be performed in the sequence > they occur in in the draft.
I've renamed Section 3.1 to "TLS Establishment Procedures".
> > > 3.1.1. StartTLS Request > 3.1.2. StartTLS Response > > If last sentence of 3.1.2 is moved to [protocol] as I suggested in > thread "[Protocol] clarification on StartTLS resonse", maybe these two > sections should be merged. There wouldn't be much left of 3.1.2, and > 3.1.1 already talks a bit about the response anyway
I agree. I've removed section 3.1.2
> > > 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. The use of the subjectName value in step three is deprecated and thus should be used as a last resort. Thus the comparison with subjectAltName values in steps 1 and 2 are preferred ahead of step 3.
> > 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. 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.
> > > 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?
> ‑‑ > Hallvard >
Roger |