On 16.07.2010 03:04, Nelson B Bolyard wrote:
> On 2010/07/14 22:07 PDT, Kaspar Brand wrote:
>> In any case, if you disregard CNs in the subject for name matching as
>> soon as there is a subjectAltName extension with at least one dNSName
>> (as draft-saintandre-tls-server-id-check-08 does), then it's becoming
>> a non-issue.
>
> Yes, but as I read it, people here are proposing to open the spec to say
> that multiple CN-IDs are just as acceptable as multiple DNS names in a
> SAN.
Acceptable in the sense that a certificate with multiple CNs and no
subjectAltName extension is treated the same as a certificate with
multiple dNSName entries in the subjectAltName extension, yes. When it
comes to name constraints, this BCP document now says what cert parts an
implementation should take into account as potential identifiers,
effectively closing a gap which is left between RFC 5280 and RFC 2818.
> SANs are having enough trouble getting off the ground. FAR too many
> people still think that CN-IDs are *THE* standard, and are utterly
> unaware of SANs. If we raise multiple CN-IDs to a status they did not
> enjoy with RFC 2818, then there will remain no motivation to use SANs at
> all, and constraints will die.
I'm not sure if beating people to use SANs by putting fierce
requirements into a BCP document ("MUST NOT put server names into CN
attributes") is the right way to evangelize them.
> Today, the ONE motivation to use SANs is to get multiple DNS names into
> a cert. And that brings with it the hope of constraints. Take away
> that sole motivation, and constraints die.
>
> Sorry, I'm repeating myself. This constraints issue is very important.
I have a somewhat different view, but it's also getting a bit off-topic
for this thread, I think. Just one point to be aware of: name
constraints will only take off if *all* relevant TLS toolkits implement
them - otherwise trying to constrain intermediate CAs (through an
extension which some will just ignore) is pretty pointless.
>> I'm doubtful if adding a MUST NOT for CN-IDs (vs. a SHOULD NOT) would
>> have a considerable impact on future CA practices. Most of them probably
>> don't want to risk compatibility issues with legacy implementations
>> (which don't recognize the subjectAltName extension).
>
> Can you name any browser or other important network client made in the
> last 8 years (since RFC 3280 was published) that does SSL3 and/or TLS
> but doesn't recognize DNS names in SANs?
"important" is a debatable term, but I'm pretty sure that as soon as you
leave the browser camp, you'll encounter quite a few... I didn't have to
search for a long time, actually: take wget as an example.
Kaspar
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
