> The duplicate 0x0403 seems a bug. Any implementor care to clarify The duplicate 0x0403 is deliberate, because Deterministic and Non-Deterministic ECDSA have different References (RFC6979 and FIPS186-4).
At one point we planned to only permit Deterministic ECDSA, but discussion on this list led us to permit both Deterministic and Non-Deterministic ECDSA (see https://github.com/google/certificate-transparency-rfcs/pull/261); although note that in Section 11.4 we still recommend Deterministic ECDSA. > As for why this registry, I assume it’s to be a subset of the TLS registry > “just because” Are there any other reasons? Mirja Kühlewind asked the same question (see the Last Call COMMENTs): "7) sec 10.3: Couldn’t you use the TLS SignatureScheme Registry directly (instead of forming an own registry)?" I responded in https://github.com/google/certificate-transparency-rfcs/pull/316: 'It makes sense to synchronize the signature algorithm values we use with the TLS SignatureAlgorithm registry, because our data structures are defined according to the conventions laid out in the TLS RFC. However, I don't think it's a good idea to use the TLS SignatureAlgorithm registry directly. In 6962-bis, we've taken steps to make log artifacts smaller (compared to RFC6962); related to that, we've removed the option of logs being permitted to use RSA keys/signatures. https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16 permits RSA, and several other signature algorithms that we don't wish to permit or recommend (i.e. "anonymous", DSA, GOST, and "Reserved for Private Use").' ________________________________ From: Trans <[email protected]> on behalf of Salz, Rich <[email protected]> Sent: 28 March 2021 21:23 To: [email protected] <[email protected]> Subject: [Trans] duplicate 0x0403 in signature scheme registry CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. >Section 10.3 > >I'm confused by this registry. Is the SignatureScheme value required to >come from/match the TLS SignatureScheme registry? Is anything going to >key off that value or otherwise use the value in a protocol data >structure? (Why are there two entries for 0x0403?) The duplicate 0x0403 seems a bug. Any implementor care to clarify? As for why this registry, I assume it’s to be a subset of the TLS registry “just because” Are there any other reasons?
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
