Re: [Acme] draft-ietf-acme-star
I don’t care about the STAR acronym not bring known by those who don’t know :)
but I think Richard’s comments – most of which are, really, wordsmithing nits
of message-field names – deserve more consideration. After all, the STAR
documents didn’t get much attention from the ACME members.
From: Richard Barnes
Date: Monday, September 9, 2019 at 6:44 PM
To: Thomas Fossati
Cc: "acme@ietf.org"
Subject: Re: [Acme] draft-ietf-acme-star
On Mon, Sep 9, 2019 at 4:15 AM Thomas Fossati
mailto:thomas.foss...@arm.com>> wrote:
Hi Richard,
Thank you for the detailed review. As you note yourself, this is quite
late in the document life-cycle (the draft completed IETF LC over a
month ago), which is unfortunate, given that every one of your comments
is an actual protocol change.
Do you have any implementations that this would break? Or is this just
avoiding spec changes?
Most of the below should be pretty easy to address, so unless there's some
massively deployed code base that's going to be broken, I would propose that
they should be addressed before publication.
Note that there are some potential deployment blockers here, most importantly
the implication that the CA should pre-date certificates.
--Richard
As far as we understand, none of them can
be seen as a "showstopper" mistake in the protocol, and therefore we
propose to move forward with the current draft version. Please let us
know if we missed anything.
Cheers, Thomas (on behalf of the authors)
> On 28/08/2019 at 15:52, Richard Barnes wrote:
>
> 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.
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] draft-ietf-acme-star
On Mon, Sep 9, 2019 at 4:15 AM Thomas Fossati
wrote:
> Hi Richard,
>
> Thank you for the detailed review. As you note yourself, this is quite
> late in the document life-cycle (the draft completed IETF LC over a
> month ago), which is unfortunate, given that every one of your comments
> is an actual protocol change.
Do you have any implementations that this would break? Or is this just
avoiding spec changes?
Most of the below should be pretty easy to address, so unless there's some
massively deployed code base that's going to be broken, I would propose
that they should be addressed before publication.
Note that there are some potential deployment blockers here, most
importantly the implication that the CA should pre-date certificates.
--Richard
> As far as we understand, none of them can
> be seen as a "showstopper" mistake in the protocol, and therefore we
> propose to move forward with the current draft version. Please let us
> know if we missed anything.
>
> Cheers, Thomas (on behalf of the authors)
>
> > On 28/08/2019 at 15:52, Richard Barnes wrote:
> >
> > 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.
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] draft-ietf-acme-star
Hi Richard,
Thank you for the detailed review. As you note yourself, this is quite
late in the document life-cycle (the draft completed IETF LC over a
month ago), which is unfortunate, given that every one of your comments
is an actual protocol change. As far as we understand, none of them can
be seen as a "showstopper" mistake in the protocol, and therefore we
propose to move forward with the current draft version. Please let us
know if we missed anything.
Cheers, Thomas (on behalf of the authors)
> On 28/08/2019 at 15:52, Richard Barnes wrote:
>
> 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.
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
