Re: [TLS] matching identity, by default

PKIX -- as a subset of X.509 -- states that the Subject and Issuer
together describe the identity.  Specifically, the Subject contains
the (unique) moniker for the entity which the certificate has been
issued to.  The Issuer describes which trust anchor to use to verify
the signature.

(Trust anchor management is horrible, and there's been no discussion
of any UI to state that, for example, the "Snake Oil RSA Root" and
"Snake Oil EC Root" are really the same Authority, simply with a
different TA.)

I believe that this specific issue (identity) is out of scope of TLS,
and is within the scope of PKIX.  Specifically, they've already
defined a way to compare identities with certificates, and it
certainly isn't with a bitwise comparison of an expired certificate!
(Hint: the Subject contains several Directory Components, and each of
those should be compared, if you want to verify that the identity
hasn't changed.)

In the alternative, I believe that the bit-wise comparison is worse
than useless, and I believe that the "MAY" should be changed to a very
strong "SHOULD".

-Kyle H

On Tue, Dec 1, 2009 at 6:38 AM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
>
>
> James Manger wrote:
>> I strongly support the consistent identity check in the Security Considerations section of draft-ietf-tls-renegotiation-01.
>
> Fair enough.
>
>> There may be some niche uses of TLS for which changing an identity during renegotiation makes sense. That is adequately supported by the last paragraph in the Security Considerations: "A TLS library MAY provide a means for the application to allow identity and/or server_name changes across renegotiations...". However, for 99.9...% of TLS uses an identity changing during renegotiation will be totally unexpected by the higher-layer application and can only cause problems.
>
> I'd buy that.
>
>> A few people have argued that the consistent identity check is a separate issue that should not be addressed now. I don't think that is a fair characterisation.
>
> I'm not sure what you mean by "characterisation."
>
> My point was simply that this *is* a different issue from the
> renegotiation bug, that we're fixing that bug in "emergency"
> mode and that we therefore shouldn't change *anything* else
> whilst in that mode.
>
> To give one example - rfc 2712 says how to use kerberos with
> TLS. (I've no idea if that's really in use.) The text in -01
> doesn't say how to handle that, but does have a MUST on
> no-change. That could break something. I don't want to hold
> the bug fix while we figure that out.
>
> I just thinks its safer to do this later with some other draft
> that UPDATEs 5246.
>
> Stephen.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>