Subject: [xmpp] #72: certificate handling if no presented identity matches

From: "xmpp issue tracker" <[email-masked]>
Date: Tue, 22 Jun 2010 02:24:54 -0000

#72: certificate handling if no presented identity matches
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |       Owner:  stpeter@…         
     Type:  defect              |      Status:  new               
 Priority:  major               |   Milestone:                    
Component:  3920bis             |     Version:                    
 Severity:  In WG Last Call     |    Keywords:                    
--------------------------------+-------------------------------------------
 Section 13.7.2.1.1 states in part:

 > ... if the connecting entity is a user-oriented client then it
 > MUST either (1) automatically terminate the connection with a
 > bad certificate error or (2) show the certificate (including
 > the entire certificate chain) to the user and give the user
 > the choice of terminating the connecting or accepting the
 > certificate temporarily (i.e., for this connection attempt
 > only) or permanently (i.e., for all future connection attempts)
 > and then continuing with the connection...

 Ben Campbell commented: "I read this to say that, if you give the user any
 choice at all, you MUST offer the option of shooting oneself in the foot.
 Is that the intent?"

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/72>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 21 Jun 2010 20:27:59 -0600

> #72: certificate handling if no presented identity matches

This is handled more carefully in Section 3.6.3 of
draft-saintandre-tls-server-id-check, which is a normative reference for
3920bis; I suggest that we simply reference that specification. The text
there is as follows (please post to the [email-masked] list if you have
substantive comments on this text):

###

3.6.3. Case #3: No Match Found, Uncached Certificate

   If the client finds no presented identifier that matches any of the
   reference identifiers and a human user has not permanently accepted
   the certificate during a previous connection attempt, the client MUST
   NOT consider the certificate to include a validated identity for the
   application server.

   Instead, the client MUST proceed as follows.

3.6.3.1. Interactive User Agent

   If the client is an interactive client that is directly controlled by
   a natural person, then it MUST either do one of the following:

   1.  Automatically terminate the connection with a bad certificate
       error; or

   2.  Actively warn the user that the certificate is untrusted and
       encourage the user to terminate the connection, but give advanced
       users the option to (a) view the entire certificate chain, (b)
       accept the certificate either temporarily (i.e., for this
       connection attempt only) or permanently (i.e., for all future
       connection attempts), and then (c) continue with the connection
       attempt.

   If a user permanently accepts a certificate (an action referred to in
   [WSC-UI] as "pinning"), the client MUST cache the certificate (or
   some non-forgeable representation such as a hash value) and in future
   connection attempts MUST behave as in "Case #2: No Match Found,
   Cached Certificate" Section 3.6.2.

      Security Note: It is the responsibility of the human user to
      verify the hash value or fingerprint of the certificate with the
      server over a trusted communication layer.

      Informational Note: The guidelines provided here are roughly
      consistent with those provided for web browsers and other HTTP-
      aware interactive clients in [WSC-UI].

3.6.3.2. Automated Client

   If the client is an automated application that is not directly
   controlled by a natural person, then it SHOULD terminate the
   connection with a bad certificate error and log the error to an
   appropriate audit log.  An automated application MAY provide a
   configuration setting that disables this check, but MUST enable the
   check by default.

###

---

From: "xmpp issue tracker" <[email-masked]>
Date: Mon, 28 Jun 2010 01:38:51 -0000

#72: certificate handling if no presented identity matches
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |        Owner:  stpeter@…         
     Type:  defect              |       Status:  closed            
 Priority:  major               |    Milestone:                    
Component:  3920bis             |      Version:                    
 Severity:  In WG Last Call     |   Resolution:  wontfix           
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by stpeter@…):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 Marking as "wontfix" because this issue is (or will be) dealt with draft-
 saintandre-tls-server-id-check, and 3920bis simply needs to reference that
 I-D instead of separately specifying the same behavior.

-- 
Ticket URL: <https://trac.tools.ietf.org/wg/xmpp/trac/ticket/72#comment:1>
xmpp <http://tools.ietf.org/xmpp/>