Re: [TLS] Summarizing identity change discussion so far

[Martin Rex <[e-mail]>]

Martin Rex wrote:
> 
> Maybe we should at least mention one valid reason for why a certificate
> may change in the Security Considerations: certificate update/renewal.
> 
> There were two scenarios mentioned where this seems to be a
> regular use case IIRC.  Was it gaming where they were using quite
> short-lived certificates and then XMPP, where they were using
> quite long-lived connections?


Thinking about the "valid reason" scenarios for certificate change,
I'm slightly concerned about a potential disconnect between the
original and the later certificates if the application designer
is a little sloppy.

If a design expects certificate renewal to be necessary
(either short lived-certs or long-lived connections) then it is
imperative that the application performs a full re-authentication
when the identity changes during renegotiation.
A simple certificate path validation could in some situations
subvert a limited-time access restriction.


Normally, you will need a specific certificate for initial authentication,
because it is used for some kind of app-level logon-operation
or ACL-check.  When a renegotiation needs to be performed because of
the expiration of the users cert, and the app does _not_ re-do the
authentication logon/ACL-check, but relies blindly on the
certificate path validation, then the user could simply use
an entirely different certificate with a longer validity during
renegotiation, succeed certificate path validation and keep
using the resource beyond the expiration of the original
access credential/certificate.


-Martin