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 <henry.st...@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 > [2] https://www.w3.org/2005/Incubator/webid/spec/identity/#overview > [3] https://www.w3.org/2005/Incubator/webid/spec/tls/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
