I’d be glad to endorse this important clarification.

 

-Tim

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Corey Bonnell 
via Public
Sent: Wednesday, January 24, 2018 2:46 PM
To: public@cabforum.org
Subject: [cabfpub] Draft ballot 219: Clarify handling of CAA Record Sets with 
no "issue"/"issuewild" property tag

 

Hello,

I reported an ambiguity in the CAA RFC (RFC 6844) two weeks ago on the IETF 
LAMPS WG mailing list: 
https://www.ietf.org/mail-archive/web/spasm/current/msg01104.html. Tim and 
Quirin responded to the initial email (links to their responses are at the 
bottom of that page) with excellent feedback and comments.

 

This issue was further discussed on last week’s Validation WG call, where it 
was decided that this ambiguity be resolved with a “two-pronged” approach. 
Specifically, to address the ambiguity in the short term, we are proposing some 
clarification in the wording of BR section 3.2.2.8 to allow for CAA processing 
consistent with the intent of the RFC. To address this ambiguity in the long 
term, a IETF erratum will be filed to clarify the wording in RFC 6844-bis.

 

I am looking for two endorsers for this Draft ballot.

 

The following motion has been proposed by Corey Bonnell of Trustwave and 
endorsed by the following CA/B Forum member representatives: XXXX and YYYY to 
clarify handling of CAA Record Sets with no "issue"/"issuewild" property tag as 
described in the Ballot.

 

Purpose of this ballot:

 

RFC 6844 contains an ambiguity in regard to the correct processing of a 
non-empty CAA Resource Record Set that does not contain any issue property tag 
(and also does not contain any issuewild property tag in the case of a Wildcard 
Domain Name). It is ambiguous if a CA must not issue when such a CAA Resource 
Record Set is encountered, or if such a Resource Record Set is implicit 
permission to issue.

 

Given that the intent of the RFC is clear (such a CAA Resource Record Set is 
implicit permission to issue), we are proposing the following change to allow 
for CAA processing consistent with the intent of the RFC.

 

-- MOTION BEGINS --

This ballot modifies the “Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates” as follows, based upon Version 1.5.4:

 

In section 3.2.2.8, add this sentence:

CAs MAY treat a non-empty CAA Resource Record Set that does not contain any 
issue property tags (and also does not contain any issuewild property tags when 
performing CAA processing for a Wildcard Domain Name) as permission to issue, 
provided that the CAA Resource Record Set does not contain any unrecognized 
property with the critical flag set.

 

to the end of this paragraph:

When processing CAA records, CAs MUST process the issue, issuewild, and iodef 
property tags as specified in RFC 6844, although they are not required to act 
on the contents of the iodef property tag. Additional property tags MAY be 
supported, but MUST NOT conflict with or supersede the mandatory property tags 
set out in this document. CAs MUST respect the critical flag and not issue a 
certificate if they encounter an unrecognized property with this flag set.

 

-- MOTION ENDS --

 

Thanks,

Corey

 

 

Corey Bonnell

Senior Software Engineer

t: +1 412.395.2233

 

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com

 

2017 Best Managed Security Service Winner – SC Media

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Reply via email to