Re: [TLS] Record layer corner cases

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

Kemp, David P. wrote:
> 
> 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.

I disagree.  This is about weeding out garbage.

> 
> The sensible thing to do in such a circumstance is to
> map the root certificate to a trust anchor:
> 
>    1) TA -> CA -> EE
>
> 
> 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

Correct.  SSLv3 (and probably TLS as well) supports only a straight
forward certification path, and if the local trust anchor happens
to be the rootCA cert, then I think it is correct to check that
rootCA cert during path validation in case the peer sends it.

> 
> 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.

>From my experience, Browsers do NOT entirely ignore a rootCA cert
sent in the SSL-Server's forward certification chain.

On a different occasion we ran into a problem with SSL server certs
issued from the GlobalSign RootCA when installed on our AppServer.

Web Browsers complained about an invalid certificate (not matching
the trust anchor) when connecting.  The problem turned out to be
that the GlobalSign RootCA cert is not valid ASN.1 DER.  Our
oem ssl software stores the RootCA (and other trust anchors)
in an unparsed format.  the signature of one's own rootCA is
retained in order to build forward certification pathes that
include the rootCA cert, however when reassembling the
GlobalSign RootCA cert with correct ASN.1 DER, the signature
no longer verifies...  And that caused the browsers to complain
(I don't remember whether all Browsers complained, and the
 original customer problem message has been moved to archive
 from our support system so I can no longer find it).

Personally, I dislike text in a specification that will result
in different, non-interoperable behaviour.  It would be much
better if all implementations did the same kind of tests so
that interoperability tests become meaningful.

In general, security software an protocols should be designed
so that they reliably fail if something is incorrect.  Every
attempt to ignore errors is a security problem waiting to happen,
just like planting land-mines -- and should be banned.

Ignoring errors is only acceptable when a spec explicitly
describes the particular error and provides exact details
what to do, so that everyone knows that the designed thought
about this problem and the resulting implementations are
all going to behave the same way.


-Martin

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