[Fwd: [saag] Paper for W3C Identity in the Browser Workshop]

for reference, another paper that's getting submitted:

-------- Original Message --------
Subject: [saag] Paper for W3C Identity in the Browser Workshop
Date: Tue, 26 Apr 2011 09:00:23 -0400
From: Sean Turner <turners@ieca.com>
To: saag@ietf.org

Please find below a paper Stephen and I are hoping to submit to the W3C
Identity in the Browser Workshop (24-25 May in Mountain View,
California).  We'd like to submit it as the IETF Security Area
Directors, but we'd obviously like to get comments from the saag list.
The deadline for submissions is April 27th.  I apologize for the very
short deadline.

spt

=====================================================================

Abstract

This position paper aims to provide some motivations for an Application
Programming Interface (API) that will allow developers access to
cryptographic algorithms already present in today's web browsers.

Motivations

More and more applications are moving to the "web" (i.e.,
http://www.example.com:80 and http://www.example.com:443).  Developers
are working within the confines of browsers to secure these applications
and most use Secure Sockets Layer (SSL)/Transport Security Layer (TLS)
to do so.  For applications whose architectures are not strictly
client-server this reliance is not always optimal.  As a work around,
developers are investigating the use of JavaScript Object Notation
(JSON) for application layer security protocols and cryptographic
algorithms.  Use of JSON makes some sense in an application layer
security protocol but developers rolling and then delivering their own
cryptographic algorithms is not only wasteful but is possibly insecure
when the browser's security "goodies" (i.e., the cryptographic
algorithms) are just an Application Programming Interface (API) away.

Downloading cryptographic algorithms is wasteful in terms of bandwidth
used.  Application and browser developers are both very interested in
ensuring their applications are speedy in the eyes of users; nobody
wants to loose a speed war on cnet®.  If web developers end up rolling
their own cryptographic algorithms to support a JSON application layer
security protocol, then the code may end up being downloaded during
application initialization.  Cryptographic code could include: message
digest/hash algorithms, digital signature algorithms, content encryption
algorithms, key wrap algorithms, keyed-Hash Message Authentication Code
(HMAC) algorithms, etc.

Developers rolling their own cryptographic code could be insecure.  As
Steve Bellovin pointed out in RFC 5406: The design of security protocols
is a subtle and difficult art.  In fact, it is worse: coding security
protocols is even more subtle and difficult than designing the security
protocol.  There is no doubt that some developers will get it right the
first time but there is also no doubt that some will get it wrong.  With
cryptographic algorithms already coded in browsers and some having been
National Institute of Standards and Technology (NIST) Federal
Information Processing Publication (FIPS PUB) 140 evaluated, it seems
unnecessarily risky to not utilize the cryptographic algorithms already
present in the browser.

Greedy Goals

An API that allows web developers to access browser-embedded
cryptographic algorithms would include the following:

o Support for hash/message digest algorithms (e.g., SHA-256);
o Support for digital signatures algorithms (e.g., RSA PKCS#1 v1.5, ECDSA);
o Support for confidentiality algorithms (i.e., AES);
o Support for key transport/agreement algorithms (e.g., RSA PKCS#1 v1.5,
ECDH);
o Support for HMAC algorithms (e.g., HMAC-SHA1, HMAC-SHA256);
o Support extracting keys from TLS sessions ala RFC 5176;
o Support for PKI path validation (i.e., input/output of base64
certificate/crl/ocsp blobs), and;
o Support for Cryptographic Message Syntax (CMS).
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

Received on Tuesday, 26 April 2011 15:24:08 UTC