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

> On 8 Mar 2016, at 09:30, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> CertificateRequest already allows you to pass an arbitrary number of
> extensions by OID.
> 
> http://tlswg.github.io/tls13-spec/#certificate-request <http://tlswg.github.io/tls13-spec/#certificate-request>
> 
> What more do you think you need?

Perhaps what would be needed in addition would be wildcard support.

Eg, it would be useful to say: Give me certificates that contain an extension without
specifying the value of the extension. Eg: give me a certificate that contains a 
SAN or IAN, I don't care what value of those are.

Is that allowed? I don't see anything regarding it when reading that section. But
I may be missing something.

> 
> -Ekr
> 
> 
> On Tue, Mar 8, 2016 at 12:22 AM, Henry Story <henry.story@bblfish.net <mailto:henry.story@bblfish.net>> 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 <https://tools.ietf.org/html/draft-thomson-http2-client-certs-01>
> [2] https://www.w3.org/2005/Incubator/webid/spec/identity/#overview <https://www.w3.org/2005/Incubator/webid/spec/identity/#overview>
> [3] https://www.w3.org/2005/Incubator/webid/spec/tls/ <https://www.w3.org/2005/Incubator/webid/spec/tls/>
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 