Re: [stir] Kathleen Moriarty's No Objection on draft-ietf-stir-certificates-11: (with COMMENT)

[[e-mail]]

Hi Sean,

Please excuse typos, sent from handheld device 

> On Nov 2, 2016, at 9:01 PM, Sean Turner <[e-mail]> wrote:
> 
>> On Nov 02, 2016, at 14:46, Kathleen Moriarty <[e-mail]> wrote:
>> 
>> Kathleen Moriarty has entered the following ballot position for
>> draft-ietf-stir-certificates-11: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> 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.
> 
> This is really kind of a heads up/observation for implementers.  We didn’t think it necessary to fight the SHA-1 die-die-die fight to get this draft published.  In other words, this bullet could safely be dropped if it turns into a thing.

No problem, that's why I just had this as a comment.
> 
>> I don't see any references to RFCs that update RFC5280, like RFC6818.  It
>> would be good to include these when 5280 is used for revocation methods
>> mentioned.  6818 is for CRLs.
> 
> There’s only one RFC that updates 5280 - 6818 ;)  I guess this gets down to your philosophy on the updates header.  YMMV, but if an RFC updates a previous one then referring to the updated RFC really ought to pull in the all the updates because it’s expected that all implementations of the original RFC also implemented the updates.  Adding the additional references would be the cautious thing to do but I’m thinking it shouldn’t be required that we do that.  Also note we 2119-recommend OCSP :)

Ok, sounds good.  When I look at 5280, I didn't see a forward reference to the updates, hence this comment for developers not as familiar with RFCs.  It's just a comment, so I'm fine either way.

Thanks,
Kathleen 
> 
> spt