Re: [Acme] Certificate chains including roots

On Wed, Mar 14, 2018 at 9:23 PM, Jacob Hoffman-Andrews wrote: > On 03/12/2018 05:25 AM, Hugo Landau wrote: >> 3. Clarify the specification to state that the root certificate must >> not appear in the chain, and that roots must be retrieved using the >> AIA URL inside the

Re: [Acme] Certificate chains including roots

On 03/12/2018 05:25 AM, Hugo Landau wrote: > 3. Clarify the specification to state that the root certificate must > not appear in the chain, and that roots must be retrieved using the > AIA URL inside the final certificate in the chain if it is needed. > This minimises the chance

Re: [Acme] Certificate chains including roots

This matches my understanding. ACME cannot be prescriptive on this, not least because the notion of a "root certificate" is not well defined for the server -- the server doesn't know what the client does or does not trust. On Mon, Mar 12, 2018 at 11:26 AM, Martin Thomson

Re: [Acme] Certificate chains including roots

On Wed, Mar 14, 2018 at 17:57:43 +, Hugo Landau wrote: > > Rationale is that the client shouldn't blindly trust that the chain > > received by the acme server is valid. > See my other reply. But to respond to this specifically, can you explain > what threat model is mitigated > by distrusting

[Acme] Questions about Account Objects in draft-ietf-acme-acme-10

I have a few questions related to Account Objects. Section 7.1.2 indicates that the “orders” field is a required field. However, the response example in Section 7.3 does not have the “orders” field. I am wondering if the “orders” field would be optional for “newAccount” response.

Re: [Acme] Certificate chains including roots

> I must admit that I'm not very familiar with DANE. > > What would be a typical use case where you use ACME but you don't > already know the root cert? Where DANE is used, a trust anchor is referenced by a hash of its public key or certificate, which is placed in a DNSSEC-secured DNS record.