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

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 <housley@vigilsec.com> wrote:
> 
> 
> On Nov 2, 2016, at 11:48 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
> 
>> Hi Sean,
>> 
>> On Tue, Nov 1, 2016, at 03:15 PM, Sean Turner wrote:
>>> 
>>>> On Nov 01, 2016, at 09:35, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
>> 
>> (snip)
>> 
>>>> ----------------------------------------------------------------------
>>>> 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.
>>> 
>>> 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.
>> 
>> Adding this somewhere in section 8 would help.
>> 
>>> 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.
>> 
>> 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?
> 
> 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
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir