On 7/20/16, 5:51 AM, "Acme on behalf of Yaron Sheffer" <[email protected] on behalf of [email protected]> 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 >[email protected] >https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
