Re: [TLS] Summarizing identity change discussion so far

[Martin Rex <[e-mail]>]

Kyle Hamilton wrote:
> 
> 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.


*I* would really prefer that a TLS spec does _NOT_ open that can of worms
called X.509 Certificate at all.

You don't know how many trust anchors there are (some software comes
preloaded with more than one hundred) and you don't know how long the
CA hierarchies are and whether those trust anchors all have path
length limits.  If you only look at Subject/sAN, you can be fooled
with certs from different CAs, and if add the issuer of the
end-entity cert, then you can be fooled if your attacker can
obtain a specific intermediate CA cert under some other root, and on and on.

I also see absolutely no reason to duplicate code and functionality
here that may get out of sync all too easily.

The application was able to perform the initial authentication
(log-on or ACL-check), so it is the duty of the application to
perform any reauthentication in the very same fashion when
renegotiation results in a different cert(chain).  Everything
else will result in endless pain.


...and that is a reason why personally, I prefer that the necessity
for cert renewal requires a new connection and full initial handshake--
because that is exaclty the code path which has all of the
functionality and checks that we are looking for!


-Martin