On Mon, Dec 3, 2018 at 6:26 PM Hugo Landau <hlan...@devever.net> wrote:
> 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.
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
> on non-ACME use cases.
>
What I meant by remove the feature was to prohibit defining non-registered
values.
I'm open to alternative methods of preventing conflicts. A prefix could
> be reserved for CA-specific use, e.g. "nonacme-".
>
That would be fine.
> 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.
>
Yes.
> 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.
>
Thanks.
-ekr
>
>
>
>
>
>
>
> > 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
>
>
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
