Ballot for draft-ietf-stir-certificates
Yes
No Objection
Note: This ballot was opened for revision 11 and is now closed.
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
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.
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.