Hi! Section 2.2.1. JSON Web Key Representation <https://www.ietf.org/archive/id/draft-ietf-cose-bls-key-representations-06.html#name-json-web-key-representation> of draft-ietf-cose-bls-key-representations-06 defines that the private key shall be encoded in little-endian byte order (the subsequent section for COSE_Key does too):
The parameter "d" MUST be present for private key representations whose > value MUST contain the little-endian representation of the private key > base64url encoded without padding as defined in [RFC7515] Appendix C. This > parameter MUST NOT be present for public keys. Is this right? The JSON Web Key Types registry <https://www.iana.org/assignments/jose/jose.xhtml#web-key-types> refers to RFC 7518 <https://www.rfc-editor.org/rfc/rfc7518.html#section-6.2> for the definition of the "EC" key type, and it in turn refers to SEC 1 <https://www.secg.org/sec1-v2.pdf> for the encoding of the private key "d", and I believe the procedure in section 2.3.7 of SEC 1 encodes integers in big-endian byte order (most significant byte first). Big-endian appears to be the general convention for both scalars and point coordinates throughout other BLS specs too, including draft-ietf-lwig-curve-representations-23 and draft-irtf-cfrg-bbs-signatures-08. Was "d" meant to be big-endian in draft-ietf-cose-bls-key-representations-06 too? Emil Lundberg Staff Engineer | Yubico <http://www.yubico.com/>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
