PKIX over Secure HTTP (POSH)
draft-ietf-xmpp-posh-06

[Ballot comment]


3.1: fingerprints: sigh, I wish we could agree to just
do this kind of thing a few times and not re-do it over
and over and over (but we always do;-). RFC6920 could
probably have been used there (caveat lector: that's an
RFC I'm a co-author on).

3.1: fingerprints - your hash input here is the entire
cert so the value will be out of date when a cert
expires (or is revoked). While 3.3 makes clear that
a match on any of these is ok, I think it'd be good
to say here that the hashes may be of different certs.
You do clarify in section 7, but I'd suggest moving
section 7 into 3.1 myself. (I don't object if you
prefer to not change though.)

3.2: A "MUST use HTTPS" statement might have been nice
there. It's not absolutely needed but would maybe be
something to help an implementer not get this wrong by
just using some generic URL handling library without a
check for scheme==https.

section 6: surely the cache expiry ought be the earliest
of the possibly two POST expires or the X.509 notAfter?

section 8: see my comments on draft-dna, I think the
.well-known URIs should be here and not there. But
it works as-is too, even if ickky:-)

section 8: I dislike the "{servicedesc}" thing, but
that's just me. Breaking down servicedesc further into
"{service}.{proto}" is worse though, I don't get why
that's a good idea at all, nor the "_" convention. If
you want/need all that you should've just registered
"posh" as a well-known and then said the the rest of the
pathname was whatever structure you needed and not
possibly end up registering loads of DNA .well-known
URLs.

section 9: section 8 is IMO an IANA section, so you're
fibbing here:-)

- 11.2: odd one this but [HASH-NAMES] might be better
in 11.1. I won't try force you to do that though as
it may be messy.

[Ballot comment]
Nice work on this draft!  I do have a few comments that I'd like to chat about.

In the examples, could you switch them to have sha-256 as the low mark instead of sha-1?  sha-1 is only a problem if you need collision resistance, but since it's just used in examples, it might be easier to just get rid of it.

In the first paragraph of the Security Considerations section, could you add a reference to RFC7525 as well?  Otherwise, it looks great.  It should fit in nicely after the RFC2818 reference. Thanks.

[Ballot comment]
No objection, in that I'm not going to block on these points, but I do ask for some discussion, please; see below.

General: You're inconsistent in your use of "URI" and "URL", using the former in Sections 3 and 8, the latter in Sections 1, 3.2, and 10 -- and, of course, calling the member "url", rather than "uri".  I'd prefer that you use "URI", but you should, in any case, be consistent.

-- Section 3 --

  When POSH is used, the first two aspects remain the same: the POSH
  server proves it identity by presenting a PKIX certificate [RFC5280]

Typo: It proves "its" identity, not "it".

      *  If it does not have any PKIX certificate information or a
          reference to such information for the requested path, it
          responds with an HTTP client error status code (e.g., 404).

Do you really want to leave the status code unspecified ("e.g."), rather than just saying that the code to use is 404?

-- Section 3.1 --

  o  A "fingerprints" field whose value is a JSON array of fingerprint
      descriptors.

Here and elsewhere: the JSON term is "member", not "field" (for members of an object; arrays have "elements").

Please check the content-length in the example; I don't think it's correct (I get 176, assuming CRLF-termination, and 135 even if I get rid of all the pretty-print).  Similarly for the example in Section 3.2.  If you're using the pretty-print, the content-length should reflect it.

  If no "expires" field
  is included or its value is equal to 0, a POSH client SHOULD consider
  these verification materials invalid.

But above you say that having "expires" is a "MUST".  Why is this "SHOULD" and not "MUST", and why is 0 not just outright invalid (previous sentence, change "non-negative" to "positive")?  (And similarly for Section 3.2.)

-- Section 3.2 --
The example shows using the same sort of .well-known URI, but I presume there's no requirement that this referral be to one of those (if there is, the doc should say so).  It might be worth making it clear, with something like this (or adjust it if my previous presumption is wrong):

OLD
  o  A "url" field whose value is a JSON string specifying the HTTPS
      URL where POSH clients can obtain the actual certificate
      information.
NEW
  o  A "url" field whose value is a JSON string specifying the HTTPS
      URL where POSH clients can obtain the actual certificate
      information.  The URL can be a similar .well-known POSH URL, but
      it need not be.
END

-- Section 8 --
I'm not terribly happy with the mechanism of having a faux hierarchy in the .well-known name (posh.servicename.json), not registering any .well-known name here, and asking the .well-known registry (via the designated expert) to register and evaluate each POSH service -- the .well-known DE is not an expert for POSH.  Also if, using your example, Victoria Beckham should want to have a .well-known URI to access her tweets from anywhere, returning them in JSON wrappers, she might want to register "posh.spice.json", which would then get in the way of that name for POSH, entirely unintentionally.

I'd be much happier with using a real URI hierarchy and registering "posh" as a .well-known name here, so a POSH URI might be this:
  https://hosting.example.net/.well-known/posh/spice/json
or this (I prefer the former, but don't really care):
  https://hosting.example.net/.well-known/posh/spice.json
...and you might establish an FCFS registry of POSH service names under which "spice" (or "spice.json") would be registered.  Now you're putting it all under one .well-known name, and only asking the .well-known expert to review this one, rather than one for every POSH service.

Hable conmigo...

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-xmpp-posh-04, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (PKIX over Secure HTTP (POSH)) to Proposed Standard


The IESG has received a request from the Extensible Messaging and
Presence Protocol WG (xmpp) to consider the following document:
- 'PKIX over Secure HTTP (POSH)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-07-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Experience has shown that it is extremely difficult to deploy proper
  PKIX certificates for TLS in multi-tenanted environments.  As a
  result, domains hosted in such environments often deploy applications
  using certificates that identify the hosting service, not the hosted
  domain.  Such deployments force end users and peer services to accept
  a certificate with an improper identifier, resulting in obvious
  security implications.  This document defines two methods that make
  it easier to deploy certificates for proper server identity checking
  in non-HTTP application protocols.  While these methods developed for
  use in the Extensible Messaging and Presence Protocol (XMPP) as a
  Domain Name Association (DNA) prooftype, they might also be usable in
  other non-HTTP application protocols.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/ballot/


No IPR declarations have been submitted directly on this I-D.

This is my AD Evaluation of draft-ietf-xmpp-posh-04. There's nothing here to block last call.


-- section 3, first paragraph after first numbered list: " ... server proves it identity ..."

s/it/its

-- 8, last sentence

With this one sentence, you've made the entire introduction serve as a shaggy dog story, without detracting from its main purpose. Bravo. Also, groan :-)

-- References:

IDNits turns up several outdated references that probably need attention before final publication.

PROTO Shepherd Writeup for draft-ietf-xmpp-posh

Shepherd writeup for draft-ietf-xmpp-posh-04

1. Summary

The document shepherd is Dave Cridland.

The responsible Area Director is Ben Campbell.

This document defines the "PKIX over Secure HTTP (POSH)" prooftype, to
be used as part of the XMPP Domain Name Assertion (DNA) framework. From
the abstract:

"Experience has shown that it is extremely difficult to deploy proper
PKIX certificates for TLS in multi-tenanted environments.  As a result,
domains hosted in such environments often deploy applications using
certificates that identify the hosting service, not the hosted domain.
Such deployments force end users and peer services to accept a
certificate with an improper identifier, resulting in obvious security
implications.  This document defines two methods that make it easier to
deploy certificates for proper server identity checking in non-HTTP
application protocols.  While these methods developed for use in the
Extensible Messaging and Presence Protocol (XMPP) as a Domain Name
Association (DNA) prooftype, they might also be usable in other non-HTTP
application protocols."

The XMPP working group believes that this technology is ready for wider
implementation, and would benefit from interoperability testing.
Therefore we request the document to be published as a "Proposed
Standard".

2. Review and Consensus

The XMPP working group is chartered to provide a solution to allow a
hosting service to share an XMPP server among multiple hosted domains.
That effort produced the Domain Name Assertion (DNA) framework, which is
still a work-in-progress at the time of this writing. POSH was
originally proposed in 2012 as a prooftype for the DNA framework.

During discussion in XMPP, it became apparent that POSH might have more
general applicability. There was a POSH BoF in the Security area at IETF
87. While there was recognition that POSH could be generally useful,
there was no consensus to expand the effort beyond the needs of XMPP.
Therefore POSH was adopted as an XMPP work item, with the idea that we
would make it as general as we reasonable could without bogging down the
work, but that we would not attempt to meet the specific requirements
for applications other than XMPP.

The  chairs believe POSH has reached a broad consensus in XMPP. There
has been considerable review in XMPP, and in the Security area due to
the BoF. POSH does not need targeted reviews beyond the usual Gen-ART,
SecDir, etc reviews.

Reviews have concentrated primarily on clarifying the specification rather
than altering how it works. Some members of the working group (including
an author) have expressed the opinion that this is a stopgap technology rather
than a long-term plan.

At the time of this writing, the shepherd is aware of two experimental
implementations which have not been deployed - however various implementors
of XMPP have expressed some interest, and some are in progress.

3. Intellectual Property

There are no IPR disclosures on this document. The authors have
explicitly indicated that they are not aware of any undisclosed IPR, and
understand their obligations under BCP 78 and BCP 79.

4. Other Points

POSH makes no requests of IANA, but it does require application
protocols that use it to register "Well-known" URIs. POSH does offer
guidance on the structure of those URIs in non-normative language.