RE: window.crypto.SignData (was Re: Need for Smart Card support)

I am also uncomfortable with the inclusion of plaintextSummary here. As far as I can tell, there is nothing ensuring that it is in any way a truthful summary of dataToSign. This opens the door for attacks where a bad app might try to fool a user into signing something by presenting a misleading summary.

I think this this is related to the idea of smart card scenarios having a slightly different security model (see my other email), and plaintextSummary breaks that model.

From: Ryan Sleevi [mailto:sleevi@google.com]<mailto:[mailto:sleevi@google.com]>
Sent: Friday, June 8, 2012 12:03 PM
To: Wan-Teh Chang
Cc: Davenport, James L.; public-webcrypto@w3.org<mailto:public-webcrypto@w3..org>
Subject: Re: window.crypto.SignData (was Re: Need for Smart Card support)


On Fri, Jun 8, 2012 at 11:31 AM, Wan-Teh Chang <wtc@google.com<mailto:wtc@google.com>> wrote:
On Mon, Jun 4, 2012 at 7:12 AM, Davenport, James L. <jdavenpo@mitre.org<mailto:jdavenpo@mitre.org>> wrote:
> Our sponsor needs the Crypto API to enable JavaScript programs to be able to
> request: "Hey, please sign this data using that smart card."
>
> The term "smart card" is a generic term that includes Common Access Card
> (CAC) and Personal Identity Verification (PIV) cards.
>
> -----------------------------
>
> Smart Card Use Cases
>
> -----------------------------
>
> In all of the following use cases the user must be prompted for his PIN
> prior to signing with the smart card. Also, the system must display to the
> user the data that is being signed, so that he knows what he is signing.
>
[...Uses cases snipped for brevity...]

Hi Jim,

Thank you for sending the use cases.  Here is a proposal of a signData
function that should support all of your use cases (digitally signing
web transactions).

Please comment on the following issues:
- Is the use of CA names sufficient to identity the right smart card?
- Is supporting just the text/plain media type in the beginning acceptable?

Wan-Teh

Some feedback:

  *   Signing operations may or may not involve a certificate - it may simply be a public/private key pair. Should the API thus take a keyID instead?
  *   If using certificates to back the signing operation, and the user has multiple certificates that meet the criteria, how is the correct certificate/key disambiguated? Is the web application responsible for prompting the user, or is the user meant to select the appropriate key/cert?
  *   Similarly, if the user may have multiple keys used for equivalent purposes (eg: an RSA key and an ECDSA key, both usable for signature/non-repudiation), how is that discovered by the application, if at all? Your description of the "signingAlgorithm" parameter suggest that the restrictions of the key are known a-priori to calling .signData().
  *   What is the form of the CA name string? Is it an LDAP-style string-formatted distinguishedName (eg: "o=Some Org, cn=SomeUser", or it is a DER-encoded, ASN.1 representation of the actual name (eg: SSL/TLS style).
  *   Why have a timeout function? What does an implementation determine as a suitable timeout value? Depending on the accessibility needs of the user, they may require more time. In particular, I'm thinking of the W3C's Web Content Accessibility Guidelines (WCAG) Guideline 2.2 "Provide users enough time to read and use content" [1]. One way to avoid any ambiguity is to simply remove the notion of a timeout - It's not clear to me why this is necessary.

[1] http://www.w3.org/TR/WCAG20/#time-limits


=============================================================================
signData Method

The signData method allows JavaScript code to ask the user to digitally sign
a piece of data. If the user approves the operation, signData returns an
encoded JWS signature.

Syntax

resultString = window.crypto.signData(dataToSign,
                                     dataMediaType,
                                     plaintextSummary,
                                     signatureAlgorithm,
                                     [caNameString1, [caNameString2, . . . ]])

Parameters

 dataToSign:
   The data you want the user to sign. The data is opaque to the
   signData function. The encoding of text data or canonicalization
   of the date encoding is the responsibility of the application.

 dataMediaType:
   One of the MIME media types registered at IANA
   (http://www.iana.org/assignments/media-types/index.html). The
   browser needs the media type to present dataToSign to the user.

   NOTE: some media types allow comments, annotations, hidden elements
   that may not be visible when presented to the user. The media types
   that are allowed should be restricted.

 plaintextSummary:
   An optional summary, in the text/plain media type, of dataToSign.
   plaintextSummary is useful when dataToSign is long or is in a rich
   text media type.

 signatureAlgorithm:
   The signature algorithm, from the list of algorithms in the
   JSON Web Signature (JWS) Internet-Draft (draft-jones-json-web-signature)..
   This is mainly used to specify the digest algorithm used in the signature
   because the signing key already constrains the signature algorithms that
   can be used (such as RSA or ECDSA).

 caNameString:
   The DN for a CA whose certificates you trust for signing. This is
   used to find the signing certificate and key, which may be on a
   smart card. The use of CA names for specifying an approproate user
   certificate and private key has been used successfully in TLS/SSL
   client authentication.

Return status

 Success

 Error_Canceled
   The user canceled the signing operation.

 Error_Timedout
   The signing operation was aborted because the user took too long
   to approve it.

 Error_NoSigningKey
   The user doesn't have a signing certificate and key that meet the
   criteria.

 Error_SigningFailed
   The signing operation failed.

Output

 On Success, the signData function generates an encoded JWS signature
 as specified in draft-jones-json-web-signature.

Discussions

 The signData function must present UI for the user to inspect dataToSign
 and the signing certificate and approve the signing operation.

 If the signing key requires the user to enter a PIN before each use,
 that will be handled by the underlying system crypto library. This means
 the PIN dialog might be separate from the signData UI.

 The signData function should work in asynchronous mode because user
 approval can take indefinitely long. This needs more work.

 The signData function as specified is independent of the rest of the
 Web Crypto API.  An alternative design is to break it into two functions:
 - A function to find the appropriate signing certificate and key, given
   caNameString.
 - A signData function that takes a certificate handle and private key handle
   as input.

 Displaying a dataMediaType other than text/plain securely is a hard
 problem.

Acknowledgments

 The signData function is modeled after the window.crypto.signText function
 in Netscape and Mozilla browsers.
 http://docs.oracle.com/cd/E19957-01/816-6152-10/sgntxt.htm

 The plaintextSummary parameter was suggested by Ian Fette.