Re: [TLS] Summarizing identity change discussion so far

[Kyle Hamilton <[e-mail]>]

I'll just state this: I believe that defining the semantics of
identity credentials provided during the course of the TLS protocol's
execution is NOT within the legitimate realm of the design of the TLS
protocol.  TLS explicitly references PKIX, and PKIX is really the only
place that uses 'identity', but (on further reading) it doesn't
describe precisely what 'identity' is.

So, I'll take a stab at a potential guidance for those who don't have
the time to research in-depth, taking into account Pasi's and
everyone's ideas: If there is a match between ANY one of the new
certificate's Subject/sAN and the old certificate's Subject/sAN,
including all path components in the same order for that entity, AND
is issued by the same authority, it SHOULD be regarded as being the
same identity, though exceptions will undoubtedly exist.  Differences
in the Certificate Policy, kU, or eKU fields SHOULD be evaluated as
well, to ensure that the new certificate is valid for the kind of
connection and transactions being performed.

The only thing that SHOULD modify the default behavior (defined as
"all 'MUST*' and 'SHOULD*' but no 'MAY*'") is the implementation of a
security policy.  If such a security policy exists but has no
information on this topic, the defaults SHOULD control (unless there's
a very, very good reason not to).

-Kyle H

On Thu, Dec 17, 2009 at 4:50 PM, Blumenthal, Uri - 0662 - MITLL
<[e-mail]> wrote:
> 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: [e-mail] <[e-mail]>
> To: [e-mail] <[e-mail]>
> Cc: [e-mail] <[e-mail]>
> 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,  <[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.
>
> -Kyle H
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>