Re: [TLS] Summarizing identity change discussion so far

[<[e-mail]>]

Kyle Hamilton wrote:

> 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.

Well, the text I proposed just said "different certificate", not
"memcmp". I know that's a bit vague, but "in accordance with PKIX
[PKIX]" is not very precise either, and would need a more specific
reference to where exactly the details are (for example, it can't mean
comparing the Subject field, since PKIX allows leaving it empty).

And the certificate might have extensions (certificate policies,
subject directory attributes, extended key usage, etc.) where changes
between API calls could surprise the application.

Here's another shot at that paragraph (also including suggestions
from Marsh's email):

   TLS implementations SHOULD offer the applications the option to
   disable renegotiation completely.

   To make life simpler for applications that do not expect the peer's
   certificate to change once it's been authenticated, TLS
   implementations may also wish to offer the applications the option
   abort the renegotiation if the peer tries to authenticate with a
   different certificate and/or different server name (in the
   server_name extension) than was used earlier. However, enabling
   this option by default for all applications could break existing
   applications that depend on using renegotiation to change from one
   certificate to another. (For example, long-lived TLS connections
   could change to a renewed certificate; or renegotiation could
   select a different cipher suite that requires using a different
   certificate.)

Best regards,
Pasi