Draft: draft-ietf-rats-architecture

Commentary: This sentence : it 's quite hard to digest . But more generally , the motivating use case ( OPC UA ) is slightly convoluted , and I 'm wondering whether it is really needed ? But assuming it were , the exposition needs to be improved to present a clear and compelling case . 
 I can not speak for the applicability of OPC UA here . It seems to be an item in an already long list . I actually wonder more why EAP is not in there to add some diversity . Having said that , how about : 
 Looks much better , thanks ! Elaborating a bit further : " Retrofitting already deployed protocols with remote attestation requires adding RATS conceptual messages to the existing data flows . This must be done in a way that does n't degrade the security properties of the protocol and should use the native extension mechanisms ( if available ) . For example , if an authentication protocol ( e.g. , the TLS handshake ) has to be extended with remote attestation capabilities , attestation Evidence may be embedded in an ad - hoc X.509 certificate extension , or into a new TLS Certificate Type . " 
 You had me at " retro " . In my kickstarting proposal , I barged on with " DER " , which is now gone but now there are TLS and Certificate Type for elaboration . None , one , or all ? I do n't want to overload that paragraph with arbitrary examples . Unfortunately , now these start to seem arbitrary to me . What is the reasoning for choosing examples here , actually ? 
 These are both existing mechanisms : the first ( new cert extension ) is , the second ( new TLS cert type ) is . I dropped DER as it 's a necessity when using x.509 certs , and looked redundant . 
 That actually helped me a lot ! Maybe we should pull these reference in ? I am aware that it is sometimes better to shy away from specifica , but in this case I think it would help the reader to be more specific . Thoughts ? 
 Doing a background check on OP CUA , I 've found that the is not open , and that there are only two research papers that talk about adding attestation to the existing model : ( 2020 ) and ( 2017 ) . This paucity of related content makes its presence as a " demo " use case a bit brittle . I suggest we remove it . DICE and TLS - CWT should be enough .
Paragraph (version A):
In this diagram, the protocol between Attester and a Relying Party
can be any new or existing protocol (e.g., HTTP(S), COAP(S), ROLIE
RFC8322, 802.1x, OPC UA, etc.), depending on the use case.  Such
protocols typically already have mechanisms for passing security
information for purposes of authentication and authorization.  Common
formats include JWTs RFC7519, CWTs RFC8392, and X.509 certificates.
Paragraph (version A):
To enable remote attestation to be added to existing protocols,
enabling a higher level of assurance against malware for example, it
is important that information needed for appraising the Attester be
usable with existing protocols that have constraints around what
formats they can transport.  For example, OPC UA OPCUA (probably the
most common protocol in industrial IoT environments) is defined to
carry X.509 certificates and so security information must be embedded
into an X.509 certificate to be passed in the protocol.  Thus, remote
attestation related information could be natively encoded in X.509
certificate extensions, or could be natively encoded in some other
format (e.g., a CWT) which in turn is then encoded in an X.509
certificate extension.
Paragraph (version A):
Especially for constrained nodes, however, there is a desire to
minimize the amount of parsing code needed in a Relying Party, in
order to both minimize footprint and to minimize the attack surface
area.  So while it would be possible to embed a CWT inside a JWT, or
a JWT inside an X.509 extension, etc., there is a desire to encode
the information natively in the format that is natural for the
Relying Party.
Paragraph (version B):
In this diagram, the protocol between Attester and a Relying Party
can be any new or existing protocol (e.g., HTTP(S), COAP(S), ROLIE
RFC8322, 802.1x, OPC UA OPCUA, etc.), depending on the use case.
Paragraph (version B):
Such protocols typically already have mechanisms for passing security
information for purposes of authentication and authorization.  Common
formats include JWTs RFC7519, CWTs RFC8392, and X.509 certificates.
Paragraph (version B):
Retrofitting already deployed protocols with remote attestation
requires adding RATS conceptual messages to the existing data flows.
This must be done in a way that doesn't degrade the security
properties of the system and should use the native extension
mechanisms provided by the underlying protocol.  For example, if the
TLS handshake is to be extended with remote attestation capabilities,
attestation Evidence may be embedded in an ad hoc X.509 certificate
extension (e.g., TCG-DICE), or into a new TLS Certificate Type (e.g.,
I-D.tschofenig-tls-cwt).
Paragraph (version B):
Especially for constrained nodes there is a desire to minimize the
amount of parsing code needed in a Relying Party, in order to both
minimize footprint and to minimize the attack surface area.  So while
it would be possible to embed a CWT inside a JWT, or a JWT inside an
X.509 extension, etc., there is a desire to encode the information
natively in the format that is natural for the Relying Party.