I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-stir-rfc4474bis-14 Reviewer: Vijay K. Gurbani Review Date: Nov-03-2016 IETF LC End Date: Unknown IESG Telechat date: Nov-03-2016 Summary: This document is ready to be published as a Proposed Standard once the nits/comments below have been addressed. Major issues: 1 Minor issues: 3 Nits/editorial comments: Various. Major: - S7.4 contains requirements for a credential system, and the draft assumes that any credential system that works with the draft will adhere to the five expectations outlined in the section. My question is how do we ensure that these expectations are met? Through IANA? (But there is no subsection in the IANA registry section corresponding to this.) Through some form of domain expert required to review a specification outlining the five expectations? It seems to me that since the credential service is an integral part of the system, some manner of review by the appropriate working group (or a designated expert) should take place. Minor: - S3: "baseline SIP" ==> What do you mean by this? (I know what you mean, of course, but others reading the document may not.) Perhaps the following substitution is better? s/purposes of baseline SIP,/use of SIP as defined in [RFC 3261],/ - S6.2.2, the 436 response case. I am a big believer of protocols imparting as much error information as they can, especially if the protocol is as expressive as SIP. Since this error code is repairable, why not provide information to the repairer on exactly which Identity header was 'bad'. Something like: 436 Bad Identity Info Warning: 399 https://biloxi.example.org/biloxi.cert is not accessible Or message/sipfrag could be used as well. We do not have to make such debugging/error information propagation mandatory (MUST), but we should at least alert the implementers to it existence (SHOULD). - S6.2.2, the 437 response case. Same reasoning as above. Example: 437 Unsupported credential Warning: 399 https://biloxi.example.org/biloxi.cert Nits: - S1: "However, the recipient of a SIP request has no way to verify that the From header field has been populated appropriately, in the absence of some sort of cryptographic authentication mechanism." Changing the order of the dependent clauses may lead to better readability. That is, "However, in the absence of some sort of cryptographic authentication mechanism, the recipient of a SIP request has no way to verify that the From header field has been populated appropriately." - S1: You may want to define what "swatting" is for those not well- versed in ART terminology. - S1: "less spoofable" ... Merriam-Webster does not define "spoofable" as a word (online version). Perhaps better to say "less amenable to spoofing" instead. Something as the following suggested text: "Ideally, a cryptographic approach to identity can provide a much stronger assurance of identity than the Caller ID service used by the public-switched telephone network today. Such an approach would also be less amenable to identity spoofing." - S3: s/through means entirely up to the authentication service,/through per-arranged means with the authentication service,/ - S3: s/credentials that will be trusted by relying parties to sign for telephone numbers are a key component of the architecture./credentials that will be trusted by relying parties to be authoritative for telephone numbers become a key component of the architecture./ - S3: s/not so easy to/not as easy to/ - S3: s/ but this document does not mandate or specify a credential system. [I-D.ietf-stir-certificates] describes a credential system compatible with this architecture./ but this document does not mandate or specify a particular credential system; [I-D.ietf-stir-certificates] describes one credential system compatible with this architecture." - S3 s/This is typically easier to deal with, as these identities are issued to users by authorities over Internet domains./This is typically easier to deal with as these identities are issued by organizations that have authority over Internet domains./ - S3: s/can issue them an identity/issues an identity/ - S3: s/prove in some fashion/proves/ - S6.2, Step 3: "The verifier must ensure that it possesses the proper keying material to validate the signature...". Here, I believe that the verifier must ensure that it *has access to* to the proper keying material, more than the fact that it "possesses" it. Namely, the verifier needs to have access to the URI in the "info" parameter. Whether or not it caches the certificate (thus making it "possess" it), is up to the policies of the verifier. Summary: s/possesses/has access to/ - S7.1, first paragraph, first sentence. With respect to my above comment, s/have access to/possess/ The Authentication Service must not only have access to, but must possess the private keying material. Possession implies access, but access may not imply possession. - S7.1, second paragaph: s/For non-telephone number user parts/For non-telephone number URIs/ - S8, s/vet the identity/confirm the identity/ Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Nokia Networks 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg at bell-labs.com / vijay.gurbani at nokia-bell-labs.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq