If the issue or issuewild records indicate that I am permitted to issue the cert, it seems excessive to reject because I can't parse the iodef record. As a permitted CA, I don't need to do anything with the iodef record.
Your intent is probably to catch the error and alert the domain owner, so that they can fix it in case a non-authorized CA tries to issue a cert for the domain. While I can see the advantage of that, I'm not sure that this action was intended by the RFC or Gerv's ballot. How do others interpret it? -Rick From: Ryan Sleevi [mailto:[email protected]] Sent: Friday, March 17, 2017 10:26 AM To: Rick Andrews <[email protected]> Cc: CA/Browser Forum Public Discussion List <[email protected]>; Gervase Markham <[email protected]> Subject: Re: [cabfpub] Results on Ballot 187 - Make CAA Checking Mandatory Fail to issue. On Fri, Mar 17, 2017 at 1:25 PM, Rick Andrews <[email protected]> wrote: But what am I supposed to do if I can’t parse the syntax? From: Ryan Sleevi [mailto:[email protected]] Sent: Friday, March 17, 2017 10:22 AM To: CA/Browser Forum Public Discussion List <[email protected]> Cc: Gervase Markham <[email protected]>; Rick Andrews <[email protected]> Subject: Re: [cabfpub] Results on Ballot 187 - Make CAA Checking Mandatory On Fri, Mar 17, 2017 at 1:18 PM, Rick Andrews via Public <[email protected]> wrote: Gerv, I would suggest simply removing "iodef" from "CAs MUST process the issue, issuewild, and iodef property tags". To me, the word "process" means to take some kind of action, as we must do with issue and issuewild tags. From what others have said, if the iodef record isn't marked critical, I can ignore it, and if it is marked critical, I can ignore it as long as I recognize it as an iodef record. I wouldn't call that "processing" the record. That's not quite correct. If it's marked critical, you must still understand how to parse the syntax, and ensure it is something you actively understand, even if you do not report. _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
