RE: [TLS] Record layer corner cases

["Kemp, David P." <DPKemp at missi.ncsc.mil>]

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.

Unlike S/MIME, the TLS spec requires transmission of a
complete cert chain from EE to TA.  However, if TLS requires
that a transmitted root cert be used as a component
of a path as in 2), not just a TA hint as in 1), then the
TLS spec is broken.  I don't believe that's the case:
SSL or TLS do not require that a transmitted self-issued
cert be used as both a TA hint *and* a path component.

Dave


-----Original Message-----
From: Martin Rex [mailto:martin.rex at sap.com] 
Sent: Monday, November 27, 2006 12:12 PM
To: Kemp, David P.
Cc: pgut001 at cs.auckland.ac.nz; martin.rex at sap.com; tls at ietf.org
Subject: Re: [TLS] Record layer corner cases

Kemp, David P. wrote:
> 
> There is no misbehavior involved at all, and no reason to
> complain to VeriSign about any dates contained in a rootCA
> certificate.  In fact, VeriSign could have made the nature
> of trust anchor information more explicitly obvious if they
> had stuck in a validity period of Jan 1, 1900 0000Z -
> Jan 1, 1900 0000Z.  Including nonsense in the certificate
> fields that are not part of a trust anchor makes it obvious
> that the certificate is just a data structure that is being
> re- (or mis-)used to convey trust anchor information.

I do not mind about not checking validity dates (or even signatures)
on trust anchors.  But when an X.509 certficates is sent as part of
a certification path, then it is not a trust anchor, but instead
a regular certificate -- and therefore MUST be a correct certificate
(or not be sent in a certification path!).


-Martin

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