[Rats] a quick look at PKIX evidence

Thomas Fossati <thomas.fossati@linaro.org> Mon, 29 July 2024 17:35 UTC

Return-Path: <thomas.fossati@linaro.org>
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 C3885C151549 for <rats@ietfa.amsl.com>; Mon, 29 Jul 2024 10:35:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=linaro.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6KOQgjA9ToS for <rats@ietfa.amsl.com>; Mon, 29 Jul 2024 10:35:41 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2248C15107A for <rats@ietf.org>; Mon, 29 Jul 2024 10:35:41 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-52f00ad303aso6061656e87.2 for <rats@ietf.org>; Mon, 29 Jul 2024 10:35:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1722274540; x=1722879340; darn=ietf.org; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=u7GJ08FJwa5Jx87pgr9Jj+AkKjkhKbZ6NsJLxoJnoT8=; b=xNlmJ4FqOv2TmMSf1MF7cmdZHCX2OzuWOnZhfAoezP27NCzydRZePVLCyt6MkuJFR2 b4kOf8RKh0sNuEU0geURfh5H3DuklA8Zs4SyR9inlVa6qLGqpRya58JKRqWLyqSAHQUM 1f9R857ZYo1kS+/PtY/bSMm4AGrTwHOKd80x3oSBSo5tPpWzeGvP6rk1HLpj5BppXcmo hBEK5UUuQ5xmwiVBQdM9qhFaxXIa+itDUprTvcDZFLkjCuHjYa6aMTdbXmB+xugWkj46 7Aeu5lowNtSg1nG7ASldwqaIZqxrs9QeNvgzDclbcuYRAwGCkdnKrjqM0uC+AcMpWXHa 1AsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722274540; x=1722879340; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=u7GJ08FJwa5Jx87pgr9Jj+AkKjkhKbZ6NsJLxoJnoT8=; b=gpSF0nTMuQBeHAlqxt22VFg0UEGs8dx9jWHBD/CqoHlv/wqVr6V61sITD6/NPYxO6S Y+Hld2y/Hd1++d4CswZcwf3RIN17KVzgzH/9345PuWfyMX29VGczKODwGiLLX9jI8eBv r0/g9VBylCCoM75tsW9hkRv3QOLoemb1A01iUOXObyDVfIZUrkMolJ/YlpJARjJEj4MZ J9rxxlwVi2kYL7CwkY58d6qwhWTOhwMDQbslBdNuBLccWsE0hylAorV9iOZTIiBfRBxi NQjaLu5fZ8UN1aNzMQorHmcVkWhgpGOs3UogzDnP1ZGRELKimdQAglfvA1BxYgyyBrg5 Bbkg==
X-Gm-Message-State: AOJu0YxeTSC0Xythh9Xl/zx+U8IkXIgLs9mGHnkj9sXdDTw3qLMvaZjm c1vFuPVlhp7JumW0c11xggdmtqvQ9jRXmMNdjYTOPQADtBlhSGx0ZCJYjJ2D9SXAHqcAXcX/2pS wG8MRnuy7M/A3Ng3BQvfyIZ386f0dvUBPk+uq5aoj7YdRHKVHTE0=
X-Google-Smtp-Source: AGHT+IFjpeBGC4iyxJGraglJzxs/c8cWKEBnjOuqkCdpgeg23Bv0qmBzDr3Rv98fOzbHuvPFBcYBfjKr+Ibiqq1oVWc=
X-Received: by 2002:ac2:5501:0:b0:52e:f950:31f3 with SMTP id 2adb3069b0e04-5309b280a2amr5894520e87.35.1722274539603; Mon, 29 Jul 2024 10:35:39 -0700 (PDT)
MIME-Version: 1.0
From: Thomas Fossati <thomas.fossati@linaro.org>
Date: Mon, 29 Jul 2024 19:35:23 +0200
Message-ID: <CA+1=6yfKQXkaQbqBXyhUSjR0QOxRBRYLT_9w5f65aWfUTEaz6Q@mail.gmail.com>
To: rats <rats@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: C7JD5MOB74UTHTVVC6Q5UQDD4DYNLNEB
X-Message-ID-Hash: C7JD5MOB74UTHTVVC6Q5UQDD4DYNLNEB
X-MailFrom: thomas.fossati@linaro.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rats.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Rats] a quick look at PKIX evidence
List-Id: Remote ATtestation procedureS <rats.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/7DPBdwPUx106GChVbJRnK4ARocE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Owner: <mailto:rats-owner@ietf.org>
List-Post: <mailto:rats@ietf.org>
List-Subscribe: <mailto:rats-join@ietf.org>
List-Unsubscribe: <mailto:rats-leave@ietf.org>

Hi,

I read draft-ounsworth-rats-pkix-evidence-00 and have a few
observations which I wanted to share.

The TL;DR of this document is it provides an ASN.1-based encoding
format for attestation evidence produced by HSMs (and similar gizmo)
which reuses (and slightly extends) EAT semantics.

I think this is a laudable goal and personally support it.

Two tiny comments regarding the claims:
* Extensible EAT claims (e.g., Measurements, Manifests) have specific
extension mechanics, and may be tricky to deal with in another
context. (At a minimum, an extra coordination layer is probably
necessary.)
* Submods are associative arrays: not sure how ASN.1 deals with that
in non-clumsy ways (SEQUENCE OF SEQUENCE { name, CHOICE { value_1 ...
value_n } } ) ? :-)


The point where I stop agreeing with the direction the document is
headed to is section 6.

This is where it is explained how these evidence claims can be
re-published as attestation results.

I have two kinds of concerns with that:
1. privacy
2. architectural

The privacy recommendations in Section 8 are IMO not sufficient.   The
draft says that "the CA MUST have a configurable mechanism to control
re-publishing", but I think the subject here should be explicitly the
attester.  It should read: "the attester MUST be able to control
granularity (including opt-out)". But this is a bit tricky because
it's a requirement that trickles through any enrolment protocol (ACME,
etc.) - i.e., every conveyance protocol / API that allows
re-publishing must offer a way to opt-out altogether and/or select
what can be exposed.  Tough stuff.

The other concerning dimension is architectural: i.e., I don’t think
this is the right approach.

The problem is it creates a strong coupling between attesters and RPs.

Consequently, RP policy complexity grows unbounded because it needs to
take care of all possible attesters’ claims-set flavours.  (If you’ve
ever had to read through one of those seemingly infinite and
infinitely growing rego files you know what I am talking about.)
You may argue that the standardised claims-set put forward by the
draft is enough to create an homogenous attesters' space, but that's
not the case - cfr. EAT profiles.  Besides, note that this kind of
re-publishing could be, in principle, be used for attesters that share
the same info model, i.e., EAT-based attesters.

To counter the looming scalability disaster, the right re-publishing
model is instead one which provides abstract trust categories and a
standardised scoring system - e.g., AR4SI.

This way no privacy-related disclosures are ever possible and all RPs
can be instructed to use a normalised set of high-level attributes to
describe their policies, which scales optimally.

cheers, thanks!
t