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

[Russ Housley <[e-mail]>]

On Nov 2, 2016, at 11:48 AM, Alexey Melnikov <[e-mail]> wrote:

> Hi Sean,
> 
> On Tue, Nov 1, 2016, at 03:15 PM, Sean Turner wrote:
>> 
>>> On Nov 01, 2016, at 09:35, Alexey Melnikov <[e-mail]> 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