Closed dimakuv closed 1 year ago
Thank you for the comment! I've created PR #7 that puts the proposed IDs in the supported list.
PR #7 looks good to me, I'm closing this issue.
(By the way, if you want the PR to auto-close the issue on GitHub, you should put Fixes #...
in the PR description -- then GitHub will close the issue automatically once PR is merged.)
I would like to settle on one point that was missing in #7 (sorry, forgot about it).
Here is the exerpt from my proposal:
I suggest this subset:
- ID=0,
RESERVED
-- defaults to sha-256
But #7 (and the current spec draft) doesn't mention this special case of ID=0. Can we assume anything about ID=0
? Or should implementations error out when they receive ID=0?
@shnwc @KB5201314 @jiazhang0 @kailun-qin What do you think?
I don't think it's a good idea to default the reserved ID=0
to a specific algo (and maybe even worse to default to sha-256
) for the interoperable RA-TLS spec. Normally the reserved is designed for possible future use and making assumptions on ID=0
in interoperable RA-TLS may incur potential compatibility issues.
Agree with @kailun-qin, the reserved ID=0
should not be a vaild hash algo ID.
I will wait for opinions from others, but in the meantime, I removed this assumption "ID=0 is SHA256" from Gramine: https://github.com/gramineproject/gramine/pull/1039
Agreed not to assign / redefine reserve ID=0 for sha256. Valid algorithm ID values must be used. As stated in IANA registry, value zero is "Reserved" and does not identify a hash algorithm.
Thanks, let me close this issue.
We state this: https://github.com/CCC-Attestation/interoperable-ra-tls/blob/a2c2323377007aa27b5ceb453a741a860e0245a0/docs/Interoperable-RA-TLS-cert-edvidence-formats.md?plain=1#L21
However, the
hash-entry
representation allows for multiple hash functions: https://www.iana.org/assignments/named-information/named-information.xhtmlBut e.g. Gramine uses mbedTLS (currently v3.3.0), which doesn't have
SHA-3
. Also, there are some exotic hash functions likeblake2s-256
which probably will never be supported by many crypto/TLS libraries.So I think for better interoperability, the Interoperable RA-TLS standard must explicitly state the minimal/preferred set of hash functions supported by any compliant implementation. I suggest this subset:
RESERVED
-- defaults tosha-256
sha-256
sha-384
sha-512