Re: [Acme] AD Review: draft-ietf-acme-star-04

[Daniel McCarney <[e-mail]>]

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 <[e-mail]>
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: [e-mail]
>
> Tel:         [phone]
>
> Mobile:  [phone]
>
> ----------------------------------
>
>
>
> On 24/12/2018, 21:18, "Eric Rescorla" <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>