Re: fyi: draft BCP on domain names in TLS/SSL certs - DNS names in SANs (was: Project Kickoff: Updating the Mozilla CA Certificate Policy)

[Kathleen Wilson]

On 10/3/10 6:26 PM, =JeffH wrote:
> I note that domain names (DNS names) in certs -- which field(s) to place
> them in and other aspects -- is an item noted in
> <https://wiki.mozilla.org/CA:CertPolicyUpdates> as well as in both
> Problematic and Recommended practices.
>
> This being an explicit item of consideration, and your having noted in
> the descriptions having the ecosystem migrate to new behavior (DNS names
> in SANs rather than in Subject:CN) means the thinking evidenced here
> intersects largely with the (draft) BCP I and Peter Saint-Andre are
> working on in the IETF..
>
> http://tools.ietf.org/html/draft-saintandre-tls-server-id-check
>
> This is a headzup that we are working on this and are processing
> IETF-wide Last Call comments on it. The spec is being discussed
> primarily on the certid@ list..
>
> https://www.ietf.org/mailman/listinfo/certid
>
> ..if folks here have feedback on the it, please send it in. Also, once
> the spec becomes and RFC (and BCP), it may be appropriate for it to be
> referenced by the "Updating the Mozilla CA Certificate Policy" project
> docs.
>
> thanks,
>
> =JeffH

I added a sub-bullet to the "DNS names in SANs" item with a link to the
draft.

* See also section 4.4.4 of IETF Draft spec on TLS Server ID Checking.

Thanks,
Kathleen

[Jean-Marc Desperrier]

=JeffH wrote:
> This being an explicit item of consideration, and your having noted in
> the descriptions having the ecosystem migrate to new behavior (DNS names
> in SANs rather than in Subject:CN) means the thinking evidenced here
> intersects largely with the (draft) BCP I and Peter Saint-Andre are
> working on in the IETF..

Indeed. Unfortunately that draft is beginning to be used as a reason to
continue using DNS names in Subject:CN.

I think it would be better if the final version of it were to seriously
obsolete that practice in the "SHOULD accept" - "MUST NOT produce" manner.

[Peter Saint-Andre]

That's where we would like to end up, and we tried to move in that
direction with this RFC. I expect the RFC to be obsoleted with an
revised spec in the next few years, and at that time I hope that we can
say "MUST NOT put the DNS domain name in the Subject".

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Eddy Nigg]

On 04/29/2011 04:59 PM, From Peter Saint-Andre:

> That's where we would like to end up, and we tried to move in that
> direction with this RFC. I expect the RFC to be obsoleted with an
> revised spec in the next few years, and at that time I hope that we can
> say "MUST NOT put the DNS domain name in the Subject"

However I believe compliance should be first enforced in the software,
meaning that they should stop checking for it in the common name field.
Only after that CAs can happily refrain from including them in the CN,
otherwise their certs will not work.

And even Apache still checks for the common name and omits a warning if
the that doesn't match the configured host.

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[Peter Saint-Andre]

On 4/29/11 10:03 AM, Eddy Nigg wrote:
> On 04/29/2011 04:59 PM, From Peter Saint-Andre:

>> That's where we would like to end up, and we tried to move in that
>> direction with this RFC. I expect the RFC to be obsoleted with an
>> revised spec in the next few years, and at that time I hope that we can
>> say "MUST NOT put the DNS domain name in the Subject"
>

> However I believe compliance should be first enforced in the software,
> meaning that they should stop checking for it in the common name field.
> Only after that CAs can happily refrain from including them in the CN,
> otherwise their certs will not work.
>
> And even Apache still checks for the common name and omits a warning if
> the that doesn't match the configured host.

Yes, I think in general the leadership here needs to come from the
community of server (often web) developers, client (often browser)
developers, and certification authorities. The spec that Jeff and I
worked on tried to capture the best current practices, but publishing a
spec doesn't change the reality on the ground.