Gerv,


What did you intend by “adverse CAA records”?   If a CA runs across a CAA 
record that identifies other CAs that are authorized to issue but not them, I 
don’t see a reason to report on that to CABF as you  suggested in the proposed 
ballot.  But,  I think CAs SHOULD log and then  report other types of failures, 
such as CAA records with critical tags that are not generally understood.  The 
RFC mentions this as a possible abuse vector which we should be sure to track.  
I’d define “adverse CAA record” as one that fails for reasons other than not 
listing the CA in issue or issuewild tags.



If we create a new section in the BRs for CAA (maybe section 3.2.2.8), do we 
need to update the EVGL with a reference to this so EV certificates need to 
comply, or is everything in the BRs also assumed for EVGL?  I’m certainly not 
the expert on how these 2 specs work together, but it seems like the EVGL 
references the applicable sections in the BRs where necessary and that if it’s 
not referenced it’s not a requirement.  I’m probably wrong.  If everything is 
assumed to apply, then why do the EVGLs reference sections as applicable?


From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham 
via Public
Sent: Thursday, January 12, 2017 9:25 AM
To: CABFPub <public@cabforum.org>
Cc: Gervase Markham <g...@mozilla.org>
Subject: [cabfpub] Draft CAA motion (3)


CAs MUST document issuances that were prevented by an adverse CAA record in 
sufficient detail to provide feedback to the CAB Forum on the circumstances, 
and SHOULD report such requests to the contact(s) stipulated in the CAA iodef 
record(s), if present. CAs are not expected to support URL schemes in the iodef 
record other than mailto: or https:.


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

Reply via email to