Re: [TLS] comments on draft-ietf-tls-tls13-19

Kurt Roeckx <kurt@roeckx.be> Sat, 22 April 2017 21:42 UTC

Return-Path: <kurt@roeckx.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 0CC1C1243F3 for <tls@ietfa.amsl.com>; Sat, 22 Apr 2017 14:42:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 XNzDyG7TlqSZ for <tls@ietfa.amsl.com>; Sat, 22 Apr 2017 14:42:08 -0700 (PDT)
Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (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 90FC31205D3 for <tls@ietf.org>; Sat, 22 Apr 2017 14:42:08 -0700 (PDT)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 70303A8A32BD; Sat, 22 Apr 2017 21:42:06 +0000 (UTC)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 558A51FE01C8; Sat, 22 Apr 2017 23:42:06 +0200 (CEST)
Date: Sat, 22 Apr 2017 23:42:06 +0200
From: Kurt Roeckx <kurt@roeckx.be>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20170422214205.bxu5whfqzy5kshsw@roeckx.be>
References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <CABcZeBMCZrVKM959F3ycKN_WAky2NAZTy9OOetnC+KJAj3L+Pw@mail.gmail.com> <1492786351.14070.2.camel@redhat.com> <CABcZeBOe4-yEW8r15fsOtHJbQrnqGJ6oUaGYjoUwYS0MQE-rHQ@mail.gmail.com> <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bchN2mayNMPtkzNUcVSBmHe0n70>
Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 22 Apr 2017 21:42:11 -0000

On Sat, Apr 22, 2017 at 03:00:17PM +0300, Ilari Liusvaara wrote:
> On Sat, Apr 22, 2017 at 07:53:50AM -0400, Eric Rescorla wrote:
> > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos <nmav@redhat.com>
> > wrote:
> > 
> > > On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote:
> > >
> > > > Do you have any thoughts on what text we should insert here? I admit
> > > > to being not that familiar with the practical matters of OCSP
> > > > stapling.
> > >
> > > My issue with OCSP when used under TLS was how to determine the
> > > validity of the response when the nextUpdate field is missing. I've
> > > added some text for that introducing an (arbitrary) upper limit at:
> > > https://github.com/tlswg/tls13-spec/pull/974
> > 
> > 
> > This text looks good to me, but it is is a normative change and we've
> > been through WGLC so I'd like to hear from a few other people that they're
> > OK
> > with it (or have the chairs tell me that silence is consent). David
> > Benjamin?
> > Richard Barnes? Ryan Sleevi?
> 
> I searched what minimum standards for "public" CAs say. The maximum
> lifetime there is 10 days (but IIRC some widely-used root program has
> lower limit, might have been 7 days)..
> 
> Anybody happens to know a CA that doesn't put NextUpdate in? If so,
> what's the OCSP issuance frequency?

The CA Browser baseline requirements have this in 4.9.7:
For the status of Subscriber Certificates: 
  If the CA publishes a CRL, then the CA SHALL update and reissue
  CRLs at least once every seven days, and the value of the
  nextUpdate field MUST NOT be more than ten days beyond the value
  of the thisUpdate field

For the status of Subordinate CA Certificates: 
  The CA SHALL update and reissue CRLs at least (i) once every
  twelve months and (ii) within 24 hours after revoking a
  Subordinate CA Certificate, and the value of the nextUpdate field
  MUST NOT be more than twelve months beyond the value of the
  thisUpdate field.

And in 4.9.10:
For the status of Subscriber Certificates:
  The CA SHALL update in formation provided via an Online
  Certificate Status Protocol at least every four days. OCSP
  responses from this service MUST have a maximum expiration
  time of ten days. 

For the status of Subordinate CA Certificates: 
  The CA SHALL update information provided via an Online
  Certificate Status Protocol at least (i) every twelve months and
  (ii) within 24 hours after revoking a Subordinate CA Certificate. 


So for OCSP of a subordinate CAs there doesn't seem to be any
requirement for a nextUpdate.


Kurt