-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request for clarification: array length and mixed encoding #55
Comments
I would similarly ask for cmw to itself contain cmw-collection, since something producing evidence could itself be amassing evidence, and you end up with a tree rather than having to flatten it and potentially have conflicting keys. |
Is this different from cmw-collection containing a cmw / cmw-collection? |
The I-D describes an ASN.1 encoding that distinguishes between cbor and json.
Is the request to give the same attention to the CDDL description? |
Not exactly, since I'm asking about mixed representation across values. If I'm accumulating evidence from A and B, where A produces a CBOR CMW, and B produces a JSON CMW, I would rather not do a full translation from one to the other for fear of corrupting the data and taking too much processing time, so I would like to produce a cbor-encoded map {"A" => cbor bytes, "B" => json string}. If A were to produce a CMW collection instead of CMW, since it's an aggregator itself, then I'd like to not have to open it up and re-encode the key => value mappings in the overall CMW collection, since I might have conflicting keys. I also am not particularly sure what |
See https://www.ietf.org/archive/id/draft-ietf-cbor-cddl-control-02.html |
[ challenging assumptions 😺 ] Why don't you let the repackager do the repackager and the providers do the providers? I.e., the binaries return their evidence payload plus the associated media type, and the daemon puts together the CMWs and wraps them in a CBOR or JSON collection. |
The "plus" there is the problem then, since now I need to specify an output format for the binaries that isn't the standard CMW / CMW-collection. What you're suggesting to me sounds like "binaries return their cmw-array value and cmw-array content type in some format for the repackager to wrap as a CMW." The third component of the cmw-array is just lost or somehow inferred? No, that "some format" to me is a CMW. I don't want plugin authors to have to implement both serialization formats as requested by the repackager to fit the final output type because that just becomes bloat. To be parsimonious with resources due to static linking overhead, some evidence collectors may want to produce an output that is already a collection of multiple evidence formats. The cc-trusted-api and go-tpm-tools clients collect multiple evidence formats already, so changing the output format for the collection is a nicer thought than splitting each format into a different binary. We therefore have either a CMW or some sort of CMW collection as allowed response types. What format do we specify? I could say it's a mixed format of JSON or CBOR CMWs given as a definite length array of definite length octet strings for the repackager to decode and repackage into a CMW-collection of its own, but the entry labels would need to be generated somehow.
Part of the assumption to be fair is that there is going to be a standard evidence request format and evidence response format, and the response doesn't necessarily need to be a CMW or CMW collection, though it'd be nicer if it were–the collection CMW / CMW-collection output of either CBOR or JSON to repackage as a single CMW collection leads to the relabeling problem I described in OP. In JSON, the label could be the provider's name followed by the index of the position in the output, and in CBOR it could just be the index of the position in the output added to the current index to the output CMW–the label is thus very different. The text describing the labels suggests that they aren't arbitrary but could hold semantic meaning like a mnemonic. I don't know how that works for the integer format, but it's not explicitly specified to be irrelevant:
The goal of being for either an aggregate attester OR a CMW aggregator should account for the multiple allowed wire formats. I don't see that without either a. a tree format for CMW-collection with mixed representation |
The daemon and its plugins all live under the same system roof, isn't it? Can't each binary return evidence in the native format using something equivalent to: int collect_evidence(
const uint8_t nonce[64],
uint8_t **evidence, size_t *evidence_sz,
struct media_type *mt
); |
this one is trivial:
I am afraid this one isn't. |
+1 |
An alternative (put forward by @nedmsmith) is to squash the productions:
|
I still don't see how nesting the trees is going to help if some output trees are JSON and others are CBOR and we need to aggregate into a single format. If we can register a tag that implies the bytes within constitute a JSON CMW-collection, then we can say
A tag in CBOR can swap to JSON, and a baes64-string in JSON can be interpreted as a serialized CBOR cmw-collection |
You are right, it doesn't help with mixtures of formats.
I am not sure that will work as written, but the gist is clear: we need tunnels :-) And given the tunnelling is symmetrical we might use a common shape by registering a couple of new media types (since tags are not a JSON thing):
where:
and the tunneling procedures are: 🚞 JSON-to-CBOR CMW 🚞
🚞 CBOR-to-JSON CMW 🚞
|
Why does the JSON to CBOR tunnel need to be base64 encoded? The cmw-array value type is bytes, not text. |
I made it like that purely for aesthetic/symmetry reasons. |
The symmetry breaks the current cmw-array schema and adds encoding bloat for aesthetics, so I'd recommend keeping it to bytes. |
To be clear, I have no strong opinions. We could do:
and change the tunnelling procedure accordingly. |
note that the
WFM |
Is the idea for this to not match cmw-array and instead be a different alternate? That changes the parsing complexity from LL(1) to LL(2), no? I would think we have this be a media type for cmw-array and a new cm-type bit for "tunnel"? |
Relevant to this discussion, one of @carl-wallace's WGLC comments in https://mailarchive.ietf.org/arch/msg/rats/xY2mwu790UOGnhFAUduGj5ddo3Y/
|
The complete (loose) grammar I have in mind is this:
|
I think we do have to specify that the media type in a cmw-array cannot be "application/cmw-j2c-tunnel" (conversely for JSON), OR we have to say that |
Yes, absolutely. The two tunnel media types are effectively magic numbers. |
An alternative would be to use as a magic number something that doesn't parse as a media-type string (i.e., anything This would also spare us from registering two mostly useless new media types :-) |
* merge collection in the top-level CMW production * rework the X.509 extension (CMWCollection -> CMW) * remove special-casing collection in all IANA registrations * add bi-directional tunnelling between JSON and CBOR serialisations * rework CDDL assembly & test * add new examples Fix #55 Signed-off-by: Thomas Fossati <thomas.fossati@linaro.org>
I'm noodling through the idea of a modular evidence collection daemon that just runs installed binaries in a certain location and assembles a cmw-collection together to send off, and I'm wondering how much interpretation of the output it would need, assuming all the binaries output a legal CMW of either CBOR or JSON encoding.
When JC<> is used, it's only when the CDDL pun breaks down and you need base64 encoding for binary. If you have your cmw-collection as a CBOR map, and we can use, say, the basename of the evidence collection binary to key the result, but the result is just bytes that are either CBOR or JSON, that doesn't seem to fit into the "cmw is either CBOR or JSON".
It seems that certainly a JSON cmw-collection that contains a CBOR-encoded cmw does not parse unless you're allowed to wantonly swap your interpretation of the CDDL as for JSON or CBOR as you see fit (say with the decapsulation algorithm), given that
cmw
doesn't have a base64 encoded string alternate to store a CBOR-encoded cmw.Can we say that
should be
I'm unsure if the
.cbor
control operator is allowed to be applied to a base64-string technically it's for byte strings and since "one can use CDDL with JSON by limiting oneself to what can be represented in JSON. Roughly speaking, this means leaving out byte strings"I don't think we can use
bytes .cbor cmw
without inserting the major type byte 0x04 before the output of any of the evidence modules, so do we just define a.feature cmw-decap
to apply the decap algorithm to arbitrary bytes instead of this JC stuff?The text was updated successfully, but these errors were encountered: