Not yet a proposal: error conditions (ACTION-390)

I owe a proposal on error conditions, for section 5.4.  For the
certificate-related error part, I've reviewed the documentation that
KDE and Mozilla had submitted early last year:

  http://www.w3.org/2006/WSC/wiki/NoteMozillaCertificateValidationErrors
  http://www.w3.org/2006/WSC/wiki/NoteKDECertificateValidationErrors

From that documentation (and from an earlier review of RFC 3280 that
had fed into the FPWD), I think we basically have the following
error conditions to look at; note that this includes the "change
against historical practice" proposals that survived the meeting:

- URL does not match certificate subject

  -> worth a danger message for AA and domain validated
    certificates; not clear what it's worth for self-signed

- Path verification fails, because...

  - certificate is outside of its validity period

    -> unclear to me what we would call for.  This one can't be
       entirely separated from the CRL checks (see next one).
       Relaxed Path Validation (still in the current version of the
       spec) was one approach to addressing it.  Possibly
       differentiate between AA and other certificates.  Possibly
       use historical knowledge?

  - the certificate has been revoked

    -> danger message

  - a certificate status check was attempted, but didn't succeed
    (e.g., due to network issues)

    This one, too, isn't entirely obvious, and I don't think I have
    a coherent view of it. One approach might be another tie-in with
    browser history:

    -> if a certificate status check was successfully performed
       before, or if the certificate is augmented assurance, then
       use danger message

    -> if a certificate status check was not successfully performed
       before, then use warning

    (Serge suggested warning / caution for this.)

  - trust root is not known

    - self-signed certificate, not pinned

      -> if another self-signed certificate was previously pinned,
	 for this site, then MUST use a warning message

      -> if a validated certificate was previously used, then SHOULD
	 use a warning message, MAY use a warning message

      -> if the site wasn't previously visited, SHOULD use
         notification message, [ SHOULD | MAY ] offer pinning the
	 certificate

    - certificate chain leads up to an unknwon CA certificate

      I wonder if there is any justification for handling this
      differently than the self-signed case.  I'm inclined to merge
      the two.

  - otherwise (e.g., cryptographic signature doesn't match)

    -> danger message

- TLS negotiation fails

  -> danger message

Am I missing any conditions?

Johnathan, in NoteMozillaCertificateValidationErrors, I also see a
remark about "certificate is incomplete". Can you clarify what
precisely was meant by this?

Additional conditions that we might want to cover (from Serge's
material about error signalling):

- Anti-phishing heuristics triggered

  -> danger or warning?  (Serge says warning, I'd lean toward
     danger.)

- Blacklisted sites or downloads

  -> danger

Regards,
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Wednesday, 26 March 2008 00:37:20 UTC