On 01/24/2017 12:59 PM, Peterson, Jon wrote: > Hey Vijay, > > Took me a bit to get back to you here, sorry. Appreciate the notes. > Here's my thoughts.
Jon: No worries. I must also apologize for the delay in getting back to you. More inline (please see to end). I have re-arranged your comments so that those we agree on appear at the end. >> 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. > > I don't think this is an IANA-like thing where failure to comply with > these requirements will result in something like a code point > overload. The relevant text in 7.4 says "in order for a credential > system to work with this mechanism, its specification must detail" > the following points. If the credential system doesn't do these > things, it won't work with the rfc4474bis mechanism. > > I think this is pretty typical of how requirements language like this > fits into our process - we may as part of a WGLC for a document ask > if it meets requirements given in a previous RFC, but it's not a > designated expert kind of thing. I imagine that any chartered > deliverable, say, to do a credential system might be held to that bar > - but we don't put text to that effect in RFCs I think. > > So in short I hear what you're saying but I think this one is fine. OK; I wanted to at least raise the issue to make sure that it was subjected to some thought. >> - 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). > > I know that ATIS has been playing around with some Reason codes for > responses to give additional information, especially in provisional > responses. I can see the use of this, but I'm not sure at this stage > in rfc4474bis's lifecycle I really want to open this up to new > functionality along those lines. It seems to me that this could be > broken off as a modular chunk of future work. > > But how about this - I can put in some text to 6.2.2 to the effect > that future specifications could look at Warnings or Reason codes as > a means to disambiguate the source of errors etc? Sure; that works for me. I will defer to you if you feel, as you write above, that you don't want to open up new functionality at this stage of rfc4474bis. But that said, I will appreciate your to-appear text in S6.2.2. I think that if protocols have primitives to aid in being descriptive, then designers should make use of the said primitives. >> - S6.2.2, the 437 response case. Same reasoning as above. Example: >> >> 437 Unsupported credential >> Warning: 399 https://biloxi.example.org/biloxi.cert > > I think a blanket statement about future work at the end of the > section could cover it. OK. >> - S3: s/can issue them an identity/issues an identity/ > > I like the original better. The organization could also issue them a > telephone number, say, instead of a SIP URI. I don't think that my suggested change precludes issuance of other forms of identity. I think that "issues an identity" reads better and is less colloquial; but if I cannot convince you (as the editor), then no worries. I'll leave it up to you. That's it. For the sake of completeness, I list below the changes agreed upon. Thanks for your time attending to my comments. > >> >> 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],/ > > Good catch, done. >> >> 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." > > Done. >> - S1: You may want to define what "swatting" is for those not well- >> versed in ART terminology. > > The "as described in [RFC7340]" is there for people to read further > about those motivations; it does define swatting etc. >> - 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." > > Um... all right, I guess. Added "... and less vulnerable to spoofing" > to the end of the clause. >> - S3: s/through means entirely up to the authentication >> service,/through per-arranged means with the authentication service,/ > > OK. >> - 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./ > > I think I like the original text here better. >> - S3: s/not so easy to/not as easy to/ > > OK. >> - 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." > > OK. >> - 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./ > > OK. >> - S3: s/prove in some fashion/proves/ > > OK. >> - 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/ > > OK. >> - 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. > > OK. >> - S7.1, second paragaph: s/For non-telephone number user parts/For >> non-telephone number URIs/ > > Um... I think the original is fine? The telephone number is in the > user part. > >> >> - S8, s/vet the identity/confirm the identity/ > > > OK. - vijay -- Vijay K. Gurbani, Bell Laboratories, Nokia Networks Email: [email protected] / [email protected] Web: https://www.bell-labs.com/usr/vijay.gurbani Calendar: http://goo.gl/x3Ogq _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
