Re: [Fud] A few questions / observations

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

See additional comments inline below.
-Ned

From: Brendan Moran <[e-mail]>
Date: Tuesday, September 26, 2017 at 1:54 PM
To: "Smith, Ned" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Fud] A few questions / observations

Hi Ned,
I’ve placed my comments inline.

Thanks for your feedback!

Best Regards,
Brendan


On 15 Sep 2017, at 16:29, Smith, Ned <[e-mail]<mailto:[e-mail]>> wrote:
[stuff deleted]
•         Why was ASN.1 selected as the encoding format? (Why not COSE?)

ASN.1 was used for a few reasons.

  1.  It is the default format for certificates. Most tools use DER rather than COSE for packing certificates, so this reduces the number of parsers in the target. Where interwork with HSMs is involved, using a format the HSM supports is beneficial.
[nms] HSMs are a computing environment that is constrained to operations involving mostly cryptographic and key exchange operations. Your observation is that ASN.1 is the data model language of choice by the HSM community. I agree that is the correct choice for that constrained environment. However, it is also the case that there are other environments that have chosen different data model languages and operate in a constrained environment. COSE, JSON and XML are commonly available parsers in these other environments. The logic that argues for propagation of ASN.1 because the HSM “constrained environment already supports it and therefore avoids ‘bloat’ of an additional parser” can be used to argue the other side as well. Since the constrained device already supports an alternative (e.g. COSE, JSON, XML…) and the dependence on ASN.1 represents additional overhead to the constrained environment. In cases where both an application processor and HSM environments exist it makes sense to use one or the other or both, but not introduce a third. I’m not taking a strong position on ASN.1 vs. COSE (or some other alternative) except to observe that it shouldn’t be the objective of FUD to advocate a particular data model language over another, but rather should try to accommodate the data model language choices of the constrained environments for which this RFC hopes to be relevant. It should be noted that most data model languages that embrace security typically make accommodation for a security DML by encapsulating PKCS and X.509 - implying ASN.1/BER/DER support exists somewhere in the platform. However, support for PKCS/X.509 should translate to general and broad support for anything ASN.1 as the range of objects known to PKCS and X.509 is typically rather small.
My opinion is the environment that generates, distributes and installs software updates isn’t entirely HSM or application framework (e.g. LWM2M). Therefore, it is reasonable to expect multiple encodings may be required.

  1.  PCKS7 / CMS / RFC5652 are widely supported. For example, OpenSSL’s smime command handles CMS signing/validation directly. This makes the custom tooling required simpler. This will also, hopefully, improve compatibility with existing HSMs
[nms] It is also the case that constrained environments may not have chosen OpenSSL, but instead rely on embedTLS, tinyDTLS or other library that doesn’t have the same dependency on SMIME. Compatibility with HSMs is important, but the question for FUD potentially is to understand how much of the RFC’s solution should be computed within the HSM vs. the host processing environment or an available TEE.

  1.  Direct code generation. In a scenario where the parser does not create a document object model, but extracts or validates specific fields, ASN.1 provides a grammar that makes it possible to generate a parser programmatically.
[nms] It is true that the ASN.1 tools ecosystem is mature. ASN.1 has been around for a while. That however has not prevented the invention and proliferation of alternative data model languages. If the argument is that ASN.1 will eventually win, we just need to wait longer, then I respectfully disagree. The ecosystems supporting alternative DMLs may be less mature, but they are evolving quickly.

  1.  The meaning of “length” for composite types. In DER, the length of a field is unambiguous. It is always the length, in bytes, of the contained object. This allows a parser that understands the document being parsed to skip large chunks of a deeply nested tree. In CBOR, the “length” of an array or map is the number of elements it contains. This makes it impossible for the parser to “skip” anything. It has to parse the entire structure. It is possible to circumvent some of these limitations using tagging, in particular tag 24 (encoded CBOR data item), but this has the downside of breaking translatability to JSON, which is a key advantage of CBOR. Consistent TLV representation makes parsing in a constrained environment offers a notional performance improvement, but this is minor and may not play out in practice.
[nms] The question to ask is whether this sort of parsing inefficiency is a larger pain point than having to do semantic mapping of structures that already are meaningful in the context of the application environment that is performing the update. In such a case, ASN.1 may be the greater pain point.

Never the less, I think that CBOR/COSE would be perfectly serviceable for this use. I’m not even certain that ASN.1 can’t be used as a schema for CBOR (see 3 above). That being the case, I can see a case for DER manifests with CMS, and CBOR manifests with COSE.

            [nms] Given COSE encodes X.509 and PKCS structures it would seem the designers anticipated interoperation with HSMs, at least at the key and certificate levels of abstraction. But given COSE defines a cryptographic message syntax of its own, it anticipates relevance in messaging processor environments. My understanding of HSMs are that they don’t anticipate being used as message processors. My question may be a bit more philosophical. Do the authors of the RFC regard the exchange of SW updates and their manifests as being fundamentally an HSM workload or something else; such as device management or possibly a distributed compute?

Thx,
Ned


_______________________________________________
Fud mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/fud

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.