|
Concerning 7.4.5. Certificate request
"A list of the
distinguished names of acceptable
certificate
authorities. These distinguished names may specify a desired distinguished name for a root CA or for a subordinate CA; thus, this message can be used both to describe known roots and a desired authorization space. If the certificate_authorities list is empty then the client MAY send any certificate of the appropriate ClientCertificateType, unless there is some external arrangement to the contrary." So, what does this all really mean, just staying within the
traditional PKI world?
Rather than send a simple list of root DNs, we are now sending 2 different
signals?
For a list of 4 DNs, Are we saying that element 1 might point to a
root, but 2 to
a CA within that root's certification domain? And then for 3 and 4
something
similar for a different certification domain?
If I understand what is being specified:
1. its up to the client to figure out which DN has which semantics; there
is NO ordering
2. its up to the client to figure out that a subordinate CA is indeed
controlled by some root
(e.g. name hierarchy, following hash chaining in PKIX cert
extensions)
3. an intended model for "authorization space" (a subordinate CA) might be:
the CA for
;organizational' certs, vs the CA for "individual" certs (in a
military messaging system context).
However, this has nothing to do with "authorization certs", SAML
authorization assertions, etc.
This text has been in this section since TLS 1.0. So, Is this
actually used widely in this 2 signal
mode...as it seems it MUST?
I'm guessing at its intended application, in 3. The text in the standard on
this
is woefully inadequate. It could mean something entirely different:
identify the
BridgeCA as root, and then the Agency CA as "authorization space".
This needs expanding.
|
_______________________________________________ TLS mailing list TLS@xxxxxxxxxxxxxx https://www1.ietf.org/mailman/listinfo/tls