Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding
draft-ietf-acme-caa-10

[Ballot comment]
Thanks for addressing my Discuss (and Comment!) points!

While adding the discussion of  the privacy considerations of publishing account URLs
suffices to clear my discuss point, I will mention that if we wanted to obscure or anonymize
the published information relating to specific account, there are pretty standard ways to
do so and I'm happy to talk about it if that's desired.

[Ballot comment]
— Section 4 —

  If appropriate non-ACME identifiers are not present in the
  ACME Validation Methods IANA registry, the CA MUST use identifiers
  beginning with the string "ca-", which are defined to have CA-
  specific meaning.

Would it be reasonable to recommend not just
"ca-", but "ca--"?  Experience has shown that if "flarb"
is a common thing among CAs (or whatever) and Verisign implements a
"ca-flarb", that will tend to leak and become an unregistered
standard... but that's far less likely to happen if it's
"ca-verisign-flarb".  I'm not suggesting any formalization nor
registry for the  part, but just the fact that it's
included tends to get us away from the problem that BCP 178 is
addressing.

This is no longer at DISCUSS level, and if the working group
thinks this isn't a good idea, go ahead as planned.  But please chew
it over a bit and see if you can swallow it.

— Section 6 —
I have no idea what you’re trying to say here.  This is a Proposed Standard, right?  It defines two new parameters.  Are you now trying to say that we have not really defined anything?  I don’t understand.

No longer a DISCUSS, and no need for further response, but if you
can re-word this to explain the situation a bit better, that'd be
great.

---------------------------------------------

=== These have been resolved and/or explained; thanks for that ===

— Section 5.4 —

  CAs MUST satisfy this requirement by using URIs which include an
  authority:
  "https://a.example.com/account/1234"

First (this is not the DISCUSS part), readers who are not extremely familiar with how URIs are constructed — and given that “authority” is a normal English word with a meaning outside the URI world — might not really understand what you mean here.  A reference will help, and I suggest it” “…include an authority (see Section 3.2 of [RFC3986])”.

Second (this is the DISCUSS part), does this mean that all CAs MUST use URIs that include an authority?  Or does it only apply to those with the sort of situation you describe in this section?  If the latter, it seems odd that you’re prescribing, at MUST level, a particular solution, where there are certainly others (such as ensuring that the account numbers are unique in the first place).


(General: I hope the RFC Editor will be changing most “which” in this document to “that”, according to the Chicago Manual of Style, but I’ll let the RFC Editor address those.)

(Also general: For a very short document, this was quite a difficult read.  There are quite a few very long, heavy, hard-to-parse sentences, with lots of things run together.  While the sentences are grammatically correct, they’re harder on the reader than they ought to be.  Picking one of many as an example:

  Because CAA records are located during validation by walking up the
  DNS hierarchy until one or more records are found, the use of the
  "accounturi" and "validationmethods" parameters, or any CAA policy,
  is not an effective way to restrict or control issuance for
  subdomains of a domain, where control over those subdomains is
  delegated to another party (such as via DNS delegation or by
  providing limited access to manage subdomain DNS records).

That’s one sentence.  The document in general would benefit from breaking up those sorts of sentences to make it easier to get the sense of what it’s trying to say.  For example, the above might go something like this:

  CAA records are located during validation by walking up the
  DNS hierarchy until one or more records are found. Sometimes,
  control over subdomains of a domain is delegated to another
  party — via DNS delegation, or by providing limited access to
  manage subdomain DNS records.  In those cases CAA policy,
  including the use of the "accounturi" and "validationmethods"
  parameters, is not an effective way to restrict or control
  issuance for subdomains.
)

— Section 3 —

  "CA account" means an object maintained by a specific CA representing
  a specific entity, or group of related entities, which may request
  the issuance of certificates.

I’m not clear on what the “which” clause goes with:

1. Do you mean that the “specific CA” may request the issuance?
2. Do you mean that the entity or group of entities may request it?
3. Do you mean that the object may be used to request the issuance?

Some of this confusion might come from the that/which issue, but I think it’s really the structure of the sentence.  I suggest that you re-word the sentence to make it clearer.  Maybe (assuming (2) above is correct):

NEW
  A “CA account” is an object maintained by a specific CA, representing
  a specific entity or group of entities.  Those entities may request the
  issuance of certificates from that CA.
END

  A property with multiple "accounturi" parameters is
  unsatisfiable.

OK, but why not say, then, that there MUST NOT be multiple “accounturi” parameters in a given property?

— Section 3.2 —

  The use of specific kinds of URI may be specified in future RFCs, and
  CAs not implementing ACME MAY assign and recognise their own URIs
  arbitrarily.

Isn’t this true of CAs that do implement ACME also?  The “MAY” in Section 3.1 implies that, surely.

-- Section 5.3 —

  A CA which is unable to ensure consistent processing of the
  "accounturi" or "validationmethods" parameters for a given CA domain
  name as specifiable in CAA "issue" or "issuewild" properties MUST NOT
  implement support for these parameters.  Failure to do so will result
  in an implementation of these parameters which does not provide
  effective security.

“Failure to do so” seems odd after “MUST NOT”.  It also makes it sound as though failure to comply with a MUST NOT is an option.  I suggest, “Otherwise, the CA would have an implementation…”

— Section 5.8 —

  Because they express a restrictive security policy, misconfiguration
  of the "accounturi" or "validationmethods" parameters may result in
  legitimate issuance requests being refused.

As written, “they” goes with “misconfiguration”, which is clearly not what you meant (I think you mean it to refer to “the … parameters”).

NEW
  Because the "accounturi" or "validationmethods" parameters express
  a restrictive security policy, misconfiguration of them may result
  in legitimate issuance requests being refused.
END

[Ballot discuss]
Firstly, thank you for writing this -- I do however have some concerns around Section "5.6.  Use with and without DNSSEC"

1: "Where a domain chooses to secure its nameservers using DNSSEC, the authenticity of its DNS data can be assured, providing that a given CA makes all DNS resolutions via an appropriate, trusted DNSSEC-validating resolver."
A: DNSSEC does *not* secure nameservers, it secures the DNS data itself (think object security vs channel security) -- I'd suggest "When a domain is signed using DNSSEC, the authenticity..."
B: I'm confused what"appropriate" means in "appropriate, trusted DNSSEC validating resolver" -- if it is trusted I'd assume it is appropriate? Please explain.
C: The way that a resolver signals to a client that it has performed validation (and that the answer validated) is to set a single bit (AD) in the response - this is obviously something which should not be relied upon for security sensitive stuff - I'd strongly suggest that i) there be some text around getting the responses from the resolver to the CA machine securely (e.g over DNS-over-TLS), or better yet ii) that the CA machine itself do the DNSSEC validation - there are many libraries / systems to make this easy, e.g Stubby, libunbound, etc.

2: "A domain can use this property to protect itself from the threat posed by a global adversary capable of performing man-in-the-middle attacks, ..."
A: What is the purpose of "global" in "global adversary" -- I'm assuming it is trying to communicate something important here, but how is this different to a "local" adversary capable of performing man-in-the-middle attacks?

3: " Use of the "accounturi" or "validationmethods" parameters does not confer additional security against an attacker capable of performing a man-in-the-middle attack against all validation attempts made by a given CA which is authorized by CAA where:
  1.  A domain does not secure its nameservers using DNSSEC, or
  2.  That CA does not perform CAA validation using a trusted DNSSEC-validating resolver.
Moreover, use of the "accounturi" or "validationmethods" parameters does not mitigate against man-in-the-middle attacks against CAs which do not validate CAA records, or which do not do so using a trusted DNSSEC-validating resolver, ..."

Can this document simply say: "When using this method, CA's MUST use a DNSSEC-validating resolver"? -- it will a: make the protocol more secure and b: simplify a bunch of the document and c: isn't a large burden.
During the so-called "DNSpionage" incident, it seems that a specific CA was chosen because it didn't do DNSSEC validation (or, perhaps would try validate, but would still issue if DNSSEC validation failed) -- see: https://mailman.nanog.org/pipermail/nanog/2019-March/099852.html

[Ballot comment]
Thank you again for writing this, and apologies for not balloting earlier - I've got a cold and am behind on my IETF work.

[Ballot comment]
Thanks to everyone who worked on this extension.

I support Barry's first DISCUSS point.  Beyond that concern, I have only one
comment.

---------------------------------------------------------------------------

§5.4:

>  Suppose that both CA A and CA B issue account URIs of the form
>
>  "account-id:1234"

This is a little concerning as an example, as "account-id" isn't a registered
URI scheme. Consider instead using:

  urn:example:account-id:1234

[Ballot discuss]
I think we need to have some privacy considerations text about how this
mechanism exposes ACME account URLs, which are otherwise intended to be
unguessable, in the public DNS view.  While ACME is generally intended
to remain secure in the face of such information disclosure, it does
have potential to enable some forms of correlation attacks, and could
lead to DoS attempts specific to a given account or accounts.

[Ballot comment]
I support Barry's Discusses (noting in particular that the "ca-" prefix is
not reserved for local use by RFC 8555).

Did we consider supplying ABNF descriptions of the parameter values?  In
particular, this would unambiguously specify whether optional whitespace
is admitted in the comma-separated list used by "validationmethods".

The shepherd writeup notes that there used to be hyphens in
"account-uri" and "accepted-challenges".  It seems that rfc6844bis has
expanded the grammar to allow such hyphens; do we want to revisit their
removal from this document?  Noting that rfc6844bis is also slated for
approval on this week's telechat, it may be worth updating the
references as well, regardless of the decision on hyphens.

Section 3

  The presence of this parameter constrains the property to which it is
  attached.  Where a CAA property has an "accounturi" parameter, a CA
  MUST only consider that property to authorize issuance in the context
  of a given certificate issuance request if the CA recognises the URI
  specified as identifying the account making that request.

nit: perhaps "URI specified in the value portion of the accounturi
parameter" for maximum clarity?

Section 4

  The presence of this parameter constrains the property to which it is
  attached.  A CA MUST only consider a property with the
  "validationmethods" parameter to authorize issuance where the name of
  the challenge method being used is one of the names listed in the
  comma-separated list.

nit: I'm not sure that we've really defined "challenge method" in the
sense it's used here.  (We do define it in the sense of "names listed in
the comma-separated list", but it seems like this usage is trying to
refer to the actual actions taken by the CA to authorize the issuance
request.

Section 5.2

I think this section may be predicated on an understanding of CAA
"issue"/"issuewild" parameters that does not match my own.  (Note that
this includes the possibility that my understanding is incorrect.)
Specifically, my reading of draft-ietf-lamps-rfc6844bis-06 Section 4.2
indicates that a given paramter is only defined for usage in a CAA
"issue" record at the explicit specification of the Issuer, and that the
Issuer alone determines their semantics.  So when this text says that
parameters are not an effective control absent out-of-band establishment
of support, that's either a non sequitur or a tautology -- nobody has
any business adding parameters to an Issuer's CAA entry unless that
Issuer has told them to do so, full stop.
Granted, we are complicating things by providing a preestablished
specification for a set of parameters that an Issuer may choose to
incorporate by reference, but I don't see that as changing the fact that
the parameters are still specific to the given Issuer (and their CAA
entry).
Similarly, "MUST NOT assume" and "SHOULD also document" are repeating
requirements from rfc6844bis, when starting from my frame of reference
(and thus would not need to use the normative capitalization).

Section 5.7

This seems perhaps more appropriate in the core CAA specification than
in this document.  Conveniently, rfc6844bis is open and in IESG
evaluation...

[Ballot discuss]
— Section 4 —

  If appropriate non-ACME identifiers are not present in the
  ACME Validation Methods IANA registry, the CA MUST use identifiers
  beginning with the string "ca-", which are defined to have CA-
  specific meaning.

Was the working group aware of BCP 178 (RFC 6648), and did they consider the “ca-“ prefix in that context?  If so, how does the working group propose to avoid the problems outlined by BCP 178?

— Section 5.4 —

  CAs MUST satisfy this requirement by using URIs which include an
  authority:
  "https://a.example.com/account/1234"

First (this is not the DISCUSS part), readers who are not extremely familiar with how URIs are constructed — and given that “authority” is a normal English word with a meaning outside the URI world — might not really understand what you mean here.  A reference will help, and I suggest it” “…include an authority (see Section 3.2 of [RFC3986])”.

Second (this is the DISCUSS part), does this mean that all CAs MUST use URIs that include an authority?  Or does it only apply to those with the sort of situation you describe in this section?  If the latter, it seems odd that you’re prescribing, at MUST level, a particular solution, where there are certainly others (such as ensuring that the account numbers are unique in the first place).

— Section 6 —
I have no idea what you’re trying to say here.  This is a Proposed Standard, right?  It defines two new parameters.  Are you now trying to say that we have not really defined anything?  I don’t understand.

[Ballot comment]
(General: I hope the RFC Editor will be changing most “which” in this document to “that”, according to the Chicago Manual of Style, but I’ll let the RFC Editor address those.)

(Also general: For a very short document, this was quite a difficult read.  There are quite a few very long, heavy, hard-to-parse sentences, with lots of things run together.  While the sentences are grammatically correct, they’re harder on the reader than they ought to be.  Picking one of many as an example:

  Because CAA records are located during validation by walking up the
  DNS hierarchy until one or more records are found, the use of the
  "accounturi" and "validationmethods" parameters, or any CAA policy,
  is not an effective way to restrict or control issuance for
  subdomains of a domain, where control over those subdomains is
  delegated to another party (such as via DNS delegation or by
  providing limited access to manage subdomain DNS records).

That’s one sentence.  The document in general would benefit from breaking up those sorts of sentences to make it easier to get the sense of what it’s trying to say.  For example, the above might go something like this:

  CAA records are located during validation by walking up the
  DNS hierarchy until one or more records are found. Sometimes,
  control over subdomains of a domain is delegated to another
  party — via DNS delegation, or by providing limited access to
  manage subdomain DNS records.  In those cases CAA policy,
  including the use of the "accounturi" and "validationmethods"
  parameters, is not an effective way to restrict or control
  issuance for subdomains.
)

— Section 3 —

  "CA account" means an object maintained by a specific CA representing
  a specific entity, or group of related entities, which may request
  the issuance of certificates.

I’m not clear on what the “which” clause goes with:

1. Do you mean that the “specific CA” may request the issuance?
2. Do you mean that the entity or group of entities may request it?
3. Do you mean that the object may be used to request the issuance?

Some of this confusion might come from the that/which issue, but I think it’s really the structure of the sentence.  I suggest that you re-word the sentence to make it clearer.  Maybe (assuming (2) above is correct):

NEW
  A “CA account” is an object maintained by a specific CA, representing
  a specific entity or group of entities.  Those entities may request the
  issuance of certificates from that CA.
END

  A property with multiple "accounturi" parameters is
  unsatisfiable.

OK, but why not say, then, that there MUST NOT be multiple “accounturi” parameters in a given property?

— Section 3.2 —

  The use of specific kinds of URI may be specified in future RFCs, and
  CAs not implementing ACME MAY assign and recognise their own URIs
  arbitrarily.

Isn’t this true of CAs that do implement ACME also?  The “MAY” in Section 3.1 implies that, surely.

-- Section 5.3 —

  A CA which is unable to ensure consistent processing of the
  "accounturi" or "validationmethods" parameters for a given CA domain
  name as specifiable in CAA "issue" or "issuewild" properties MUST NOT
  implement support for these parameters.  Failure to do so will result
  in an implementation of these parameters which does not provide
  effective security.

“Failure to do so” seems odd after “MUST NOT”.  It also makes it sound as though failure to comply with a MUST NOT is an option.  I suggest, “Otherwise, the CA would have an implementation…”

— Section 5.8 —

  Because they express a restrictive security policy, misconfiguration
  of the "accounturi" or "validationmethods" parameters may result in
  legitimate issuance requests being refused.

As written, “they” goes with “misconfiguration”, which is clearly not what you meant (I think you mean it to refer to “the … parameters”).

NEW
  Because the "accounturi" or "validationmethods" parameters express
  a restrictive security policy, misconfiguration of them may result
  in legitimate issuance requests being refused.
END

[Ballot comment]
(1) I can't claim to fully understand the contents of this document.  However, I find the use of Normative language in the following sentence in the IANA Considerations confusing: "This document merely specifies a RECOMMENDED semantic for parameters..."

First of all, there's nothing that can be Normatively enforced in that piece of text.  Second, Sections 3-4, where the parameters are specified, are the appropriate place for the Normative specification.

Solution: s/RECOMMENDED/recommended

(2) I don't think that there's a significant impact, or any at all...but it seems to me that this document should reference draft-ietf-lamps-rfc6844bis instead of RFC6844.

[Ballot comment]
I can't claim to fully understand the contents of this document.  However, I find the use of Normative language in the following sentence in the IANA Considerations confusing: "This document merely specifies a RECOMMENDED semantic for parameters..."

First of all, there's nothing that can be Normatively enforced in that piece of text.  Second, Sections 3-4, where the parameters are specified, are the appropriate place for the Normative specification.

Solution: s/RECOMMENDED/recommended

[Ballot comment]
Hugo, thank you for the work put into this document. Adding some examples was a good idea.

I found it interesting that the security section represents roughly 50% of the document ;-)

I have two comments and one nit. See below.

== COMMENTS ==


-- Section 2 --

Please use RFC 8174 boiler template for this section ;-)

-- Section 3 --

The word 'applicable' is used but never strictly defined. If defined in another document, please add a reference (perhaps in the section 2), else please define it.

== NIT ==

-- abstract --

Expand CAA, CA in the abstract ?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-acme-caa-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-04-10):

From: The IESG
To: IETF-Announce
CC: ekr@rtfm.com, Daniel McCarney , acme@ietf.org, cpu@letsencrypt.org, draft-ietf-acme-caa@ietf.org, acme-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (CAA Record Extensions for Account URI and ACME Method Binding) to Proposed Standard


The IESG has received a request from the Automated Certificate Management
Environment WG (acme) to consider the following document: - 'CAA Record
Extensions for Account URI and ACME Method Binding'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-04-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The CAA DNS record allows a domain to communicate issuance policy to
  CAs, but only allows a domain to define policy with CA-level
  granularity.  However, the CAA specification also provides facilities
  for extension to admit more granular, CA-specific policy.  This
  specification defines two such parameters, one allowing specific
  accounts of a CA to be identified by URI and one allowing specific
  methods of domain control validation as defined by the ACME protocol
  to be required.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-acme-caa/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-acme-caa/ballot/


No IPR declarations have been submitted directly on this I-D.

Technical Summary

The ACME-CAA draft extends the base CAA mechanism described by RFC 6844 to
allow fine-grained authorization for draft-ACME based CAs. It adds two new
parameters to the "issue" property tag, and the "issuewild" property tag. The
new parameters are "accounturi" and "acceptedchallenges" and can be used to
extend a CAA policy for an ACME based CA.

The "accounturi" parameter allows the domain holder to restrict authorization
to issue for a domain to only the ACME account URI specified in the CAA
policy. The "acceptedchallenges" parameter allows the domain holder to restrict
the ACME challenges that can be used for domain validation of a domain to those
specified in the CAA policy.

Working Group Summary

Earlier drafts used a hyphen character in the "validationmethods" and
"accounturi" parameters that was incompatible with the grammar defined in RFC
6844. This has been addressed in the latest draft by removing the hyphen
character.

Early discussion of the draft addressed issues raised by the community with
regards to the security considerations section, and the handling of non-ACME
challenge methods. Overall consensus was reached within the WG process without
any rough areas and no controversial topics remain unaddressed.

Document Quality

Let's Encrypt, a large high-volume production ACME based CA, has fully
implemented the ACME-CAA draft in a testing environment (not yet promoted to
production usage). Let's Encrypt has committed to promoting ACME-CAA features
to production in the near future.

The overall document quality is high. Developing an implementation based on the
specification text is reasonable.

Personnel

The document shepard is Daniel McCarney. The responsible area director is Eric
Rescorla.

There are no IANA considerations and no IANA experts/registry work is required.

IRTF Note

Not applicable.

IESG Note

Not applicable.

IANA Note

Not applicable.