Subject: Re: [xmpp] UPDATED: draft-miller-xmpp-posh-prooftype

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Mon, 7 Jan 2013 16:45:23 +0000

On Dec 17, 2012, at 12:49 AM, Philipp Hancke <[email-masked]> wrote:

> On Fri, 13 Jul 2012, Matt Miller (mamille2) wrote:
>> An update to draft-miller-xmpp-posh-prooftype is now available.  The only change is the syntax of the .well-known URI.
>> 
>> < http://tools.ietf.org/html/draft-miller-xmpp-posh-prooftype-01 >
>> 
>> 
>> Enjoy!
> 

Thank you for the feedback!

> Just had a chance to do so again -- some questions:
> 1) can there be multiple certificates (for rollover) in the file?
> 2) can the file contain a chain of certificates or is this limited to the
>   end entity certificate?

The current revision implies a single certificate.  However, specifying a chain and/or rollovers is definitely something that needs to be supported.  I was trying to keep deployment as simple as possible; ideally not more than "copy the PEMs into the file".  I think concatenation can handle either chains or rollovers fine, but not both.  I'm open to suggestions here.

> 3) is the subject of the certificate(s) fetched checked against RFC 6125?
>   If not, wouldn't it be sufficient to compare hashes?

That is a good question.  The current revision states that it does not supersede RFC6125, which one could interpret to mean the fetched certificate MUST contain a matching reference identifier.

I personally think a hash compare is fine.  How about something along the lines of the following?

####

7. Security Considerations

This document supplements but does not supersede the security
considerations provided in [RFC2616], [RFC2818], [RFC6120], and
[RFC6125], except as specified below.  Specifically, communication
via HTTPS depends on checking the identity of the HTTP server in
accordance with [RFC2818].

A client MAY accept the server's TLS certificate if the Public Subject
Key Info (or hash thereof) matches the POSH-obtained certificate,
forgoing any identifier matches mandated by [RFC6125].

####

Thoughts?

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.