[Rats] eat-claims definition

Thomas Fossati <tho.ietf@gmail.com> Fri, 06 November 2020 13:02 UTC

Return-Path: <tho.ietf@gmail.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447C83A1165 for <rats@ietfa.amsl.com>; Fri, 6 Nov 2020 05:02:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UAPUbDVHruAT for <rats@ietfa.amsl.com>; Fri, 6 Nov 2020 05:02:24 -0800 (PST)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 010923A11D1 for <rats@ietf.org>; Fri, 6 Nov 2020 05:02:19 -0800 (PST)
Received: by mail-lj1-x22b.google.com with SMTP id y25so372413lja.9 for <rats@ietf.org>; Fri, 06 Nov 2020 05:02:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=MdeZ77ofk3zLyjq7HtzHIaVGzijKw5ji3W0yQw504vU=; b=HCP8AtgYQ2yrvDBRRqSjX3JmVLF5iqdjwZU7qnRsfOcOBRtxtE0Pw4jc/rI6HfuX2i xEhAvb+NHaLVwJ5ALxXQZuJujR4JXqv8Ep5zOVzjKreaBMyfLB3c8PO+Ts+JvKIrCfoo eTqtN8crzSB14wqctA2eVD94D+Uon7K2gf0rTeUMfU3IKRBjW5cao0x92B/zdDAuyF6c YB6pvebXWD6fR/jPIBRz9xwrgaod0JXiO2AbNW+bdfgfJD7Mo0cUUoBy4qJonYQgcIR3 VU01puBYfTlDtAyo97YVMwFW5200r4lrrioi9IEYLlvZlATxQZeBQRNiep8YLre4CNYW LQNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MdeZ77ofk3zLyjq7HtzHIaVGzijKw5ji3W0yQw504vU=; b=sllMbHoKP61NU2bTIbMZ22dd3aVdurHZd2a+h/fZwB6fGSM6uYq+83Hqss+An//XQW MahsHkcqToflOni2PVxgHVHbLIuptPceLExNOSLD7Du2UJb9ZcMX77irLHBztkud7cM8 J7JTUyJcOrIAWoqOJANJA02T5k8AGgl+JqFwgUqbs/tD125Q18ll+0hD8mSw6NYOh7ww BqXDmdQUF1muy3jH5lq6ppfvli/VtyrGpYanLQLZCU7JqnGM+axywZtVG2/S5Q4XYhi8 PpWkYJyG50UWGLQr/3xcgjXjMBBZS75l4/ojRpBtgulBao/hbmUmamLKPgbjP0NQa6uF oNcA==
X-Gm-Message-State: AOAM532oN/XRECNIP4u7L2IAmJzJi9LdHoE75cf4m1LTOnOFvm6tg6dK BgjtEdUjmOxu6vIZeJwsGBNuHwlYEsB4Q1xjEieSuu7te/ABZw==
X-Google-Smtp-Source: ABdhPJxdPDsS3TgI6aiiwJb7y6eG8bOvCEqDeSckacFF3c+9u5yH5ozT9ejgOahiyFF8ExhbRPR+Ds7R01ZTd47paE8=
X-Received: by 2002:a2e:9243:: with SMTP id v3mr744738ljg.47.1604667737461; Fri, 06 Nov 2020 05:02:17 -0800 (PST)
MIME-Version: 1.0
From: Thomas Fossati <tho.ietf@gmail.com>
Date: Fri, 6 Nov 2020 13:02:06 +0000
Message-ID: <CAObGJnMzEDEg+AyhG1SYMVV3dgZq2ikQvwB1w60kpNhVGRvi3w@mail.gmail.com>
To: rats@ietf.org, Laurence Lundblade <lgl@island-resort.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/nIJ7GouxIRk1nU5ivu4fK-rInR8>
Subject: [Rats] eat-claims definition
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Nov 2020 13:02:25 -0000

Hi Laurence, all,

I'm giving the latest EAT version a go and I got slightly puzzled by the
fact that the CDDL seems to allow claim duplication (at least
theoretically):

~~~
eat-claims = { ; the top-level payload that is signed using COSE or JOSE
    * claim
}

claim = (
    ueid-claim //
    nonce-claim //
    origination-claim //
    oemid-claim //
    security-level-claim //
    secure-boot-claim //
    debug-disable-claim //
    location-claim //
    age-claim //
    uptime-claim //
    submods-part //
    cwt-claim //
;    generic-claim-type //
)
~~~

Now, CBOR does not allow duplicate keys in a map, and that is re-stated
in Section 4.4.1 of EAT - BTW, I guess a ref to 7049 should be enough,
rather than duplicating text?

With JSON the situation is slightly more nuanced (8259 a "names SHOULD
be unique"), but still it makes total sense to avoid duplicates if one
wants to maximise interop across different stacks.

Besides, if we aim at isomorphism between serialisation formats we need
to go for the LCD here.

So, wouldn't something like:

~~~
eat-claims = {
    ? ueid-claim,
    ? nonce-claim,
    ...
}
~~~

more precisely describe what we actually want?

cheers!
-- 
Thomas