[TLS] Clarification on Delegated Credential validation

Kevin Jacobs <kjacobs@mozilla.com> Wed, 26 February 2020 22:53 UTC

Return-Path: <kjacobs@mozilla.com>
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 911423A09C8 for <tls@ietfa.amsl.com>; Wed, 26 Feb 2020 14:53:00 -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, HTML_MESSAGE=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 (1024-bit key) header.d=mozilla.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 GeGJCfkL3vtP for <tls@ietfa.amsl.com>; Wed, 26 Feb 2020 14:52:58 -0800 (PST)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 BC6523A09C7 for <tls@ietf.org>; Wed, 26 Feb 2020 14:52:58 -0800 (PST)
Received: by mail-io1-xd33.google.com with SMTP id s24so1033988iog.5 for <tls@ietf.org>; Wed, 26 Feb 2020 14:52:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=kUmYbAfq2vnNXSoJ4dzoqk4TF2x7V6o+ryXoWqY+JAE=; b=f7YTOJ66cE55W84A3OqTHlhq2m2DtsyciBsep3ZhZ0GKZ8HR7Y5hbrx1x7QKH/R+wY 10/X3VTOKSpEqSerYN96CfwHnUGckjgj2AaET+wYL84OJ/GGK2GWIS98dd1DdItAR9Z3 ksRxNx7nb1v9mTCkSuOG9eT9kpS0p9TJENNsg=
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=kUmYbAfq2vnNXSoJ4dzoqk4TF2x7V6o+ryXoWqY+JAE=; b=tefva9ruRMWeKYNd6r74RTwJcGwQ7bDr05gzLS3ECP2osYf7y8nCbdukc/qzumuYRg oq+tPPL7o5bkrkWJSFDdK0RdkWp1wMnfTH6MUl3MeniKJfkagJkFteAm1wPbGCTfwi6B A1TIY5n1ahEtcoJ0SMFaxKiE1EW+8h/kenUwIZi98UR1i2wdxTx9/1gMGCEzln6AlpIL EX9H3ArTHOUK3OLpacMEUZ2seUtzrlsXGtAvQU7C8BXfwdgsJj+QRU3OXTi7M45VsdYP 9ns1RQPRCK46mCuOQC+6kuPm5QOIgmD333es2bGKL1f3sQX1VlpGElg7D/Xho7vMcHf0 HnEQ==
X-Gm-Message-State: APjAAAVdFIIRgkAI4QW+jyeK5BN9cUlwJ2T8d1tVtAOaGz+wfdXRA8+g ezEJJyu3dDc+FZ+DofikREDb5BcLpS0x83Kgz0J/DtILz2Y=
X-Google-Smtp-Source: APXvYqx8s70di2pZ57JyQNu2LMTe6f5E3z1+D2XGwF030T1QtkeZdtfMcCezLNVPec+qTw8X1qfGJgC4Juc8N99EsmE=
X-Received: by 2002:a5d:9c05:: with SMTP id 5mr963012ioe.18.1582757577690; Wed, 26 Feb 2020 14:52:57 -0800 (PST)
MIME-Version: 1.0
From: Kevin Jacobs <kjacobs@mozilla.com>
Date: Wed, 26 Feb 2020 14:52:46 -0800
Message-ID: <CAJF4Pum1Li18KchdTJTrpxeRD_bQPkrOt0nfpybCrLro7nJiDg@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002f2f03059f82774e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/vMeCnG7GDOmbjS2F0SfjmTC3LvQ>
Subject: [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: Wed, 26 Feb 2020 22:53:02 -0000

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:
      1. 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".
      2. 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