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 <[email protected]> On Behalf Of Kevin Jacobs Sent: Wednesday, February 26, 2020 5:53 PM To: [email protected] 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
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
