On Wednesday 13 January 2016 17:43:02 Kai Thiele wrote: > Hubert Kario <hkario <at> redhat.com> writes: > > On Monday 11 January 2016 15:53:26 Kai Thiele wrote: > > > Hi, > > > > > > regarding CMS (Cryptographic Message Syntax), > > > which RFC is the current one NSS is supporting ? > > > (e.g RFC 5652 and RFC 5753 or only RFC 2630) > > > > > > I already searched for this in the list, > > > but relevant entries are 5 to 10 years old. > > > > > > > > > I tried to decrypt a CMS container using cmsutil (NSS 3.21) > > > The container(signed-data) was generated by OpenSSL 1.0.1p > > > Keys are ECC secp256v1 and signature is ECDSA_SHA256. > > > > > > It seems that NSS is not identifying the keys as 'ecKey' > > > and the algorithm-ids like SEC_OID_ANSIX962_ECDSA_SHA256_SIGNATURE > > > are ignored. That leads to error Messages from cmsutil. > > > > > > So I wonder, to which RFC the CMS in NSS is compliant. > > > > Could you provide exact steps needed to reproduce this? > > OpenSSL create certificates (selfsigned ca-cert and SIG certificate): > ecparam -name prime256v1 -genkey -noout -out key_priv_01.pem > ec -in key_priv_01.pem -pubout -out key_pub_01.pem > ecparam -name prime256v1 -genkey -noout -out key_priv_02.pem > ec -in key_priv_02.pem -pubout -out key_pub_02.pem > req -x509 -new -sha256 -key key_priv_01.pem -out ca-cert.pem -outform > PEM -days 7300 > req -new -key key_priv_02.pem -out client-csr.pem > x509 -req -days 3653 -outform PEM -inform PEM -sha256 -extfile > client.ext -in client-csr.pem -CA ca-cert.pem -CAkey key_priv_01.pem > -CAcreateserial -out client-cert.pem
contents of client.ext?
> pkcs12 -export -out SIG.pfx -inkey key_priv_02.pem -in client-cert.pem
> -certfile ca-cert.pem
>
> If the client/SIG-certificate contains an Extended Key Usage
> extension, then it must contain the id-kp-emailProtection OID.
> The Client/SIG-certificate is signed by the ca-certificate.
>
> OpenSSL create and verify CMS container:
> cms -sign -in test.txt -out signed.bin -inkey key_priv_02.pem -md
> sha256 -signer client-cert.pem -outform DER -nodetach -nosmimecap
> -stream cms -verify -inform DER -in signed.bin -signer
> client-cert.pem -out signedtext.txt -CAfile ca-cert.pem
>
> test.txt is a file with some text in it, like: '01234567890'
> cms - verify is only done to chek if with OpenSSL if the Container is
> good.
>
>
> NSS import certificates:
> ./certutil -A -n TstCA -t "TCu,TCu,TCu" -d /home/xxx/nss-3.21/db -p
> nss -i ../ca-cert.pem
> ./pk12util -i SIG.pfx -d /home/xxx/nss-3.21/db -p nss
>
>
> NSS decode CMS container (as Validation of signature):
> ./cmsutil -D -i ../signed.bin -o ../decode.txt -d
> /home/xxx/nss-3.21/db -p nss
>
> That ends in:
> signer 0 status = SignatureAlgorithmUnsupported
> cmsutil: problem decoding: SEC_ERROR_PKCS7_BAD_SIGNATURE: Signature
> verification failed: no signer found, too many signers found, or
> improper or corrupted data.
>
>
> If all the certificates are available to OpenSSL and NNS only the
> following lines are needed to reproduce.
>
> OpenSSL:
> cms -sign -in test.txt -out signed.bin -inkey key_priv_02.pem -md
> sha256 -signer client-cert.pem -outform DER -nodetach -nosmimecap
> -stream
>
> NSS:
> ./cmsutil -D -i ../signed.bin -o ../decode.txt -d
> /home/xxx/nss-3.21/db -p nss
>
>
>
>
> With the following changes it works:
>
> nss-3.21\nss\lib\cryptohi\secvfy.c : line 169
> static SECStatus
> decodeECorDSASignature(SECOidTag algid, const SECItem *sig, unsigned
> char *dsig,
> unsigned int len) {
> SECItem *dsasig = NULL; /* also used for ECDSA */
> SECStatus rv=SECSuccess;
>
> if ((algid != SEC_OID_ANSIX9_DSA_SIGNATURE) &&
> (algid != SEC_OID_ANSIX962_ECDSA_SHA224_SIGNATURE) && /* RFC
5753
> */
> (algid != SEC_OID_ANSIX962_ECDSA_SHA256_SIGNATURE) && /* RFC
5753
> */
> (algid != SEC_OID_ANSIX962_ECDSA_SHA384_SIGNATURE) && /* RFC
5753
> */
> (algid != SEC_OID_ANSIX962_ECDSA_SHA512_SIGNATURE) && /* RFC
5753
> */
> (algid != SEC_OID_ANSIX962_EC_PUBLIC_KEY) ) {
> if (sig->len != len) {
> PORT_SetError(SEC_ERROR_BAD_DER);
> return SECFailure;
> }
>
> ----------
>
> nss-3.21\nss\lib\cryptohi\seckey.c : line 492
> seckey_GetKeyType (SECOidTag tag) {
> KeyType keyType;
>
> switch (tag) {
> ...
> case SEC_OID_ANSIX962_EC_PUBLIC_KEY:
> case SEC_OID_ANSIX962_ECDSA_SHA224_SIGNATURE: /* RFC 5753 */
> case SEC_OID_ANSIX962_ECDSA_SHA256_SIGNATURE: /* RFC 5753 */
> case SEC_OID_ANSIX962_ECDSA_SHA384_SIGNATURE: /* RFC 5753 */
> case SEC_OID_ANSIX962_ECDSA_SHA512_SIGNATURE: /* RFC 5753 */
> keyType = ecKey;
>
>
> I am not shure what side effects these changes would have.
>
> BR Kai
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
