RE: [TLS] Record layer corner cases

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

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.

RFC 3280 (and draft 3280bis-05) clearly specify that trust
anchors are maintained out of band, and that trust anchor
information does not include a validity period any other
certificate fields except the four listed:

-----------------------------------------------------------------

      (d)  trust anchor information, describing a CA that serves as a
      trust anchor for the certification path.  The trust anchor
      information includes:

         (1)  the trusted issuer name,

         (2)  the trusted public key algorithm,

         (3)  the trusted public key, and

         (4)  optionally, the trusted public key parameters associated
         with the public key.

      The trust anchor information may be provided to the path
      processing procedure in the form of a self-signed certificate.
      When the trust anchor information is provided in the form of a
      certificate, the name in the subject field is used as the trusted
      issuer name and the contents of the subjectPublicKeyInfo field is
      used as the source of the trusted public key algorithm and the
      trusted public key.  The trust anchor information is trusted
      because it was delivered to the path processing procedure by some
      trustworthy out-of-band procedure.

------------------------------------------------------------------

A root CA certificate transmitted in a TLS handshake is neither a
trust anchor nor a component of the path to be validated.  It is merely
a hint to the relying party as to which trust anchor to use for path
validation in case the relying party has installed more than one
trust anchor key with the same issuer name.  If every trust anchor key
has a unique issuer name, sending root CA certificates in handshakes
is a pure waste of bandwidth without even the benefit of
minimizing trial signature verifications.

Dave


-----Original Message-----
From: Peter Gutmann [mailto:pgut001 at cs.auckland.ac.nz] 
Sent: Thursday, November 23, 2006 11:07 PM
To: martin.rex at sap.com
Cc: tls at ietf.org
Subject: Re: [TLS] Record layer corner cases

Martin Rex <martin.rex at sap.com> writes:

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

They just checked the DN and key and left it at that, since only
the date had changed the new cert was silently accepted.

>Maybe there should be some guidance, common sense doesn't seem to be
>sufficient (it took VeriSign several months to fix it when I complained
to
>them about their server misconfiguration/misbehaviour).


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