RE: [TLS] Record layer corner cases

We are not discussing weeding out garbage sent by a
peer, we are discussing a peer that sends (hypothetically)
exactly three certs: root, CA, and EE.

The sensible thing to do in such a circumstance is to
map the root certificate to a trust anchor:

   1) TA -> CA -> EE

And in fact, you indicated that that is exactly the
observed behavior:

> A few years ago, www.verisign.com had been sending
> out an expired rootCA certificate in the certification
> path of the Server, and curiously, none of the Web Browsers
> complained when it had a replacement cert (same
> Subject&Issuer, same key, longer validity) in the list
> of trust anchors.

This discussion is about why the observed behavior is correct.

You argue that a TLS receiver should go out of its way to
build a second, longer path that contains the root certificate:

   2) TA -> Root -> CA -> EE

just so it could reject that path, but that is not how either
PKI fanciers or TLS implementers intend root certificates
to be used.  Root certs are *not* part of a certification
path, they are convenient containers for conveying trust
anchor information, and everything else in them (including
signature and validity) can (and should, to minimize load
on busy servers) be safely ignored during path validation.

Dave

--------------------------------------------------
Martin Rex <martin.rex@sap.com> writes:

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