Subject: [wpkops] ID:Browser processing of server certificates:Definitions

From: "Ben Wilson" <[email-masked]>
Date: Thu, 3 Oct 2013 18:32:11 -0600

Some of us are working on an Internet Draft titled, "Browser processing of
server certificates".  

Here are some draft definitions for terms that I think we'll be using:

Bypassable error - A behavior in which the browser detects an abnormal
condition and asks the user whether to proceed with (i.e. click-through to)
the SSL/TLS connection. 

Fatal error  -- A behavior in which the browser detects an abnormal
condition and halts (or technically cannot complete) session negotiation and
drops the connection or otherwise blocks the user from continuing (also
referred to as "hard fail"). 

Name mismatch - A condition detected by a browser in which no name in the
common name or subject alternative name for the subject in the certificate
matches the hostname sought by the client (i.e. the client's reference
identity - usually a Fully Qualified Domain Name - is not in the
certificate).  

Pinned - A condition in which the association between two or more aspects of
the entity-public-key relationship (e.g. server name, public key, CA,
certificate) are configured and set in the browser before initiation of a
TCP connection.  

Stapled - A condition in which information related to the server's
certificate (e.g. OCSP response) is delivered by the server to the client as
part of the SSL/TLS handshake, and not by direct communication with the
issuing CA. 

Visual indicator - A behavior in which the browser changes the color(s)
and/or intensity of pixels on a screen in the browser chrome to indicate a
changed condition.

Wildcard character - An asterisk - *  (Unicode 2A). 

We're welcome to ideas on how to fine-tune them.  I'd prefer that they be
broad enough to include lots of uses-leaving clarification for their
particular use for description in the text.  

Additional definitions might include:  "browser chrome", warning, dialog
box, blacklist, and whitelist-but at this point I don't think they need to
be defined.  I'm mainly interested in defining special terms used in
describing a type of condition or behavior.  Otherwise, we'll have
disagreement over whether the condition and treatment are comparable among
browsers.

What words are missing above that might help make it easier to discuss this
topic? 

And for a little fun, try to figure out which conditions triggered the
following responses/behaviors:

Apple - 379 -  "This certificate is not in the trusted root database." 

Apple - 322 - "This certificate was signed by an untrusted issuer" 

Apple - 5 - "Certificate signed by unknown certifying authority" 

Windows - 3294 - "The issuer of this certificate could not be found."

Windows  - 3296 -  "This CA Root certificate is not trusted because it is
not in the Trusted Root Certification Authorities store."

Windows - 3298, 3339, 3343 - "CA not trusted or authorized to issue
certificate" 

Windows - 3331 - "This CA Root certificate is not trusted. To enable trust,
install this certificate in the Trusted Root Certification Authorities
store."

NSS - 12195 SSL_ERROR_UNKNOWN_CA_ALERT - "Peer does not recognize and trust
the CA that issued your certificate."

Opera - 2104370139 -      "The root certificate from "%1" is not known to
Opera. Opera cannot decide if this certificate can be trusted."

Opera - 1490416928 - "The presented certificate has an unknown Certificate
Authority."

Opera - 1023477417 - "The certificate is not signed by a trusted authority."

Google - /* ERR_UNKNOWN_CA */ { "Unknown Certificate issuer!", USER},

---

From: David Chadwick <[email-masked]>
Date: Fri, 04 Oct 2013 12:24:56 +0100

Hi Ben

In terms of the actual reported errors which you list below for fun, 
many of them are quite clear to someone who understands PKI. I think one 
of the main problems is determining whether such an error is bypassable 
or not. Eg. Apple 379 is bypassable if the user dynamically adds the 
certificate to the root database, but is a fatal error otherwise. Thus 
the definition of bypassable is fuzzy. How much user interaction is 
needed in order to circumvent the error and proceed? E.g. ignoring the 
fact that the CRL held by the browser is out of date because it could 
not download the latest one is different to asking the user to install a 
new root CA. But the user can make decisions in both of these cases, so 
both in principle are bypassable.

regards

David

On 04/10/2013 01:32, Ben Wilson wrote:
> *Some of us are working on an Internet Draft titled, “Browser processing
> of server certificates”. *
>
> Here are some draft definitions for terms that I think we’ll be using:
>
> *Bypassable error* – A behavior in which the browser detects an abnormal
> condition and asks the user whether to proceed with (i.e. click-through
> to) the SSL/TLS connection.
>
> *Fatal error * -- A behavior in which the browser detects an abnormal
> condition and halts (or technically cannot complete) session negotiation
> and drops the connection or otherwise blocks the user from continuing
> (also referred to as “hard fail”).
>
> *Name mismatch* – A condition detected by a browser in which no name in
> the common name or subject alternative name for the subject in the
> certificate matches the hostname sought by the client (i.e. the client's
> reference identity – usually a Fully Qualified Domain Name – is not in
> the certificate).
>
> *Pinned* – A condition in which the association between two or more
> aspects of the entity-public-key relationship (e.g. server name, public
> key, CA, certificate) are configured and set in the browser before
> initiation of a TCP connection.
>
> *Stapled* – A condition in which information related to the server’s
> certificate (e.g. OCSP response) is delivered by the server to the
> client as part of the SSL/TLS handshake, and not by direct communication
> with the issuing CA.
>
> *Visual indicator* – A behavior in which the browser changes the
> color(s) and/or intensity of pixels on a screen in the browser chrome to
> indicate a changed condition.
>
> *Wildcard character* – An asterisk - *  (Unicode 2A).
>
> We’re welcome to ideas on how to fine-tune them.  I’d prefer that they
> be broad enough to include lots of uses—leaving clarification for their
> Additional definitions might include:  “browser chrome”, warning, dialog
> box, blacklist, and whitelist—but at this point I don’t think they need
> to be defined.  I’m mainly interested in defining special terms used in
> describing a type of condition or behavior.  Otherwise, we’ll have
> disagreement over whether the condition and treatment are comparable
> among browsers.
>
> What words are missing above that might help make it easier to discuss
> this topic?
>
> Apple - 379 - “This certificate is not in the trusted root database.”
>
> Apple – 5 - "Certificate signed by unknown certifying authority"
>
> Windows – 3294 – “The issuer of this certificate could not be found.”
>
> Windows  - 3296 -  “This CA Root certificate is not trusted because it
> is not in the Trusted Root Certification Authorities store.”
>
> Windows - 3298, 3339, 3343 – “CA not trusted or authorized to issue
> certificate”
>
> Windows – 3331 – “This CA Root certificate is not trusted. To enable
> trust, install this certificate in the Trusted Root Certification
> Authorities store.”
>
> NSS – 12195 SSL_ERROR_UNKNOWN_CA_ALERT - "Peer does not recognize and
> trust the CA that issued your certificate."
>
> Opera - 2104370139 -      "The root certificate from "%1" is not known
> to Opera. Opera cannot decide if this certificate can be trusted."
>
> Opera - 1490416928 - "The presented certificate has an unknown
> Certificate Authority."
>
> Opera – 1023477417 - "The certificate is not signed by a trusted authority."
>
> _______________________________________________
> wpkops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wpkops
>