Re: [Trans] v2 SCTs and v1 SCTs distinguishability

Rob Stradling <rob@sectigo.com> Mon, 16 August 2021 11:42 UTC

Return-Path: <rob@sectigo.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3D33A0920 for <trans@ietfa.amsl.com>; Mon, 16 Aug 2021 04:42:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sectigo.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 FBU6eXr6QezL for <trans@ietfa.amsl.com>; Mon, 16 Aug 2021 04:41:58 -0700 (PDT)
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2057.outbound.protection.outlook.com [40.107.92.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08CC3A0907 for <trans@ietf.org>; Mon, 16 Aug 2021 04:41:57 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DpYj9HvTuP4zdrn4zm4L3LkdE80D7DCzPyW8DSr7REjIKvi3/ekWchPuMwLortrBVq0tX4Vs9dQizUeHF+bJaenSd/h2e0cL+gQlrZI+4eOa4srV9DXUHPh/I1kvSJ4tfEAbsRJ4Wc+HJLrJeXqWH9Z2Ku2ZipuU/qIAXNP4OCuiXjYe4pScBOXgEB/Tb93hV7CDxsFsAv0GC918yOt7kYBO/yZopBwXleSsCVyg4YQXzv8y8WpzwBRrGXywEiLpUUUjYwmSWvcFZPNvHhsdU7Rdx8dhZlyJ7A24sIaGiux5QMJlfWLJTgfAgEYPQfqiX2kiQO8BwbCSOkoRBeO1Ig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QdlcV9DHa8tYsDRlf+KZekuWdfKbJr1XeSnYrGwhMho=; b=WXADZY7loTnkUX5fL6hmVeI72lkamZCU/MVuIETrHSr8Mc65/GC0nduxl9VF0ytnIsngzL2ZzOZynkusZc2M8VB7w1skeNlDEnxnhmTriXAHOtvrXjiA030FrX/upqC8ntc1hy1VyUXi9PW28unl3sdBL6BG9vpOKfj7/A88DSHPcz9AEcEbLeiPgpsPeegXdGs4xs4b0scGNKB0zhf0KCzDY3K0ad7zk2uBgXel2DrhtwY6k2Ikl6sHMF4DpBjjIgvufGIfqYJYMuPzS+q0lxXmsSvkSwqRRwFYVU2G2+T+l9es0Yx7X8uxuMuPVsX2+SV/AfMfQmVfYyBw5yOirA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sectigo.com; dmarc=pass action=none header.from=sectigo.com; dkim=pass header.d=sectigo.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sectigo.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QdlcV9DHa8tYsDRlf+KZekuWdfKbJr1XeSnYrGwhMho=; b=g+6lNotyg+djrywXXYkcBZ17ynlX3qE2NexsgHLwoXAf3XOri7eZ8aC11XIyx4x34inhhWCmmNNIHX4bqAEs/QKtnDlxbceYtqMkMNVeFm25dVxKlfn1g+yxxPyvmah6+qjTkVSf4uFz5gmU2mZiALjoMldXumEhz72ky138lVc=
Received: from SJ0PR17MB4726.namprd17.prod.outlook.com (2603:10b6:a03:377::10) by BY5PR17MB4068.namprd17.prod.outlook.com (2603:10b6:a03:23e::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.15; Mon, 16 Aug 2021 11:41:54 +0000
Received: from SJ0PR17MB4726.namprd17.prod.outlook.com ([fe80::c407:8942:e772:a2c6]) by SJ0PR17MB4726.namprd17.prod.outlook.com ([fe80::c407:8942:e772:a2c6%8]) with mapi id 15.20.4415.023; Mon, 16 Aug 2021 11:41:54 +0000
From: Rob Stradling <rob@sectigo.com>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Ryan Sleevi <ryan-ietf@sleevi.com>
CC: "trans@ietf.org" <trans@ietf.org>, "trains@airmail.cc" <trains@airmail.cc>
Thread-Topic: [Trans] v2 SCTs and v1 SCTs distinguishability
Thread-Index: AQHXj7OzYjYxc4eSzUi+uLdQk4HLNqtwT/cAgAAJdACAABZSgIAFgqXn
Date: Mon, 16 Aug 2021 11:41:54 +0000
Message-ID: <SJ0PR17MB4726FA55F275C5BDBB5ECA6DAAFD9@SJ0PR17MB4726.namprd17.prod.outlook.com>
References: <1bb0f57710cdf3967fc23a7b8c7e859d@airmail.cc> <157A1E67-8C74-4209-B64E-17F39EEF1524@akamai.com> <CAErg=HHp5AJjSYB87Rq3WcDWj9iMu43D+hjstDpAf8hHGffwZw@mail.gmail.com> <EA9B0F62-98AA-4F01-B8BE-3FCE72A240A6@akamai.com>
In-Reply-To: <EA9B0F62-98AA-4F01-B8BE-3FCE72A240A6@akamai.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=sectigo.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 867ff39a-36e7-4748-4141-08d960aad8ce
x-ms-traffictypediagnostic: BY5PR17MB4068:
x-microsoft-antispam-prvs: <BY5PR17MB4068B2D3F6E5130E98880A4DAAFD9@BY5PR17MB4068.namprd17.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: pj80U1LCRVngQpBYWyyDWXuIAkSj3Tmf2nl68kO/4HOXPQp/YcMN1qYfuQsT9LgvFpo9BJzTkvv8S3WTlQTtHX4flRdVfQ0cubqRo8IdHsjwgDrZKlECe7Ssp2cWw5Tk0SPcZlaeq7KaTvJY1c2oWymctExKjMJiDPU8tE+ir0ij26lXpV88DA8VqQSXL+xyNOQlDPDfYHf4udVdU/AcbEZnnt0omMmUu6HXnw7ThuWzFALE0Az5eVk4qxy4/wNGLUcsS93OJ3cCkYR4jpclHrmCm1My31AYKDYd5bOtdmpFhAAABGncHYXvLCVALNqjEcW+61GcZAG4NXD4l6HODEjg+GY6Oc/4Ggqc0LWBV241kmXetMRHAdaZKSAk1T52gIEXNbu/Az2+pD2uLXF4JtnuCxQ7pNJsMjfHgyN0EI5Qv8DecfFPvhhzhW/1g1T7Y5sd3yxacb0iTvK9uFYOG2r+C622pgKYTDgyn915YMsmLnLYK3M+lBuv020bN4F6+lXpkmiAAWULA+Ex1ISGSU7oFpf9AV0vdjbhQBl/FmiTSx+Yg6hqbAyT8qEdHcRgoViM/xHim4KCRsMkJXWRO/YA1JiODrmFDyuRifJb5lYs49rGAl4DhvJF8waGtmo9jwFUV3WH97S7P+Lg1umxRDVdNsMuNU/kpfuTxcYzBuhDLrWHJn9y3R/mP7xd+0j96NoUq0vkBCI/3ZCMVsD7nKA9nZBMzm6+nmHdBjmrbQX2078Z1dMhR6XF8jGJqjC6HvxR5Ut0Gg0Nf+fTcu49i+x/qf9lcly4qKWcpEAdBuo=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR17MB4726.namprd17.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(396003)(136003)(366004)(346002)(376002)(186003)(2906002)(86362001)(122000001)(38100700002)(4326008)(66446008)(8676002)(478600001)(66556008)(966005)(64756008)(66476007)(76116006)(38070700005)(66946007)(91956017)(52536014)(71200400001)(6506007)(19627405001)(5660300002)(54906003)(9686003)(33656002)(7696005)(316002)(8936002)(55016002)(110136005)(53546011)(83380400001)(166002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?QiBowschZESsRSZK8nCA1az1ygsDrxTSEv1Tt5E9VAcoYCG8bcIYakkL?= =?Windows-1252?Q?fEfCj7jW4MbqqPty0fTASsOVlFErdjXXgh1eXY4bPi8NcDrKg12gDbya?= =?Windows-1252?Q?QM6ZBlXvKtQsLmYAPM1rIbg7FrDxybUJyiXOJvV8jc97y2AQqkfhLcBo?= =?Windows-1252?Q?DaWjFYGE3RlbvDaLV2RclSfB+Gy7MpXUSMpyQqQ8cDTBsm6mkSeonJXc?= =?Windows-1252?Q?N1KEcaT/lruY0FsvHkR8ezQ2k2We6qpgTnuXEghf6hY/g5dpUDuh35w3?= =?Windows-1252?Q?kdF0CbGHVBBFSTaUY12L144eFeMYIrkr1EuhWJ/C2L/k8rO7gyDy4LTW?= =?Windows-1252?Q?oY/K0tNI65g5gX+DsF2PjuDARos5EzpwS5FAXuBlKyppYxGDOg4NsAWK?= =?Windows-1252?Q?7a+FYcC1kxi/nYLW6nvXT5SO8rRy0q3eaW82Lkz+jRv8IYuNsp0Dm0II?= =?Windows-1252?Q?6uxFOEiCspFvqw6GwulgWp8VeKLE3XeYs9RiSdWNBNmX+uOUjRxtPEl1?= =?Windows-1252?Q?398/DHSj0/GK9sbJKLcKZnn78OmZl5uNouuVcBm/XW+Ca9mAF6QZ1BdI?= =?Windows-1252?Q?oT+9Q6E/1rlZa2S/k793gci7R7VxB/RmEEnXz1Q3eOwOpXS5/2bDVbOf?= =?Windows-1252?Q?zzD2QzDm+RY3SJaJ+KypnZYS1NRmvLHrqTu97K4xrF1WSvUfHp7DtiVw?= =?Windows-1252?Q?3V1YxTJYQfs2eUDaTdt82E7ZKGpAJRPL5UypWSMFhDqYIzN1wdRUSUKa?= =?Windows-1252?Q?Ef4Rw2QT8i/F8bHWUz7syzp6LwVZUUf4+AbJRnQv30U62rhric2MRcYr?= =?Windows-1252?Q?9bTFsS0ltNu7JgvlKoXIpPJhFCCb14QT9wJOA5B5URx4fE9AmcQ9D81T?= =?Windows-1252?Q?luHFUdbH8QvQVja9lbbZvyepA49ONWvYdsbw+c56awhY3dZZqv5osxBD?= =?Windows-1252?Q?d9znm9c/LJEgrjMisriNe8hS4HlDO5LRAeEfCOqZNSIh5pmiKQv3zKX7?= =?Windows-1252?Q?PJXa6q0n12dxeI1u+JI4c6ueU3WEcQW/huX1oqnQeFYr5nPhTIOS/fHp?= =?Windows-1252?Q?Be6Db/uIW2DKrdot0SMyCtKL+hhMmGn5SEE1O9MX+8y81HSSmia+tbGy?= =?Windows-1252?Q?ZOwA/GdEruxbXscrducMvKm7wbLY5QDG16skkLlQP6MVSHTa1GpcNIQP?= =?Windows-1252?Q?NzjKaw7RmxTZx92rD1hPsQ3TFlN6lfvQdW43L6EnxguyvDouqXdlQeBp?= =?Windows-1252?Q?K86ci1mzIIK0ibN93upuELlwcTLJR4TZPk3O9HSIkmP/32jqztVf7sYG?= =?Windows-1252?Q?SJZVmBxHari9QFzV/YluzYDYXGN+cEEBZiaxmqFoUljQZAXfqJAbe1jQ?= =?Windows-1252?Q?/2S9hpnLK7z2bSfnPQ/6teuza9t15/wCFz8jEKCYJmJBA8143FFr3uMP?= =?Windows-1252?Q?M2Xav+uPavgCEfQ8NrSBWifYAb99akeceMJpLR2nT3OUwi7Kmc4vSUJj?= =?Windows-1252?Q?GzAWWuc+?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_SJ0PR17MB4726FA55F275C5BDBB5ECA6DAAFD9SJ0PR17MB4726namp_"
MIME-Version: 1.0
X-OriginatorOrg: sectigo.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR17MB4726.namprd17.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 867ff39a-36e7-4748-4141-08d960aad8ce
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2021 11:41:54.6702 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0e9c4894-6caa-465d-9660-4b6968b49fb7
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: nYk1EQCNSyhQkqO6+AsP25JzUXHmbXsVkYrq6XCapaFX4OyXmC0JQ4q/zUTAF7e/uAI6W1JRbOGBBNZZhELwCg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR17MB4068
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/r2Cr6aYZV9rsbwL8p4Q9SrW56Bc>
Subject: Re: [Trans] v2 SCTs and v1 SCTs distinguishability
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Aug 2021 11:42:07 -0000

>From memory our (the authors) concern was that a log client that supports both CTv1 and CTv2 might create a "bag of SCTs" or even a "bag of TransItems", obtained from various sources, but not retain metadata about which source supplied which one.  It therefore seemed intuitive that each SCT and each TransItem should self-describe its type and version without any ambiguity, which meant that we needed to ensure that CTv2 TransItems cannot have a 0x00 byte in the position where a CTv1 SCT parser looks for the SCT Version byte.

However, this current thread correctly points out that we screwed up.  The error is obvious in the Description of https://trac.ietf.org/trac/trans/ticket/157, so...err...sorry about that.

Perhaps (as Ryan pondered) this version ambiguity might never become a problem in practice, but I know that my foresight doesn't stretch far enough into the future to be confident of that.  In any case, we need to fix the document somehow, because it shouldn't claim to deliver, but fail to deliver, SCT version un-ambiguity.

I think we should go with the proposal from trains@airmail.cc to "reserve the range 0x0000 to 0x00FF, not just 0x0000" and renumber the initial entries in the VersionedTransType registry accordingly.  We haven't yet gone through AUTH48, so I'm hoping there's still time to get consensus from the Chairs, A-D, IANA, and the RFC Editor to approve this change.

I've proposed a PR: https://github.com/google/certificate-transparency-rfcs/pull/346

Given the (presumed) lack of any 6962-bis implementations thus far, I'm hoping that this PR wouldn't negatively affect anyone.

________________________________
From: Trans <trans-bounces@ietf.org> on behalf of Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org>
Sent: 12 August 2021 23:15
To: Ryan Sleevi <ryan-ietf@sleevi.com>
Cc: trans@ietf.org <trans@ietf.org>rg>; trains@airmail.cc <trains@airmail.cc>
Subject: Re: [Trans] v2 SCTs and v1 SCTs distinguishability


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


No, I misread the concern so the PEBKAC is on me.



>That said, I'm struggling to think that this actually matters, due to the fact that the TransItem is no longer presented the same as the SignedCertificateTimestamp - that is, as discussed in https://www.ietf.org/archive/id/draft-ietf-trans-rfc6962-bis-41.html#name-presenting-scts-inclusions-<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-trans-rfc6962-bis-41.html*name-presenting-scts-inclusions-__%3BIw!!GjvTz_vk!FdBQc1XlZqkUsWHiXq4_ISAgESX6182gBKlZddj8AIyx11QBuw1PKfBCSGZB%24&data=04%7C01%7Crob%40sectigo.com%7Cc7927d04f06640db279e08d95ddec97b%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637644033733001818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=n%2BAT09XdWHlfARfhmr6Sjqoy7pRHTFKiglZm4YM88Cc%3D&reserved=0> , these are conveyed through separate TLS extension (transparency_info), as well as new X.509 and OCSP extensions ( https://www.ietf.org/archive/id/draft-ietf-trans-rfc6962-bis-41.html#name-transparency-information-x5<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-trans-rfc6962-bis-41.html*name-transparency-information-x5__%3BIw!!GjvTz_vk!FdBQc1XlZqkUsWHiXq4_ISAgESX6182gBKlZddj8AIyx11QBuw1PKZ9wEdMH%24&data=04%7C01%7Crob%40sectigo.com%7Cc7927d04f06640db279e08d95ddec97b%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637644033733011774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AV%2Bm97TXvAOZryyiL0b2d5DWr294B9lJvm3ZV3fBpRE%3D&reserved=0> ), so this overlap in "how to interpret first byte" is no longer relevant.



That makes sense to me.  Perhaps the original poster is fetching SCT’s some other way and there’s no context to distinguish them?