Опять же, все в rfc. Логика следующая: Если в будущем добавится какой-то тип записи, которого нет в данном rfc, как пример приводится новое поле tbs, которого нет в этом rfc. У CA которое знает только о существовании rfc6844 и не знает что делать с tbs есть два варианта - если critical flag у данного поля выставлен в 0, оно может его проигнорировать и все равно выдать сертификат, если остальные условия соблюдены (issue "ca.example.net; policy=ev") или если critical flag выставлен 128, то не выдавать сертификат.

$ORIGIN example.com
.       CAA 0 issue "ca.example.net; policy=ev"
.       CAA 128 tbs "Unknown"

Так как issue/issuewild/iodef определены в этом rfc, то особого смысла ставить 128 нет.
Либо CA должны поддерживать эти записи и соблюдать их, либо они вообще пока на CAA запись не смотрят.

При некорректной записи, например CAA 0 issue "incorrect record" CA поддерживающий этот rfc не должен выдать сертификат в любом случае.
Я не уверен как оно должно реагировать на CAA 0 или 128 issue "ca.example.net; unknown=blabla", если не понимает что делать с unknown=blabla, в rfc написано, что все дополнительные параметры могут быть site-specific, т.е. определяться CA и поэтому не оговариваются в данном rfc. Можно предположить, что оно должно тоже отказывать в выдаче и наверно опять же независимо от значения critical flag.