Signing a digest

[wayne-davidson-tickle]

Hello,

I am using node-webcrypto-ossl via fortify.

I wish to sign a digest (I.E. as generated by subtle.digest OR as generated by another system). I believe the subtle.sign method does not expect a digest, it expects the message (original data) to be signed.

This is based on the assumption that subtle.sign (when using PKCS1) uses the RSA_PKCS1_sign method under the hood (https://github.com/PeculiarVentures/node-webcrypto-ossl/blob/master/src/rsa/rsa_pkcs1.cpp), which uses the EVP_DigestSign* methods, and that these methods are generating the digest internally.

I believe if i pass in a digest to the subtle.sign method, i will end up signing a digest of that digest.

Are there any plans to allow a digest to be passed in and have this digest signed (I.E. use the underlying EVP_Sign* methods instead of the EVP_DigestSign* methods).

https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying

The use case for this is as follows:

• A PDF document requires digital signing
• The PDF is loaded in the browser via a URL
• We do not have access to the raw PDF data in the browser (E.G. as a base64 string)
  (The PDFs may be large documents therefore it is better if these are loaded via a URL, not via passed in raw data)
• We do however have a hash (digest) of the PDF available, this is what we would like to sign

[rmhrisk]

That is correct.

WebCrypto has no mechanism to do this.

Though we have added additional algorithms and added extra features to-date we have not (intentionally) not followed the WebCrypto.

We can discuss how we might be able to expose this. Can you elaborate on use case further?

[microshine]

WebCrypto extended API

RSA

• Add new algorithm support RSA, don't use hash parameter
• Mechanism can be used for sign and verify operations
• If RsaParams doesn't have hash parameter, then signing data is hash, otherwise compute hash from data and use it for signing

interface RsaKeyGenParams extends Algorithm {
  // The length, in bits, of the RSA modulus
  modulusLength: number;
  // The RSA public exponent
  publicExponent: Uint8Array;
}

interface RsaParams extends Algorithm {
  hash?: AlgorithmIdentifier;
  params?: RsaSigningParams; 
}

interface RsaSigningParams {
  // type of RSA signing params. Can be PKCS1_v1_5 or PSS
  type: string;
}

interface RsaPkcs1SigningParams extends RsaSigningParams {
  type: "PKCS1-v1_5"
}

interface RsaPssSigningParams extends RsaSigningParams {
  type: "PSS";
  // The desired length of the random salt
  saltLength: number;
}

function generate(algorithm: RsaKeyGenParams, extractable: boolean, keyUsage: KeyUsages) : Promise<CryptoKeyPair>;

function sign(algorithm: RsaParams, key: CryptoKey, data: BufferSource): Promise<ArrayBuffer>;
function verify(algorithm: RsaParams, key: CryptoKey, signature: BufferSource, data: BufferSource): Promise<boolean>;

Example

declare const data: ArrayBuffer; // data for signing operation

const keys = await crypto.subtle.generateKey({ 
    name: "RSA", 
    publicExponent: new Uint8Array([1, 0, 1]),
    modulusLength: 2048,
  }, 
  false,
  ["sign", "verify"]);

// get SHA-256 hash from data
const hash = await crypto.subtle.digest("SHA-256", data);

// Signature without padding info
const signature1 = await crypto.subtle.sign({
    name: "RSA"
  },
  keys.privateKey,
  hash);

// Signature with PKCS1-v1_5 padding and SHA-256 hash computing
const signature2 = await crypto.subtle.sign({
    name: "RSA",
    hash: "SHA-256"
    params: {
      type: "PKCS1-v1_5"
    }
  },
  keys.privateKey,
  data);

// Signature with PSS params
const signature3 = await crypto.subtle.sign({
    name: "RSA",
    params: {
      type: "PSS",
      saltLength: 128
    }
  },
  keys.privateKey,
  hash);

ECDSA

• Extend EcdsaParams. W3 uses hash parameter as required. I suggest to make it optional. If hash is empty then incoming data fo signing/verifying is hash.

interface EcdsaParams extends Algorithm {
  hash?: AlgorithmIdentifier;
}

Example

declare const data: ArrayBuffer; // data for signing operation

const keys = await crypto.subtle.generateKey({ 
    name: "ECDSA", 
    namedCurve: "P-256"
  }, 
  false,
  ["sign", "verify"]);

// get SHA-256 hash from data
const hash = await crypto.subtle.digest("SHA-256", data);

// without hash parameter
const signature1 = await crypto.subtle.sign({
    name: "ECDSA"
  },
  keys.privateKey,
  hash);

// with hash parameter
const signature2 = await crypto.subtle.sign({
    name: "ECDSA",
    hash: "SHA-256"
  },
  keys.privateKey,
  data);

[microshine]

@wayne-davidson-tickle @rmhrisk any thoughts about extended API?

[rmhrisk]

I don’t love deviating from the WebCrypto API but think this might be a good change but don’t want to do it for the sake of doing it. E.g we need to hear from Wayne to understand scenario and importance.

[wayne-davidson-tickle]

@microshine The extended API would work for my scenario

I'll attempt to explain the scenario a bit more:

Scenario:

• Signing a PDF in the browser using Fortify (which uses node-webcrypto-ossl)

Available solution (with current APIs):

• Encoded byte data (E.G. base64) of the PDF is required to be sent to the browser
• This can be rendered as a .PDF to be viewed by the user
• This data is what is signed (I.E. converted to byte data and passed into the subtle.sign method)

In this scenario, the PDF is exposed to the browser via server request with a response payload that may look like this

pdfBase64: "Abbbbbccccc............................"

Problem:

• PDFs can be large documents, passing a PDF as encoded data is not the preferred way to render a PDF in browser.
• Generally, the PDF will be loaded via a URL, possibly using an iFrame or embed

In this scenario, the PDF is exposed to the browser via server request with a response payload that may look like this

pdfUrl: "https://www.com.mypdf.pdf"

When loading the PDF via a URL we do not have access to the byte data of this PDF for signing

Preferred solution:

• If a method to sign a digest existed, then, I could have a response payload that may look like this

pdfUrl: "https://www.com.mypdf.pdf"
pdfDigest: "AbCdEf...."

• The PDF can be loaded the preferred way (via URL)
• The digest can be signed

My scenario is specifically around .PDFs, but it would have implications for any scenario in which the data used to render something in-browser (E.G. in this case, the URL) is different from the underlying data it represents (E.G. the PDF as byte data)