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

Chris Wendt <chris-ietf@chriswendt.net> Mon, 17 May 2021 15:19 UTC

Return-Path: <chris-ietf@chriswendt.net>
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 92DEF3A3B83 for <stir@ietfa.amsl.com>; Mon, 17 May 2021 08:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com
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 yGIKKSDaff1I for <stir@ietfa.amsl.com>; Mon, 17 May 2021 08:19:53 -0700 (PDT)
Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710BA3A3B82 for <stir@ietf.org>; Mon, 17 May 2021 08:19:53 -0700 (PDT)
Received: by mail-qv1-xf2e.google.com with SMTP id ee9so3248928qvb.8 for <stir@ietf.org>; Mon, 17 May 2021 08:19:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=o71acu9G7b8bTuPbiOlDyJAdjgmmOd3H3nYJGvpSZ9c=; b=v9BHtAGjlgg+JzIJ1MC8fZ399rOOS6VmCo1+t+zT8lirQBG5vk9u2I7uuE/jU0pEid 4K3D1UpUioi7kEpLI1nICRspKaGAt2WvIcvUp9EX5j38DnH5lopKMG61k/yvbn14PZUW 6F1f8FsoolDL3y5kWqhBK0biKeyCCE9Rb6nCQUyt3Q0oq4RGEGZVNuWjrGor8IiiJX6D zDdrkI9L5vbpNg8oeKTtDFnL69eRqNwhCl0kemtoo2hmq046mKJoMrigatYBw0oTrFIM zqNYqw/gusvIL94HqCsrkrQWeFs7IKjC3EQJxBeNrmxzr+34d16VnrS0f0LjmCU0HTXn IquA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=o71acu9G7b8bTuPbiOlDyJAdjgmmOd3H3nYJGvpSZ9c=; b=V0c00yIaRz6CyYOvZHGnK7QVEFs7FWkjYw5/DP6fAfQc5bzQW6MUJ2PKQj4dZzcsro m/1xbKhuAEzRjpfV4o0+ea+Gezi82Jd9VEolwf2+C9ZhFUdi3vBfM8ZPfImlHUDTsglB dVkbcO5vLuq02J/3p5EpRlla2GxB1c6gLm5lEgzsXFSaZE2jglImkjj7K9L5BTpfmO+/ XBulFr0yRoTsqT33+rjkhvAvi1ADnzqaZcdrec8ZQ0VwMkPfoqc203RRtL/H2RhKNOFn bQAqARu6TAGE9XmT0TpdbjoSwZ1zhy/6aPEbpnsDCiRANSFFxlxWTtp7cRFMOOXZ0VUW eKgA==
X-Gm-Message-State: AOAM530EI4QZmqvpzMVz5RAKHiOe4mn6gBjVe+nWKxCr3k6cgRPi+cJG cGP2WUoPDsE+L0N5DDrtUekwPA==
X-Google-Smtp-Source: ABdhPJyBZSQEiwJ3/A9/CuOJwKC8gue0XXDe8fRgrISanoYXhMXytIhpwRWfxovy5TfzYXXfdOSbpg==
X-Received: by 2002:a0c:f98a:: with SMTP id t10mr116770qvn.54.1621264791499; Mon, 17 May 2021 08:19:51 -0700 (PDT)
Received: from smtpclient.apple (c-68-82-121-87.hsd1.pa.comcast.net. [68.82.121.87]) by smtp.gmail.com with ESMTPSA id h12sm10526790qkj.52.2021.05.17.08.19.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 May 2021 08:19:50 -0700 (PDT)
From: Chris Wendt <chris-ietf@chriswendt.net>
Message-Id: <6A155012-4DE3-4BB2-9C5E-D452639334C3@chriswendt.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_27512E2B-33B2-4A11-ADB0-748BC49711CF"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Date: Mon, 17 May 2021 11:19:50 -0400
In-Reply-To: <74C5EB05-EBE8-46A7-AF41-DBB6D0E42450@vigilsec.com>
Cc: IETF STIR Mail List <stir@ietf.org>
To: Russ Housley <housley@vigilsec.com>
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>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/T-vkU-D1CNk8aDXqswM5RLlgrxA>
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:20:00 -0000

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> 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> 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
>