That is correct. Marking an attribute critical is basically the ‘break backwards compatibility’ hammer. The hope is that it never needs to be used. But it would be a really bad idea not to have it.
I would have liked to change the name as people misunderstand the PKIX criticality flag as meaning ‘important’ rather than ‘reject this certificate completely if you don’t understand this attribute’. Hence the path constraints lunacy. Unfortunately that was not practical. > On Mar 15, 2017, at 2:42 PM, Ryan Sleevi via Public <[email protected]> > wrote: > > > > On Wed, Mar 15, 2017 at 2:17 PM, Rick Andrews via Public <[email protected] > <mailto:[email protected]>> wrote: > Gerv, > > There's another "bug" that I hope you'll consider clarifying regarding iodef > records. > > Part of the ballot says "CAs MUST process the issue, issuewild, and iodef > property tags" > > Another part says " CAs... SHOULD dispatch reports of such issuance requests > to the contact(s) stipulated in the CAA iodef record(s), if present." > > I assume you meant that CAs MUST dispatch reports to the contacts in iodef > records, otherwise "processing" an iodef tag is the same as ignoring it. > > Not quite. > > A compliant CAA implementation MUST understand the semantics of these fields > and not break if they're marked critical. However, that does not mean an > implementation must do what is in that field - for example, sending an iodef. > > This is no different from X.509v3, so it should be very easy for CAs to > understand the concept. > _______________________________________________ > Public mailing list > [email protected] <mailto:[email protected]> > https://cabforum.org/mailman/listinfo/public > <https://cabforum.org/mailman/listinfo/public>
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
