[Gen-art] COMPLETE Gen-ART review of draft-ietf-stir-rfc4474bis-14

["Vijay K.Gurbani" <[e-mail]>]

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: [e-mail] / [e-mail]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq