Re: [TLS] Record layer corner cases

[Martin Rex <martin.rex at sap.com>]

SSLv3 didn't say whether the certification path includes a rootCA
(=self-signed) cert or not, i.e. the spec was ambiguous.

TLSv1 improved the situation, indicating that the path may or may not
contain a rootCA (=self-signed) cert, and mentioned that such a cert,
if present, should not have an impact on the decision whether the
peer's certificate is trusted.

Kemp, David P. wrote:
> 
> The objective of path validation is to ensure that a valid path
> exists from an end entity certificate back to a trust anchor.
> If a self-issued certificate is transmitted as part of a path
> and its name and key are also used as a trust anchor, then there
> are many paths that will satisfy signature/name chaining:
> 
> 1) TA -> CA Cert -> EE Cert
> 2) TA -> Root Cert -> CA Cert -> EE Cert
> 3) TA -> Root Cert -> Root Cert -> CA Cert -> EE Cert
> 4) TA -> Root Cert -> Root Cert -> Root Cert -> CA Cert -> EE
> 5) ...
> 
> If the root cert has a bad validity, then path 2) will not
> validate.  However, in order to authenticate the end entity,
> it is sufficient that path 1) validates.  The fact that there
> are any number of invalid paths from EE to TA does not negate the
> fact that there is at least one valid path.

I don't know whether the PKI fanciers have specified this anywhere,
but I would consider it seriously braindead if there was such a
path validation algorithm.

If a path can be built, it must verify.  If a path can not be built,
it can not be verified and must be ignored.

Requiring the receiver to weed our garbage sent by the peer is
asking for (interoperability) troubles, and a serious waste of
every receives resources (especially for busy servers).


-Martin

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls