This re-review identifies about 46 points on which the original response did not address the review. Given that the 160+ interjections in the original review often contain multiple comments each, easily adding up to hundreds of comments, some amount of error here was inevitable. That was no doubt compounded by my attempt to sort these into categories to help indicate the overall character of the review, and also because I sometimes addressed multiple comments in one response. Still, 46 would be quite a number to ignore. From reviewing these, however, I think the actual number of missing responses is closer to 8. Fresh responses to those are given below (search JP); none are issues of any severity. No doubt the way that I aggregated the responses didn't help to correlate these back into a line-by-line review. The re-review also contains some points of rebuttal to the original response to the review. While for the most part, these didn't contain any fresh argument that would make me reconsider my original response, I do have a few re-responses at the end of this document. ---- No Responses ---- As a bit of a preclude, when I was writing my notes on the original review, I broke the responses into 4 categories. About halfway through, I decided to change them from 1 through 4 to A through D. I never quite followed through on that, though, so the first section is labelled "A" and the rest are labelled 2, 3, and 4. That makes identifying sections where I responded a little harder than it should be. You'll see below constructions like A 5.1, meaning look in section A and find the comments on 5.1, but also 4 5.1, for look into Section 4 and find the comments on 5.1. Regarding the main comments before the line-by-line review, I'd have to say I did respond to those - I sent a summary mail that alludes to the points in the "main comments", but more materially, the main comments draw on the detailed points here, and addressing them necessarily addresses the main comments. Line-by-line: 'interdomain' might suffice, but I suspect it's worth pressing the issue, with language like "especially across trust boundaries" or somesuch. {{ No response from Jon. }} (true) JP: I don't have much of an opinion either way. I guess I think 'interdomain' suffices. add: Hence the foundation to accurate authorization is valid authentication. {{ No response from Jon. }} (true) JP: I agree with the statement. I'm removing the text in this neighborhood though due to a different review comment. But I'll see if I can find somewhere else to stick this. "provides a strong identity system for detecting" could mean many things, whereas the goal here is quite specific. So replace it with: ...enables an authentication capability for protecting against... {{ No response from Jon. }} (false, this is addressed in A 2) sender? Does that mean the caller? the caller's ua? the caller's operator? the term is ambiguous. {{ No response from Jon. }} (well, false, the ambiguity of "sender" is addressed in A 5.1) worth breaking this sentence into two, for better clarity. {{ No response from Jon. }} (false, this is addressed in A 2) The situation is however more complicated for telephone numbers, however. Authority over telephone numbers does not correspond however...however {{ No response from Jon. }} (false, also in A 2) Again, how is discussion of the internal, non-STIR aspects of SIP operationally relevant here? {{ No response from Jon. }} (false - this was answered by the previous comment 4 4 regarding TLS; one may not like the answer, but it was answered. The "again" here is just posing the same question.) That bit of vagueness isn't helpful, given the motivation for doing this work. It reduces to: something will get authenticated, but we won't say what and we won't say where to find out. {{ No response from Jon. }} (false, answered in 4 4) header -> header /field/ ? And, by the way, what header field is that? {{ No response from Jon. }} (false, all aggregated in 3 A - though the "what header field" admittedly is not.) 'checking' and 'converting' are very different actions. So 'it does not' does not flow from the preceding text in the sentence. {{ No response from Jon. }} (false, A 5.1) "When however"? {{ No response from Jon. }} (false, A 5.1) This is offered as descriptive text here. Where is this SIP behavior documented in this spec? {{ No response from Jon. }} (false, in 4 5.1, though it is blended into the end of the note beginning "The review interrupts the spec text reading...") Identity header with the "canon" parameter, it SHOULD retry a request and hence it doesn't do retries. All of this needs to be recast in terms that match the specified architecture. {{ No response from Jon. }} (false: the review text is literally in the quoted paragraph from my notes right above the place where the re-review says there is no response.) [$] This interaction needs to be re-specified to be deterministic. {{ No response from Jon. }} (false, A 5.1 in the paragraph beginning "The authentication service does the sending?") it doesn't do forwarding. {{ No response from Jon. }} (false, A 5.1 in the paragraph beginning "The authentication service does the sending?", see the very end) is the 'below' here different from the one before it? {{ No response from Jon. }} (well... the A 5.2 "'normally' implies" comment explains what "below" means in the second sentence of Step 1. I will grudgingly concede that I did not specifically say here if the "below" here in the forth sentence of Step 1 means the same thing. It does. I am not sure I feel that requires me to put this one into the "true" category though.) From the above text, it appears that ppt does not affect processing, as long as the ppt is "supported". That is, an absent ppt and a valid ppt both produce the same sequence 'below'. {{ No response from Jon. }} (false, this is also literally in the quoted paragraph from my notes right above this in the A 5.2 "'normally' imples" comment) [$] ' Step 2: Step 2: Signature Scope {{ No response from Jon. }} (true, I did not reply to any of the review proposals that the Steps be assigned their own names. To be honest, I think I really missed that this was the intention here. Here's a response.) JP: I don't object. I'll try to stick some in. [optional] remove. it's redudnant with 'if' [of the Identity header] remove. there is no other canon parameter. But really I suspect that even the 'if' is unecessary. The optionality has been established elsewhere. The task here is merely to specify what is in a canon. {{ No response from Jon. }} (false, A 5.2.1 "The introductory sentence") number form. Also, when "canon" is present, during Step 4 the verification service SHOULD compare the "iat" value in the "canon" to This is talking about actions during Step 4. Move it to Step 4! {{ No response from Jon. }} (true, I don't seem to have replied to this, so here's a response.) JP: Yeah, all right, I'll move it. [potentially] remove {{ No response from Jon. }} (false, A 6.1) Again, this much non-determinacy in such an essential mechanism ensures /non-/interoperability. I do understand the intent to have private/proprietary mechanism at work for use of this spec back in the regulated telecom space, but that does not mean it needs to distract the public specification. A complete specification of a STIR service needs to include a publicly-usable key certification mechanism, a la DANE or DKIM or the like. The application of STIR for other, non-open operations are always free to amend the specification through a separate profile that overrides one or another piece of the base STIR specifications. {{ No response from Jon. }} (false, 4 6.2 the paragraph beginning "The review here insists" toward the end - again, the answer may not make everyone happy, but it's the answer the WG has chosen) [on the ABNF of RFC3261, snip] Ditto for "alg". Ditto for ppt. {{ No response*S* from Jon. }} (false, this is covered at some length in 4 6.3 "The review alleges...", which is literally quoted in the response right above this in the re-review) [$] Again, specification, not handling. Also, what do the instructions mean? How is the signer to know what is dereferenceable by the verifier? {{ No response from Jon. }} (well, this one is ambiguous even to me. I do respond to this with A 6.3 with regards to what is "handling" versus "specification". But more the more significant technical question of how the signer is know what is dereferencable is really addressed in 4 6.3, in the discussions about the "real need" to have some centralized credential registry. I wouldn't say this comment wasn't addressed, though it wasn't addressed here. This doesn't add up to "true" I think.) Also note that the claimed interest in authentication beyond SIP will also require credentialing systems. As such, the entire topic appears to be larger than this specification. {{ No response from Jon. }} (false, this is specifically addressed in 2 6.4, "The suggestion in the review" paragraph.) the above isn't 'requirements'. {{ No response from Jon. }} (well, maybe, though the response in 2 6.4 "The suggestion in the review" is basically a response to this, in so far as it alludes to the fact that the section does in fact have requirements. The requirements are broken into bullets, and obviously follow like two lines later in the spec. The fact that an introductory paragraph before the requirements is not in fact "requirements" would not be lost on anyone who is trying to understand the spec. But I agree it isn't super clear that 2 6.4 was in passing refuting this statement in the review.) Looks like this needs to define a STIR Credential Registry. {{ No response from Jon. }} (false, this is addressed in 4. 6.3 "after reading about". Though admittedly that is labelled 4 6.3 and not 4 6.4 as it should be) remove above paragraph. {{ No response from Jon. }} (false, this is addressed in 3 7 "once again." In fact, the text reading "On similar grounds, the review goes on to suggest that another helpful paragraph of mechanism be removed" is literally quoted a handful of lines up in the re-review from the claim that there is no response.) [$] If there is an algorithm to follow, specify it as an algorithm. Otherwise, this is non-normative discussion and isn't very helpful here. {{ No response from Jon. }} (false, this is addressed in 4 7 "when the spec".) How are they to do this? {{ No response from Jon. }} (well, I'd say this is addressed in 4 7 "when the spec") If a local environment is doing 'local policy' then it will document that separately. There is no utility in making vague statements about possibilities that are outside the spec. {{ No response from Jon. }} (well, by this stage this high level comment rehashes a point that has been answered before, like in 3 7 "once again") Take the original string and remove any characters that do not conform to the above format. Then tweak that text for any cases that need to add characters. {{ No response from Jon. }} (false, this proposal is explicitly considered in 4 7.2, "also, as a minor point") must or MUST? {{ No response from Jon. }} (true, this doesn't get a response) JP: I don't think that statement is normative. Really, I suspect all of the above detail is out of scope, given the way these specifications have been partitioned. {{ No response from Jon. }} (false, this is addressed in 4 7.3 "the review here asks") Canonicalization for phone numbers and Normalization for URI. Why the difference? {{ No response from Jon. }} (true, this doesn't seem to get a response) JP: URI "normalization" is the term used by RFC3986, and "canonicalization" is the term we had already been using for telephone numbers. I thought it was actually helpful to have those terms be different, since you are performing a different operation when you execute them. transformation -> transformations {{ No response from Jon. }} (false, A 7.4) "including"? By my reading there isn't anything other than those two rules. {{ No response from Jon. }} (false, addressed in 4 7.4 "the review here is alarmed") In other words, just get {{ No response from Jon. }} (well, 4 7.4 discusses the comments on this algorithm as a whole; it's true that the response doesn't specifically entertain replacing everything with "get " but surely the response is clear about why the mechanism as written is retained.) canon is optional. why doesn't the abnf show it as optional? I suspect the issue is that the abnf needs to distinguish between mandatory and optional components of the Identity header field. {{ No response from Jon. }} (true, I think, I don't see anywhere that I addressed this.) JP: The intention is for the ABNF to show canon (and the remainder of the ident-info-parameters) as optional, hence the "*( SEMI ident-info-params )". My ABFN may be rusty, but I'm not seeing the problem? These sorts of rules (including base-64-char, which is defined syntactically but not semantically) need explicit ABNF rules with their names and then need prose text to explain their semantics. {{ No response from Jon. }} (false, 8 "the review is very concerned" talks about where these ABNF elements come from) I naturally assume that some portion of this is inherited from JSON and/or JWT, which is a nice example of the significant, additional overhead being being introduced with their use. And in this case, apparently confusion. {{ No response from Jon. }} (false, 8 "While the review objects" covers this} And since every RFC contains a security considerations section, a generic reference like this, here, is of no obvious value. It's just more text. {{ No response from Jon. }} (false, 8 "the review is skeptical" covers this) "with now claims"? {{ No response from Jon. }} (false, A 9) The term 'header key' does not occur in the Passport specifiction. Perhaps this is meant to refer to that doc's section 4.1 header parameter? {{ No response from Jon. }} (true, I think) JP: This is not a term of art. PASSporT objects are referred to as "header" and "claim" objects here. The contents of objects are keys and values. A key in the header object is all this means. But... I think that got killed in some unrelated edit I'm doing, so it may be moot. If...but then appears to be a non-sequitor or incompletely formulated sentence. {{ No response from Jon. }} (false, A 9 "the review correctly notes") In fact there is so little overlap of substantive text, this really is an entirely new document and not a bis. {{ No response from Jon. }} (false, 3 10) ---- Re-Responses ----- As I already said on the list, the review (and re-review) focuses attention on the question of how to handle signatures that have been broken by intermediaries in transit. The re-review puts hard emphasis on rfc4474bis's relative flexibility about this question. "*That's a mistake. If the infrastructure will sometimes break the signature, then penalizing the signer for actions not under their control will be problematic. That's why DKIM explicitly mandates treating a broken signature exactly the same an absent signature.*" But for all that vehemence, the re-review isn't making any new point here. Yes, the DKIM community has thought about this for more than a decade. So have we in SIP. We've tooled the signature to minimize that breakage, created a mechanism to compensate for unnecessary breakage, and left a tremendous amount of latitude on how to handle breakage. To say merely that we're been over this turf many times is an understatement. Coming in at the last minute and just saying "that's a mistake" is not going to convince us. There are differences about the way that SIP and email handle messages. RFC5585 Section 3.2.2, for example, gives a rationale for treating a broken email signature as an absent signature that has no bearing on SIP whatsoever. Regarding the whole idea of having authentication service and verification service "roles," the re-review exclaims, "This appears to be a very basic disagreement about a very basic issue! *In point of fact, these specifications are attempting to define an authentication service overlay for SIP. That is, STIR is an additional layer of architecture ABOVE SIP. *" I fail to see why this is an interesting or important point, nor what explanatory power we gain by calling this an "overlay." I do understand that SIP messages are carrying PASSporT objects, and in some sense that we are simply tunneling PASSporT over SIP - but since the contents of that PASSporT claims are in fact signed fields taken from the SIP request, I don't see the same simple and obvious layering that the re-review seems to. To me, this is an evolution of the concatenated string in RFC4474, which was in turn an evolution of the AIB mechanism (RFC3893), which was in turn an evolution of the mechanism in RFC3261 23.4. All of those are encapsulation mechanisms that carry signed fields of a SIP request. Where AIB carried a copy of the fields, so we could see how they looked to the signer before transit (and any intermediary interference), RFC4474 discarded the copy - so PASSporT splits the difference, offering you both modes, but defaulting to discarding the copy. We (Chris and I) do sometimes still debate which it should default to. I'm willing to go into the field with what we have and see how it works. So is the working group, which contains a much larger share of the major operators than is typical in an IETF working group. But this gets a further hearing in the section about the steps that entities instantiating the authentication and verification service must perform. The re-review goes on "*The immediate problem is that the steps are part of the architecture, independent of implementation details. So by saying 'entities instantiating' the document is stepping into sounding like it is talking about implementation. There is a general challenge in the IETF, and elsewhere, in creating and maintaining clarity about networking architectures -- which are abstractions -- as distinct from the many ways they can be implemented. IETF specifications should encourage clarity, not add to the confusion.*" While at a high level, I agree we shouldn't be in the business of dictating implementation, I don't think the specification of these steps, or the entities involved, oversteps the common bounds of the IETF. Ordinarily, I find reference to precedents in existing RFCs convinces participants in our process that something falls within our norms - I gather that argument doesn't persuade everyone. I think what we've got is good enough. The re-review is still quite firm about how the invocation of "local policy" throws an exception that nothing can catch. "*As soon as one says 'local policy' for anything other that a generic and non-normative discussion, one has stepped out of the sandbox in which the specification controls and, therefore, has stepped out of the specification. In other words, local policy for something like this needs to be out of scope.*" I can only reiterate that this is a bizarre and baseless restriction on IETF documents. On the question of how far rfc4474bis needs to go in advising relying parties about validation and trust the re-review has some choice words. "*The response shows a confusion about validation and trust. Validation is the task of STIR. Within the scope of establishing validation -- that is, within the standardized and interoperable details of an authentication mechanism like STIR -- there *must* be a semantic component provided which establishes the authority of the entity asserting validity to make that assertion. The premise of an authentication mechanism is clarity about the authority of the entity vouching for the use of the key. This is entirely different from the trust component which assesses whether that entity is a good actor or not (or whether the authorized entity doing the signing is a good actor or not.)*" I don't think we're actually confused about that. We have two sections about what it means to have "authority" over telephone numbers and domain names for the purposes of validation - though admittedly, they do defer to stir-certs because it is the nature of the credential that communicates that scope of authority, not any other element of the over-the-wire prtoocol. And yes, that's entirely separate from the question of why you trust any particular credential. But that means that ultimately both the "validation" and "trust" parts of this equation must defer to the credential mechanism. My point in the response stands: "the fields that go in PASSporT and the semantics of the SIP Identity header field value will not be any different as a result of those different architectures" for trust and/or credential scope. More to this point, the re-review asserts that "*The operational history of certificate-based services is highly problematic. For a criticial infrastructure service like STIR, the technical design of the cert service is not something that can be deferred and treated merely as a matter of operational design.*" While I know this has gotten some list discussion recently, we are not closing the door on using, say, a DNS-based service for this. We had a proposal for one initially; the proponents lost interest. Maybe that'll return some day - we put some modularity into the architecture to allow for that. What we have now are some people that want to use certs. While no credential mechanism is perfect, we believe that certificate-based services are adequate, and hope that they'll be implemented properly. The P-Asserted-Identity mechanism in RFC3325 is the main culprit for raising the dread specter of local policy. "*"What is local policy, as the spec says, is the decision of whether you extract the identity from PAI or the From" is a perfect example of failing to ensure interoperability. It is exactly the sort of thing that needs to have determinacy in sources of information. The concept of "local" policy for such an action is an explicit statement that a participant has stepped outside the four walls of the standardization process.*" Well, look. RFC3325 (which in turn relies on RFC3324) is a weird beast. PAI is specified only for use in a closed and trusted environment (of the kind described by RFC3324). If you are in one of those environments, you know that you are - I tried to explain this in the response. I'm not going spend much time defending RFC3324/5; its deployment is something that must be managed, not endorsed. The text we have about this is the best way we could agree to manage it. Literally at the last IETF, I put up slides about this again, asking if we wanted to have some explicit indication in PASSporT that we were using PAI rather than From to derive the identifier. The answer once again was no. I can imagine if you don't deal with PAI in everyday life why you might think this would lead to interop failures. But RFC3325 is what it is, and we're just trying to work around its weird constraints. Anyway, the working group thinks what we have works. This is not an unconsidered decision. A couple other random points: In terms of whether the citation of a discussion of how to hRFC2818 is adequate forandle name subordination - we could upgrade that to citing RFC5922, and in particular pointing to 7.2. Olle already asked for that. "To maximize end-to-end security, it is obviously preferable for end-systems to acquire their own credentials" works for me. "I meant that for the next use of identity (just below,) the 'that' isn't a clear reference to me. I was commenting on ambiguous writing, not the meaning of the term identity." (1st para 5.1) I think it's clear. "(My review missed the typo: "when each an header")" - Yeah, I spotted that too when I was going through your review initially. It's fixed in the next v. "Google certainly does not produce results that shows it as ab otherwise-common term." Googling I get no shortage of specs on certificate enrollment (like, say, RFC2797, or RFC4210, or RFCC5272, or RFC6402, or RFC7030). But if there's to be a cite here, it'll be to stir-certs, which uses the term liberally.