Hi Diego,
> There is a Boulder-based full implementation Does Telefonica plan to maintain the copy of Boulder you forked into this repo as a stand-alone project separate from github.com/letsencrypt/boulder? On Wed, Jan 16, 2019 at 6:21 PM Diego R. Lopez <[email protected]> wrote: > 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] > > Tel: +34 913 129 041 > > Mobile: +34 682 051 091 > > ---------------------------------- > > > > On 24/12/2018, 21:18, "Eric Rescorla" <[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 >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
