search

rfcs / crypto-conditions

Composable cryptographic conditionals (signatures, hashes)
https://tools.ietf.org/html/draft-thomas-crypto-conditions-03
22 stars 12 forks source link

Subtypes not including root type #17

Open stevenroose opened 7 years ago

stevenroose commented 7 years ago

The spec says this:

Subtypes is a bitmap that indicates the set of types an implementation must support in order to be able to successfully validate the fulfillment of this condition. This is the set of types and subtypes of all sub-crypto-conditions, recursively excluding the type of the root crypto-condition.

If the root type is excluded, though. The subtypes set no longer represents all the types of the sub-conditions. In that case it's more like an "extra required types" field in that case.

For implementers it's only a minor issue (it means adding all subtypes recursively and removing the root type again in case it's also a subtype), but it's a little bit confusing.

adrianhopebailie commented 6 years ago

This is just a space optimization in the encoding. It adds no value to have the type in two places.

stevenroose commented 6 years ago

It is a bitmap, though, so it will most likely not increase the size of the encoding.

But it feels weird that a condition that has subconditions of types A, B and C will have a subtypes set either (A, B, C) or (A, B) or (A, C) or (B, C) depending of its own type. Even though the subconditions are the same.

I don't see any direct problems with that, though. Other than not being very intuitive.