Skip to main content

Secure Telephone Identity Credentials: Certificates
draft-ietf-stir-certificates-18

Yes

(Alissa Cooper)
(Ben Campbell)

No Objection

(Alia Atlas)
(Alvaro Retana)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 11 and is now closed.

Alissa Cooper Former IESG member
Yes
Yes (for -11) Unknown

                            
Ben Campbell Former IESG member
Yes
Yes (for -11) Unknown

                            
Alexey Melnikov Former IESG member
(was Discuss) No Objection
No Objection (2017-03-23 for -12) Unknown
Thank you for addressing my DISCUSS. The latest revision has introduced some minor errors which I don't think are intentional:

8.  JWT Claim Constraints Syntax

   The subjects of certificates containing the JWT Claim Constraints
   certificate extension are specifies values for PASSporT claims that
   are permitted, values for PASSporT claims that are excluded, or both.
   The syntax of these claims is given in PASSporT; specifying new
   claims follows the procedures in [I-D.ietf-stir-passport]
   (Section 8.3).  When a verifier is validating PASSporT claims, the
   JWT claim MUST contain permitted values, and MUST NOT contain
   excluded values.  The non-critical JWT Claim Constraints certificate
   extension is included in the extension field of end entity
   certificates [RFC5280].  The extension is defined with ASN.1
   [X.680][X.681][X.682] [X.683].

The above text lists "excluded" claims several times, but you removed excluded from the ASN.1:

    JWTClaimConstraint ::= SEQUENCE {
      claim IA5String,
      permitted SEQUENCE OF IA5String
          }

 So I think the text needs to be edited to be correct or you need to fix the ASN.1

In Section 9:

ServiceProviderCodeList ::= SEQUENCE SIZE (1..3) OF	
  IA%String

Typo: IA5String
Alia Atlas Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2016-11-02 for -11) Unknown
Introduction: nit,
   Robocallers use impersonation as a means
   of obscuring identity; while robocallers can, in the ordinary PSTN,
   block (that is, withhold) their caller identity, callees are less
   likely to pick up calls from blocked identities, and therefore
   appearing to calling from some number, any number, is preferable.

s/appearing to calling/appearing to call/

Section 10.2.1:
I'm wondering why SHA-1 is described as follows instaed of discouraged/not allowed ...
o  There is no requirement to support SHA-1, RSA with SHA-1, or DSA
      with SHA-1.

I don't see any references to RFCs that update RFC5280, like RFC6818.  It would be good to include these since 5280 is used for revocation methods mentioned.  6818 is for CRLs.
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2017-03-14 for -12) Unknown
Thanks for handling my discuss points, esp about cert
status. I think it'd be great if STIR prompted work to
ensure better privacy for OCSP transactions as that'd
be a useful mechanism (in addition to stapling) so I 
hope that the further work envisaged here happens 
in the not too distant future.
Suresh Krishnan Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -11) Unknown