Dear Douglas,
Sorry, I don't understand how it works.
The RSA_get_ex_new_index allocates an index in the internal openssl table.
This index is a global variable.
Then on loading a particular key we use a function pkcs11_rsa_wrap that
sets a pointer to a pkcs11_key structure identifying that particular key.
https://github.com/openssh/openssh-portable/blob/1bb130ed34721d46452529d094d9bbf045607d79/ssh-pkcs11.c#L486-L508
The internal openssl implementation that is used for this purpose uses a
stack.
So basically all the _set_ex_data functions put a pointer to some data in
stack on position with idx:
https://github.com/openssl/openssl/blob/c8c6e7438c03b2fc24e7ead460feeaef04911fb4/crypto/ex_data.c#L369-L388
(see the definition of OPENSSL_sk_set for details
https://github.com/openssl/openssl/blob/c8c6e7438c03b2fc24e7ead460feeaef04911fb4/crypto/stack/stack.c#L392-L399
)
I think, it an easily be checked just by adding a 2nd RSA key to
regress/agent-pkcs11.sh test
On Sat, Feb 13, 2021 at 4:13 PM Douglas E Engert <deengert at gmail.com>
wrote:
> You are partially right.
> The rsa_idx, and ec_key_idx should not be set to 0, but should be set
> using RSA_get_ex_new_index() as is done later in:
>
>
https://github.com/openssh/openssh-portable/blame/1bb130ed34721d46452529d094d9bbf045607d79/ssh-pkcs11.c#L471
>
> rsa_idx = RSA_get_ex_new_index(0, "ssh-pkcs11-rsa",
>
> This then allows for multiple components to store data in a key.
> The index is not of the key, but of extra data that can be stored in a key.
> Thus every key can have its own "ssh-pkcs11-rsa" with different
data.
>
> The ec_key_idx is set in:
>
>
https://github.com/openssh/openssh-portable/blame/1bb130ed34721d46452529d094d9bbf045607d79/ssh-pkcs11.c#L587
>
>
> https://www.openssl.org/docs/man1.1.1/man3/RSA_get_ex_new_index.html
> and is also in OpenSSL-1.0.2.
>
> OpenSC/libp11 examples start here:
> https://github.com/OpenSC/libp11/blob/master/src/p11_rsa.c#L399
>
> https://github.com/OpenSC/libp11/blob/master/src/p11_ec.c#L155
>
>
> On 2/13/2021 8:22 AM, Dmitry Belyavskiy wrote:
> > Dear Douglas,
> >
> > Everything is fine with methods. But I'm speaking about the
variables
> rsa_idx and ec_key_idx, sorry for being unclear.
> > They serve as handles in a global OpenSSL table and identify a
> pkcs11_data associated with a particular key, don't they?
> >
> > On Sat, Feb 13, 2021 at 3:07 PM Douglas E Engert <deengert at
gmail.com
> <mailto:deengert at gmail.com>> wrote:
> >
> > These lines are for METHODS, i.e. RSA_METHOD and EC_KEY_METHOD.
RSA
> keys can share an RSA_METHOD,
> > and EC keys can share an EC_KEY_METHOD. A method can be copied,
for
> example an OpenSSL engine
> > for using PKCS11, would then provide the routines in the method to
> not use the default software version
> > of RSA signature or decrypting operations, but use PKCS11 to have
> these operations done on the token or smart card.
> > So for RSA keys on the token, all these keys would share a copied
> and modified RSA_METHOD PKCS11 method
> > where the rsa_idx in these keys is used to point to key specific
> data such as PkCS11 slot and KeyIDs.
> >
> >
> >
> > On 2/12/2021 10:31 AM, Dmitry Belyavskiy wrote:
> > > Hello,
> > >
> > > Do I correctly understand that there can't be more than
one key
> of each
> > > type of PKCS#11?
> > >
> > > The lines
> > >
>
https://github.com/openssh/openssh-portable/blame/1bb130ed34721d46452529d094d9bbf045607d79/ssh-pkcs11.c#L191-L196
> > <
>
https://github.com/openssh/openssh-portable/blame/1bb130ed34721d46452529d094d9bbf045607d79/ssh-pkcs11.c#L191-L196
> >
> > > seem to use the global variables for RSA/ECDSA
pkcs11-related data
> > > structures.
> > >
> > > Many thanks!
> > >
> >
> > --
> >
> > Douglas E. Engert <DEEngert at gmail.com
<mailto:DEEngert at gmail.com
> >>
> >
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org <mailto:openssh-unix-dev at
mindrot.org>
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev <
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>
> >
> >
> >
> > --
> > Dmitry Belyavskiy
>
> --
>
> Douglas E. Engert <DEEngert at gmail.com>
>
>
--
Dmitry Belyavskiy