rfcs / crypto-conditions

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

Document how fields in the test vectors have to be interpreted #10

Open stevenroose opened 7 years ago

stevenroose commented 7 years ago

Some binary values are hexadecimal, this can be spotted rather easily. Some, however, appear to be Base64, looking at the code, but they could just as well be UTF8.

Please document this somewhere.

stevenroose commented 7 years ago

Oh, also, is it base64 or base64url? Apparently the modulus and signature fields of a RSA-SHA-256 fulfillment are not valid base64. I'm out of inspiration for testing other encodings.

stevenroose commented 7 years ago

I think I found out it's base64url.

justmoon commented 7 years ago

Yes, this should be documented.

stevenroose commented 7 years ago

Is there a reason why both hexadecimal and base64url are used? I might be OK with making a PR converting them all to the same format, whichever one you prefer.

I think hex makes the most sense, it gives you a clear idea about the size of the data and a bit about the contents.

On 11 Apr 2017 7:07 PM, "Stefan Thomas" notifications@github.com wrote:

Yes, this should be documented.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rfcs/crypto-conditions/issues/10#issuecomment-293330706, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0F3Eq85lCGjqcIJ1VMm6OcBpOZZHJhks5ru7M6gaJpZM4M5wiJ .

justmoon commented 7 years ago

Yeah, there is a reason both are used. IIRC, the JSON format for conditions is defined in the cryptoconditions spec and specifies base64url for efficiency.

Outside of the standardized JSON representation of the cryptoconditions I used hex because it makes comparing expected vs actual a lot simpler.

This is from memory, so apologies if I'm misremembering.