Subject: Re: [Acme] AD Review: draft-ietf-acme-caa-05

From: Hugo Landau <[email-masked]>
Date: Tue, 4 Dec 2018 02:26:42 +0000

On Sun, Nov 04, 2018 at 07:18:05PM -0800, Eric Rescorla wrote:
> IMPORTANT
> S 4.
> >      Where a CA supports both the "validationmethods" parameter and one or
> >      more non-ACME challenge methods, it MUST assign identifiers to those
> >      methods.  These identifiers MUST be chosen to minimise the likelihood
> >      of conflict with any ACME challenge method name; it is RECOMMENDED
> >      that, at the very least, CAs avoid assigning identifiers ending in a
> >      hyphen and two digits ("-00").
> 
> This doesn't seem sufficient to prevent conflicts. You need to either
> (a) ensure they don't conflict or (b) remove this feature.
Since the ACME WG appears to have adopted the policy of always assigning
validation method names according to this scheme, this is effective to
prevent conflicts. Removing this paragraph is a bad idea because CAs are
then likely to invent their own ad-hoc solutions if not given guidance
on non-ACME use cases.

I'm open to alternative methods of preventing conflicts. A prefix could
be reserved for CA-specific use, e.g. "nonacme-".

> S 5.4.
> >      CAA record validation.
> >
> >      It is RECOMMENDED that CAs satisfy this requirement by using URIs
> >      which include an authority:
> >
> >      "https://a.example.com/account/1234"
> 
> What is the reason for ever not including URIs with an authority? This
> just seems like a recipe for fail.
In other words, you'd prefer this to be changed to a MUST? Alright.

> S 5.6.
> >      1.  Use the "accounturi" parameter to ensure that only accounts which
> >          it controls are authorized to obtain certificates, or
> >
> >      2.  Exclusively use validation methods which rely solely on
> >          information obtained via DNSSEC, and use the "validationmethods"
> >          parameter to ensure that only such methods are used.
> 
> I don't think this is right unless *also* all CAs do DNSSEC
> validation, because one CA might not do DNSSEC and *then* the CAA
> record could be attacked.
This is supposed to be covered by section "Limited to CAs Processing CAA
Records" but could be clearer. I'll revise the wording.

> COMMENTS
> 
> >   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
> extensions.
In this context the word is being used as a verb, not a noun.

> 
> 
> S 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 NOT consider that property to authorize issuance in the context
> >      of a given certificate issuance request unless the CA recognises the
> >      URI specified as identifying the account making that request.
> 
> This is very awkward writing. Can you rephrase in a positive way.
> I.e.,
> "The CA MUST only issue if..."
OK

> 
> S 3.
> >      MUST NOT consider that property to authorize issuance in the context
> >      of a given certificate issuance request unless the CA recognises the
> >      URI specified as identifying the account making that request.
> >
> >      If a certificate issuance request is made to a CA such that no
> >      account URI is available, because the request is made in the absence
> 
> IMPORTANT What does "available" mean in this context.
This is explained by the end of the sentence.

> 
> 
> S 3.
> >      account URI is available, because the request is made in the absence
> >      of any account or the account has no URI assigned to it, a CA MUST
> >      NOT consider any property having an "accounturi" parameter as
> >      authorizing issuance.
> >
> >      If a CA finds multiple CAA records pertaining to it (i.e., having
> 
> pertaining to what? the CA?
Not seeing an issue with this wording. It's also clarified by the
parenthetical.

> 
> 
> S 3.
> >      If a CA finds multiple CAA records pertaining to it (i.e., having
> >      property "issue" or "issuewild" as applicable and a domain that the
> >      CA recognises as its own) with different "accounturi" parameters, the
> >      CA MUST NOT consider the CAA record set to authorize issuance unless
> >      at least one of the specified account URIs identifies the account of
> >      the CA by which issuance is requested.  A property without an
> 
> The account of the CA? CAs don't have accounts.
One would hope that a CA has accounts, else it has no customers.
Defined previously:

  "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.

> 
> Does this say anything other than "at least one of the records must
> match according to the conditions above"
Reworded.

> S 3.
> >      CA MUST NOT consider the CAA record set to authorize issuance unless
> >      at least one of the specified account URIs identifies the account of
> >      the CA by which issuance is requested.  A property without an
> >      "accounturi" parameter matches any account.  A property with an
> >      invalid or unrecognised "accounturi" parameter is unsatisfiable.  A
> >      property with multiple "accounturi" parameters is unsatisfiable.
> 
> So you have to ignore it?
?

> 
> 
> S 3.
> >
> >      The presence of an "accounturi" parameter does not replace or
> >      supercede the need to validate the domain name specified in an
> >      "issue" or "issuewild" record in the manner described in the CAA
> >      specification.  CAs MUST still perform such validation.  For example,
> >      a CAA property which specifies a domain name belonging to CA A and an
> 
> Please use the property names here.
OK

> 
> 
> S 3.1.
> >      An ACME [I-D.ietf-acme-acme] account object MAY be identified by
> >      setting the "accounturi" parameter to the URI of the ACME account
> >      object.
> >
> >      Implementations of this specification which also implement ACME MUST
> >      recognise such URIs.
> 
> What does this mean as a practical matter? How would you implement
> this specification without that?

  A CAA parameter "accounturi" is defined for the "issue" and "issuewild"
  properties defined by {{RFC6844}}. The value of this parameter, if specified,
  MUST be a URI {{RFC3986}} identifying a specific CA account.

There is no specific requirement that the "accounturi" parameter be used
with ACME.

  The "accounturi" specification provides a general mechanism to identify
  entities which may request certificate issuance via URIs. 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.

> S 3.2.
> >
> >      The "accounturi" specification provides a general mechanism to
> >      identify entities which may request certificate issuance via URIs.
> >      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.
> 
> It seems like you need to say something about the properties of said
> URIs.
What properties do you want to see discussed? The "URI Ambiguity"
section of the security considerations already discusses essential
requirements of any URIs used.

> 
> 
> S 5.
> >      expressed.  This allows the set of entities capable of successfully
> >      requesting issuance of certificates for a given domain to be
> >      restricted beyond that which would otherwise be possible, while still
> >      allowing issuance for specific accounts of a CA.  This improves the
> >      security of issuance for domains which choose to employ it, when
> >      combined with a CA which implements this specification.
> 
> It seems like you also need to acknowledge that it increases the risk
> of bricking yourself.
OK

> 
> 
> S 5.1.
> >
> >      All of the security considerations of the CAA specification are
> >      inherited by this document.  This specification merely enables a
> >      domain with an existing relationship with a CA to further constrain
> >      that CA in its issuance practices, where that CA implements this
> >      specification.  In particular, it provides no additional security
> 
> This isn't correct. I could use validationmethods to restrict some CA
> I've never spoken to.
This would require a commitment from that CA to implement the ACME-CAA
specification, which it isn't required to do. Thus effective use
requires deployment in specific conjunction with a CA which has
committed to implement it.

> 
> 
> S 5.5.
> >      a certificate issuance request.  The CAA policy expressed by a domain
> >      may have changed in the meantime, creating the risk that a CA will
> >      issue certificates in a manner inconsistent with the presently
> >      published CAA policy.
> >
> >      CAs SHOULD consider adopting practices to reduce the risk of such
> 
> https://tools.ietf.org/rfcmarkup?doc=6919#section-2
Reworded.

Updated version at
https://github.com/ietf-wg-acme/acme-caa/commit/a4b9f87ecd00262c1febc1bc6f00cd051c186271
https://github.com/ietf-wg-acme/acme-caa/blob/master/draft-ietf-acme-caa.md

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 21 Dec 2018 08:26:24 -0800

On Mon, Dec 3, 2018 at 6:26 PM Hugo Landau <[email-masked]> wrote:

> prevent conflicts.

Traditional practices do not a policy make.

Removing this paragraph is a bad idea because CAs are
> then likely to invent their own ad-hoc solutions if not given guidance

What I meant by remove the feature was to prohibit defining non-registered
values.

> be reserved for CA-specific use, e.g. "nonacme-".

That would be fine.

> In other words, you'd prefer this to be changed to a MUST? Alright.

Yes.

> Records" but could be clearer. I'll revise the wording.

Thanks.

-ekr

---

From: Hugo Landau <[email-masked]>
Date: Sat, 22 Dec 2018 16:28:16 +0000

> > be reserved for CA-specific use, e.g. "nonacme-".

Amended to:

  Where a CA supports both the "validationmethods" parameter and one or
  more non-ACME challenge methods, it MUST assign identifiers to those
  methods. If appropriate non-ACME identifiers are not present in the
  ACME Validation Methods IANA registry, the CA MUST use identifiers
  beginning with the string "nonacme-". Such identifiers have
  CA-specific meaning.

Attention should be drawn to the following text in the ACME I-D:

  When evaluating a request for an assignment in this registry, the designated
  expert should ensure that the method being registered has a clear,
  interoperable definition and does not overlap with existing validation methods.
  That is, it should not be possible for a client and server to follow the
  same set of actions to fulfill two different validation methods.

  Validation methods do not have to be compatible with ACME in order to be
  registered.  For example, a CA might wish to register a validation method in
  order to support its use with the ACME extensions to CAA
  {{?I-D.ietf-acme-caa}}.

Since this is a prefix and not an entry per se, it seems like the
cleanest way to accommodate this is to amend the ACME I-D, rather than
use of "IANA Considerations" section, which is currently nil. The ACME
I-D is already referencing ACME-CAA above. But I'm open to suggestions.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 22 Dec 2018 09:25:41 -0800

This SGTM. ACME editors?

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 22 Dec 2018 19:14:10 +0000

Would like to see proposed wording, but the concept seems fine.

From: Eric Rescorla <[email-masked]>
Date: Saturday, December 22, 2018 at 12:26 PM
To: Hugo Landau <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Acme] AD Review: draft-ietf-acme-caa-05

This SGTM. ACME editors?

-Ekr

Amended to:

---

From: Hugo Landau <[email-masked]>
Date: Sat, 29 Dec 2018 02:11:31 +0000

> Would like to see proposed wording, but the concept seems fine.
How about, changes marked:

+   Validation methods beginning with the prefix "ca-" are reserved for CA-local
+   meaning and may not be registered.

I've changed from "nonacme-" to "ca-" because the validation-methods
registry states that non-ACME methods may be registered, so "nonacme-"
as a prefix is a little nonsensical. The core utility here is to provide
a CA-local naming prefix. I'm not picky on what the prefix is, though.

And the applicable clause in ACME-CAA becomes:

    Where a CA supports both the "validationmethods" parameter and one or more
    non-ACME challenge methods, it MUST assign identifiers to those methods. 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.

I think that about does it?

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 29 Dec 2018 03:23:35 +0000

"need not be" ?  Or "SHOULD NOT be" ?

>    I think that about does it?
  
Looks good to me.

---

From: Hugo Landau <[email-masked]>
Date: Sat, 29 Dec 2018 03:30:32 +0000

> "need not be" ?  Or "SHOULD NOT be" ?
My intention was that the rules of the registry state that such names
MUST NOT be registered. I didn't use a capitalised keyword here for
consistency with the prose already in that section.