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

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 02 Nov 2016 11:46:24 -0700

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.

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.

---

From: Sean Turner <[email-masked]>
Date: Wed, 2 Nov 2016 21:01:43 -0400

> https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/

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.

> 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 :)

spt

---

From: [email-masked]
Date: Thu, 3 Nov 2016 08:52:06 -0400

Hi Sean,

Please excuse typos, sent from handheld device 

> On Nov 2, 2016, at 9:01 PM, Sean Turner <[email-masked]> wrote:
> 

No problem, that's why I just had this as a comment.
> 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 real…

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 3 Nov 2016 12:23:16 -0400

Sean,

> 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 real…

This *really* further opens up that can of worms!

IIUC you are taking the position that once an update to RFCnnnn is 
published then *every* implementation of RFCnnnn must/will immediately 
implement and deploy the update. That seems unrealistic.

The situation is slightly different when we are talking about a 
reference in a new document that will of necessity get a new 
implementation. Even so, it seems unwise to make such an assumption. It 
is cheap to add the reference to the updating document.

	Thanks,
	Paul