[Rats] Re: Iotdir early review of draft-ietf-rats-msg-wrap-04

["Smith, Ned" <[e-mail]>]

>> * Section 5.2: I wonder about the consequences of having two different CMW
>> specifications: one by the Trusted Computing Group (TCG) and the other in this
>> draft. I downloaded the TCG specification and found a reference to this draft.
>> Would it be possible for future versions of the TCG specification to reuse this
>> draft rather than creating a subset? Also, this draft states that the "CMW
>> extension" "MUST NOT be marked critical," whereas the TCG specification states
>> that the "tcg-dice-conceptual-message-wrapper extension criticality flag SHOULD
>> be marked critical." In summary, I wonder if these specifications can somehow
>> be synchronized.
>
>I think you are right, they should be fully aligned.
>Ned is the chair of the DICE WG in TCG, so he's the authoritative
>voice wrt this point.
Actually, I'm not the DICE WG chair.
The DICE WG was concerned with the potential for legacy X.509 parsers to grant access to resources even though the certificate extension contains attestation evidence, including evidence for layered DICE components (the components upon which the Target Environment depends for trustworthy operation). A non-DICE-aware parser's normal behavior is to succeed when ignoring noncritical extensions. Therefore, the CA issuing the cert can force a failure in legacy code that should be DICE aware (aka CMW aware) by marking it critical. 

A DICE-aware parser will already have logic that expects a DICE / CMW extension, hence, there's no need for the extension to be critical. The normative language allows for use of the criticality flag when it makes sense and to avoid using it when it makes sense also. Whether the two specs align on SHOULD or SHOULD NOT seems equivalent to achieving the goal.