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

Chris Wendt <chris-ietf@chriswendt.net> Tue, 18 May 2021 00:24 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 63C323A1541 for <stir@ietfa.amsl.com>; Mon, 17 May 2021 17:24:15 -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 IcPiZhhNRPzV for <stir@ietfa.amsl.com>; Mon, 17 May 2021 17:24:10 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 236013A1528 for <stir@ietf.org>; Mon, 17 May 2021 17:24:10 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id j11so6242253qtn.12 for <stir@ietf.org>; Mon, 17 May 2021 17:24:09 -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=reVMpS7wgqIzauVd+nvQoMciocVh5Rk+gEJnA6/wh8E=; b=yM4b6OWWo2lDvr3kz66n0+bHJqrbXhYNB+A2jwnxAoHyjG7XpZ/+rK+J0g05SvK3NS rOh+s1v9v6+mZZnun/H23BAobwTKKYihXUmoxg2X77OS73FPjYZGY4XzBvtwkURT2bBk yxQQzUOZzUBLcL5fx1aluZlSJsXv1qIV7OFiDpJAeppl73HNMtpeRDI2tlgMJeaQ2kAr Lm+s1zbMSiPjFtUy8YUyeJWW2X+XNDCmfzE+o2f+DPtppsTQfkWXoI0BXht90NZcKlc9 K1eHOu2cdSgC6HdjhzuQZpL7ROg+TPpgjAo/ipTyMeNRKzhUoaIDp3Of+IB7u8ip0cpZ 0qHQ==
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=reVMpS7wgqIzauVd+nvQoMciocVh5Rk+gEJnA6/wh8E=; b=QSmpK9unZkFrVM0Lb7CQ1QT1l/fvDyDObDl0bWq0M9+ha/cTqOLUrw3lW4knKL2Qzp AlVFiWyinzG4RLeoWlAglWIUb4IMnYx0SOSKPy/bs4cqu63tGtvbNTFJpaRlGqBqTJIH AHdioxZvU+IUt2asVdnAfOdMaN+E0MAkW1w2NH8hupwqjdwfuiqPNpOKuHmurAh5d+Xs OEi41O5JdJd21IB1nazkIOLGVjW42inWN8GQE5tzF34/UNVJeBki+Ssw2QbFNPRNdV2l DRdrfUJ+Q9n4Y42FaJwfRZ/8L2n+dzfGf+jA9h1s90NFD4b+8138BSeiQ6rKnwy9nabO HZIg==
X-Gm-Message-State: AOAM533mNsSWD/h3lLlCpM5qXYsmOJen0hneqy2fZoJP/kTR7UAxYowI pp8YDtAcorbZuszIVHfhp8H6i/7kpwpCOQsW
X-Google-Smtp-Source: ABdhPJwYzGd+HkAXk3Tb/o1BG+7Rkr2wrP78hNOSVMDXRWL+puReuoq/iuAwi8fLkWKpETfrMRuT9Q==
X-Received: by 2002:ac8:7084:: with SMTP id y4mr2110729qto.119.1621297448556; Mon, 17 May 2021 17:24:08 -0700 (PDT)
Received: from smtpclient.apple (29.sub-174-198-18.myvzw.com. [174.198.18.29]) by smtp.gmail.com with ESMTPSA id j29sm11418808qtv.6.2021.05.17.17.24.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 May 2021 17:24:08 -0700 (PDT)
From: Chris Wendt <chris-ietf@chriswendt.net>
Message-Id: <2643D4FC-2917-4BCB-BF8D-FC934AEC6751@chriswendt.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7122B972-A71F-456F-9442-EA2DE502FC93"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Date: Mon, 17 May 2021 20:24:05 -0400
In-Reply-To: <EB782EC9-E17C-4FB1-9200-DC90F2CC281E@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> <6A155012-4DE3-4BB2-9C5E-D452639334C3@chriswendt.net> <EB782EC9-E17C-4FB1-9200-DC90F2CC281E@vigilsec.com>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/-Pa6GYbpcsjmqxlHy9HuPcnVl14>
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: Tue, 18 May 2021 00:24:23 -0000

Ok, sorry i guess i misread what you were saying and was confused at which security considerations in which document we were talking about.  I can definitely include something to address what happens if certificate owner mistakenly includes a mustExclude for “rcdi” in the cases it is required.  I think addressing the point below in RCD document is valid as well although i’ll make it specific to rcd/rcdi and i can include stronger words.  Will update in new version of rcd document.

-Chris

> On May 17, 2021, at 11:52 AM, Russ Housley <housley@vigilsec.com> wrote:
> 
> 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 <mailto: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
>>> 
>> 
>