[Acme] I-D Action: draft-ietf-acme-star-08.txt

2019-08-28 Thread internet-drafts


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment 
WG of the IETF.

Title   : Support for Short-Term, Automatically-Renewed (STAR) 
Certificates in Automated Certificate Management Environment (ACME)
Authors : Yaron Sheffer
  Diego Lopez
  Oscar Gonzalez de Dios
  Antonio Agustin Pastor Perales
  Thomas Fossati
Filename: draft-ietf-acme-star-08.txt
Pages   : 26
Date: 2019-08-28

Abstract:
   Public-key certificates need to be revoked when they are compromised,
   that is, when the associated private key is exposed to an
   unauthorized entity.  However the revocation process is often
   unreliable.  An alternative to revocation is issuing a sequence of
   certificates, each with a short validity period, and terminating this
   sequence upon compromise.  This memo proposes an ACME extension to
   enable the issuance of short-term and automatically renewed (STAR)
   X.509 certificates.

   [RFC Editor: please remove before publication]

   While the draft is being developed, the editor's version can be found
   at https://github.com/yaronf/I-D/tree/master/STAR.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-star/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-star-08
https://datatracker.ietf.org/doc/html/draft-ietf-acme-star-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


[Acme] draft-ietf-acme-star

2019-08-28 Thread Richard Barnes
I had a chance to take a look at this draft as a result of being a
designated expert on the registries.  I approved the registrations, but
independently, I have several major concerns about the draft.  In no
particular order

- The use of the "STAR" acronym is not helpful.  This is not an acronym
that will be familiar to a reader, and less so an implementer who has not
fully read and absorbed this spec.  Instead, you should say what you mean,
e.g., for the "meta" fields:

star-enabled -> auto-renewal-allowed
star-min-cert-validity -> min-cert-validity
star-max-renewal -> max-auto-renewals

- Likewise, "recurrent" is not a common word in English.  If you want to
use a single word, "recurring" is more common, but referring to
"auto-renewal" would be even better.

- It would be even cleaner to group all these "recurrent" fields into a
sub-object, so that you wouldn't have to worry about them being present if
"recurrent" wasn't set.  In other words, just signal the "recurrent"
boolean by the presence of the object, and specify the parameters in the
object.

{
  "auto-renew": {
"start": ...,
"end": ...,
"lifetime": ...,
  }
}

- The idea of "predating" is toxic.  Pre-dating a certificate means making
the notBefore date earlier than when you actually issued it, which is a
huge problem for a real CA to do.  That's not what you mean here.  You just
want there to be some overlap between certificates.  Say that instead
("recurrent-certificate-predate" -> "overlap") and adjust Section 3.5
accordingly.

- The Not-Before and Not-After headers should be removed.  On the one hand,
it's not clear to me that it's any easier to parse these headers than it is
to parse the certificate.  On the other hand, there are existing HTTP
headers that express almost exactly the same semantics, e.g., Expires.

- It's not clear that there's any reason to negotiate certificate-GET on a
per-order basis.  Just have the CA allow it or not unilaterally and delete
the "recurrent-certificate-get" field.

- The "star-certificate" attribute is unnecessary.  Instead, you should
just say that when auto-renewal is enabled, the "certificate" attribute
points to the current certificate, and use "previous" link relations to
expose earlier certs.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme