IETF Logo Mail Archive

Re: [TLS] Clarification on Delegated Credential validation

Mike Bishop <mbishop@evequefou.be> Thu, 27 February 2020 20:32 UTC

Return-Path: <mbishop@evequefou.be>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336F23A0B8C for <tls@ietfa.amsl.com>; Thu, 27 Feb 2020 12:32:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.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 Gah5-l6-TCla for <tls@ietfa.amsl.com>; Thu, 27 Feb 2020 12:32:26 -0800 (PST)
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2091.outbound.protection.outlook.com [40.107.236.91]) (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 E9C833A0B91 for <tls@ietf.org>; Thu, 27 Feb 2020 12:32:25 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UUXanKSQxCjPcOPERrbJmF/mI0y7n3Lz5BEFu+pRzHvMHEvo1z8i9AVcF1XmwMLjNIhKZI5Kb5pCmzPtbWR30wRL4KJRAx9QCT+oeFjIxZGENQSUVLX6Xreo96Wqjn7RaBPn4TB7EjDEh4q0Vx8Pu8M7NRokbw3njJBvfwgvzONCXo71u1Z4bTb8M362cdhV9HTl2zLkqOV2ZOncs5oGJiqGvEfc+EMtzfdddzDVs1fQOQmKWexmxx3MYqNMGdBR8UYEZ5IzsusXUZl60HSLECy7ADeSq6uVQIWzGmrOYPB3kgL9mcjtef+SND59xJIbVG+neCcHwpRRLFpWikQUvw==
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=/UwUHA+OdW7K55ivLcLjwfV8uYloZqV1O+2Hk/osd2I=; b=g3FW84emafyFbdDCUZVD6TcsdrU1UbYnrgX/lx9IhsfP7PM/rhRrHuwUFu0t21g5VfjYqO00Jzv25/9zkshd79YSdFHLQ8qCchfhtl+2EppfDi6y4drlOi4lJeqv7x1NqkaeY9xUSjN6nu6bo1Imr96z/68PgM6pe3Lewkg96y/TGFEnuv7pyXHPBY7OZAiV+1+nU3dQYROl+SbgCJzvvj+v0rLbJoMxDqMZpjVcRTnMgcdRnAQLA31fHqGYYnAq7wiYJ8ZyWbU0RthzUsoh6cY+WVYKrwu63ttiTWMUAvNFcsJGF1b64BqKFyLquXwp02YR7LGSviZk5MX29x1ehQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=evequefou.be; dmarc=pass action=none header.from=evequefou.be; dkim=pass header.d=evequefou.be; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector2-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/UwUHA+OdW7K55ivLcLjwfV8uYloZqV1O+2Hk/osd2I=; b=bquWN+H3fxpqcPEV6w/l4xrUyq6qXlaocj2IhPcmmumb832qZ82c6P0SSukOKgHRpDwcgi5Ad2M2sjLv8yGsHgXLpvP2/YPqFpWZO8JsPQc98mcsnnAUNIfDGjowjnvl4X97/4TR1ZJ80zX0leWnn4sLO+PgCoGe9OuJ9aHYOwE=
Received: from CH2PR22MB2086.namprd22.prod.outlook.com (2603:10b6:610:8c::8) by CH2PR22MB2088.namprd22.prod.outlook.com (2603:10b6:610:89::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Thu, 27 Feb 2020 20:32:23 +0000
Received: from CH2PR22MB2086.namprd22.prod.outlook.com ([fe80::fc4c:de9:3fcd:96dd]) by CH2PR22MB2086.namprd22.prod.outlook.com ([fe80::fc4c:de9:3fcd:96dd%7]) with mapi id 15.20.2772.012; Thu, 27 Feb 2020 20:32:23 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: Kevin Jacobs <kjacobs@mozilla.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Clarification on Delegated Credential validation
Thread-Index: AQHV7PeSlJIrLeOhrU6EdQPKiXodsKgvf6WQ
Date: Thu, 27 Feb 2020 20:32:23 +0000
Message-ID: <CH2PR22MB2086C8D1BE1EB75A3868BDCDDAEB0@CH2PR22MB2086.namprd22.prod.outlook.com>
References: <CAJF4Pum1Li18KchdTJTrpxeRD_bQPkrOt0nfpybCrLro7nJiDg@mail.gmail.com>
In-Reply-To: <CAJF4Pum1Li18KchdTJTrpxeRD_bQPkrOt0nfpybCrLro7nJiDg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be;
x-originating-ip: [2600:2b00:9317:a001:c168:aed1:949b:628]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7fa57143-e698-45a0-c939-08d7bbc426ee
x-ms-traffictypediagnostic: CH2PR22MB2088:
x-microsoft-antispam-prvs: <CH2PR22MB2088CC139A74035628D068CEDAEB0@CH2PR22MB2088.namprd22.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03264AEA72
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(346002)(366004)(39830400003)(396003)(199004)(189003)(5660300002)(2906002)(66946007)(186003)(64756008)(66446008)(52536014)(66476007)(71200400001)(508600001)(66556008)(76116006)(316002)(6506007)(81156014)(8676002)(81166006)(8936002)(110136005)(86362001)(55016002)(7696005)(33656002)(53546011)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR22MB2088; H:CH2PR22MB2086.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Xk7xVYCBV80ip5q+yRXdHQO1mO3NLSnK4+M+Y4mXPWGRicENyMbiNNvTR+uUCQt2QLoy3sJQHqsN3kEDqsbrTpnFOJ/CsEg9Yk66WYvi+1sVGzL+putXdAvpExuT74aITGsgAaxKVK21v9HguWKPJfHOvqdbFzPUqu6pLjTxs2qq3Yf0d1d/DjWj6NCPZMvVjldzXIWlNEyMgTvJIfsGJpFFjqXHXxQFsEW8oWHEpona45MrqO2kLs8xqVBVQuS6jDry1E0vfb6TlaIOWO4U3XnMusF//g9cePIDvbZzL38Jh9agxaUId1geaebg4lT58j0EcMKrDtq8nZ0OD+U7+sReID4v/RBnzRmGFIenHu8ylIjeF7WnpVf/sHHTfyusopEfUbnbR/AH6JY33CF51c47zbkyYQkSFp97VXHGHZOORGzmoRpvJlsEtYraz1Jj
x-ms-exchange-antispam-messagedata: Vh4QCapK9IBSD1xVreULugkMkQpLTSwS3JVkHeKpHz3AjqTD4C6LLBpNLpNrpR1W5KOSljRElDGi2W/JvPNjbfi3EB0xTZF/UnRp147w8WsV+fM/+yVA0FByBKeYpSat1aXLfg7Y7Yki0BZnZPS8Pin6ACe3lQ1+9ByGZjgzo8aDYNeleMpdaaK+28jHy3gGMOw3G+YElhE2m/D0w028Ng==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR22MB2086C8D1BE1EB75A3868BDCDDAEB0CH2PR22MB2086namp_"
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 7fa57143-e698-45a0-c939-08d7bbc426ee
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2020 20:32:23.5440 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8emgiODAE8eLD5cYFC0/peA2oj9oaNK5Pel4BUjGO8wkTp9cUooAui4WVpMXjbgOizUpjgOAFzZ8FnKNuwQIEA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR22MB2088
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4UodjLH-eRVmqQaqzkmNjxsi5iQ>
Subject: Re: [TLS] Clarification on Delegated Credential validation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2020 20:32:35 -0000

I would have assumed the second interpretation as the intent, but you’re correct that value doesn’t exist.  Perhaps we should say that the credential’s “remaining” time to live is no more than the maximum validity period?  And fix the assertion, of course.

From: TLS <tls-bounces@ietf.org> On Behalf Of Kevin Jacobs
Sent: Wednesday, February 26, 2020 5:53 PM
To: tls@ietf.org
Subject: [TLS] Clarification on Delegated Credential validation


TLSWG,

There seems to be some ambiguity in draft-ietf-tls-subcerts. [4.1.3 Validating a Delegated Credential] states: "1. Verify that the current time is within the validity interval of the credential and that the credential's time to live is no more than the maximum validity period. This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time."

There are two issues with this:

  1.  The described assertion only ensures that the first condition is met.
  2.  The second condition - "and that the credential's time to live is no more than the maximum validity period" - is unclear:

     *   If we assume "time to live" on a DC to be the remaining time (based on the verifying peer's clock), the described check should also assert "EECert.notBefore + DC.valid_time - currentTime <= maximum validity period".
     *   If we assume "time to live" on a DC to be the initial TTL (spanning issuance to expiration), we lack the information needed to effectively verify this, as DC.valid_time is based on EECert.notBefore rather than DC.notBefore (which does not exist). For example, if 7-day DCs are issued, "EECert.notBefore + DC.valid_time" will be a 7-day span on the first issuance, a 14-day span on the second, etc. until the EE cert is reissued.

I believe the first interpretation is intended, but the client is then unable to verify that the DC lifespan is actually less than the maximum validity period (should such a check be desired), only that the DC will expire within that period. Either way, the expected behavior should be clarified.

Thanks,
Kevin

v2.23.0 | Report a Bug | By Email