Re: [TLS] Summarizing identity change discussion so far

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> Michael Gray wrote:
> > 
> > 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
> 
> It does seem that in many cases a memcmp() of the certificates is
> entirely appropriate. It's certainly a well-defined comparison and it
> avoids getting the TLS spec overly wrapped up in the details of PKIX.
> 
> As long as people don't start claiming memcmp() is some "official TLS
> definition of identity".

memcmp() is the TLS method to check that the TLS connection parameter
"peer certificate" is still the same after renegotiation.

Simililarly, memcmp() is the TLS extension RI method to check that
the client and the servers notion of the enclosing TLS session
is the same during renegotiation.


-Martin