[Acme] New STAR draft
This came up during IESG/IETF last calls. Most of the changes are editorial, such as changing some of the field names in the JSON structures etc (e.g., recurrent to auto-renewal). But a couple are operational and CA/B forum compliance. Quoting the summary of changes: o STAR Order and Directory Meta attributes renamed slightly and grouped under two brand new "auto-renewal" objects; o IANA registration updated accordingly (note that two new registries have been added as a consequence); o Unbounded pre-dating of certificates removed so that STAR certs are never issued with their notBefore in the past; o Changed "recurrent" to "autoRenewal" in error codes; o Changed "recurrent" to "auto-renewal" in reference to Orders; o Added operational considerations for HTTP caches. If anyone in the working group dislikes these changes, please speak up by Monday. Thanks. /r$, co-chair On 9/17/19, 11:02 AM, "internet-dra...@ietf.org" wrote: A new version (-09) has been submitted for draft-ietf-acme-star: https://www.ietf.org/internet-drafts/draft-ietf-acme-star-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-star/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-09 Please note that it may take a couple of minutes from the time of submission until the diff is available at tools.ietf.org. IETF Secretariat. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] I-D Action: draft-ietf-acme-star-09.txt
On 17/09/2019, 16:02, "Acme on behalf of internet-dra...@ietf.org" wrote: > 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-09 > https://datatracker.ietf.org/doc/html/draft-ietf-acme-star-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-09 > > > 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/ This revision addresses Richard's review. A summary of the changes (cut & paste from the changelog) is as follows: o STAR Order and Directory Meta attributes renamed slightly and grouped under two brand new "auto-renewal" objects; o IANA registration updated accordingly (note that two new registries have been added as a consequence); o Unbounded pre-dating of certificates removed so that STAR certs are never issued with their notBefore in the past; o Changed "recurrent" to "autoRenewal" in error codes; o Changed "recurrent" to "auto-renewal" in reference to Orders; o Added operational considerations for HTTP caches. Cheers! 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
[Acme] I-D Action: draft-ietf-acme-star-09.txt
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-09.txt Pages : 27 Date: 2019-09-17 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-acme-star-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-09 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] Artart last call review of draft-ietf-acme-tls-alpn-06
Reviewer: Martin Thomson Review result: Ready with Nits This is a clear description of a simple protocol that addresses a well-defined problem. I didn't find any real issues, though I have some suggestions that might improve the document a little. My view is that publication without these would still produce a useful RFC. Suggestions: The document should probably talk about minimum TLS versions and expected algorithms. I think that it would be enough to say TLS 1.2 minimum with the mandatory cipher suites from that spec. You might also want to require certificates with a PKCS#1v1.5 RSASSA key (as much as those are terrible), but to permit use and negotiation of other alternatives. If your CA supports ECDSA, I see no reason not to prepare an ECDSA certificate on that basis, but that would be based on extra-textual knowledge, it's no guarantee of interoperability. Section 4 I have two suggestions here for making the properties you rely on with the protocol clearer to readers. You should explicitly say that the "acme-tls/1" protocol as negotiated here does not carry application data, it only requires that the server provide certificate-based authentication. AND that the certificate-based authentication provided uses an alternative method than that described in RFC 5280, even though it uses X.509 certificates. Both of these are already implicit in the text here, but I think that it would help to be very clear about these as they are a little surprising ways to use TLS. You might also want to explicitly point out that though the protocol does not depend on the server providing a valid signature, or even that it successfully complete the TLS handshake, these are both required by the protocol and a validator MAY withhold authorization if the TLS handshake does not complete successfully. (This is implied in Step 4, but not explained.) Nits: Section 1 The history lesson in the appendix is useful. It helps to articulate why the design is this way. However, I don't think that you need to spend a third of the introduction on a reference to that historical information. I'd cut that paragraph entirely. Section 3 https://www.quickanddirtytips.com/sites/default/files/styles/insert_large/public/images/937/use-utilize-pin.png?itok=Bt7A6RQq Step 3: s/AMCE/ACME; this sentence is two with a comma-splice Section 4 This is taste only, but I find the extra version decoration on these identifiers unnecessary. Decorate v2 if you are unfortunate enough to need one. Section 5 The parallel list construction in this sentence is a little awkward: "This means that if User A registers Host A and User B registers Host B the server should not allow a TLS request using a SNI value for Host A to be served by User B or Host B to be served by User A." The first part of this sentence is fine, but the second part "or Host B to be served by User A" might be clearer if it said "or a TLS connection with a server_name extension identifying Host B to be answered by User A." Or similar. Section 6.2 Please don't use uppercase for an identifier when the actual protocol is identified using lowercase ASCII. I know that RFC 7301 did this for HTTP/1.1, but that was a confusing mistake that doesn't need to be propagated. Section 7 This is not an appendix. You can make appendices using `` in XML or by moving the section under `---back` in kramdown-rfc2629. The implication of this text is to say that this is a replacement for an important part of ACME. I would instead say that this is an iteration on an earlier design that used the TLS server_name extension to carry the challenge. And that that earlier design was shown to have some serious issues in practice. My understanding of the problem differs from what is described here though: the problem - as I recall - was that this used high-entropy, generated values for the server_name extension and an HTTP or absent ALPN identifier. These names might not have as strong a binding to the user that controlled the validated portion of that name (the suffix) as desired. Some servers would route these SNI values to a "default" handler. The "default" handler could be under the control of any user; in fact, users could in some cases choose a name that would greatly improve their chances of having their certificate used as a default (e.g., a.example.host or z.example.host. As formulated here, particularly with the User A/Host B phrasing, you are almost implying that the security property you rely on in the ALPN design doesn't hold. As far as I'm aware, that security property does hold because you are including exactly the validated name in the SNI. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
