[cabfpub] "[UNVERIFIED SENDER]Re: no CAA authorizations -- RFC 6844
Phillip
philliph at comodo.com
Thu Jun 22 20:25:49 UTC 2017
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:public-bounces at cabforum.org] On Behalf Of Phillip via Public
Sent: Thursday, June 22, 2017 4:13 PM
To: 'Ryan Sleevi' <sleevi at google.com>; 'Peter Bowen' <pzb at amzn.com>; 'CA/Browser Forum Public Discussion List' <public at cabforum.org>
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:sleevi at google.com]
Sent: Thursday, June 22, 2017 3:57 PM
To: Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com> >; CA/Browser Forum Public Discussion List <public at cabforum.org <mailto:public at cabforum.org> >
Cc: Phillip <philliph at comodo.com <mailto:philliph at comodo.com> >
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 <public at cabforum.org <mailto:public at cabforum.org> > 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 <public at cabforum.org <mailto:public at cabforum.org> > 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:public-bounces at cabforum.org] On Behalf Of philliph---
via Public
Sent: Thursday, June 22, 2017 10:47 AM
To: Gervase Markham <gerv at mozilla.org <mailto:gerv at mozilla.org> >; CA/Browser Forum Public Discussion
List <public at cabforum.org <mailto:public at cabforum.org> >
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
<public at cabforum.org <mailto:public at cabforum.org> > 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
Public at cabforum.org <mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
Public at cabforum.org <mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
Public at cabforum.org <mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
Public at cabforum.org <mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170622/97926171/attachment-0002.html>
More information about the Public
mailing list