[lamps] discuss: empty OSCP (as: Re: Call for adoption of draft-nir-saag-star)

Toerless Eckert <tte@cs.fau.de> Mon, 30 July 2018 00:19 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D4A3A130DEA for <spasm@ietfa.amsl.com>; Sun, 29 Jul 2018 17:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.949
X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DG4gj7oxEZ8o for <spasm@ietfa.amsl.com>; Sun, 29 Jul 2018 17:19:36 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A405B130E19 for <spasm@ietf.org>; Sun, 29 Jul 2018 17:19:36 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de []) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7801258C4C2; Mon, 30 Jul 2018 02:19:32 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5F4F74402CB; Mon, 30 Jul 2018 02:19:32 +0200 (CEST)
Date: Mon, 30 Jul 2018 02:19:32 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Russ Housley <housley@vigilsec.com>
Cc: Tim Hollebeek <tim.hollebeek@digicert.com>, SPASM <spasm@ietf.org>
Message-ID: <20180730001932.hrz5ehijcbvcjccr@faui48f.informatik.uni-erlangen.de>
References: <BN6PR14MB1106140408FFB08553DEAE98835F0@BN6PR14MB1106.namprd14.prod.outlook.com> <B44AAFBA-A7C1-4565-8307-D3B493A964B8@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <B44AAFBA-A7C1-4565-8307-D3B493A964B8@vigilsec.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/heg2esZPXrECbsm5IFy1vEoTFzE>
Subject: [lamps] discuss: empty OSCP (as: Re: Call for adoption of draft-nir-saag-star)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jul 2018 00:19:39 -0000

On Fri, Jul 27, 2018 at 01:48:50PM -0400, Russ Housley wrote:
> A WG call for adoption is underway.  This document is about Short-Term
> Auto-Renewed (STAR) certificates.  There is no revocation information
> for these certificates, and the short validity period of makes this
> acceptable.  The automatic issuance of replacement certificates
> overcomes the operational challenges of short-term certificates.
> Two use cases are driving this work: IPsec VPNs and software-defined
> storage.  These certificate might not be suitable for the Web PKI.
> Many people in the room felt that an extension for that tells the
> relying party that no revocation information is available is needed.
> The authors feel that such an extension should be defined in another
> document; this document should remain a BCP.

Separating normative from informational text is always a WGs style
option. Guidance from the WG chairs would be useful.

Personally (not speaking for the co-authors), i am a fan
of indicating in a certificate how/where to renew it. After all,
certificates allow to include CRL, which helps a lot for discovery,
so why not have the same for renewal URL. And figuring out how
to indicate that the semantic is STAR. For example, you may have
a STAR certificate, sign an offline data item, and when it arrives,
the STAR certificate has expired - but the recipient may still go
to the renewal URL and query if there is a current certificate 
(for the same identity) and leverage that as additional information
if the originator is "still" to be trusted.

> Some people felt that these certificates should point to an empty CRL
> and a similar OCSP responder so that anyone looking for revocation
> information would not get a failure.

I don't quite remember who raised this point and expicitly for
what reason, the minutes don't say. Maybe whoever raised the point
could chime in.

If you already have useable CRL/OCSP, this option seems like a useful
simplification, but it does not address the most lightweight instance
of STAR where you do NOT want to set up (unnecessarily) any CRL/OCSP
infra. Maybe whoever raised the issue would be fine if the solution
space would be framed this way ?


> Some people felt that the WG should not adopt this document until
> it addresses thes two topics.
> """
> My conclusion from this discussion is that an update to the Internet-Draft is needed for the LAMPS WG to consider adoption.  Please speak now id you come to a different conclusion.
> Russ
> > On Jul 14, 2018, at 12:01 PM, Tim Hollebeek <tim.hollebeek@digicert.com> wrote:
> > 
> >  
> > The recently approved LAMPS WG Charter adds this work item:
> >  
> > 3. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority.
> >  
> > Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information.  As a result, revoking short-lived certificates is unnecessary and pointless.
> >  
> > It has been suggested that the WG adopt draft-nir-saag-star as the starting point for this work.  Please voice your support or concerns on the list.
> > 

> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm