Hello Naked, (replying to both lists from the more longer starting point; for readers of CBOR, see [1] for the original message)
> I am posting this as a complete outsider to any of the IETF stuff. > Apologies if that is not appropriate. It is very much appropriate; this is an open forum. > I recently wrote a specification for a new CBOR tag for flagging sensitive > values such as password, encryption keys, credit card information or GDPR > information, so that generic decoders may treat them differently. If I understand this right, the idea here is to tell a CBOR decoder that some data should be stored in a way that is only accessible by next stage processors that promise to also treat the data as confidential. I do not think that CBOR is the right place to do that. CBOR data does not arrive at a decoder out of thin air, but comes from some context -- it may be the decryption result of a COSE container, or it may be transported in some other protocol such as HTTP. If you can't trust memory managed by the CBOR decoder with the sensitive data, how can you trust the outer container that also needs to process the data? (For example, the HTTP library may log the payload containing the sensitive data before even handing it off to a CBOR decoder). If sensitive data needs special treatment, the container needs to treat all the unprocessed CBOR as sensitive -- and then a generic CBOR decoder can just as well treat all the items as sensitive. (After all, data of the size of the full CBOR document was just small enough to be treated as sensitive). I think the better approach is to ask the container what the security requirements are, and then process all content as sensitive until a later processor opts it out of such processing. > As a concrete example, a COSE symmetric key is a map with keys 1, 2 > and -1, and the -1 key contains the symmetric secret that should be > kept confidential. Without understanding the full semantics of the > message, it's impossible to know that the value for -1 is confidential > and the value for 1 is not. For this example, let's assume it comes from an encrypted COSE message. In an environment where there is a type level representation for sensitive data, the COSE decryption would already place the plaintext in such a sensitive data container. (It was encrypted, after all). The decoder then receives the data as sensitive and treats all fields as sensitive until further notice. When the parsed data is then processed into a COSE key data structure, that data structure might emit some warnings in case the -1 was not already marked as sensitive (but it is, in our example), and would free the value in 1 from the obligation to be treated as sensitive henceforth. Does this make sense for the concrete sensitive-data tools you have in mind? (From the tools you mention, like mlock, it would make sense with the decoders I use: parsing an mlock'd buffer would produce references into there, and only when processed into a concrete data structure that is already aware of which parts are sensitive, it is copied into other buffers). Best regards Christian [1]: https://mailarchive.ietf.org/arch/msg/cbor/-NHkVGXMXjYb1Rp6Onxd3yvwZ08 -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
signature.asc
Description: PGP signature
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
