Ballot for draft-ietf-xmpp-posh
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
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...
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.
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.