> On 8 Mar 2016, at 09:30, Eric Rescorla <e...@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.st...@bblfish.net > <mailto: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 > <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> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
