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
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

-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to