Re: [Acme] Short term certificates - two options

[Carl Wallace <[e-mail]>]

On 7/20/16, 5:51 AM, "Acme on behalf of Yaron Sheffer"
<[e-mail] on behalf of [e-mail]> wrote:

><snip>
>
>
>Option 2: Certificate Delegation
>
>This option moves more of the responsibility to the ACME server.
>
>1. Domain owner contacts the ACME server and obtains a "delegation
>ticket" which is specific to the TLS server. The ticket is good for a
>long period, e.g. 1 year.
>
>2. TLS server regularly contacts the ACME server, proves ownership of
>the delegation ticket, and receives a short-term certificate.

Would there be an indicator in the certificate indicating it is
essentially a proxy certificate? Ideally, relying parties could confirm
the domain owner had a role in the issuance of the certificate.

>
>If something bad happens, the domain owner contacts the ACME server and
>revokes the delegation ticket.
>
>
>Comparison:
>
>1. Option 2 is clearly more complicated to specify and to implement.
>
>2. Option 2 extends the ACME protocol. Many clients can ignore it, but
>servers will need to implement it.

Option 2 could take the form of a non-critical extension. The flow could
be something along these lines:

- TLS server generates a key pair and sends request for delegation ticket
to the domain owner
- The domain owner prepares an X.509 extension containing the key (or key
identifier), any constraints (e.g., name or validity) and the domain
owner's signature covering that information
- TLS server includes the extension in the request for a certificate
(short lived or otherwise but always consistent with constraints in the
extension)
- CA issues a certificate containing the non-critical extension
- TLS clients that want to understand the delegation can verify the
extension, others would carry on without processing the non-critical
extension

If this were always a long-lived certificate, the pre-certificate
mechanism in CT could be adapted with the domain owner signing instead of
the log (or maybe using CT exactly and acting as a special case log), but
this would complicate issuance.

>
>3. Option 1 requires the domain owner to have a server available
>regularly, even if it is only a short REST interaction once every few
>days. Option 2 doesn't require any such server.
>
>4. Option 1 looks to the ACME server as a normal cert request, and
>therefore will swamp the CT logs with lots of short-term certs. With
>Option 2, we can log to CT the issuance of the delegation ticket instead
>of the actual certificates.
>
>
>I would appreciate your input!
>
>Thanks,
>
>      Yaron
>
>
>[1] https://tools.ietf.org/html/draft-sheffer-lurk-cert-delegation-00
>
>_______________________________________________
>Acme mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/acme