[openpgp] Re: WG Last Call: draft-ietf-openpgp-nist-bp-com p-04 (Ends 2026-09-09)

Hello all,

I have written a (partial) draft implementation of 
draft-ietf-openpgp-nist-bp-comp-04 for the rPGP library, and made a MR 
that adds the current test vectors from the draft to the interop suite.

Details follow.


# Implementation in rPGP

https://github.com/rpgp/rpgp/pull/839/

The PR is limited to the NIST P curves (there are no Rust brainpool 
crates that can be easily used with rPGP's main branch).

The implementation in the PR can (mostly) consume the NIST P based test 
vectors in the draft, and (mostly) interoperates with the RNP 
implementation  [*].


## [*]: A subtle issue with test vectors and RNP interop

This rPGP PR cannot validate the data signature from the 
ML-DSA-87+ECDSA-NIST-P-521 key, in the test vectors.

This is because the data signature is based on 32 byte sized hash 
digest. The Rust Crypto ECDSA implementation that rPGP currently uses 
("ecdsa", version 0.16.9) refuses to handle digests that are shorter 
than half of the curve's field size: 
https://docs.rs/ecdsa/0.16.9/src/ecdsa/hazmat.rs.html#185-206

So in the case of NIST-P-521, 32 byte hash digests are rejected by Rust 
Crypto's ECDSA machinery.


However, the ML-DSA-87+ECDSA-NIST-P-521 self-signatures in the TPK/TSK 
in A.2 use 64 byte hashes, and the rPGP PR can validate those without issue.
So it seems clear that interop is not a problem, besides the (relatively 
shallow) question of accepted digest sizes.

I would say that both the draft and the test vectors are fine as they 
are, and would consider the rejected 32 byte signatures a bug in Rust 
Crypto.
And indeed, the relevant behavior is changed in the next version of the 
ecdsa crate: https://github.com/RustCrypto/signatures/pull/1310 (which 
rPGP can use in the future, but not easily right now).


## Side note, hash algorithm guidance

As a side note, it does seem slightly unfortunate that the hash 
algorithm guidance in RFC 9980 doesn't align with the ECDSA guidance 
from 
https://www.rfc-editor.org/info/rfc9580/#name-algorithm-specific-fields-for-d, 
which reads:

 > An ECDSA signature MUST use a hash algorithm with a digest size of at 
least the curve's "fsize" value (see Section 9.2), except in the case of 
NIST P-521, for which at least a 512-bit hash algorithm MUST be used.

However, I don't think this can or should be changed now.


# Interop test suite

I've made a MR to add the test vectors from the draft to the interop 
test suite:

https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite/-/merge_requests/248

The tests should be easy enough to update, once code points are assigned.


In conclusion, I (continue to) think that the draft is ready for 
publication.
While implementing, the text seemed useful and concise (and it's of 
course good that the draft faithfully mirrors RFC 9980).

Thanks,
Heiko


On 8/21/26 9:28 PM, Daniel Kahn Gillmor wrote:
> There's no harm in adding the draft algorithms to the interop test suite
> using experimental codepoints.  Ideally, i'd recommend doing that
> (tagged appropriately within the test suite) before final algorithm ID
> assignment, as then the only change needed is an algorithm ID change and
> a test vector refresh.
>
> That is: interop should be testable even when using experimental
> codepoints!  It would be nice for an implementer to not have to wait.

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]