Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

public key as octet string #4

Open
csosto-pk opened this issue Aug 9, 2022 · 5 comments
Open

public key as octet string #4

csosto-pk opened this issue Aug 9, 2022 · 5 comments

Comments

@csosto-pk
Copy link
Contributor

csosto-pk commented Aug 9, 2022

Address discussion in https://mailarchive.ietf.org/arch/msg/spasm/pDD40rIFpdN7SijRp_2WgihRbxA/ about bit or octet string according to consensus

@csosto-pk
Copy link
Contributor Author

csosto-pk commented Sep 8, 2022

By Simon G.

  • I also support the byte array encoding for the private key proposed by the algorithm designers. It is an already defined encoding, so I think it makes sense to take that one.
    Also the public key is encoded as an array (but as a BIT STRING instead, because of rfc 5912), so I think to be at least somewhat consistent the private and public key should be
    encoded as an OCTET STRING and BIT STRING respectively.
  • On that note I just wanted to add that I think it would make more sense that the public key is also encoded as an OCTET STRING, but I guess that can't happen because of backward-compatibility.

@csosto-pk
Copy link
Contributor Author

csosto-pk commented Sep 8, 2022

By Markku,

I guess it can be a BIT STRING, but it clearly must be of a specific length. For verification purposes, the algorithm identifiers for Dilithium2, Dilithium3, and Dilithium5 should be explicit. Determining that from the public key length is a hack and could be a security issue. Just noting that for completeness; the current "id-dilithiumTBD" is clearly temporary. Anyway, a Dilithium-in-PKI I-D would need very clear verification rules related to this issue.

Whatever format the public key is wrapped in, the "raw concatenated sequence of bytes" (without any ASN.1 tags, as defined for algorithm designers for public keys) is actually used inside the signature process itself: the thing being signed is always prefixed by its hash: mu = H( H(pk) | m ). One obviously can't sign or verify in an interoperable fashion if one doesn't use that specific raw format for the hash prefix H(pk), also denoted "tr" in the spec. It is encoded into the secret key just to tie the public key with the secret key: Key import functions must check that the "tr" hash matches.

@jakemas jakemas transferred this issue from jakemas/draft-massimo-pq-pkix-00 Sep 26, 2022
@csosto-pk
Copy link
Contributor Author

Current language used is similar to RFC3279 says

The elliptic curve public key (an ECPoint which is an OCTET STRING)
is mapped to a subjectPublicKey (a BIT STRING) as follows: the most
significant bit of the OCTET STRING becomes the most significant bit
of the BIT STRING, and the least significant bit of the OCTET STRING
becomes the least significant bit of the BIT STRING.

@csosto-pk
Copy link
Contributor Author

csosto-pk commented Nov 3, 2022

Suggestion by @baentsch

may I suggest to (re-)add reference to [SEC1] as well as a sample pub key in section 4 of your draft?

@csosto-pk csosto-pk changed the title key as octet string public key as octet string Nov 3, 2022
@csosto-pk
Copy link
Contributor Author

From @baentsch

Should you be looking for a sample pub key, here we go: Dilithium2 with the next available NIST OID "2.16.840.1.101.3.4.3.17" as it's now generated by OpenSSL3+oqsprovider:

-----BEGIN PUBLIC KEY-----
MIIFMjALBglghkgBZQMEAxEDggUhAGfo4APVpCWuTTvyoUpSRos6ku+jjqY5QeLz
SSERjGF26euQOc4vzl0BtR3IC7cNvFp4oKkplCPWuvHTB3mkW+KOBE+tm4xdxAXG
TwNrgCbUZVGfZpcVmNRQpliF1P5hC2s2jUtZvqOI1VMMOwy9S0i4XmgRIQo3MhOX
GPeTtAzp1EiyH6LlCVgHZKBLoof5dka5yLMkUidEf7JmsQVsPCd8PpfVOmkMgr0D
BY+iUx5xLM5IRw6eVCgZTgx62IRG0Qcu0FlpL0giV/tniV4R9y/4gIQT/ThRy1YU
8KggifXDngNPyxRVd+Z/U81VBxTiSD8syqmn/Jg5QEbhBnV1FERV1kRBstMRNUld
pJ6u2j7ru03vnqlf0LhX57RP8gJmTqu2fsvuRCpCVQ/6WG89I3tBGjSrYshJIKLE
OtxSQTmKoqyRm8A2T/OGDflyQ9KBJZbdzP7ILJUUBbsS69/3Fd57ke8LIsxkhpNX
lXUSFxRQkz91WmE1yaVnawgb3H+pWxUWWlWj5Un95RYpLMeW1EATAXrAIGHHa2wX
VHofEMsHiow7PsWFvW6TCOPGeEifJPRFCbcGkiay7PqFW/WPiCqt/jPhf/43/SqB
4Rm+5RdYdp+dRtWFgnw73WRA84eYwr9U692LwEu9J6QKcRXua7zCP/PDbIaDpVij
wLW8/Xso9F135VJxR9GHPa/IS1lHBE1NrCxTSOvgqgVKzWYvxYkn/UkGCRzKlDW4
q2r22+4Y5c9j8Pil9tlt/6BMVAai+rpTgbAnU2w81TsFtQMiCHAiKDzz1xow6Aic
dbX6+oLLuZrwsgKeXe7XtnhFQJuupgUbBRLTo6tVu/kwdpCwJBH4NtwkTwZUTDy8
NbPVFE7ljZ8J5lcsYCf780Bh4DRkg3Ld5RnrWif4yNGgzzSBKidgAiw1jJgsZaQa
ktb4wgGyx4iXw+SqDTewaUO8cPCtgvn5IYJIVFRidNUflpTpETjgQES8z8/VwgQW
gu3W639dygg+8D1QOytlI8gDrIOEa3+xQpoSIXAmzOT3y9ipSr57SuphFdHwvaw2
p5w+bMgAdSDk+CBEJPzjkdhp7iGk0i6JHxRbXns4kFJpdnNqZnh7T7fwgmpWaeuv
esXOn94Jucda4wSFNHxV/VIth3QtizysyY5gjsOfHTOxI8u4jDGG/m1Ei5oduRfj
NFQE+7VR/PisG/YM+rcBuE2uJITB68mRpiHG1lSpDOtOmDjAeIHvjSI7/eFyHU4M
DYXQZFoc77CrF/lSRYZPwN5uJAXJB9SiJsYbLNwUAIXlkVDq+p+YEedElR/rnH3V
+9Vha0zsLMmQFNrmJpkRedQ2LCSVUx8vuiFSB05a0sb2LmeOIGr4eoE9u6UvLNun
U1e8rhX1NZafATIWhqedJQjzSfsGQjkHrQfWRjH1IWdPP9ZJiNP0jSHTsMgnOpnz
YPe6ob9fwmCNTrtL79gUEDPe1s05+5JDzmyehMiEnYAm8xYXXFmEmi6dVzIKv5rf
6ENJT90dba3PQM2jyLsqt0ywYzpL9xyg/dwpjhQa9gMm8cdJiJ6JrfdL8h1D1Rzt
c/2HHKoBkwssE3P/llbF3qD/j3dB7nM/2UXBZja2jLU6fOGxRnDdresWJK0qEPej
ixCjNQfTTCpFNc1/+6LAG6GnvPIUMgrT/Bc2HCW6AY1qWArUOwq2E2PQR3KhJ6rc
zXmCrNsf5s5Z2QoiGVuva6OiiVPFMB5TmXnuGU5pLO3FVyvxo9A=
-----END PUBLIC KEY-----

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant