Re: [Acme] Certificate chains including roots

[Martin Thomson]

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 final certificate in the chain if it is needed.
>>  This minimises the chance of clients for non-DANE applications
>>  messing up and provides a viable method for discovery of the root
>>  CA for applications which need it.
> This seems fine to me.

MUST NOT is too strong.  Advise against it in the same way that TLS
does.  Even point to TLS.

Adding a note that when intended for a particular use (such as for
securing HTTPS), the chain that is provided should be directly usable
in that context and might need some assumptions about what relying
parties in that context need.

Don't require AIA or even use it.  It's a mess and not widely
deployed.  It's mostly just a waste of bytes - it's not like you can
remove it from a certificate once added (sure, if your intermediate
has it, then that's fine, but I'd content that this is a mistake).
You could use an "up" link relation (or whatever we decided works for
that) on the response if you feel that providing a link to the root is
necessary.

> To push a little more on why it's required, though: In DANE, you might
> indicate a trust anchor in your records. Presumably that trust anchor
> could be either a self-signed root, or an intermediate issuer
> certificate, right?

DANE adds a whole new dimension to this problem.  I think that if the
expectation is that DANE is used, then the server will need to be told
about this so that it can adjust as needed.  Often that means a
shorter chain.  However, I think that this sort of optimization is an
extension and doesn't really belong in the core spec (i.e., ship the
damned thing already and stop messing with it).

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Certificate chains including roots

[Jacob Hoffman-Andrews]

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 of clients for non-DANE applications
>  messing up and provides a viable method for discovery of the root
>  CA for applications which need it.
This seems fine to me.

To push a little more on why it's required, though: In DANE, you might
indicate a trust anchor in your records. Presumably that trust anchor
could be either a self-signed root, or an intermediate issuer
certificate, right?

The reason to prefer putting a root in DNS rather than an issuer is
generally that the root won't change as often, right? But if you're
automating DANE updates based on the returned certificate chain, why not
just use the issuer, and update the trust anchor record every time a new
certificate is issued?

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Certificate chains including roots

[Richard Barnes]

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 
wrote:

> The usage model I think we should aim for is where chains are used
> as-is.  For instance, the chain is fed straight to the HTTPS server.
> There is reasonably strong advice against sending trust anchor
> certificates over the wire, and most software simply spools out
> everything it is given.
>
> I thought that we already had this discussion and concluded that roots
> wouldn't be included.  That's consistent with the above.
>
> Obviously that would leave this open to some discretion, but that's
> OK.  For instance, during the period that a new CA has a
> cross-signature on their root, they might include their own anchor for
> maximum compatibility, but they might phase that out over time.  But
> the CA is in a reasonable position to know when to move, and it isn't
> as though this would prevent clients from adding or removing as they
> see fit.
>
> On Mon, Mar 12, 2018 at 3:14 PM, Jörn Heissler
>  wrote:
> > On Mon, Mar 12, 2018 at 16:01:24 +0100, Philipp Junghannß wrote:
> >> But isn't the point of this proposal that the client CANNOT be expected
> >> knowing the root like with DANE/TLSA'd servers with a custom root or
> >> whatever?
> >
> > 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?
> >
> > ___
> > Acme mailing list
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme
> >
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Certificate chains including roots

[Jörn Heissler]

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 the chain served by the ACME server?

It's certainly far-fetched: Assume you've currently got a valid
certificate installed. It will expire in 3 Weeks, so you're going to
renew it. The CDN in front of the ACME server, or your
enterprise MitM appliance, could send you a broken certificate. If you
blindly install it, your website will be down immediately. If you verify
the cert+chain and thus notice the problem, you've got three Weeks to address
the problem.
So it mitigates a possible DoS by a malicious party or simply some
malfunction somewhere.


signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Zhang, Ning]

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.

Additionally, Section 9.7.1 specifies an optional “externalAccountBinding” 
field. Should this field be included in Section 7.1.2?

Also, Section 9.7.1 specifies the “orders” field as an “array of string”. 
Should be just a “string” as specified in Section 7.1.2?

Thanks,
-Ning
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Certificate chains including roots

[Hugo Landau]

> 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. This
trust anchor isn't necessarily one already known to the client
connecting to a TLS server, since the whole idea is that DANE/DNSSEC is
the real trust anchor and whatever CA is used for the TLS server
certificate is trusted by virtue of being referenced by hash.

Because of this, where DANE is used, the trust anchor must be served by
the TLS server in the certificate chain. This is a waste of bandwidth
but otherwise harmless where DANE is not used, but is critical when
supporting DANE.

An ACME setup shouldn't be expected to know the root certificate because
it may change over time. For example, currently Let's Encrypt serves
certificates using the IdenTrust cross-signed intermediates. It could at
some point switch to using its own ISRG root, once it has sufficient
prevalence in trust stores; if an ACME setup makes assumptions about
what root an ACME server issues using, breakage would result when this
happens. Moreover root certificates do have an eventual expiry date and
need to be swapped out. (Or acquired CAs could desire to switch to a new
root without breaking servers, or so on, and so forth.)



signature.asc
Description: OpenPGP digital signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme