Subject: [xmpp] #44: certificate validation during during TLS negotiation

From: "xmpp issue tracker" <[email-masked]>
Date: Tue, 22 Jun 2010 00:31:32 -0000

#44: certificate validation during during TLS negotiation
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |       Owner:  stpeter@…         
     Type:  defect              |      Status:  new               
 Priority:  minor               |   Milestone:                    
Component:  3920bis             |     Version:                    
 Severity:  In WG Last Call     |    Keywords:                    
--------------------------------+-------------------------------------------
 Section 5.3.3.1 (which covers rules for TLS negotiation) states:

 > 4.  The initiating entity MUST validate the certificate to determine
 > if the TLS negotiation will succeed; see Section 13.7.2 regarding
 > certificate validation procedures.

 Dave Cridland commented: "(4) mandates that the receiving entity lives or
 dies on the sole basis of its certificate, whereas we've commonly treated
 this as one possible authentication rather than the sole means."

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 27 Jun 2010 16:38:08 -0600

> #44: certificate validation during during TLS negotiation

I think the appropriate text is "MUST attempt to validate", not "MUST
validate". Perhaps you have some local service policy about not failing
the stream negotiation on a certificate that cannot be validated, but
you MUST at least attempt to validate the certificate.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "xmpp issue tracker" <[email-masked]>
Date: Sun, 27 Jun 2010 22:38:33 -0000

#44: certificate validation during during TLS negotiation
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |        Owner:  stpeter@…         
     Type:  defect              |       Status:  closed            
 Priority:  minor               |    Milestone:                    
Component:  3920bis             |      Version:                    
 Severity:  In WG Last Call     |   Resolution:  fixed             
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by stpeter@…):

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

Comment:

 Changed "MUST validate" to "MUST attempt to validate".

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

---

From: Dave Cridland <[email-masked]>
Date: Mon, 28 Jun 2010 11:22:51 +0100

> > #44: certificate validation during during TLS negotiation

I see what you're aiming for here, but I don't think that text quite  
hits the mark.

What about:

  <t>Both entities attempt to validate the peer's certificate, if  
any, following the procedures detailed in Section 13.7.2. If this  
validation fails, either entity MAY choose to unilaterally terminate  
the session.</t>

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jun 2010 08:42:03 -0600

On 6/28/10 4:22 AM, Dave Cridland wrote:
>  <t>Both entities attempt to validate the peer's certificate, if any,
> following the procedures detailed in Section 13.7.2. If this validation
> fails, either entity MAY choose to unilaterally terminate the session.</t>

I strongly prefer to phrase normative rules with normative language. I
cannot tell you the number of times implementers have told me "well that
text doesn't say MUST so I'll simple ignore the rule" (even if it says
"SHOULD", let alone something so weak as "both entities attempt").

I propose:

###

13.7.2.  Certificate Validation

   When an XMPP entity is presented with a server certificate or client
   certificate by a peer for the purpose of encryption or authentication
   of XML streams as described under Section 5 and Section 6, the entity
   MUST attempt to validate the certificate to determine if the
   certificate will be considered a TRUSTED CERTIFICATE, i.e., a
   certificate that is acceptable for encryption and/or authentication
   in accordance with the XMPP entity's local service policies or
   configured settings.

   For both server certificates and client certificates, the validating
   entity MUST attempt to verify the integrity of the certificate, MUST
   attempt to verify that the certificate has been properly signed by
   the issuing Certificate Authority, and MUST support certificate
   revocation messages.  An implementation MUST enable a human user to
   view information about the full chain of certificates.

   If these validation attempts fail, either entity MAY choose to
   unilaterally terminate the session.

###

---

From: Dave Cridland <[email-masked]>
Date: Mon, 28 Jun 2010 16:01:49 +0100

> "SHOULD", let alone something so weak as "both entities attempt").
Well, you know I prefer statements of fact, reserving 2119 for when I  
really have to underline the point, but that's stylistic.

>    unilaterally terminate the session.

WFM.

To be entirely accurate, is it worth saying "validate the certificate  
chain"? (I'm not sure).

Dave.

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 28 Jun 2010 17:08:09 +0200

>>    unilaterally terminate the session.

+1

> To be entirely accurate, is it worth saying "validate the certificate 

MUST attempt to validate the certification path? (5280)

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jun 2010 10:12:07 -0600

+1