[TLS] Certificate alert severity

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

In Issue #84 (http://www3.tools.ietf.org/wg/tls/trac/ticket/84) Pasi writes:

    Currently bad_certificate, unsupported_certificate,
    certificate_revoked, certificate_expired, and certificate_unknown can
    be either warning or fatal; unknown_ca is always fatal.
    
    This is not fully consistent. Also, my understanding is that current
    implementations don't usually send these as warnings -- if the
    certificate is e.g. expired, but the user anyway accepts it (by
    clicking "OK" in browser), no alert is sent.
    
    Furthermore, I don't think sending them as warnings ("I think your
    cert is expired, but I'm going to accept it anyway") would really work
    -- I'd guess that many servers would get confused, and close the
    connection.
    
    This is related to Martin's comment (2007-12-06) about what servers
    should do if they receive a client certificate they don't like
    (e.g. can't chain to any trust anchor): should they send a fatal alert
    and close the connection (which seems to be what some implementations
    do today), or should they continue as if no certificate had been sent?

As far as I can tell, warning alerts (except for close_notify),
have turned out to be pretty useless. I would be fine with
making all of these fatal, but I'd like to hear comments from
the WG here...

-Ekr


_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls