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
