Re: [TLS] Summarizing identity change discussion so far

mrex@sap.com wrote:

> Kyle Hamilton wrote:
> >
> > On Tue, Dec 8, 2009 at 1:13 AM,  <Pasi.Eronen@nokia.com> 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.

Yes the problem is defining what an identity change is precisely.  We know
that CA's load all sorts of stuff in to certificates as part of the DN etc
and the same identify could have multiple certificates, and could be
identified by multiple CAs.  If we say that in TLS we are going to check
identity then it has to be very precisely defined, or extremely vaguely
defined so that the implementation can not be accused of non compliance or
invalid/suspect identity matching.  Perhaps it needs to be a vague as
possible so that TLS implementation can simply push it back to the
application layer in practice

- Mick
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls