Martin Rex | 2 Jan 2007 17:31
Picon
Favicon

Re: TLS1.2: focus on non X.509 certs, cert URLs,

home_pw <at> msn.com wrote:
> 
> 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?

This is *NOT* about PKI.
It is about X.509 certificates and certificate chains.

It means that the client should search his credentials and see
whether there is a match between one of the CAs from that list
of the Server and the issuer field of the certificate of
the clients credentials (itself, or of (one) of its chain(s)).

If there's at least one match, the client can use that credentials
for client authentication, including the certification path up
to at least the matching CA from the servers list.

(Continue reading)

home_pw | 31 Dec 2006 20:58
Picon
Favicon
Gravatar

Re: TLS1.2: focus on non X.509 certs, cert URLs, authoirzation spaces, registration practices

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 <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls

Gmane