[stir] draft-ietf-stir-passport-rcd-04

Russ Housley <housley@vigilsec.com> Mon, 09 September 2019 18:45 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 69F1E1200A4 for <stir@ietfa.amsl.com>; Mon, 9 Sep 2019 11:45:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 qqNhF1dJ26n1 for <stir@ietfa.amsl.com>; Mon, 9 Sep 2019 11:45:47 -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 45E07120020 for <stir@ietf.org>; Mon, 9 Sep 2019 11:45:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BCF90300AF6 for <stir@ietf.org>; Mon, 9 Sep 2019 14:45:45 -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 hqUoK2cNnGAL for <stir@ietf.org>; Mon, 9 Sep 2019 14:45:44 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 181903004C0 for <stir@ietf.org>; Mon, 9 Sep 2019 14:45:44 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A63DA8AE-F38B-4509-8CDA-494B1417136B"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 09 Sep 2019 14:45:44 -0400
References: <D0D57997-56AC-4E68-BC12-2CE07C52B711@nostrum.com> <0CCCD3F6-B0A5-4B0C-B563-2E85AC3E3B3A@nostrum.com> <549EB9C4-A4AA-4C8F-976A-FA3E442072C9@nostrum.com>
To: IETF STIR Mail List <stir@ietf.org>
In-Reply-To: <549EB9C4-A4AA-4C8F-976A-FA3E442072C9@nostrum.com>
Message-Id: <EE8FEF3A-3752-4E22-8121-3AB59F4727CF@vigilsec.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/v-gg7CqN5IhbAuq1SH-qPpOunWw>
Subject: [stir] draft-ietf-stir-passport-rcd-04
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, 09 Sep 2019 18:45:50 -0000

Based on Ben's recent questions, I read draft-ietf-stir-passport-rcd-04, and I am concerned about the integrity mechanism.

First, as silly editorial comment.  The example at the end of Section 4.1.1 is:

   "rcd": { "nam" : "James Bond",
            "icon" : "https://example.org/james_bond.jpg"
          }

Based on Section 3.2, I think this should be "icn".

Now, my more substantive concern.

What order must the claims appear?

Consider this example:

   "rcd": { "nam" : "James Bond",
            "icn" : "https://example.org/james_bond.jpg",
            "jcl" : "https://example.org/james_bond.jcard"
          }

This will produce an rcdi that contains the hash of:

   {"nam":"James Bond","icon":"https://example.org/james_bond.jpg", "jcl":"https://example.org/james_bond.jcard"};
   BASE64(WGET(https://example.org/james_bond.jpg <https://example.org/james_bond.jpg>));BASE64(WGET(https://example.org/james_bond.jcard <https://example.org/james_bond.jcard>))

On the other hand, this rcd:

   "rcd": { "nam" : "James Bond",
            "jcl" : "https://example.org/james_bond.jcard",
            "icn" : "https://example.org/james_bond.jpg"
          }

This will produce an rcdi that contains the hash of:

   {"nam":"James Bond","icon":"https://example.org/james_bond.jpg", "jcl":"https://example.org/james_bond.jcard"};
   BASE64(WGET(https://example.org/james_bond.jcard <https://example.org/james_bond.jcard>));BASE64(WGET(https://example.org/james_bond.jpg <https://example.org/james_bond.jpg>))

I think it would be cleaner if there were a specific ordering (maybe alphabetical by the claim key) to eliminate any possibility surprises.


>>> 
>>> 1) Do I understand correctly that the certificate used to sign a PASSporT with an rcdi claim MUST include a constraint for the _value_ of the digest? That is, if someone makes any change to any of the information they would normally include in an rcd claim, the signing party must get a new cert?

I think that Ben is talking about this text:

4.2.  JWT Constraint for "rcdi" claim

   Once both the contents of the "rcd" claim is certified and the
   construction of the "rcdi" claim is complete, the "rcdi" digest is
   linked to the STIR certificate associated with the signature in the
   PASSporT via JWT Constraints as defined in [RFC8226] Section 8.

   The certificate JWT Constraint MUST include both of the following:

   o  a "mustInclude" for the "rcd" claim

   o  a "mustInclude" for the "rcdi" claim and a "permittedValues" equal
      to the created "rcdi" claim value string.

The "permittedValues" part of the last bullet seems like overkill.  I like the a "mustInclude" for the "rcdi" claim, but signing over the digest as computed in Section 4.1.1 should eliminate any surprises.  Putting those have values into the certificate seems like the lifespan of the certificate will be greatly reduced.

Russ