Do I understand correctly, that SPKI still should follow RFCs about Algorithm Identifier? Like, RFC8410.

With this MR, Ed25519/X25519 public keys exported with pkcs15-tool --read-public-key can be parsed by openssl, finally.

@Jakuje could you, please, test if with Nitrokey? I think that this one should allow p11test to really test sign/derive (before this commit, these tests were ignored, as algorithm id was not known to OpenSSL, and RFC8410), and pubkeys read with pkcs15-tool should be parseable by openssl now:

pkcs15-tool --read-public-key 02 | openssl pkey -pubin -text

Tested with Nitrokey Start and it looks like working fine for me. Thanks!

@Jakuje BTW, have you checked, what is the maximum amount of data, which can be signed by Nitrokey? I mean, it seems that in EDDSA, hashing is done as a part of algorithm, inside the token (at least for Yubikey), and OpenSC is now limited in 512 bytes. When I changed buffer sizes in pkcs15-sec.c and mechanism.c to 4096, I found that Yubikey can sign up to 3053 bytes. I wonder, if this limit could be found somewhere, and used as a size of buffer...

P.S. Found some DOs and reader capabilities detect, will take a look into it

I was able to get only 256 bytes signed with Nitrokey. If it is more, the driver attempts to chain the data in the next APDU and it fails for some reason:

$ OPENSC_DEBUG=9 ./src/tools/pkcs11-tool --sign -m EDDSA --id 01 --slot 1 --pin 123456 --input-file data --output-file data.sig --module ./src/pkcs11/.libs/opensc-pkcs11.so
[...]
P:3605915; T:0x140076030845376 12:05:16.551 [opensc-pkcs11] card-openpgp.c:2068:pgp_set_security_env: called
P:3605915; T:0x140076030845376 12:05:16.551 [opensc-pkcs11] card-openpgp.c:2086:pgp_set_security_env: Key ref 0
P:3605915; T:0x140076030845376 12:05:16.551 [opensc-pkcs11] card-openpgp.c:2089:pgp_set_security_env: Operation: Sign.
P:3605915; T:0x140076030845376 12:05:16.551 [opensc-pkcs11] card-openpgp.c:2115:pgp_set_security_env: returning with: 0 (Success)
P:3605915; T:0x140076030845376 12:05:16.551 [opensc-pkcs11] sec.c:109:sc_set_security_env: returning with: 0 (Success)
P:3605915; T:0x140076030845376 12:05:16.551 [opensc-pkcs11] sec.c:59:sc_compute_signature: called
P:3605915; T:0x140076030845376 12:05:16.551 [opensc-pkcs11] card-openpgp.c:2178:pgp_compute_signature: called
P:3605915; T:0x140076030845376 12:05:16.551 [opensc-pkcs11] apdu.c:548:sc_transmit_apdu: called
P:3605915; T:0x140076030845376 12:05:16.551 [opensc-pkcs11] card.c:473:sc_lock: called
P:3605915; T:0x140076030845376 12:05:16.551 [opensc-pkcs11] card.c:513:sc_lock: returning with: 0 (Success)
P:3605915; T:0x140076030845376 12:05:16.551 [opensc-pkcs11] apdu.c:515:sc_transmit: called
P:3605915; T:0x140076030845376 12:05:16.551 [opensc-pkcs11] apdu.c:363:sc_single_transmit: called
P:3605915; T:0x140076030845376 12:05:16.551 [opensc-pkcs11] apdu.c:367:sc_single_transmit: CLA:10, INS:2A, P1:9E, P2:9A, data(255) 0x7fff84d974b0
P:3605915; T:0x140076030845376 12:05:16.551 [opensc-pkcs11] reader-pcsc.c:323:pcsc_transmit: reader 'Nitrokey Nitrokey Start (FSIJ-1.2.10-43245521) 00 00'
P:3605915; T:0x140076030845376 12:05:16.551 [opensc-pkcs11] reader-pcsc.c:324:pcsc_transmit: 
Outgoing APDU (260 bytes):
10 2A 9E 9A FF 64 61 74 61 20 74 6F 20 73 69 67 .*...data to sig
6E 20 28 6D 61 78 20 31 30 30 20 62 79 74 65 73 n (max 100 bytes
29 0A 64 61 74 61 20 74 6F 20 73 69 67 6E 20 28 ).data to sign (
6D 61 78 20 31 30 30 20 62 79 74 65 73 29 0A 64 max 100 bytes).d
61 74 61 20 74 6F 20 73 69 67 6E 20 28 6D 61 78 ata to sign (max
20 31 30 30 20 62 79 74 65 73 29 0A 64 61 74 61  100 bytes).data
20 74 6F 20 73 69 67 6E 20 28 6D 61 78 20 31 30  to sign (max 10
30 20 62 79 74 65 73 29 0A 64 61 74 61 20 74 6F 0 bytes).data to
20 73 69 67 6E 20 28 6D 61 78 20 31 30 30 20 62  sign (max 100 b
79 74 65 73 29 0A 64 61 74 61 20 74 6F 20 73 69 ytes).data to si
67 6E 20 28 6D 61 78 20 31 30 30 20 62 79 74 65 gn (max 100 byte
73 29 0A 64 61 74 61 20 74 6F 20 73 69 67 6E 20 s).data to sign 
28 6D 61 78 20 31 30 30 20 62 79 74 65 73 29 0A (max 100 bytes).
64 61 74 61 20 74 6F 20 73 69 67 6E 20 28 6D 61 data to sign (ma
78 20 31 30 30 20 62 79 74 65 73 29 0A 64 61 74 x 100 bytes).dat
61 20 74 6F 20 73 69 67 6E 20 28 6D 61 78 20 31 a to sign (max 1
30 30 20 62                                     00 b
P:3605915; T:0x140076030845376 12:05:16.551 [opensc-pkcs11] reader-pcsc.c:242:pcsc_internal_transmit: called
P:3605915; T:0x140076030845376 12:05:16.552 [opensc-pkcs11] reader-pcsc.c:333:pcsc_transmit: 
Incoming APDU (2 bytes):
90 00 ..
P:3605915; T:0x140076030845376 12:05:16.552 [opensc-pkcs11] apdu.c:382:sc_single_transmit: returning with: 0 (Success)
P:3605915; T:0x140076030845376 12:05:16.552 [opensc-pkcs11] apdu.c:537:sc_transmit: returning with: 0 (Success)
P:3605915; T:0x140076030845376 12:05:16.552 [opensc-pkcs11] apdu.c:515:sc_transmit: called
P:3605915; T:0x140076030845376 12:05:16.552 [opensc-pkcs11] apdu.c:363:sc_single_transmit: called
P:3605915; T:0x140076030845376 12:05:16.552 [opensc-pkcs11] apdu.c:367:sc_single_transmit: CLA:0, INS:2A, P1:9E, P2:9A, data(2) 0x7fff84d975af
P:3605915; T:0x140076030845376 12:05:16.552 [opensc-pkcs11] reader-pcsc.c:323:pcsc_transmit: reader 'Nitrokey Nitrokey Start (FSIJ-1.2.10-43245521) 00 00'
P:3605915; T:0x140076030845376 12:05:16.552 [opensc-pkcs11] reader-pcsc.c:324:pcsc_transmit: 
Outgoing APDU (8 bytes):
00 2A 9E 9A 02 79 0A 00 .*...y..
P:3605915; T:0x140076030845376 12:05:16.552 [opensc-pkcs11] reader-pcsc.c:242:pcsc_internal_transmit: called
P:3605915; T:0x140076030845376 12:05:16.553 [opensc-pkcs11] reader-pcsc.c:333:pcsc_transmit: 
Incoming APDU (2 bytes):
69 85 i.
P:3605915; T:0x140076030845376 12:05:16.553 [opensc-pkcs11] apdu.c:382:sc_single_transmit: returning with: 0 (Success)
P:3605915; T:0x140076030845376 12:05:16.553 [opensc-pkcs11] apdu.c:537:sc_transmit: returning with: 0 (Success)
P:3605915; T:0x140076030845376 12:05:16.553 [opensc-pkcs11] card.c:523:sc_unlock: called
P:3605915; T:0x140076030845376 12:05:16.553 [opensc-pkcs11] iso7816.c:128:iso7816_check_sw: Conditions of use not satisfied
P:3605915; T:0x140076030845376 12:05:16.553 [opensc-pkcs11] card-openpgp.c:2217:pgp_compute_signature: Card returned error: -1209 (Not allowed)
P:3605915; T:0x140076030845376 12:05:16.553 [opensc-pkcs11] sec.c:63:sc_compute_signature: returning with: -1209 (Not allowed)
P:3605915; T:0x140076030845376 12:05:16.553 [opensc-pkcs11] card.c:523:sc_unlock: called
P:3605915; T:0x140076030845376 12:05:16.553 [opensc-pkcs11] pkcs15-sec.c:169:use_key: returning with: -1209 (Not allowed)
P:3605915; T:0x140076030845376 12:05:16.553 [opensc-pkcs11] pkcs15-sec.c:747:sc_pkcs15_compute_signature: use_key() failed: -1209 (Not allowed)
P:3605915; T:0x140076030845376 12:05:16.553 [opensc-pkcs11] card.c:523:sc_unlock: called
P:3605915; T:0x140076030845376 12:05:16.553 [opensc-pkcs11] reader-pcsc.c:737:pcsc_unlock: called
P:3605915; T:0x140076030845376 12:05:16.553 [opensc-pkcs11] framework-pkcs15.c:4255:pkcs15_prkey_sign: Sign complete. Result -1209.

one byte less works fine as it fits into single APDU. I did not investigate the issue further.

EDDSA, hashing is done as a part of algorithm

Yes, the hash size is based on the key size. Ed22519 uses SHA-256: RFC 8032 It also talks about the "prehash" function "PH" For Ed25519, PH is the message which could be any size.

But it might be possible for a card driver to do the PH in software, or pass on the whole message to the card.

So in any case OpenSC needs to pass on the message to the card driver. There is at least one card drivers that can do a hash in the driver. If card driver set the flags to include SC_ALGORITHM_ECDSA_HASH_SHA then it wants to do the hash in the driver or pass on to the card.
grep SC_ALGORITHM_ECDSA_HASH_SHA card-*

So you may need to add code similar to card-sc-hsm.c or card-epass2003.c

And for EDDSA, to not set the SC_ALGORITHM_ECDSA_HASH_NONE flag as this tells PKCS11 that the application can do the hash.

It may be that one card is using Ed25519ph, and one is using Ed25519.

For Ed25519ph, phflag=1 and PH is SHA512 instead. That is, the input
is hashed using SHA-512 before signing with Ed25519.

I don't have any devices to test any of the above.

Value of context is set by the signer and verifier (maximum of 255
octets; the default is empty string, except for Ed25519, which can't
have context) and has to match octet by octet for verification to be
successful.

RFC 8032 has a few Erratas:
https://www.rfc-editor.org/errata_search.php?rfc=8032.

Value of context is set by the signer and verifier (maximum of 255
octets;

This restriction may be what is seen with the NitroKey. But not with the Yubikey.

If it is possible to load a specific key on one or both of these devices, a good test would be to get the same key on both, maybe one of the the ones from RFC 8032
"7.1. Test Vectors for Ed25519" Note "-----TEST 1024" has a message of length 1024 bytes. and see if either card can reproduce the signatures.

You where also asking about the format of SPKI. https://tools.ietf.org/html/rfc8410 has some examples of certificates and comments on https://tools.ietf.org/html/rfc8032

@dengert

RFC 8032 has a few Erratas:
https://www.rfc-editor.org/errata_search.php?rfc=8032.

Value of context is set by the signer and verifier (maximum of 255
octets;

This restriction may be what is seen with the NitroKey. But not with the Yubikey.

It applies to context, which is not the message, and used only by ed25519ctx and ed25519ph, which is not what tokens support (I think, it's just ed25519. From the RFC:

For Ed25519, dom2(f,c) is the empty string. The phflag value is irrelevant. The context (if present at all) MUST be empty.

If it is possible to load a specific key on one or both of these devices, a good test would be to get the same key on both, maybe one of the the ones from RFC 8032
"7.1. Test Vectors for Ed25519" Note "-----TEST 1024" has a message of length 1024 bytes. and see if either card can reproduce the signatures.

I've checked my keys against python implementation in cryptography library, and it can verify signature made by my key. I've also checked it against test vectors in the rfc. Oh, and I managed to hack XCA, to sign x509 certificate using my token, and then verify it via openssl - all is good (that's why I need more than 512 bytes, as certificates could be longer)
Oh, and with this change and change from #2286 I managed to pass p11test (without NDEBUG), and it says that signature matches (it verifies using openssl as well), and I was increasing message to be more than 512 bytes.

EDDSA, hashing is done as a part of algorithm

Yes, the hash size is based on the key size. Ed22519 uses SHA-256: RFC 8032 It also talks about the "prehash" function "PH" For Ed25519, PH is the message which could be any size.

But it might be possible for a card driver to do the PH in software, or pass on the whole message to the card.

So in any case OpenSC needs to pass on the message to the card driver. There is at least one card drivers that can do a hash in the driver. If card driver set the flags to include SC_ALGORITHM_ECDSA_HASH_SHA then it wants to do the hash in the driver or pass on to the card.
grep SC_ALGORITHM_ECDSA_HASH_SHA card-*

So you may need to add code similar to card-sc-hsm.c or card-epass2003.c

The problem is that I need to know, how to inform OpenPGP token about variant of ed25519. I cannot find any info in OpenPGP 3.4, and according to it, ECDSA supports only prehashed messages, so, no other options for it as well

And for EDDSA, to not set the SC_ALGORITHM_ECDSA_HASH_NONE flag as this tells PKCS11 that the application can do the hash.

It may be that one card is using Ed25519ph, and one is using Ed25519.

For Ed25519ph, phflag=1 and PH is SHA512 instead. That is, the input
is hashed using SHA-512 before signing with Ed25519.

I don't have any devices to test any of the above.

Value of context is set by the signer and verifier (maximum of 255
octets; the default is empty string, except for Ed25519, which can't
have context) and has to match octet by octet for verification to be
successful.

P.S. I've just checked gnupg, and it seems that it sends data as is, for EDDSA.
Here is sha1 id (3021300906052B0E03021A05000414) prefixed data:

chan_6 <- SETDATA 3021300906052B0E03021A0500041400000020D5EE4BCC...

And here is APDU:

send apdu: c=00 i=88 p1=00 p2=00 lc=146 le=256 em=0
   PCSC_data: 00 88 00 00 92 00 00 00 20 D5 EE 4B CC...

I'll check with gpg --sign, though

P.P.S Just checked sign - gnupg is doing prehash, and put 64 bytes of sha512 hash in card, but it is not using any prefix, or DSI, or doesn't use any other APDUs to inform token that data is pre-hashed. So, I'm assuming that this is standard way to do so, but this means that token supports only PureEdDSA mode.
Am I right that X509 also supports only PureEdDSA algorithm for signing?

Actually, maybe this discussion is little bit off-topic, as it has nothing to do with current MR. I'll create a issue, to discuss possible solutions.

Certificates to be signed are a good example, but there should be no limit. A user could ask for a large document to be signed. https://docs.oasis-open.org/pkcs11/pkcs11-curr/v3.0/csprd01/pkcs11-curr-v3.0-csprd01.html has:

Table 44, EdDSA: Key and Data Length
Function | Key type | Input length | Output length
-- | -- | -- | --
C_Sign | CKK_EC_EDWARDS private key | any | 2bLen
C_Verify | CKK_EC_EDWARDS public key | any, £2bLen 2 | N/A

Note that for EdDSA in pure mode, Ed25519 and Ed448 the data must be processed twice. Therefore, a token might need to cache all the data, especially when used with C_SignUpdate/C_VerifyUpdate. If tokens are unable to do so they can return CKM_TOKEN_RESOURCE_EXCEEDED.

So I was suggesting that the card driver could collect up multiple segment of data much like a driver doing the hash in software but not doing the hash, which was why I brought up card-sc-hsm.c as example of how a driver could accept any size data then use extended APDUs or command chaining to the card, or do some of the processing in software so the card does not have to look at the data twice. But the "the data must be processed twice" may be a limiting factor.

An trace of the Yubikey at the pcscd level would show what the the Yubkey driver or OpenPGP is doing.

What I am saying is I don't think changing the size of the buffer in pkcs15-sec.c is the correct way to address this.

PKCS11 implies there might be some token resource limit to what can be handled.
@Jakuje's test with the NitroKey may have a 255 byte limit, or maybe the extended APDUs might allow a larger limit.

If all the tokens have some reasonable limit, like 4K, then maybe pkcs15-sec.c buffer size would be OK.

P.S. I found I do have a NitroKey Start token that supports Ed25519. I hope to be able to do some testing with it soon.

@dengert Could we continue in #2300, please? This MR doesn't depend on max size of signed data. I'll answer you there.

I'm pretty happy with the code in this MR now, so, just waiting it to be merged.

@Jakuje Can I ask you, to test master branch of OpenSC, if EdDSA Pubkey from Nitrokey can be parsed by OpenSSL? Same command as #2293 (comment)

@Jakuje Can I ask you, to test master branch of OpenSC, if EdDSA Pubkey from Nitrokey can be parsed by OpenSSL? Same command as #2293 (comment)

Sure:

[jjelen@t490s OpenSC (master)]$ ./src/tools/pkcs15-tool --read-public-key 02 | openssl pkey -pubin -text
Using reader with a card: Nitrokey Nitrokey Start (FSIJ-1.2.10-43245521) 00 00
unable to load Public Key
140631660181312:error:0609E09C:digital envelope routines:pkey_set_type:unsupported algorithm:crypto/evp/p_lib.c:210:
140631660181312:error:0B09406F:x509 certificate routines:x509_pubkey_decode:unsupported algorithm:crypto/x509/x_pubkey.c:114:
140631660181312:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib:crypto/pem/pem_oth.c:33:

It works fine in your branch though:

[jjelen@t490s OpenSC ((fab20bd8...))]$ ./src/tools/pkcs15-tool --read-public-key 02 | openssl pkey -pubin -text
Using reader with a card: Nitrokey Nitrokey Start (FSIJ-1.2.10-43245521) 00 00
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VuAyEAFlDFzD3+M2T/lCyaFUQYYbsMXV718gVqEnIr1NOu7SA=
-----END PUBLIC KEY-----
X25519 Public-Key:
pub:
    16:50:c5:cc:3d:fe:33:64:ff:94:2c:9a:15:44:18:
    61:bb:0c:5d:5e:f5:f2:05:6a:12:72:2b:d4:d3:ae:
    ed:20

This means, that tests will, almost certainly, silently fails for Nitrokey, as well, as I described in #2304. Thank you! So, this branch is good to fix this bug for any token, supporting ed25519/curve25519.

I have also run some tests using a combined version of your PRs by doing the following:

git clone https://github.com/ya-isakov/OpenSC.git
git checkout -b dee-test
git branch -a
git log --oneline --abbrev-commit --all --graph --decorate --color
# from the the do_fa branch:
#git rev-list e9969384...1a366636
git cherry-pick e9969384...1a366636
# from the ed25519 branch only 1 commit:
git cherry-pick fab20bd8

I felt it was most important to make sure these PR all work together. as I have both a Nitro Start and Yubikey 5 NFC. Both have a Ed25519 key for signature and one for authenticate.

./pkcs11-tool  --slot 1 --sign -i /tmp/200.txt -o /tmp/200.sig -m EDDSA
./pkcs11-tool  --slot 1 -r --id 01 -y pubkey -o /tmp/pub.pem

was run on both and creates a signature file and extract the public key Unfortunately, OpenSSL does not have a utility to verify an EdDSA signature. (I even looked at 3.0.0-alpha15.) And pkcs11-tool does not either.

So I am attaching the 5 files here for your verification.

the "-n" files are for the Nitrokey and the "-y" are for the Yubikey. The both used the 200 byte 200.txt file as input. the sig files are binary.

dee-2293.zip

I had to specify -m EDDSA, as it looks like pkcs11-tool does not figure that out based on the key.

p11test are checking, that what is signed by token could be verified. If you compile it without -DNDEBUG, output will show something like

 [ KEY 03 ] Signing message of length 32 using CKM_EDDSA
 [ KEY 03 ] Verify message signature
 [ KEY 03 ] Falling back to openssl verification
 [  OK 03 ] EdDSA Signature of length 32 is valid.

This even works for messages of length 2048 (with hacked tests and increased buffer). I'll try to verify your files using python cryptography library (I had success using it, with my signatures)

I have also run some tests using a combined version of your PRs by doing the following:

git clone https://github.com/ya-isakov/OpenSC.git
git checkout -b dee-test
git branch -a
git log --oneline --abbrev-commit --all --graph --decorate --color
# from the the do_fa branch:
#git rev-list e9969384...1a366636
git cherry-pick e9969384...1a366636
# from the ed25519 branch only 1 commit:
git cherry-pick fab20bd8

I felt it was most important to make sure these PR all work together. as I have both a Nitro Start and Yubikey 5 NFC. Both have a Ed25519 key for signature and one for authenticate.

./pkcs11-tool  --slot 1 --sign -i /tmp/200.txt -o /tmp/200.sig -m EDDSA
./pkcs11-tool  --slot 1 -r --id 01 -y pubkey -o /tmp/pub.pem

was run on both and creates a signature file and extract the public key Unfortunately, OpenSSL does not have a utility to verify an EdDSA signature. (I even looked at 3.0.0-alpha15.) And pkcs11-tool does not either.

The 3.0 should have it, I think:

https://github.com/OpenSC/OpenSC/wiki/Using-pkcs11-tool-and-OpenSSL#eddsa-wip

At least that was what I used when I started testing Ed25519.

@Jakuje I knew I saw instruction somewhere, but I forgot, where :)

@dengert I checked your data, signature matches:

>>> from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey
>>> testfile = open("200.txt", "rb").read()
>>> len(testfile)
200
>>> print(testfile)
b'123456789\n123456789\n123456789\n123456789\n123456789\n123456789\n123456789\n123456789\n123456789\n123456789\n123456789\n123456789\n123456789\n123456789\n123456789\n123456789\n123456789\n123456789\n123456789\n123456789\n'
>>> from binascii import unhexlify
>>> nitro_pkey = Ed25519PublicKey.from_public_bytes(unhexlify("ff8fd5661f1252dc86286a88cb8b1e280fc1e29c402976dac4b9216ebcbe0f30"))
>>> nitro_sign = open("200-n.sig", "rb").read()
>>> nitro_pkey.verify(nitro_sign, testfile)
>>> yubi_pkey = Ed25519PublicKey.from_public_bytes(unhexlify("46ede83e9fd42981d527c269cff0abe6c01ce06fec17770bf6333a444877a953"))
>>> yubi_sign = open("200-y.sig", "rb").read()
>>> yubi_pkey.verify(yubi_sign, testfile)

verify should show an error, if signature is not matching, but it is not showing, so, verify works. But definitely, @Jakuje's way to test it is much more convenient.

@Jakuje Thanks for 3.0.0 tip! I built OpenSSL 3.0.0-alpha15-dev from git.

/opt/ossl-3.0.0/bin/openssl pkeyutl -verify -inkey /tmp/pub-n.pem -in /tmp/200.txt -sigfile /tmp/200-n.sig -pubin -rawin
/opt/ossl-3.0.0/bin/openssl pkeyutl -verify -inkey /tmp/pub-y.pem -in /tmp/200.txt -sigfile /tmp/200-y.sig -pubin -rawin

both return Signature Verified Successfully

@dengert I think this PR is ready and it would make sense to apply it for 0.22.0, what do you think?

I don't see any problems. But I have not tried anything since April, 19, and that was just to prove a Nitro Start with just a key worked.

And do we have something else to try? For the input sizes, we have separate issue.

Ok. I will merge this as without that, I have failures in p11test handling the EC_PARAMS (unfortunately silent ones).