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

[Alexey Melnikov <[e-mail]>]

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.

> Thanks,
> Alissa
> 
> > On Nov 2, 2016, at 11:54 AM, Russ Housley <[e-mail]> wrote:
> > 
> > 
> > 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
> > _______________________________________________
> > stir mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/stir
>