Subject: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT)

From: "Alexey Melnikov" <[email-masked]>
Date: Tue, 01 Nov 2016 06:35:02 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-stir-certificates-11: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have one small issue that I would like to discuss before recommending
approval of this document:

Reading Section 8 I was unable to figure out what are "claim",
"permitted" and "excluded" and what exact syntaxes they use. I think this
is underspecified.
You are probably missing some references, examples or both.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

URI (RFC 3986), HTTP (RFC 7230) and HTTPS (RFC 2818) need to be Normative
References.

---

From: Sean Turner <[email-masked]>
Date: Tue, 1 Nov 2016 11:15:01 -0400

> On Nov 01, 2016, at 09:35, Alexey Melnikov <[email-masked]> wrote:
> 

From s5.1:

   The public key in the certificate is used to validate the signature
   on a JSON Web Token (JWT) [RFC7519] that conforms to the conventions
   specified in PASSporT [I-D.ietf-stir-passport].  This specification
   supports constraints on the JWT claims, which allows the CA to
   differentiate those enrolled from proof-of-possession versus
   delegation.

the JWT claims for STIR are found in s5 of [I-D.ietf-stir-passport].  We define our own but also use some existing ones so we could add a reference as follows to clear this up:

   …, This specification
   supports constraints on the JWT claims [I-D.ietf-stir-passport],
   which allows the CA to differentiate those enrolled from
   proof-of-possession versus delegation.

Permitted and excluded are in s8 (they’re just IA5Strings):

JWTClaimConstraint ::= SEQUENCE {
      claim IA5String,
->      permitted [1] SEQUENCE OF IA5String OPTIONAL,
->      excluded  [2] SEQUENCE OF IA5String OPTIONAL }
       ( WITH COMPONENTS { ..., permitted PRESENT } |
       WITH COMPONENTS { ..., excluded PRESENT } )

These are analogous to the permitted and excluded name and policy constraints in X.509/RFC 5280.

spt

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Nov 2016 15:48:45 +0000

Hi Sean,

> > On Nov 01, 2016, at 09:35, Alexey Melnikov <[email-masked]> wrote:

 (snip)

> the JWT claims for STIR are found in s5 of [I-D.ietf-stir-passport].  We
> define our own but also use some existing ones so we could add a
> reference as follows to clear this up:
> 
>    …, This specification

Adding this somewhere in section 8 would help.

> constraints in X.509/RFC 5280.

I am sorry if I am being thick, but I still don't get what is this all
about. Doing a quick scan of RFC 5280 I only found permittedSubtrees.
Can you give me an example or two on how this is going to be used?

---

From: Russ Housley <[email-masked]>
Date: Wed, 2 Nov 2016 11:54:21 -0400

> Can you give me an example or two on how this is going to be used?

Alexey:

For a named claim, the extension limits the possible values that can appear.

If the permitted SEQUENCE is populated, then the listed claim MUST contain one of the listed values.

If the excluded SEQUENCE is populated, then the listed claim MUST NOT contain one of the listed values.

Russ

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 2 Nov 2016 14:41:40 -0400

Alexey,

My understanding of the JWT Claim Constraints is that a CA can use them to constrain which claims it expects to receive when asked to validate a cert. Let’s imagine a context in which the base set of claims defined in this spec has been extended to include a “confidence” claim that allows a carrier to differentiate between cases where a number block is fully operated by a customer (e.g., Carrier X assigns a block to Enterprise Y), delegated to a wholesaler, or operating via an SBC. Imagine that the “full,” “delegated,” and “sbc” claims about a “confidence” claim have all been specified. The permitted and excluded constraints could be used to limit claims to one of these categories, e.g., permitted would be set to “full” for the claim “confidence” for numbers in the block used by Enterprise Y.

The syntax for expressing permitted and excluded is analogous to the syntax used for name constraints and policy constraints in RFC 5280 (sections 4.2.1.10 and 4.2.1.11).

I realize this is a little hard to grasp because it is defining a constraint mechanism largely for use cases involving claims that have yet to be specified. Does it make sense conceptually, though? If so, hopefully the authors can figure out some text to add that would clarify it, if necessary.

Thanks,
Alissa

> On Nov 2, 2016, at 11:54 AM, Russ Housley <[email-masked]> wrote:
> 
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Dave Crocker <[email-masked]>
Date: Wed, 2 Nov 2016 11:52:03 -0700

> My understanding of the JWT Claim Constraints is that a CA can use them to constrain which claims it expects to receive when asked to validate a cert. Let’s imagine a context in which the base set…

Alissa,

This presumes that claims are to be made about 'interesting' properties 
and issues, whereas the actual task the work is chartered for is far 
simpler, namely authentication of a call's identifier.

More generally, you have described here a broad model for processing 
that is to be performed by the receiver, based on these (standardized?) 
claims by the caller (or, rather, the caller's operator.)

Do you have examples of such a distributed, multi-administration policy 
and decision model being used successfully?

What has been defined and what you describe is quite a complex system.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Nov 2016 19:17:44 +0000

Hi Alissa,

On Wed, Nov 2, 2016, at 06:41 PM, Alissa Cooper wrote:
> Alexey,
> 
> My understanding of the JWT Claim Constraints is that a CA can use them
> to constrain which claims it expects to receive when asked to validate a
> cert. Let’s imagine a context in which the base set of claims defined in
> this spec has been extended to include a “confidence” claim that allows a
> carrier to differentiate between cases where a number block is fully
> operated by a customer (e.g., Carrier X assigns a block to Enterprise Y),
> delegated to a wholesaler, or operating via an SBC. Imagine that the
> “full,” “delegated,” and “sbc” claims about a “confidence” claim have all
> been specified. The permitted and excluded constraints could be used to
> limit claims to one of these categories, e.g., permitted would be set to
> “full” for the claim “confidence” for numbers in the block used by
> Enterprise Y.

Ok, this makes some sense.

A followup question: what is the syntax of claim name? (I understand
that IA5String provides a restriction, but I am wondering if many people
outside of Security area actually know what these restrictions are).

Are claim tokens likely to be allocated by IANA?

> The syntax for expressing permitted and excluded is analogous to the
> syntax used for name constraints and policy constraints in RFC 5280
> (sections 4.2.1.10 and 4.2.1.11).
> 
> I realize this is a little hard to grasp because it is defining a
> constraint mechanism largely for use cases involving claims that have yet
> to be specified. Does it make sense conceptually, though? If so,
> hopefully the authors can figure out some text to add that would clarify
> it, if necessary.

Yes, that is why I've asked about an example. Adding something along the
lines of your hypothetical example is fine.

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 3 Nov 2016 13:12:36 +0000

>outside of Security area actually know what these restrictions are).

PASSporT claim names are simply JWT claim names (per stir-passport Section
5), and...

>Are claim tokens likely to be allocated by IANA?

... PASSporT simply reuses the IANA allocation method of JWT, so yes, the
claims are allocated by IANA. This is the registry.

http://www.iana.org/assignments/jwt/jwt.xhtml

To your more recent question, "I was also wondering if any of these value
can possible contain non ASCII Unicode characters, and if they do, how can
they be encoded as IA5String." If the question is "can possibly" then I'm
not sure JWS/JWT specifically bars it (someone likely knows better than
me, this may just devolve back to how JSON member strings are defined).
However, I don't think any of the existing or planned registered values
fall outside of ASCII ranges. I don't think I'd lose much sleep over it,
given what the review processes are like and what the likely constraints
are CAs would want to apply.

Jon Peterson
Neustar, Inc.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 03 Nov 2016 13:37:13 +0000

> claims are allocated by IANA. This is the registry.

I think this document should say so.

> are CAs would want to apply.

I would just add a warning about possibility to alert future readers and
Expert Reviewers.

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 3 Nov 2016 13:46:36 +0000

>I think this document should say so.

I mean, the thing in stir-certs is called "JWT Claim Constraints". I think
it would be clear that to figure out how you register claims, you look at
JWT. The section also refers you to PASSporT, which pretty quickly drops
you back to JWT, like stir-passport Section 8.3:

"Specifying new claims follows the baseline JWT procedures ([RFC7519]
Section 10.1)."

Do you just want us to put another copy of that sentence in stir-certs?

>I would just add a warning about possibility to alert future readers and

Makes sense, we can do that - though again I might ask the reviewers (Jim
Schaad etc) whether their reading of the existing procedures wouldn't make
that warning redundant.

Jon Peterson
Neustar, Inc.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 03 Nov 2016 14:06:16 +0000

> "Specifying new claims follows the baseline JWT procedures ([RFC7519]

Please stick the relevant reference in Section 8 of this draft, this was
not clear to me, especially as I read this document first.

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 3 Nov 2016 14:08:14 +0000

Not a problem.

Jon Peterson
Neustar, Inc.

On 11/3/16, 10:06 AM, "Alexey Melnikov" <[email-masked]> wrote:

>> >> can possible contain non ASCII Unicode characters, and if they do,
>>how
>> >> can

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 3 Nov 2016 15:22:28 -0400

Hi Dave,

> On Nov 2, 2016, at 2:52 PM, Dave Crocker <[email-masked]> wrote:
> 
> This presumes that claims are to be made about 'interesting' properties and issues, whereas the actual task the work is chartered for is far simpler, namely authentication of a call's identifier.

The above was a hypothetical example provided to help Alexey understand how the JWT Claim Constraints may be used. Section 8.1 of draft-ietf-stir-passport specifies the requirements for additional claims, which need to relate to the required claims and behaviors. What is presently documented is simply the extension point, not any particular extensions.

> 
> More generally, you have described here a broad model for processing that is to be performed by the receiver, based on these (standardized?) claims by the caller (or, rather, the caller's operator.)
> 
> Do you have examples of such a distributed, multi-administration policy and decision model being used successfully?
> 

I think the existing system of relationships and network paths that comprise the phone system is the root of the complexity here; the challenge for STIR has been to provide building blocks with enough flexibility to help address the requirements in RFC 7340 across a variety of different deployment scenarios and use cases.

Alissa

---

From: Dave Crocker <[email-masked]>
Date: Thu, 3 Nov 2016 14:11:31 -0700

On 11/3/2016 12:22 PM, Alissa Cooper wrote:
> I think the existing system of relationships and network paths that
> comprise the phone system is the root of the complexity here; the
> challenge for STIR has been to provide building blocks with enough
> flexibility to help address the requirements in RFC 7340 across a
> variety of different deployment scenarios and use cases.

Alissa,

I've heard that being said, but in fact the phone system's design is 
almost completely irrelevant to the specifics of STIR.  STIR's actual 
task is almost identical to the job that DKIM does.

The only relevant detail from the world of telephony is the existence of 
call centers that must be able to generate calls that appear to be from 
a call center customer.

This is identical to being able to have an email From: address contain a 
value that differs from the domain name associated with the email 
operator being used.

d/
-- 

   Dave Crocker

-- 

   Dave Crocker