> > CAs MUST select and process account URIs under the assumption that
> > untrusted third parties may learn of them.
>
> As Tim notes, this isn't really an actionable MUST, so we probably should
> just go with "are encouraged to".
Done.
> >
> > The value of the "validationmethods" parameter MUST comply with the
> > following ABNF {{RFC5234}}:
> >
> > value = [*(label ",") label]
> > label = 1*(ALPHA / DIGIT / "-")
>
> That looks okay to my eye, but let's see if we can get an ART AD to look at
> it, as well -- I'm only an amateur at ABNF.
Sounds good, putting this in for now.
> > > 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).
> > I agree with your interpretation, and this interpretation is in fact
> > explicitly stated in the IANA considerations section — but I don't think
> > how this is worded currently is a problem.
>
> This is a non-blocking comment, so it's entirely your call. If you wanted
> a concrete suggestion from me, I'd probably consider a minimal change like
> adding a new sentence at the start and tweaking the transition:
> "CAA
> records are inherently an indicator of an agreement between a domain owner
> and one or more CAs, so inserting CAA records into the DNS without
> cooperation from a CA is not expected to have any effect. Accordingly, the
> CAA parameters specified in this section rely on [...]". But I just wrote
> that on the fly and will not be surpirsed if it is unsatisfactory :)
I don't want the document to assume some sort of legal/contractual
relationship, so I decided to go with this:
Because the parameters of "issue" or "issuewild" CAA properties
constitute a CA-specific namespace, the CA identified by an "issue" or
"issuewild" property decides what parameters to recognise and their
semantics. Accordingly, the CAA parameters defined in this
specification rely on their being recognised by the CA named by an
"issue" or "issuewild" CAA property, and are not an effective means of
control over issuance unless a CA's support for the parameters is
established beforehand.
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
