Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3?

[Eric Rescorla <[e-mail]>]

CertificateRequest already allows you to pass an arbitrary number of
extensions by OID.

http://tlswg.github.io/tls13-spec/#certificate-request

What more do you think you need?

-Ekr


On Tue, Mar 8, 2016 at 12:22 AM, Henry Story <[e-mail]>
wrote:

> Hi,
>
>
>   I was reading with interest M. Thomson and M. Bishop's
> "Reactive Certificate-Based Client Authentication" draft RFC [1].
> In the section 2.3 "The CERTIFICATE_REQUEST Frame"
>
> [[
>       CA-Count and Certificate-Authorities:  "Certificate-Authorities" is a
>       series of distinguished names of acceptable certificate
>       authorities, represented in DER-encoded [X690] format.  These
>       distinguished names may specify a desired distinguished name for a
>       root CA or for a subordinate CA; thus, this message can be used to
>       describe known roots as well as a desired authorization space.
>       The number of such structures is given by the 16-bit "CA-Count"
>       field, which MAY be zero.  If the "CA-Count" field is zero, then
>       the client MAY send any certificate that meets the rest of the
>       selection criteria in the "CERTIFICATE_REQUEST", unless there is
>       some external arrangement to the contrary.
> ]]
>
> Would it not be possible to extend that so that one could also pass
> issuer Alternative Names, and not just DNs?
>
> Using DNs made sense when it was thought that LDAP and X500 would
> end up being the protocols for global directories. This turned out
> not to be the case. It turned out that DNs were a special case of
> what could be termed a URI (even though DNs are not in URI format).
> And many (most?) URIs can refer to agents, least but not last
> http(s) URLs (See the WebID spec [2] for a nice diagram of how this
> works conceptually and the WebID-TLS spec for one way this can be tied
> to TLS [3]).
>
> If TLS1.3 could start moving away from sole reliance on DNs this
> would open quite a lot of possibilities, including the ability to
> build institutional Webs of trust for CAs (ie trust anchors could
> list CAs by reference at one or more levels of indirection), and CAs
> could also describe themselves at their URI.
>
> Those last two paragraphs are just hints of some possibilities that
> could emerge from moving away from DNs that I can think of. Others
> members of this group will certainly find other possibilities.
>
> In any case it seems that the time for DNs is passed, and that
> one should perhaps move away from reliance on those and generalise
> this part of TLS.
>
> Henry
>
>
>
> [1] https://tools.ietf.org/html/draft-thomson-http2-client-certs-01
> [2] https://www.w3.org/2005/Incubator/webid/spec/identity/#overview
> [3] https://www.w3.org/2005/Incubator/webid/spec/tls/
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>