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

> On Mon, Jun 4, 2012 at 7:12 AM, Davenport, James L. <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.
>
>