IETF Logo Mail Archive

Re: [SCITT] Constraints on unprotected data in receipt...

Orie Steele <orie@transmute.industries> Wed, 10 May 2023 22:45 UTC

Return-Path: <orie@transmute.industries>
X-Original-To: scitt@ietfa.amsl.com
Delivered-To: scitt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4FAC1D25BF for <scitt@ietfa.amsl.com>; Wed, 10 May 2023 15:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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=transmute.industries
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 sCziXE09w_Dw for <scitt@ietfa.amsl.com>; Wed, 10 May 2023 15:45:17 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA169C1CCC9B for <scitt@ietf.org>; Wed, 10 May 2023 15:45:17 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-50bd2d7ba74so73538255a12.1 for <scitt@ietf.org>; Wed, 10 May 2023 15:45:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; t=1683758715; x=1686350715; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=I9HvgBgph5mAVIwO0ZsfYxPVmW9KFzsensOAugynzX4=; b=bm7cZxv9Rf4c4o22MapcCJKKUdbF4yrq32765lhcwys7mFgeR7iiqQgo2NpF+gIwa+ 369Thj3M9qKYY26YrGc4OkBn5cj6C77QdOlWRWxdD6aTQgvQb4qXSHOcGiqU4ymy1Ly+ Y9aurKRhJDGunz4S1SLuikNIRqsoaURQLT3ArfBuU+8LS7Dqet0OGeZoLhXDzmpfuiBi GMVWxxul4eJPm6RBV/QqgkUrSgEZvl+AHRcBUQ+WdgxL+Qqgg5NgF1i63CIjOoNyegxu 2XROYGhu0tpMIB0mP7UwjmACqJnFpeD+TyvYWfBSxIMAdPUqgZrPWMhaIbi9LC/yZ3/7 l5cw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683758715; x=1686350715; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=I9HvgBgph5mAVIwO0ZsfYxPVmW9KFzsensOAugynzX4=; b=CKJ0RAiMq5E3fuA4dSjDXU5Qv1MnOnoqQ6a9WdPmPzZ6gJ5U+zEC57op4PfSmgtxlm qf0I+/q4EgD3xkWowt8HYs7Q1LHysBte6JAS5hzcEJLOECmYuNA4dWb8BFZn55Jhbeqg Z4qo0of1kDPVROpLcnmza3+nDRQiZ1jJKhSheXFSDruAI1JKDzEfFF02lkPLhhD6p07B 5pBLiVa5pkS8iFEiqO4axhTxj2hcpV3dCj3usXBXxkp9mcX6Sm+zyGub5OT9sVORh/aF Gq5688bWLLA5tXa3iAg0yR5ePEZcd+Xic5DZfoUU7a1ylf/Cp9MF36lUxmC/BHgsCbOW b6vw==
X-Gm-Message-State: AC+VfDz5Ci3EYSn1stp/invL9PaVRBb571XQvZdn/AdXBSK2Iw/zL3lZ iNw4RYmRmkZIBaBggtaWLYyR0k4NrnqOQq88mfz06QSaHH6K0MGk
X-Google-Smtp-Source: ACHHUZ6YH3WadDp6YjNOA40dDhQLMjU+Tz+auiK5615VCsSSfYeaPTXTJ7Qmnl9UYI6Fm0DRWklVNuH8FreDVzBsrtY=
X-Received: by 2002:a17:907:8a24:b0:969:e993:6ff0 with SMTP id sc36-20020a1709078a2400b00969e9936ff0mr6918564ejc.25.1683758714816; Wed, 10 May 2023 15:45:14 -0700 (PDT)
MIME-Version: 1.0
References: <5b797713-0618-1eb2-1b74-ecee65af423b@citizensoversight.org>
In-Reply-To: <5b797713-0618-1eb2-1b74-ecee65af423b@citizensoversight.org>
From: Orie Steele <orie@transmute.industries>
Date: Wed, 10 May 2023 17:45:02 -0500
Message-ID: <CAN8C-_KAhmR85BOSnVppQ-b75=9a7p9nkB6KpFS4STH1HMS=TQ@mail.gmail.com>
To: Ray Lutz <raylutz@citizensoversight.org>
Cc: scitt <scitt@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000159cc805fb5ea01f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/scitt/XZXU5jnNX6xzv8Medkoyqe76y_c>
Subject: Re: [SCITT] Constraints on unprotected data in receipt...
X-BeenThere: scitt@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Supply Chain Integrity, Transparency, and Trust" <scitt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scitt>, <mailto:scitt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scitt/>
List-Post: <mailto:scitt@ietf.org>
List-Help: <mailto:scitt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scitt>, <mailto:scitt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 May 2023 22:45:21 -0000

Question seems related to keytrans and this issue:

https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/65

OS

On Wed, May 10, 2023, 5:32 PM Ray Lutz <raylutz@citizensoversight.org>
wrote:

> Hi SCITT list:
>
> Henk asked me a question the other day and I had more time to think
> about it, and so I am providing these ideas to the list.
>
> The question is: Should the public key appear in the unprotected portion
> of the receipt, or can it be an id of the public key.
>
> The answer I think is driven by a rule I think is appropriate for the
> design of the SCITT architecture.
> This rule is that the receipt should be testable without consulting any
> other resource, to a great extent, but indeed not fully.
> If the public key is included in the receipt, then we can check the
> consistency of the receipt without an internet connection, and even in
> an air-gapped environment.
> If we have only a "public key ID," then that may not comply with this
> rule, bc then the public key has to be looked up using the ID and that
> may not
> be possible. Thus, including the public key in the receipt of the SCITT
> service would be the best course.
>
> Given a SCITT receipt, it should be possible to check the consistency
> using the public key without any other information.
> Later, and if the user is no longer in an air-gapped isolated network,
> the certificates can be checked etc. to further substantiate the data.
>
> Further, I notice in the architecture docs the idea that the public key
> and private key of a SCITT service has to be consistent for a long
> period of time.
> That is obviously not a good idea, as we will need the option of
> rotating keys and upgrading algorithms. So that should not be an
> underlying assumption.
> But it also means that there may be a set of keys and with each the
> signing algorithm that need to be maintained to allow the older receipts
> are to be validated.
>
> --Ray
>
>
>
>
> --
> -------
> Ray Lutz
> Citizens' Oversight Projects (COPs)
> http://www.citizensoversight.org
> 619-820-5321
>
> --
> SCITT mailing list
> SCITT@ietf.org
> https://www.ietf.org/mailman/listinfo/scitt
>

v2.23.0 | Report a Bug | By Email