Re: [TLS] Summarizing identity change discussion so far

[Martin Rex <[e-mail]>]

Kyle Hamilton wrote:
> 
> On Tue, Dec 8, 2009 at 1:13 AM,  <[e-mail]> wrote:
> > (wearing Area Director hat)
> >
> > - We recommend that TLS libraries SHOULD provide identity matching
> > (with memcmp, abort handshake if changed) functionality to
> > applications, and SHOULD allow applications to enable/disable this
> > functionality.
> 
> No, identity matching SHOULD be done in accordance with PKIX.  memcmp
> is not at all sufficient.
> 
> However, I would support the following:
> 
> - TLS libraries SHOULD provide identity matching services between and
> throughout renegotiation handshakes.  Libraries SHOULD implement this
> in accordance with PKIX [PKIX], but MAY do so with a direct memory
> comparison.  Implementors are cautioned that this latter approach does
> not provide for changing the cipher parameters -- such as a
> renegotiation with an EC or DH certificate after identification with
> an RSA certificate.  If the identity matching service fails to match
> the identity, implementations MUST abort the handshake with a fatal
> bad_certificate alert.

The way the TLS specifications are currently archtected, this is
a service that is _not_ available from TLS.

Although there is likely some PKI(X)-Software available to the
TLS implementation for the X.509 stuff and certificate path validation
processing, but it can easily be that it is a completely different
module.

If an application currently wants to look at the contents of
the certificates exchanged and authenticated during the TLS handshake,
then this is explicitly declared out-of-scope for TLS in the base spec
(RFC-5246, section 1. last paragraph).  I would strongly recommend
to leave the code slicing (modularization) between application,
PKI-Software and TLS-implementation outside the scope of this spec.


-Martin