Subject: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 29 Aug 2018 11:53:52 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-acme-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-acme/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is a great thing to have, and I intend to eventually ballot Yes, but I
do have some questions that may require further discussion before this
document is approved.

It looks like the server returns an unauthenticated "badSignatureAlgorithm"
error when the client sends a JWS using an unsupported signature algorithm
(Section 6.2).  What prevents an active attacker from performing a
downgrade attack on the signature algorithm used?

Similarly, since we include in the threat model a potentially hostile
CDN/MitM between the ACME client and ACME server, can that attacker strip a
success response and replace it with a badNonce error, causing the client
to retry (and thus duplicate the request processing on the server)?

I am not an ART AD, but there is not yet an internationalization
directorate, and seeing statements like "inputs for digest computations
MUST be encoded using the UTF-8 character set" (Section 5) without
additional discussion of normalization and/or what the canonical form for
the digest input is makes me nervous.  Has sufficient internationalization
review been performed to ensure that there are no latent issues in this
space?

Section 6.1 has text discussing TLS 1.3's 0-RTT mode.  If this text is
intended to be a profile that defines/allows the use of TLS 1.3 0-RTT data
for the ACME protocol, I think you need to be more specific and say
something like "MAY allow clients to send early data (0-RTT); there are no
ACME-specific restrictions on which types of requests are permitted in
0-RTT", since the runtime configuration is just 0-RTT yes/no, and the
protocol spec is in charge of saying which PDUs are allowed or not.

Section 6.2 notes that servers MUST NOT respond to GET requests for
sensitvie resources.  Why are account resources the only sensitive ones?
Are authorizations not sensitive?  Or are those considered to fall under
the umbrella of "account resources" (Section 7.1 seems pretty clear that
they do not)?

Section 7.1.1 discusses how the server can include a caaIdentities element
in its directory metadata; does this (or anything else) need to be
integrity protected by anything stronger than the Web PKI cert
authenticating the HTTPS connection?  It seems that a bogus caaIdentities
value could lead to an unfortunate DoS in some cases.

I am also a bit uncertain if the document is internally consistent about
whether one challenge verification suffices or there can be cases when
multiple challenge verifications are required for a successful
authorization.  I attmpted to note relevant snippets of the text in my
comments on Section 7.1.4.

I also have some important substantive comments in the section-by-section
COMMENTS, since they would not in and of themselves block publication.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This document was quite easy to read -- thank you for the clear prose and
document structure!  It did leave me with some questions as to whether
there are missing clarifications, though, so there are a pile of notes in
the section-by-section comments below.

It seems natural to feel some unease when the concept of automated
certificate issuance like this comes up.  As far as I can tell, though,
the only substantive difference between this flow and the flow it's
replacing is that this one qualitatively feels like it weakens the "know
your customer" aspect for the CA -- with current/legacy methods registering
for an account can be slow and involves real-world information.  Such can
be spoofed/forged, of course, but ACME seems to be weakening some aspect by
automating it.  Given the spoofability, though, this weakening does not
seem to be a particular concern with the document.

I was going to suggest mentioning the potential for future work in doing
time-delayed or periodic revalidation or other schemes to look at the
stability of the way that identifiers/challenges were validated, but I see
that discussion has already happened.

It's probably worth going over the examples and checking whether nonce
values are repeated in ways that are inconsistent with expected usage.  For
example, I see these three values appearing multiple times (but I did not
cross-check if a nonce returned in the Replay-Nonce response header was
then used in a JWS header attribute):
      2 K60BWPrMQG9SDxBDS_xtSw
      3 IXVHDyxIRGcTE0VSblhPzw
      4 JHb54aT_KTXBWQOzGYkt9A

Perhaps the examples could be offset by a description of what they are?
(They would probably also benefit from a disclaimer that the whitespace in
the JSON is for ease of reading only.)

Section-by-section comments follow.

Abstract (also Introduction)

If I read "authentication of domain names" with no context, I would be more
likely to think of the sort of challenge/authorization process that this
document describes, than I would be to think of using an X.509 certificate
to authenticate myself as being the owner of a given domain name.  But it's
unclear whether there's an alternative phrasing that would be better.

Section 1

   Different types of certificates reflect different kinds of CA
   verification of information about the certificate subject.  "Domain
   Validation" (DV) certificates are by far the most common type.  The
   only validation the CA is required to perform in the DV issuance
   process is to verify that the requester has effective control of the
   domain.

Can we get an (informative) ref for the "required"/requirements?

Section 6.1

W3C.CR-cors-2013-0129 shows up as "outdated" when I follow the link.

Section 6.2

IMPORTANT: The JSON Web Signature and Encryption Algorithms registry does
not appear to include an explicit indicator of whether an algorithm is
MAC-based; do we need to include text on how to make such a determination?

Section 6.3

For servers following the "SHOULD ... string equality check" and for
requests where the equality check fails, does that fall into the "MUST
reject the request as unauthorized" bucket?

Section 6.4

   In order to protect ACME resources from any possible replay attacks,
   ACME requests have a mandatory anti-replay mechanism.

We don't seem to actually define what an "ACME request" is that I can see.
>From context, this requirement only applies to JWS POST bodies, and not to,
say, newNonce, but I wonder if some clarification would be useful.

IMPORTANT: How tightly are these nonces scoped?  Are they only good on a
specific TLS connection?  Bound to an account key pair?  Globally valid?
(This is not a DISCUSS point because AFAICT there is no loss in security if
the nonce space is global to the server.)

Section 6.6

IMPORTANT: Providing an accountDoesNotExist error type probably means we
need to give guidance that the server should choose account URLs in a
non-guessable way, to avoid account enumeration attacks.

   [...] Servers
   MUST NOT use the ACME URN namespace Section 9.6 for errors other than
   the standard types.

"standard" as determined by inclusion in this document, or in the IANA
registry?

Section 7.1

The "up" link relation for going from certificate to chain seems to only be
needed for alternate content types that can only represent a single
certificate.  (Also, the "alternate" link relation is used to provide
alternate certifciation chains.)  Could this text be made more clear?

Presumably this is just my confusion, but what does "GET order certificate"
mean?

Section 7.1.1

   [...] It is a JSON
   object, whose field names are drawn from the following table and
   whose values are the corresponding URLs.

Er, from the IANA registry, right?

   The following metadata items are defined, all of which are OPTIONAL:

Maybe also refer to the registry?

Section 7.1.2

IMPORTANT: I'm unclear if the "contact" is supposed to be a "talk to a
human" thing or not.  If there are supposed to be different URLs that are
used for different purposes, wouldn't more metadata be needed about them?
So it seems most likely that this is indeed "talk to a human", in which
case that might be worth mentioning.  (Are these always going to be
mailto:?)

Section 7.1.2.1

IMPORTANT: Am I reading this correctly that the GET to the orders URL does
not require the client to be authenticated, in effect relying on
security-through-obscurity (of the account URL) for indicating which
account is trying to order certificates for which identifiers?

Section 7.1.4

   challenges (required, array of objects):  For pending authorizations,
      the challenges that the client can fulfill in order to prove
      possession of the identifier.  For final authorizations (in the
      "valid" or "invalid" state), the challenges that were used.  Each
      array entry is an object with parameters required to validate the
      challenge.  A client should attempt to fulfill one of these
      challenges, and a server should consider any one of the challenges
      sufficient to make the authorization valid.

This leaves me slightly confused.  A final authorization can have multiple
challenges.  But a client should only attempt to fulfill one, and a server
should treat any one as sufficient.  So I can only get to the case with
multiple challenges present in a final order of both "should"s are
violated?  Is there a way for the server to express that multiple
challenges are going to be required?
Hmm, but Section 7.1.6's flow chart for Authorization objects says that a
single challenge's transition to valid also makes the authorization
transition to valid, which would seem to close the window?
Section 7.5.1 has inline text that implicitly assumes that only one
challenge will be completed/validated.

   wildcard (optional, boolean):  For authorizations created as a result
      of a newOrder request containing a DNS identifier with a value
      that contained a wildcard prefix this field MUST be present, and
      true.

Is there a difference between false and absent?

Section 7.3

   A client creates a new account with the server by sending a POST
   request to the server's new-account URL.  The body of the request is
   a stub account object optionally containing the "contact" and
   "termsOfServiceAgreed" fields.

Given that we go on to describe those two and also the optional
onlyReturnExisting and externalAccountBinding fields, does this list need
expanding?

IMPORTANT: How does the client know if a termsOfService in the directory is
actually required or just optional?  (There doesn't seem to be a dedicated
error type for this?)  The text as-is seems to only say that if the server
requires it, the field must be present in the directory, but not the other
way around.  I guess Section 7.3.4 describes the procedure for a similar
case; should the same thing happen for the original terms acceptance?

IMPORTANT: The example response uses what appears to be a sequential
counter for account ID in the returned account URL, which loses any sort of
security-through-obscurity protections if those were desired.  Should a
more opaque URL component be present, maybe a UUID?  (The "orders" field
would need to be modified accordingly, of course, and this pattern appears
in later examples, as well.)

Section 7.3.2

It's a little unclear to me whether the fields the client can put in the
POST are the ones listed from Section 7.3 or 7.1.2, or the full set from
the registry.  But presumably the server must ignore the "status" field,
too, or at least some values should be disallowed!  The IANA registry's
"configurable" column may not quite be the right thing for this usage,
especially given how account deactivation works.

Section 7.3.5

   The server MAY require a value for the "externalAccountBinding" field
   to be present in "newAccount" requests.

All requests including queries for the current status and modification of
existing accounts?  Or just creation of new ones?

   To enable ACME account binding, the CA operating the ACME server
   needs to provide the ACME client with a MAC key and a key identifier,
   using some mechanism outside of ACME.

This key needs to also be tied to the external account in question, right?
One might even say that it is provided not to the ACME client, but to the
external account holder, who is also running an ACME client.

   [...] The payload of
   this JWS is the account key being registered, in JWK form.

This is presumably my fault and not the document's, but I had to read this
a few time to bind it as the ACME account key, and not the external MAC
key.

   If a CA requires that new-account requests contain an
   "externalAccountBinding" field, then it MUST provide the value "true"
   in the "externalAccountRequired" subfield of the "meta" field in the
   directory object.  If the CA receives a new-account request without [...]

nit: maybe "If such a CA"?

IMPORTANT: I don't think I understand why "nonce" MUST NOT be present in
the external-binding JWS object, though I think I understand why one is not
needed in order to bind the MAC to the current transaction.  (That is, this
is in effect a "triply nested" construct, where a standalone MAC that
certifies an ACME account (public) key as being authorized by the
external-account holder to act on behal of that external account.  But this
standalone MAC will only be accepted by the ACME server in the context of
the outer JWS POST, that must be signed by the ACME account key, which is
assumed to be kept secure by the ACME client, ensuring that both
key-holding entities agree to the account linkage.)  Proof of freshness of
the commitment from the external account holder to authorize the ACME
account key would only be needed if there was a scenario where the external
account holder would revoke that association, which does not seem to be a
workflow supported by this document.  Any need to effectuate such a
revocation seems like it would involve issuing a new MAC key for the
external account (and invalidating the old one), and revoking/deactivating
the ACME account, which is a somewhat heavy hammer but perhaps reasonable
for such a scenario.
Account key rollover just says that the nonce is NOT REQUIRED, and also
uses some nicer (to me) language about "outer JWS" and "inner JWS".  It
might be nice to synchronize these two sections.

Section 7.3.7

IMPORTANT: The "url" in this example looks like an account URL, not an
account-deactivation url.  If they are one and the same, please include
some body text to this effect as is done for account update in Section
7.3.2.

Section 7.4

Is Section 7.1.3 or the registry a better reference for the request
payload's fields?

Does the exact-match policy (e.g., on notBefore and notAfter) result in CA
maximum lifetime policies needing to be hardcoded in client software (as
opposed to being discoverable at runtime)?

(I like the order url in the example, "[...]/order/asdf".  Not much entropy
though.)

IMPORTANT: Why does the example response include an identifier of
www.example.com that was not in the request?

Is the "order's requested identifiers appear in commonName or
subjectAltName" requirement an exclusive or?

After a valid request to finalize has been issued, are "pending" or "ready"
still valid statuses that could be returned for that order?

Section 7.4.1

Elsewhere when we list "identifier (required, object)" in a JWS payload we
also inline the "type" and "value" breakdown of the object.

How is "expires" set for this pre-authorization object?

We probably need a reference for "certificate chain as defined in TLS".

Section 7.5

"When a client receives an order from the server" is a bit jarring without
some additional context of "in a reply to a new-order request" or "an order
object" or similar.

Section 7.5.1

   To do this, the client updates the authorization object received from
   the server by filling in any required information in the elements of
   the "challenges" dictionary.

"challenges" looks like an array of objects, not directly a dictionary with
elements within it.

Section 8

IMPORTANT: What do I do if I get a challenge object that has status "valid"
but also includes an "error" field?

Section 8.1

   [...] A key authorization is a string that expresses
   a domain holder's authorization for a specified key to satisfy a
   specified challenge, [...]

I'm going to quibble with the language here and say that the
keyAuthorization string as defined does not express a specific
authorization for a specific challenge, since there is no signature
involved, and the JWK thumbprint is separable and can be attached to some
other token.  (This may just be an editorial matter with no broader impact,
depending on how it's used.)  One could perhaps argue that the mere
existence of the token constitutes an authorization for a specified key to
satisfy the challenge, since the token only gets generated upon receipt of
such an authorized request.

Section 8.3

I'm not sure that 4086 is a great cite, here.  For example, in RFC 8446 we
say that "TLS requires a [CSPRNG].  In most case, the operating system
provides an appropriate facility [...] Should these prove unsatisfactory,
[RFC4086] provides guidance on the generation of random values."  On the
other hand, citing 4086 like this is not wrong, so use your judgment.

   4.  Verify that the body of the response is well-formed key
       authorization.  The server SHOULD ignore whitespace characters at
       the end of the body.

nit: "a well-formed"

Can we get some justification for the "SHOULD follow redirects", given the
security considerations surrounding doing so?

Section 8.4

Should this "token" description include the same text about entropy as for
the HTTP challenge?

Section 9.7.1

There is perhaps some subtlety here, in that the "configurable" column
applies only to the new-account request, but its description in the
template does not reflect that restriction.  In particular, "status" values
from the client *are* accepted when posted to the account URL, e.g., for
account deactivation.

Section 10.1

Can there be overlap between the "validation server" function and the "ACME
client" function?

Section 10.2

   [...] The key authorization reflects the
   account public key, is provided to the server in the validation
   response over the validation channel and signed afterwards by the
   corresponding private key in the challenge response over the ACME
   channel.

I'm stumbling up around the comma trying to parse this sentence.  (Maybe a
serial comma or using "and is signed" would help?)
IMPORTANT: Also, I don't see where the key authorization is signed in the
challenge response -- the payload is just an empty object for both the HTTP
and DNS challenges' responses.

Some of this text sounds like we're implicitly placing requirements on all
(HTTP|DNS) server operators (not just ones trying to use ACME) to mitgate
the risks being described.  In general this sort of behavior seems like an
anti-design-pattern, though perhaps one could argue that the behaviors in
question should be avoided in general, indepnedent of ACME.

Section 10.4

   Some server implementations include information from the validation
   server's response (in order to facilitate debugging).  Such

Disambiguating "ACME server implementations" may help, since we talk about
other HTTP requests in the previous paragraph.

Section 11.1

IMPORTANT: This may be an appropriate place to recommend against reuse of
account keys, whether after an account gets deactivated or by cycling
through keys in a sequence of key-change operations (or otherwise).  I
think there are some attack scenarios possible wherein (inner) JWS objects
could be replayed against a different account, if such key reuse occurs.

Section 11.3

   The http-01, and dns-01 validation methods mandate the usage of a

nit: spurious comma.

   [...] Secondly, the entropy requirement
   prevents ACME clients from implementing a "naive" validation server
   that automatically replies to challenges without participating in the
   creation of the initial authorization request.

IMPORTANT: I'm not sure I see how this applies to the HTTP mechanism --
couldn't you write a script to reply to .well-known/acme-challenge/<foo>
with <foo>.<key thumbprint> for a fixed key thumbprint?  The validation
server would ned to know about the ACME account in question, but not about
any individual authorization request.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 Aug 2018 21:10:06 -0400

Hi Ben,

Thanks for the detailed review.  Responses to the DISCUSS comments inline.
My co-author Daniel McCarney is working on the COMMENT comments.

--Richard

> downgrade attack on the signature algorithm used?

HTTPS, and the minimum requirements established in this document.  We can
add some comments to the Security Considerations if you want.

> to retry (and thus duplicate the request processing on the server)?

In the spectrum of DoS attacks the CDN could wage against the server, this
seems pretty lame.  The CDN could also just stop forwarding requests.

In other words, I don't really think the

> review been performed to ensure that there are no latent issues in this

Two of the three ART ADs have already signed off, so we have that going for
us :)

The only place we have human-readable text is in the problem documents, so
at that level, the i18n considerations are handled by that spec.  Other
than that, everything is ASCII, so saying "UTF-8" is just a fancy way of
saying, "don't send extra zero bytes".

> protocol spec is in charge of saying which PDUs are allowed or not.

The risk for HTTPS with 0-RTT is replay of requests.  The text already
notes that that is not an issue for ACME requests because they have their
own anti-replay protection.  There are no restrictions on which PDUs are
allowed.   What further specificity do you need?

> the umbrella of "account resources" (Section 7.1 seems pretty clear that

That sentence has an overly prescriptive tone.  Obviously it's up to the
CA's policy what it considers sensitive.  (Some especially profligate CA
that's not subject to GDPR might be OK publishing its account objects.)
Happy to dial it back to something like "For example, most CAs will likely
consider account resources to be sensitive."

> value could lead to an unfortunate DoS in some cases.

I don't know what you would consider stronger than a WebPKI cert.  You
could use a secondary key that isn't provided to the CDN and do JWS in the
server-to-client direction.  But that would require clients to configure a
public key as well as a URL, and you would have to figure out whether you
wanted caching or anti-replay and build the corresponding addenda to JWS.
All in all, a lot of complexity for marginal benefit, especially this late
in the game.

> comments on Section 7.1.4.

The document is clear that (1) any one challenge is sufficient for a given
authorization ("the server should consider any one of the challenges
sufficient to make the authorization valid") and (2) the server may provide
multiple authorizations in the order object if it requires multiple
different validations.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 29 Aug 2018 20:58:59 -0500

> On Aug 29, 2018, at 8:10 PM, Richard Barnes <[email-masked]> wrote:
> 
> 
> Two of the three ART ADs have already signed off, so we have that going for us :)
> 
> The only place we have human-readable text is in the problem documents, so at that level, the i18n considerations are handled by that spec.  Other than that, everything is ASCII, so saying "UTF-8" is just a fancy way of saying, "don't send extra zero bytes".
> 

I am an ART AD, for what it’s worth :-)

I didn’t sweat this because of the exact reason mentioned; that is, this seems mostly not intended to be read by humans.

On a related note, I did note some heartburn about the reference to RFC 3492 for IDNA, but for the purposes of ACME I suspect that’s the right thing to do. OTOH, Alexey is more of an expert on IDNA than I am. Alexey?

Ben.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 30 Aug 2018 12:18:53 +0100

Hi all,

On Thu, Aug 30, 2018, at 2:58 AM, Ben Campbell wrote:
>>> directorate, and seeing statements like "inputs for digest
>>> computations>>> MUST be encoded using the UTF-8 character set" (Section 5) without
>>> additional discussion of normalization and/or what the canonical
>>> form for>>> the digest input is makes me nervous.  Has sufficient
>>> internationalization>>> review been performed to ensure that there are no latent issues
>>> in this>>> space?
>> 
>> Two of the three ART ADs have already signed off, so we have that
>> going for us :)>> 
>> The only place we have human-readable text is in the problem
>> documents, so at that level, the i18n considerations are handled by
>> that spec.  Other than that, everything is ASCII, so saying "UTF-8"
>> is just a fancy way of saying, "don't send extra zero bytes".>> 
> 
> I didn’t sweat this because of the exact reason mentioned; that is,
> this seems mostly not intended to be read by humans.Agreed.

And JSON should be encoded in UTF-8, so stating that explicitly is a
good thing.
> On a related note, I did note some heartburn about the reference to
> RFC 3492 for IDNA, but for the purposes of ACME I suspect that’s the
> right thing to do. OTOH, Alexey is more of an expert on IDNA than I
> am. Alexey?
RFC 3492 defines Punicode, i.e. how to encode U-labels in ASCII to
produce A-labels. This particular encoding hasn't changed between
IDNA2003 and IDNA2008, so I think referencing it is Ok.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 30 Aug 2018 18:45:00 -0500

> I didn’t sweat this because of the exact reason mentioned; that is, this seems mostly not intended to be read by humans.

I also didn't expect any issues, but felt the need to explicitly check :)

(BTW, what are the digest computations that are referred to?  I was not
sure on first read.)

I think that we've discussed this point enough, and will reply to the other
ones on a different fork of the thread.

-Benjamin

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 30 Aug 2018 19:06:18 -0500

> add some comments to the Security Considerations if you want.

It's probably worth some security considerations text.
(BTW, I was more picky than usual for this doc, since apparently TLS MitM
capabilities are explicitly in the threat model via the
"CDN-in-front-of-ACME-server" case.  So in some sense that is implying that
the web PKI is not quite good enough for that channel.)

> In other words, I don't really think the

(incomplete sentence)
But yes, I was thinking about this some more after I balloted and it did
end up seeming likely innocuous by comparison.  It's still good to have
people more familiar with the document than me think about the
possibilities, though -- it seems like most things the client would be
trying to do are relatively idempotent (that is, new challenge tokens and
such could be generated, but that's easy to recover from unless the CDN is
blocking lots of stuff, in which case nothing works anyway), but maybe I
missed something.

> saying, "don't send extra zero bytes".

[this thread forked]

> allowed.   What further specificity do you need?

I would like it to be explicitly stated that there are no restrictions on
which PDUs are allowed.

If it helps, I'm trying to make a distinction between "you can negotiate
0-RTT in the TLS handshake" and "this is what you can put in early data";
in my mind, an application profile should explicitly cover the latter.

> consider account resources to be sensitive."

I think this is basically going to be subsumed/rendered OBE by Adam's
DISCUSS; please let me know if you think there is more to talk about here.

> All in all, a lot of complexity for marginal benefit, especially this late

Yeah, it's clearly a lot of complexity for marginal benefit (since the DoS
would likely be easy to notice and recover from) and late in the game.
Though the CA does already have a key that the client trusts...
Do you want to mention that the caaIdentities element gives a leaf cert
some control over the trust anchors that are used, in the security
considerations?  (This is a serious question; I am leaning towards it being
worth doing, but it would not be very hard to convince me otherwise.)

> multiple authorizations in the order object if it requires multiple

I think I'm still confused.  How could we end up with a case where a single
authorization object in the "valid" state includes more than one challenge?
(Looking at my notes, maybe this is just an editorial matter where a stray
's' slipped into one instance of "challenges", so we want "challenge that
was used" vs. "challenges that were used"?)

Thanks for the discussion!

-Benjamin

---

From: Richard Barnes <[email-masked]>
Date: Fri, 31 Aug 2018 12:32:08 -0400

I've started a PR for your DISCUSS comments here:

https://github.com/ietf-wg-acme/acme/pull/447

Right now, there are the following major edits there:

- Added some text to the Security Considerations that clarifies that the
only protection we provide against an ACME MitM is that we prevent it from
getting improper authorization.  We don't prevent it from doing downgrade
attacks or DoS.

- Added an explicit statement that there are no restrictions on the use of
0-RTT

- Clarified what contents are expected in the "challenges" array

Some more comments inline below.  Comments addressed by PR / overcome by
events trimmed.

> Though the CA does already have a key that the client trusts...

I guess it's true that the CA could present a key certified by its trusted
root, say in the directory object.  But that just turns the complexity knob
even higher :)

> worth doing, but it would not be very hard to convince me otherwise.)

I'm not sure what you mean by "caaIdentities element gives a leaf cert some
control over the trust anchors that are used".  Who is controlling whose
use of trust anchors, and how?

---

From: Richard Barnes <[email-masked]>
Date: Fri, 31 Aug 2018 13:46:24 -0400

On Fri, Aug 31, 2018 at 1:39 PM Benjamin Kaduk <[email-masked]> wrote:

> On Fri, Aug 31, 2018 at 12:32:08PM -0400, Richard Barnes wrote:
> > > > could use a secondary key that isn't provided to the CDN and do JWS
> in
> > > the
> > > > server-to-client direction.  But that would require clients to
> configure
> > > a
> Yup.  And having the trusted root directly sign a statement of CAA
> identifiers is probably right out for many reasons, including X.509
> constraints and it being a bad idea operationally to pull out your offline
> key to do something this mundane.
>
> >
> >
> The scenario I had in mind, which may be completely bogus, was that you
> have a CDN/whatever in front of the ACME server; that CDN's EE cert could
> in principle be signed by a different CA hierarchy than the ACME server is
> doing issuance for.  So you have a TLS cert from CA XYZ that is the
> authentication on a statement "use CAA value <foo> for CA ABC".  If the
> ACME
> client and its friends then go off and installs <foo> as their CAA record
> with a large TTL, when the client goes to ask for a cert, ABC goes and
> checks the CAA record and says "nothing doing".  If ABC caches for the full
> TTL, the client might have to find a different CA (perhaps one that does
> not use an actively harmful CDN to front its operations, heh).  This seems
> to only differ from the case of a CDN just dropping traffic on the floor or
> the other DoS vectors available to it, by virtue of the long TTL on the CAA
> record -- even after ABC decides that this CDN is evil and switches, that
> bogus CAA record is still valid.  Maybe it's better to say that the CDN's
> EE cert is controlling which trust anchor is *not* used [for issuing
> certificates for the client's domain] than to say it controls which trust
> anchor is used.
>

I agree that the TTL is the only issue here, and I don't think even that's
an issue.  RFC 6844 already requires CAs to be self-reliant and do their
own recursing ("Data cached by third parties MUST NOT be relied on"), so
they won't be stuck behind someone else's cache.  And it seems like CAs
have an incentive to get fresh data, since if they don't issue because of a
bad cached CAA record, they're losing business.

So I don't think there's anything to resolve here.

--Richard

> computations
> form
> > > for
> going
> > > for
> documents,
> > > so
> > > > > intended to be a profile that defines/allows the use of TLS 1.3
> 0-RTT
> > > data
> > > > could use a secondary key that isn't provided to the CDN and do JWS
> in
> > > the
> > > > server-to-client direction.  But that would require clients to
> configure
> > > a

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 31 Aug 2018 12:39:36 -0500

authentication on a statement "use CAA value <foo> for CA ABC".  If the ACME

-Benjamin

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 31 Aug 2018 12:51:00 -0500

> So I don't think there's anything to resolve here.

If you think that the CA will be willing to ignore its local cache and
re-fetch, I'm okay with dropping this topic.

-Benjamin