Subject: [stir] I-D Action: draft-ietf-stir-certificates-17.txt

From: [email-masked]
Date: Thu, 14 Dec 2017 07:55:19 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Telephone Identity Revisited WG of the IETF.

        Title           : Secure Telephone Identity Credentials: Certificates
        Authors         : Jon Peterson
                          Sean Turner
	Filename        : draft-ietf-stir-certificates-17.txt
	Pages           : 22
	Date            : 2017-12-14

Abstract:
   In order to prevent the impersonation of telephone numbers on the
   Internet, some kind of credential system needs to exist that
   cryptographically asserts authority over telephone numbers.  This
   document describes the use of certificates in establishing authority
   over telephone numbers, as a component of a broader architecture for
   managing telephone numbers as identities in protocols like SIP.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-stir-certificates-17
https://datatracker.ietf.org/doc/html/draft-ietf-stir-certificates-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-certificates-17

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Sean Turner <[email-masked]>
Date: Thu, 14 Dec 2017 10:57:13 -0500

This version addresses ekr’s discuss and IANA’s request to include additional fields (which I forgot).

spt

> On Dec 14, 2017, at 10:55, [email-masked] wrote:
> 
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Dec 2017 10:42:23 -0600

Hey Sean, why did you choose to allow capped ranges rather than making
them invalid?

"123"+900 is now equivalent to "123"+876, which means that you have
two ways to represent the same thing.  Don't we try to avoid that in
certificates?  (I mean otherwise we'd use BER...)

---

From: Sean Turner <[email-masked]>
Date: Thu, 14 Dec 2017 12:40:43 -0500

The only reason I can come up with is to allow laziness.

spt

> On Dec 14, 2017, at 11:42, Martin Thomson <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Dec 2017 11:42:14 -0600

That doesn't sound like a good reason.

---

From: Sean Turner <[email-masked]>
Date: Thu, 14 Dec 2017 12:59:01 -0500

> certificates?  (I mean otherwise we'd use BER...)

As far encoding something the same way: I’d be worried if “123”+900 and “123”+876 resulted in the same DER code, but it doesn’t.

spt

---

From: Russ Housley <[email-masked]>
Date: Thu, 14 Dec 2017 16:19:59 -0500

> On Dec 14, 2017, at 12:59 PM, Sean Turner <[email-masked]> wrote:
> 

No, this bits on the wire are different, but they specify the same block of telephone numbers.  Why do we want more than one way to specify the same block of numbers?

Russ

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Dec 2017 17:03:25 -0500

> No, this bits on the wire are different, but they specify the same block of telephone numbers.  Why do we want more than one way to specify the same block of numbers?

I agree that "123"+900 seems like a bad idea.

But even without that there are multiple ways to specify the same range 
of numbers: a single range, two or more smaller ranges that collectively 
cover the range, or a complete list of individual numbers.

	Thanks,
	Paul

---

From: Russ Housley <[email-masked]>
Date: Fri, 15 Dec 2017 16:45:01 -0500

> On Dec 14, 2017, at 5:03 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> But even without that there are multiple ways to specify the same range of numbers: a single range, two or more smaller ranges that collectively cover the range, or a complete list of individual numbers.

To be clear, there is not a security issue here.  "123" + 900 and "123" + 876 specify the same block of numbers.  If a certificate issuer says "123" + 900, do we really want to reject the certificate as badly formed?

Does anyone have language to make "123" + 876 the preferred encoding?

Russ

---

From: Martin Thomson <[email-masked]>
Date: Fri, 15 Dec 2017 17:08:31 -0600

> To be clear, there is not a security issue here.  "123" + 900 and "123" + 876 specify the same block of numbers.  If a certificate issuer says "123" + 900, do we really want to reject the certifica…

Yup.

> Does anyone have language to make "123" + 876 the preferred encoding?

OLD:
   count never
   makes the number increase in length (i.e., a TelephoneNumberRange
   with TelephoneNumber=10 with a count=91 will address numbers
   10-99); formally, given the inputs count and TelephoneNumber of
   length D the end of the TelephoneNumberRange is:
   MIN(TelephoneNumber + count, 10^D - 1).
NEW:
   count MUST NOT make the number increase in length (i.e., a
TelephoneNumberRange
   with TelephoneNumber=10 with a count=91 is invalid); formally,
given the inputs count and TelephoneNumber of
   length D TelephoneNumber + count MUST be less than 10^D.

That is, treat "123"+900 the same way you would a range with a
negative count "123"+(-10).

---

From: Russ Housley <[email-masked]>
Date: Fri, 15 Dec 2017 19:59:17 -0500

> On Dec 15, 2017, at 6:08 PM, Martin Thomson <[email-masked]> wrote:
> 

Note, the ASN.1 syntax requires the count to be an INTEGER greater than 2.

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 18 Dec 2017 14:28:11 -0500

{STIR WG Chair Hat ON}

>   length D TelephoneNumber + count MUST be less than 10^D.

I have not heard anyone object to this text, so I'm asking the authors to add it to the document.

Russ