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

Alissa Cooper <> Wed, 02 November 2016 18:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE85A129B34; Wed, 2 Nov 2016 11:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=ECDawxpl; dkim=pass (1024-bit key) header.b=NG1+EyNT
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i0wZygh8rl85; Wed, 2 Nov 2016 11:41:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E046B129B2E; Wed, 2 Nov 2016 11:41:43 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 4D0A220945; Wed, 2 Nov 2016 14:41:43 -0400 (EDT)
Received: from frontend2 ([]) by compute3.internal (MEProxy); Wed, 02 Nov 2016 14:41:43 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=1lAhir2GpOBhZ5N Tuvd+iKIfxMc=; b=ECDawxplOX7BRHDGuDAvlX0RfzS4bAAFN1Th9/B4Dx2T1aV 7w4gT+NvVtU3Ih7Mw/q+9S3G64grXi7eivG3g/Lka+DY2oQX9kUppxiO35c25jd9 mwAOacRZO2rnoxyvIw+n+gFC9Zb5AH8TPkTjvFOVPqnX1okCAAPdb9Ld9Xlc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=1lAhir2GpOBhZ5NTuvd+iKIfxMc=; b=NG1+EyNT1D4kGQjOjTOp PbHzZQdrgMFBP79LbxYTTYbr40uK5dG9sEaZ3b3fbg9x7+syrJARip7Zp3NFtsdq T8HMhlvjjcYc+7wz6sM0dp3WuhIQ1513OlyIoJX8QvPbqInerURhcxFac8zkJcUd s7qFCvLM9btGkLU/9HQM5/s=
X-ME-Sender: <xms:ZzMaWFAJaHBZ2vlm5XJ9sUN4JKkCZLhp2DlcNyEGe9kSop7soYqhLQ>
X-Sasl-enc: 2vr4/izWa/m1AM232dr79+68PtPlqFAMeULcEmm+vLPE 1478112102
Received: from (unknown []) by (Postfix) with ESMTPA id 3FE58CC02A; Wed, 2 Nov 2016 14:41:41 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <>
In-Reply-To: <>
Date: Wed, 02 Nov 2016 14:41:40 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Alexey Melnikov <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: Russ Housley <>, IETF STIR Mail List <>, IESG <>,,, Robert Sparks <>
Subject: Re: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Nov 2016 18:41:46 -0000


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 and

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.


> On Nov 2, 2016, at 11:54 AM, Russ Housley <> wrote:
> On Nov 2, 2016, at 11:48 AM, Alexey Melnikov <> wrote:
>> Hi Sean,
>> On Tue, Nov 1, 2016, at 03:15 PM, Sean Turner wrote:
>>>> On Nov 01, 2016, at 09:35, Alexey Melnikov <> wrote:
>> (snip)
>>>> ----------------------------------------------------------------------
>>>> ----------------------------------------------------------------------
>>>> 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