Re: [TLS] draft-rescorla-tls-subcerts

Kyle Rose <krose@krose.org> Fri, 08 July 2016 00:08 UTC

Return-Path: <krose@krose.org>
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 535FF12D8E6 for <tls@ietfa.amsl.com>; Thu, 7 Jul 2016 17:08:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 dnewhRqNpCTC for <tls@ietfa.amsl.com>; Thu, 7 Jul 2016 17:08:13 -0700 (PDT)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 0499112D11B for <tls@ietf.org>; Thu, 7 Jul 2016 17:08:12 -0700 (PDT)
Received: by mail-qt0-x235.google.com with SMTP id w59so16830613qtd.3 for <tls@ietf.org>; Thu, 07 Jul 2016 17:08:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EKZTO93WJKuN/31Ob8Mg6gcTDrIJ40IYFPopx4KR4jE=; b=FxKCcdHujcaxEVPkB/F70HNZ2a1yLVfT8VZG+u84r3bNL9UtCcQSH5ZW/w8S3m81uU pwxbdDdAciNFEKabU8VMPOr7PqqDzSJObt8EgL0/t4LY/ou46+4DoV3EqMFwk4PtgAZY ZMFLqWwhyHEFDW+QY+qAjlWAmdb6VWjhaTkE4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EKZTO93WJKuN/31Ob8Mg6gcTDrIJ40IYFPopx4KR4jE=; b=lGaWK1DM9F+Q9djSz0z2GS7xYUE65HZWc3SI01Y/LIZNmC1/5gJP8YcYqe96LzhY7C 6mWKmn1V4Fb+MK94M6dtxXOgfHrOjBKGtBDAJfj79qdEWw4uLEFJZPA3kay0pcvwpX1i EvMyWjXtqvn4gSkT/Fkktq7L9ErWExxusUEG6sMOv2I71GySPgg/k27yBaJGLcWMT/QA m2cHXAVqH5A40+JzfVq2kM6sZm7JeIm8+Um0lFh8+/TlbEoT+rzeqCwwQ5+sxIShr1wl Qfv2SURo1oDsko6zlaCGL+lM60LaUk8U9kEOcDdubt2FLY6v0LaGnD7XMqLFWiqPhU97 2WaQ==
X-Gm-Message-State: ALyK8tId5TyjI3J5FmyzorJ0N65xj5Urk3ALUnvIC1GLLFyZVRwZA2JuSdLOjNriai2OqNxvdXnd9xw4siL+1A==
X-Received: by 10.200.57.121 with SMTP id t54mr4651419qtb.3.1467936492001; Thu, 07 Jul 2016 17:08:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.80.66 with HTTP; Thu, 7 Jul 2016 17:08:11 -0700 (PDT)
X-Originating-IP: [2001:470:1f07:121:713a:86d:a34a:1966]
In-Reply-To: <20160707221324.GA13128@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBP+6AP50L06knsnOmyMqbv3fFw6TrcSrqs0x9FgoxyKcw@mail.gmail.com> <20160707221324.GA13128@LK-Perkele-V2.elisa-laajakaista.fi>
From: Kyle Rose <krose@krose.org>
Date: Thu, 07 Jul 2016 20:08:11 -0400
Message-ID: <CAJU8_nWvqcAPiT03eLrvYGxFYf3hL4QpLw529yVS+f1hgBpycA@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary="001a1140bd2628b34f05371499f3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KTmxOpMNrbk8a6xe8bmE0WnspI4>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] draft-rescorla-tls-subcerts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 08 Jul 2016 00:08:16 -0000

On Thu, Jul 7, 2016 at 6:13 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

>
> I also checked if one could do some funky stuff with credential lifetime
> notation to limit the lifetime. Nothing came up (apart for using 16-bit
> count in decaseconds (das) only allowing presenting lifetimes up to 7
> days, 14 hours, 2 minutes and 30 seconds). :->
>

What would it be anchored to if it's not an absolute time? If you anchor
the interval to, say, the issue time of the end-entity cert you haven't
limited the resolution of the interval in any useful way: it still needs to
be able to express intervals that end at or after the expire time. I
suppose an implementor could be less likely to screw up if you also include
and sign the interval start and require two things:

(1) interval start <= now() + fuzz
(2) interval length < 7 days

Are these really much easier than

(1) interval start <= now() +- fuzz <= interval end
(2) interval end - interval start < 7 days

?

Kyle