[cabfpub] CAA "issue" addresses wildcard issuance ? (was: CAA records on opera.com)

[Phillip Hallam-Baker]

Remember that CAA records grant permission. The reason that the issuewild record was added is that some people said they wanted to make issue of wildcard certs more restrictive than issue of non-wildcard or enforce a ‘no wildcard certs’ policy.

The intention was that the issue property would cover wildcard certs unless there was a specific statement about wildcard certs.

Perhaps we should put in a clarifcatory errata.



On Nov 25, 2013, at 6:21 PM, Rob Stradling <rob.stradling at comodo.com> wrote:

> Section 5.2 says nothing about wildcards and non-wildcards.  It talks about the issuance of certificates.
> 
> In the first sentence of section 5.3, "same syntax and semantics...except...only" can't make sense if issue properties never apply to wildcards.  To me, that clearly states that issuewild is a subset of issue, not a separate set.
> 
> Section 5.3 also says...
>     "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."
> ...which implies, surely, that if zero issuewild properties are specified, then all issue properties should _not_ be ignored when processing a request for a domain that is a wildcard domain.
> (If it were the case that issue properties were never applicable to wildcard domains, then that entire sentence would be completely redundant).
> 
> But perhaps it would've been useful if Section 5.2 had explicitly said something like:
>  "The issue property always applies to non-wildcard domains.  Also, except where noted in Section 5.3, the issue property also applies to wildcard domains".
> 
> On 25/11/13 20:29, Ryan Sleevi wrote:
>> On Mon, Nov 25, 2013 at 10:06 AM, =JeffH <Jeff.Hodges at kingsmountain.com> wrote:
>>> Rob Stradling wrote..
>>>  >
>>>  > You're currently serving an "issue" record and an "issuewild" record,
>>>  > both for "digicert.com".
>>>  >
>>>  > That "issuewild" record is redundant.
>>>  >
>>>  > If there is no "issuewild" record present, the "issue" record(s) are
>>>  > applicable to both non-wildcards and wildcards.
>>> 
>>> Hi Rob & Phil,
>>> 
>>> I've been looking through rfc6844 to try to parse out the above assertion
>>> that if the issuer is the same for both an "issue" record and an "issuewild"
>>> record, that the "issuewild" record is redundant.
>>> 
>>> This appears to be implied by section "5.2. CAA issue Property" in rfc6844,
>>> but not explicitly stated.
>>> 
>>> Am I missing something in rfc6844 that explicitly states that an "issue"
>>> record applies to issuance of all types of certs by the stated issuer?
>>> 
>>> If I am not missing something and others also interpret the spec similarly
>>> -- i.e., that "issue" alone doesn't apply to wildcard cert issuance -- then
>>> I'm a bit concerned about CA tooling implementors getting this correct on
>>> their end.
>>> 
>>> thanks,
>>> 
>>> =JeffH
>>> 
>> 
>> I'll point out that this also tripped us up while deploying -  Google
>> also deployed both issue and issuewild, and Comodo also needed to
>> point this out.
>> 
>> It's definitely implied by the first paragraph of 5.2, but the
>> ambiguity in relationship to 5.3 was indeed confusing.
>> 
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
> Office Tel: +44.(0)1274.730505
> Office Fax: +44.(0)1274.730909
> www.comodo.com
> 
> COMODO CA Limited, Registered in England No. 04058690
> Registered Office:
>  3rd Floor, 26 Office Village, Exchange Quay,
>  Trafford Road, Salford, Manchester M5 3EQ
> 
> This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.  If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.