Re: [Acme] AD Review: draft-ietf-acme-caa-05
This works for me. -Ekr On Thu, Jan 3, 2019 at 11:33 AM Salz, Rich wrote: > @ekr, is this okay with you? > > On 12/28/18, 10:30 PM, "Hugo Landau" wrote: > > On Sat, Dec 29, 2018 at 03:23:35AM +, Salz, Rich wrote: > > > > + Validation methods beginning with the prefix "ca-" are > reserved for CA-local > > + meaning and may not be registered. > > > > "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. > > > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] AD Review: draft-ietf-acme-caa-05
@ekr, is this okay with you? On 12/28/18, 10:30 PM, "Hugo Landau" wrote: On Sat, Dec 29, 2018 at 03:23:35AM +, Salz, Rich wrote: > > + Validation methods beginning with the prefix "ca-" are reserved for CA-local > + meaning and may not be registered. > > "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. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] AD Review: draft-ietf-acme-caa-05
On Sat, Dec 29, 2018 at 03:23:35AM +, Salz, Rich wrote: > > + Validation methods beginning with the prefix "ca-" are reserved for > CA-local > + meaning and may not be registered. > > "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. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] AD Review: draft-ietf-acme-caa-05
+ Validation methods beginning with the prefix "ca-" are reserved for CA-local + meaning and may not be registered. "need not be" ? Or "SHOULD NOT be" ? >I think that about does it? Looks good to me. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] AD Review: draft-ietf-acme-caa-05
> Would like to see proposed wording, but the concept seems fine.
How about, changes marked:
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}}.
+ 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?
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] AD Review: draft-ietf-acme-caa-05
Would like to see proposed wording, but the concept seems fine.
From: Eric Rescorla
Date: Saturday, December 22, 2018 at 12:26 PM
To: Hugo Landau
Cc: "acme@ietf.org"
Subject: Re: [Acme] AD Review: draft-ietf-acme-caa-05
This SGTM. ACME editors?
-Ekr
On Sat, Dec 22, 2018 at 8:28 AM Hugo Landau
mailto:hlan...@devever.net>> wrote:
> 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.
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.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] AD Review: draft-ietf-acme-caa-05
This SGTM. ACME editors?
-Ekr
On Sat, Dec 22, 2018 at 8:28 AM Hugo Landau wrote:
> > 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.
>
> 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.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] AD Review: draft-ietf-acme-caa-05
> 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.
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.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] AD Review: draft-ietf-acme-caa-05
On Mon, Dec 3, 2018 at 6:26 PM Hugo Landau 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?
Re: [Acme] AD Review: draft-ietf-acme-caa-05
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
