PKIX over Secure HTTP (POSH)
RFC 7711

Note: This ballot was opened for revision 04 and is now closed.

(Ben Campbell) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2015-08-05 for -04)
No email
send info

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

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.

Barry Leiba No Objection

Comment (2015-07-29 for -04)
No email
send info
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

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):

   o  A "url" field whose value is a JSON string specifying the HTTPS
      URL where POSH clients can obtain the actual certificate
   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.

-- 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:
or this (I prefer the former, but don't really care):
...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...

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-08-04 for -04)
No email
send info
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.

Alvaro Retana No Objection