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

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 ?

Cheers
    Toerless

> 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