[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-0003.html>


More information about the Public mailing list