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

[Hugo Landau <[e-mail]>]

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