Hi, There is a Boulder-based full implementation (including the delegation mechanisms in draft-ietf-acme-star-delegation) available in Github:
https://github.com/mami-project/lurk (the repository is called “lurk” and not “star” because pure historical reasons) It has been used in several demos and pilots of STAR, within Telefonica and elsewhere. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D https://www.linkedin.com/in/dr2lopez/ e-mail: [email protected]<mailto:[email protected]> Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- On 24/12/2018, 21:18, "Eric Rescorla" <[email protected]<mailto:[email protected]>> wrote: Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4723 After reviewing this document, I'd like to reconsider the proposed status of this document. Based on Section 5, it doesn't appear that there are any production implementations of this document. Are there any existing or planned production implementations from live CAs or clients? If not, this seems like a better fit for Experimental. IMPORTANT S 3.4. > present and set to true, the client requests the server to allow > unauthenticated GET to the star-certificate associated with this > Order. > > If the server accepts the request, it MUST reflect the key in the > Order. it seems like some security considerations are needed here to prevent enumeration. S 4.1. > of clock-related breakage reports which account for clients that are > more than 24 hours behind - happen to be within 6-7 days. > > In order to avoid these spurious warnings about a not (yet) valid > server certificate, it is RECOMMENDED that site owners pre-date their > Web facing certificates by 5 to 7 days. The exact number depends on I don't understand how this works. The client is able to provide the notbefore date, which gives a pre-date for the first certificate, but S 2.2 just says that the re-issue is "before the previous one expires". So suppose it is currently 2018-07-15" and I ask for a certificate with "recurrent-start-date=2018-07-10" and "recurrent- certificate-validity=5", I thus get back a cert with validity "2018-07-10 -- 2018-07-20", i.e., pre-dated by 5 days. The next certificate needs to be issued on or before "2018-07-20", but the text doesn't say when it's notbefore has to be, so it could have validity "2018-07-19 -- 2018-07-25". It seems like this document needs to specify an explicit way to pre-date, but it doesn't. COMMENTS S 1. > new short-term certificate is needed - e.g., every 2-3 days. If done > this way, the process would involve frequent interactions between the > registration function of the ACME Certification Authority (CA) and > the identity provider infrastructure (e.g.: DNS, web servers), > therefore making the issuance of short-term certificates exceedingly > dependent on the reliability of both. I don't see why this is the case. Once you have authorized once, the CA can just return that no authorizations are required. S 3.1.1. > o recurrent-certificate-validity (required, integer): the maximum > validity period of each STAR certificate, an integer that denotes > a number of seconds. This is a nominal value which does not > include any extra validity time which is due to pre-dating. The > client can use this value as a hint to configure its polling > timer. This text is confusing. The client produces the order, so how is it using it as a hint. S 3.1.2. > > Issuing a cancellation for an order that is not in "valid" state has > undefined semantics. A client MUST NOT send such a request, and a > server MUST return an error response with status code 400 (Bad > Request) and type > "urn:ietf:params:acme:error:recurrentCancellationInvalid". This doesn't sound like undefined semantics. It's just illegal. ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
