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

From: =JeffH <[email-masked]>
Date: Wed, 27 Apr 2011 17:22:45 -0700

Glad you folks are putting this together and that PSA will be there with an 
IETF hat on.

I'm supportive of everyone's feedback on this so far. Below's my editorial 
suggestions, applied to the original version of the writeup. I found it a bit 
confusing terminology- and organization-wise. I'm sorta guessing about some of 
the intent/context, but took a stab at enhancing it.

Basically, I'd spell things out in a bit more contextual detail because if one 
isn't mired in the middle of all this web and web browser stuff, it can be 
pretty confusing.

take what you will of the below, hope it helps a bit,

=JeffH

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

Today, Web applications are constructed from a combination of server side code 
and dynamically-downloaded client side amalgamations of HTML and Javascript 
(plus other components). The formally standardized environment the client-side 
Javascript programmer has to work with is provided by the browser 
implementation (e.g. the DOM Core [1], CSS Selectors, Geolocation, 
localStorage, etc  APIs [2]). Additionally, various de-jure standard Javascript 
libararies are often downloaded and utilized (e.g. JQuery []). But again, those 
libraries are limited to the same native client side APIs that main web 
application client-side Javascript modules have access to. The standardized 
native client side APIs do not include cryptographic functions at this time.

This position paper presents motivations for specifying a native in-browser 
cryptographic Application Programming Interface (API) facilitating developer 
access to basic cryptographic functions -- that are already part of the browser 
or its execution environment -- similar to what is available to application 
programmers developing directly on typical operating system platforms.

 > Motivations
 >
 > More and more applications are moving to the "web" (i.e.,
 > http://www.example.com:80 and http://www.example.com:443).

More and more applications are moving to the "web" (i.e.,
HTTP + HTML + Javascript + other stuff as appropriate).

 > 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.
                                                      ^
                                                    insert:

For example, for some applications there is a need to apply data-origin 
message-level authentication and possibly encryption to objects exchanged 
between the browser and other network entities.

 > As a work around,
 > developers are investigating the use of JavaScript Object Notation
 > (JSON) for application layer security protocols and cryptographic
 > algorithms.

As a work around,
developers are investigating the use of JavaScript Object Notation
(JSON) for application layer security protocols, as well as implenting various 
cryptographic functions directly in Javascript libraries (Javascript libraries 
are typically stored at well-known web addresses and fetched as needed by any 
web application needing them).

New para here:

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

Use of JSON as an object encoding construct makes sense in a web application 
layer security protocol. Hoever, developers rolling and then delivering their 
own cryptographic libraries is wasteful when the browsers' already existing 
cryptographic functions are just an "Application Programming Interface (API) 
away". The various functions that could be made available via such APIs are: 
message digest/hash algorithms, digital signature algorithms, content 
encryption algorithms, key wrap algorithms, keyed-Hash Message Authentication 
Code (HMAC) algorithms, etc.

 > Downloading cryptographic algorithms is wasteful in terms of bandwidth
 > used.

delete above -- it was already said immediately above.

combine this..
 > 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.
..with "Use of JSON..." para.

s/algorithms/libraries/

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

above sentence was moved upwards.

 >
 > Developers rolling their own cryptographic code could be insecure.

Developers rolling their own new cryptographic code will almost certainly begat 
insecure functionality.

 >  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
                 ^^^^^^^^^^         ^^^^^
                functions         implemented

 > 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.                              ^^^^^^^^^^
                                                       functions

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

add references:

[1]  http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/

[2]  http://blog.frontendforce.com/2010/04/html5-javascript-api-whats-new/
      see also pages 20 & 21 of..
     http://www.ietf.org/proceedings/80/slides/plenaryt-6.pdf

 > _______________________________________________
end

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 27 Apr 2011 23:34:02 -0400

Jeff, thanks for the feedback. I just arrived in Princeton for another
W3C workshop (on web tracking and user privacy) and I need to submit the
position paper today (I think that means in the next 30 minutes), so
I'll try to incorporate as much of your feedback as possible.

On 4/27/11 8:22 PM, =JeffH wrote:
> Glad you folks are putting this together and that PSA will be there with
> an IETF hat on.
> 
> I'm supportive of everyone's feedback on this so far. Below's my
> editorial suggestions, applied to the original version of the writeup. I
> found it a bit confusing terminology- and organization-wise. I'm sorta
> guessing about some of the intent/context, but took a stab at enhancing it.
> 
> Basically, I'd spell things out in a bit more contextual detail because
> if one isn't mired in the middle of all this web and web browser stuff,
> it can be pretty confusing.
> 
> Today, Web applications are constructed from a combination of server
> side code and dynamically-downloaded client side amalgamations of HTML
> and Javascript (plus other components). The formally standardized
> environment the client-side Javascript programmer has to work with is
> provided by the browser implementation (e.g. the DOM Core [1], CSS
> Selectors, Geolocation, localStorage, etc  APIs [2]). Additionally,
> various de-jure standard Javascript libararies are often downloaded and
> utilized (e.g. JQuery []). But again, those libraries are limited to the
> same native client side APIs that main web application client-side
> Javascript modules have access to. The standardized native client side
> APIs do not include cryptographic functions at this time.
> 
> This position paper presents motivations for specifying a native
> in-browser cryptographic Application Programming Interface (API)
> facilitating developer access to basic cryptographic functions -- that
> are already part of the browser or its execution environment -- similar
> to what is available to application programmers developing directly on
> typical operating system platforms.
> 
> 
> 
>> Motivations
>>
> message-level authentication and possibly encryption to objects
> exchanged between the browser and other network entities.
> 
>> As a work around,
> (JSON) for application layer security protocols, as well as implenting
> various cryptographic functions directly in Javascript libraries
> (Javascript libraries are typically stored at well-known web addresses
> and fetched as needed by any web application needing them).
> 
> 
> New para here:
> 
> Use of JSON as an object encoding construct makes sense in a web
> application layer security protocol. Hoever, developers rolling and then
> delivering their own cryptographic libraries is wasteful when the
> browsers' already existing cryptographic functions are just an
> "Application Programming Interface (API) away". The various functions
> that could be made available via such APIs are: 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 new cryptographic code will almost
> certainly begat insecure functionality.
> 
>>  As
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Apr 2011 00:05:04 -0400

> I'll try to incorporate as much of your feedback as possible.

See attached PDF file for what I submitted.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/