Re: [TLS] Summarizing identity change discussion so far

I'm jumping in late (what would you expect from somebody on vacation :-), but most of what I may want to say is already eloquently put by Kyle. 

I agree with him points - including (and especially!) those made about WG defining & hard-coding inflexible policies (stated in subsequent postings).

----- Original Message -----
From: tls-bounces@ietf.org <tls-bounces@ietf.org>
To: Pasi.Eronen@nokia.com <Pasi.Eronen@nokia.com>
Cc: tls@ietf.org <tls@ietf.org>
Sent: Thu Dec 17 16:37:15 2009
Subject: Re: [TLS] Summarizing identity change discussion so far

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.

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