I reviewed this draft. The concerns raised about the textual transmission of certificates, have not been fully addressed. But at least they have been partially addressed, so that progress is appreciated.
However since it’s my bad that I have not had the time to flesh out a response, we can let this go if the certificates are just transmitted “according to [RFC7468]”, and as text/plain. I would also advocate stronger language about the format, namely, that it is just -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----, separated only by newlines (no other text, supplemental or otherwise). I also don’t see why a client “‘SHOULD’ verify that the ‘file’ contains only encoded certificates. “MUST” would be better, and closes security holes. (MUST is also essentially stated by the sentence that follows.) If there is any “SHOULD”, the client “SHOULD” verify that the public key of the certificate matches the public key of the submission. Also it’s not a ‘file’, it’s unnamed content. Given that the payload is text (and, in particular, no supplementary text), you may want to note that it’s charset=us-ascii. However that is the default anyway. I can supply draft text if desirable. Regards, Sean > On Jun 21, 2017, at 12:00 PM, internet-dra...@ietf.org wrote: > > > 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 > of the IETF. > > Title : Automatic Certificate Management Environment (ACME) > Authors : Richard Barnes > Jacob Hoffman-Andrews > James Kasten > Filename : draft-ietf-acme-acme-07.txt > Pages : 74 > Date : 2017-06-21 > > Abstract: > Certificates in PKI using X.509 (PKIX) are used for a number of > purposes, the most significant of which is the authentication of > domain names. Thus, certificate authorities in the Web PKI are > trusted to verify that an applicant for a certificate legitimately > represents the domain name(s) in the certificate. Today, this > verification is done through a collection of ad hoc mechanisms. This > document describes a protocol that a certification authority (CA) and > an applicant can use to automate the process of verification and > certificate issuance. The protocol also provides facilities for > other certificate management functions, such as certificate > revocation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-acme-acme-07 > https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-07 > > > 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 mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
