BTW it would be rather nice if people could avoid lawyering the language of every post. Natural language descriptions of this type of specification are prone to end up with ambiguity. I am trying very hard to avoid introducing changes or ambiguity into the proposed revised text.
I would much prefer to do this sort of thing with Z. But that isn’t going to be practical until the new RFC format and even then, I doubt it will be accepted. It is my understanding that any errata would be a non breaking change and thus eligible to be accepted as opposed to held for document revision. From: Public [mailto:[email protected]] On Behalf Of Phillip via Public Sent: Thursday, June 22, 2017 4:13 PM To: 'Ryan Sleevi' <[email protected]>; 'Peter Bowen' <[email protected]>; 'CA/Browser Forum Public Discussion List' <[email protected]> Subject: Re: [cabfpub] "[UNVERIFIED SENDER]Re: no CAA authorizations -- RFC 6844 I am pretty sure that Peter and myself only diverged in our interpretation of the original proposal from Iida. I had not considered the case that alice.com is explicitly authorized but only for issue. We did in fact have a lot of discussion on the list about this when issuewild was proposed. We certainly did not want the addition of issuewild to require everyone to publish records for both but some people did want to specify separate semantics for both. I will thus amend my earlier post to read: It is my understanding that the text as drafted prohibits issue of a wildcard certificate by any CA if the record set only contains issue records and issue of a non wildcard certificate if the record set only contains issuewild records. I do not think that this actually changes the proposed errata since 5.3 applies regardless. From: Ryan Sleevi [mailto:[email protected]] Sent: Thursday, June 22, 2017 3:57 PM To: Peter Bowen <[email protected] <mailto:[email protected]> >; CA/Browser Forum Public Discussion List <[email protected] <mailto:[email protected]> > Cc: Phillip <[email protected] <mailto:[email protected]> > Subject: Re: [cabfpub] "[UNVERIFIED SENDER]Re: no CAA authorizations -- RFC 6844 This is consistent with the deployed reality, so I similarly concur with Peter's view and believe that Phillip's understanding may be a misunderstanding of the text. Certainly, it would be a breaking change for deployments to adopt the proposed interpretation, and for that reason, would be very concerning. On Thu, Jun 22, 2017 at 2:59 PM, Peter Bowen via Public <[email protected] <mailto:[email protected]> > wrote: I believe that this is a misreading, based on section 5.3: <https://tools.ietf.org/html/rfc6844#section-5.3> 5.3. CAA issuewild Property The issuewild property has the same syntax and semantics as the issue property except that issuewild properties only grant authorization to issue certificates that specify a wildcard domain and issuewild properties take precedence over issue properties when specified. Specifically: issuewild properties MUST be ignored when processing a request for a domain that is not a wildcard domain. If at least one issuewild property is specified in the relevant CAA record set, all issue properties MUST be ignored when processing a request for a domain that is a wildcard domain. This makes it clear that issue property applies when a wildcard domain is processed unless there is an issuewild property. Thanks, Peter On Jun 22, 2017, at 11:46 AM, Phillip via Public <[email protected] <mailto:[email protected]> > wrote: It is my understanding that the text as drafted prohibits issue of a wildcard certificate if the record set only contains issue records and issue of a non wildcard certificate if the record set only contains issuewild records. My reasoning is as follows: The relevant parts of the specification are: 4. Certification Authority Processing Before issuing a certificate, a compliant CA MUST check for publication of a relevant CAA Resource Record set. If such a record set exists, a CA MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA Resource Record set or (2) an exception specified in the relevant Certificate Policy or Certification Practices Statement applies. A certificate request MAY specify more than one domain name and MAY specify wildcard domains. Issuers MUST verify authorization for all the domains and wildcard domains specified in the request. 3. The CAA RR Type issue <Issuer Domain Name> [; <name>=<value> ]* : The issue property entry authorizes the holder of the domain name <Issuer Domain Name> or a party acting under the explicit authority of the holder of that domain name to issue certificates for the domain in which the property is published. issuewild <Issuer Domain Name> [; <name>=<value> ]* : The issuewild property entry authorizes the holder of the domain name <Issuer Domain Name> or a party acting under the explicit authority of the holder of that domain name to issue wildcard certificates for the domain in which the property is published. Section 4 specifies that the CA MUST NOT issue a certificate unless... 'is consistent' If we were to interpret 'is consistent' as meaning that the absence of an authorization record implies authorization than the whole specification becomes meaningless. The argument made that silence on issue permits issuewild would apply just as well to issue. Proposed resolution: I do not believe that the text as written is ambiguous. However, 'out of an abundance of caution and to eliminate any possible doubt, I propose an errata to read as follows: Existing text 4. Certification Authority Processing Before issuing a certificate, a compliant CA MUST check for publication of a relevant CAA Resource Record set. If such a record set exists, a CA MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA Resource Record set or (2) an exception specified in the relevant Certificate Policy or Certification Practices Statement applies. Replacement text 4. Certification Authority Processing Before issuing a certificate, a compliant CA MUST check for publication of a relevant CAA Resource Record set. If such a record set exists, a CA MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with and explicitly authorized by the applicable CAA Resource Record set or (2) an exception specified in the relevant Certificate Policy or Certification Practices Statement applies. -----Original Message----- From: Public [mailto:[email protected]] On Behalf Of philliph--- via Public Sent: Thursday, June 22, 2017 10:47 AM To: Gervase Markham <[email protected] <mailto:[email protected]> >; CA/Browser Forum Public Discussion List <[email protected] <mailto:[email protected]> > Subject: Re: [cabfpub] no CAA authorizations -- RFC 6844 It was certainly the intention that presence of an issue prevents issue of wildcard certs. I will re-read that section and report. Meanwhile, I have had some comment on the discovery fixup and will rev that. On Jun 22, 2017, at 8:34 AM, Gervase Markham via Public <[email protected] <mailto:[email protected]> > wrote: On 22/06/17 06:42, y-iida--- via Public wrote: <C> Likewise, when there are some relevant CAA records, but no CAA with "issuewild" property tag at all for a certificate domain, we will issue wildcard certificate for that domain. You should read RFC6844 carefully, but to my understanding, this is incorrect. If there is an "issue" property but no "issuewild" property, then the "issue" property also controls the issuance of wildcard certs. So you need to respect it in that case. Gerv _______________________________________________ Public mailing list [email protected] <mailto:[email protected]> https://cabforum.org/mailman/listinfo/public _______________________________________________ Public mailing list [email protected] <mailto:[email protected]> https://cabforum.org/mailman/listinfo/public _______________________________________________ Public mailing list [email protected] <mailto:[email protected]> https://cabforum.org/mailman/listinfo/public _______________________________________________ Public mailing list [email protected] <mailto:[email protected]> https://cabforum.org/mailman/listinfo/public
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
