On 6/30/22 12:06 PM, Andrew Cagney wrote:
Hi,
I'm reading this code:
NSSLOWKEYSubjectPublicKeyInfo spki;
NSSLOWKEYPublicKey pubk;
SECItem *publicKeyInfo;
if (SEC_ASN1EncodeItem(arena, &spki.subjectPublicKey,
&pubk, nsslowkey_RSAPublicKeyTemplate) == NULL)
{
crv = CKR_HOST_MEMORY;
goto loser;
}
publicKeyInfo = SEC_ASN1EncodeItem(arena, NULL,
&spki,
nsslowkey_SubjectPublicKeyInfoTemplate);
if (!publicKeyInfo) {
crv = CKR_HOST_MEMORY;
goto loser;
}
in nss/lib/softoken/pkcs11c.c:sftk_unwrapPrivateKey()
I little bit more context would have help, but I finally found it.
It looks like it's happening for PSS keys where it's trying to create
CKA_PUBLIC_KEY_INFO. I don't see anything in NSS proper which references
CKA_PUBLIC_KEY_INFO, so it quite likely could be wrong and we haven't
notices.
In my version of this code I'm finding that I need to convert the
returned subjectPublicKey's length to bits, something like:
spki.subjectPublicKey *= 8;
before making the second SEC_ASN1EncodeItem() call. I believe this is
because that field is encoded using:
{ SEC_ASN1_BIT_STRING,
offsetof(NSSLOWKEYSubjectPublicKeyInfo, subjectPublicKey) },
and SEC_ASN1_BIT_STRING expects the SECItem.len to be in bits not bytes.
could the above have the same problem?
I think you are right, it could have the same problem.
bob
Andrew
--
You received this message because you are subscribed to the Google Groups
"dev-tech-crypto@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dev-tech-crypto+unsubscr...@mozilla.org.
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/9abdd3ee-f800-4dd6-8940-8a8fd04e62fd%40redhat.com.
