On Tue, 07 Oct 2009, Robert Relyea wrote:
On 10/06/2009 01:14 AM, Konstantin Andreev wrote:
On Mon, 05 Oct 2009, Robert Relyea wrote:
On 10/05/2009 09:27 AM, Konstantin Andreev wrote:
Could you, please, advice, how should I handle CKA_NETSCAPE_DB for GOST private
keys ?
GOST private key? Are you talking about a new asymmetric algorithm (a.la. RSA
and DH)? If so, then you would need to worry about private keys. If you are
just talking about a symmetric algorithm, then there is no need. You're key is
a secret key, and should be handled automatically.
Yes, the GOST (i.e. "Russian Federation National Standard") suite includes asymmetric
digital signature algorithm. That is what referenced as "GOST R 34.10-2001" in RFC
documents, and what I am talking about.
OK, we're just talking signature here, then.
Basically, this is an elliptic curve algorithm, but GOST signature slightly differ from
X9.62 EC signature. GOST digital signature is not affected by Certicom patents and free
for use. Even more, in Russia, it is mandated for use in government organizations and
"working for government" organizations.
Thanks. So the actual signature algorithm is different than EC DSA, but it
works on EC curves. Is there anything different about the key itself?
No. As for EC DSA, GOST private key is big integer, GOST public key is a EC
base point multiplied by a private key. As noted above, the signature algorithm
is different. Also GOST places some forcible restrictions on algorithm
parameters. For instance, EC must be prime, not binary.
From NSS perspective, GOST ECC signatures can't be intermixed with X9.62
signatures, because all data formats are completely different. You can refer to
patch 1 in bug 518787 for some examples of this difference.
In the "softoken", CKA_NETSCAPE_DB is applied to private keys in a various
mystic ways. It's unclear, which concern it has to GOST private keys. Could you, please,
advice ?
You can still supply asymmetric algorithms from an external module. -- remember
that will be faster coming up. That being said, I can see why you may want to
use softoken (so your keys will wind up in softoken's database).
The main reason is to ship a working solution ASAP. Developing an own PKCS#11 module
seems to be more complicated and error-prone task, than adding support to
"softoken".
CKA_NETSCAPE_DB is the database key (key as in lookup key, not crypto key) that
the object will be stored under. This is typically the public key (so that NSS
can present both the private and public keys, even though only the private key
is stored in the database). This is only needed for the old dbm database, the
new database format just stores the value, but never needs or uses it.
At the moment, I do not understand well what is a legacy and new database
formats, and need to improve my knowledge.
But, given your explanation, I could conclude: there should not be a difference
in handling CKA_NETSCAPE_DB for various private key types.
However, here is a what sftk_unwrapPrivateKey @ pkcs11c.c does (pseudo-code):
switch( private_key_type ) {
case RSA_KEY:
if(sftk_hasAttribute(key, CKA_NETSCAPE_DB)) {
sftk_DeleteAttributeType(key, CKA_NETSCAPE_DB);
}
...
case DSA_KEY:
case ECC_KEY:
crv = (sftk_hasAttribute(key, CKA_NETSCAPE_DB)) ? CKR_OK :
CKR_KEY_TYPE_INCONSISTENT;
Why this difference is needed ?
I presume the question is generated by your work on GOST signing (as opposed to
verification?).
Yes, it is.
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
