Re: [stir] Second WGLC: draft-ietf-stir-passport-rcd-10

Russ Housley <housley@vigilsec.com> Mon, 17 May 2021 15:52 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BD73A3C6C for <stir@ietfa.amsl.com>; Mon, 17 May 2021 08:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcTYpCHWA4PY for <stir@ietfa.amsl.com>; Mon, 17 May 2021 08:52:45 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF323A3C6B for <stir@ietf.org>; Mon, 17 May 2021 08:52:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C26C3300BCC for <stir@ietf.org>; Mon, 17 May 2021 11:52:43 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LzIMESoc-YDf for <stir@ietf.org>; Mon, 17 May 2021 11:52:38 -0400 (EDT)
Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id E5FAC300B10; Mon, 17 May 2021 11:52:37 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <EB782EC9-E17C-4FB1-9200-DC90F2CC281E@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4A80EC38-7116-4B3A-A3DA-2A7C850CFB4F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\))
Date: Mon, 17 May 2021 11:52:37 -0400
In-Reply-To: <6A155012-4DE3-4BB2-9C5E-D452639334C3@chriswendt.net>
Cc: IETF STIR Mail List <stir@ietf.org>
To: Chris Wendt <chris-ietf@chriswendt.net>
References: <5393b70d-bfc7-c8ac-eb8d-30c8087a1e89@nostrum.com> <A8AE8905-8083-40BB-A903-92B5BB409861@vigilsec.com> <DAA9009D-815F-4C87-9614-E02261B8E75F@chriswendt.net> <977e68f2-a2fd-27d8-37cc-8bd232caccf7@nostrum.com> <2CBA8444-013D-4A34-A0F4-00BD41A2C033@vigilsec.com> <5DEB6C9F-A532-4D1D-9489-771C9C4F8247@vigilsec.com> <824DF1D9-61C6-47A0-AC1C-42B744AF8E66@chriswendt.net> <74C5EB05-EBE8-46A7-AF41-DBB6D0E42450@vigilsec.com> <6A155012-4DE3-4BB2-9C5E-D452639334C3@chriswendt.net>
X-Mailer: Apple Mail (2.3445.104.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/RxwPHjL6tXKNfedNA4g697lYZ3o>
Subject: Re: [stir] Second WGLC: draft-ietf-stir-passport-rcd-10
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 May 2021 15:52:51 -0000

Chris:

I think we want to be stronger that "little value".  I think we want to tell certificate issuers that included int "rcdi" claim in the mustExclude list would prevent the relying party from validating the integrity of the rcd.

Russ


> On May 17, 2021, at 11:19 AM, Chris Wendt <chris-ietf@chriswendt.net> wrote:
> 
> Hi Russ,
> 
> Following up on this item. How about this proposed text for security consideration section for enhance-rfc8226:
> 
> There are potentially certain PASSporT claims that are defined to be claims that enhance security or integrity for another claim.  A specific example, “rcd” and “rcdi” are claims defined in [I.D.ietf-stir-passport-rcd] where “rcdi” first depends on the existence of the “rcd” claim and “rcdi” is only serving to qualify the integrity of the information in the “rcd”, not transmit any new information.  Therefore, there is likely little value for whether “rcdi” or claims with similar properties should be included as part of the mustExclude constraint and probably considered general best practice to not include those types of claims.
> 
> Let me know if this aligns with your concern and resolves it.
> 
> -Chris
> 
> 
>> On Mar 19, 2021, at 11:45 AM, Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>> wrote:
>> 
>> Chris:
>>> 
>>> Thanks Russ for the review will take care of editorial/nits, discussion inline:
>>> 
>>>> On Mar 16, 2021, at 12:42 PM, Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>> wrote:
>>>> 
>>>> I have reviewed the document.  It is in good shape, but I have a few comments.
>>>> 
>>>> 
>>>> TECHNICAL:
>>>> 
>>>> What happens if the JWTClaimConstraints in the certificate explicitly excludes the "rcdi" claim?
>>> 
>>> 
>>> Good question, i think the easiest answer is I can’t think of a reason any authoritative certificate creator would want to do that, so question is whether we explicitly say MUST NOT do this normatively somewhere in the document?  I can do that, unless someone can come up with a scenario that excluding “rcdi” claim would be a good thing to do.  To me adding a unauthorized “rcdi” can only confirm the contents that is authorized or break the verification, so not sure there is any possibility of an attack if a “rcdi” is added by delegate signer if it’s not in mustInclude already.
>> 
>> I think a sentence or two in the Security Considerations of draft-ietf-stir-enhance-rfc8226 might be desirable.  It will need a reference to this document to be effective.  That is probably okay.
>> 
>> Russ
>> 
>