Just FYI, please reply on the apps-discuss list if you have feedback. -------- Original Message -------- Subject: [apps-discuss] Position Paper for W3C Identity in the Browser Workshop Date: Tue, 26 Apr 2011 11:12:02 -0600 From: Peter Saint-Andre <[email protected]> To: [email protected] <[email protected]> CC: Sean Turner <[email protected]>
Folks, over on the SAAG list, Sean Turner and Stephen Farrell have posted a draft position paper for the upcoming W3C Workshop on Identity in the Browser: http://www.ietf.org/mail-archive/web/saag/current/msg03201.html http://www.w3.org/2011/identity-ws/ Because neither Sean nor Stephen will be able to attend the workshop, I offered to help them by co-authoring the position paper and presenting about the topic if the proposal is accepted. Since this proposal straddles the line between apps and security, I figured it would be good to get feedback from the AppsArea community before we submit the proposal (the deadline is tomorrow, sorry about the late notice). Your feedback is welcome. Thanks! Peter ### Submitters Sean Turner Stephen Farrell Peter Saint-Andre Abstract This position paper advocates an Application Programming Interface (API) that will enable developers access to cryptographic algorithms already present in today's web browsers. Motivations More and more applications are moving to the "web" (e.g., http://app.example.com:80 and https://app.example.com:443). Developers are working within the confines of various browsers to secure these applications, and most use Secure Sockets Layer (SSL)/Transport Security Layer (TLS) to do so. This reliance is not sub-optimal for applications whose architectures are not strictly client-server (e.g., IM and VoIP). As a workaround, developers are currently investigating the creation of new Javascript-based cryptography libraries, along with new formats for signed and encrypted objects based on JavaScript Object Notation (JSON). Use of JSON makes some sense in an application layer security protocol. However, it makes less sense for developers to roll (and deliver) their own cryptographic algorithms -- it's not only wasteful, it's also dangerous when the browser's security "goodies" (i.e., the cryptographic algorithms) are just an 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 lose 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. Such cryptographic code could include message digest/hash algorithms, digital signature algorithms, content encryption algorithms, key wrap algorithms, and keyed-Hash Message Authentication Code (HMAC) algorithms. This kind of code is typically not small because of the significant math involved in producing strong security. However, the greatest danger here is not a waste of bandwidth, but possible security breaches. Obviously, downloading cryptographic algorithms is an easy attack vector if not done over SSL/TLS. But the real challenge is that security is hard. As Steve Bellovin pointed out in RFC 5406, the design of security protocols is a subtle and difficult art. In fact, coding security protocols is even more subtle and difficult than designing security protocols. 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. Given that cryptographic algorithms alread coded into browsers (and that some of them have already been evaluated by the U.S. National Institute of Standards and Technology (NIST) for compliance with Federal Information Processing Publication (FIPS PUB) 140), it seems unnecessarily risky to not make use of the cryptographic algorithms already present in the browser. A consistent API for access to those algorithms would provide a strong foundation for securing the web. Goals We propose that a consistent web security API would support the following algorithms and functions: o Hash/message digest algorithms (e.g., SHA-256) o Digital signatures algorithms (e.g., RSA PKCS#1 v1.5, ECDSA) o Confidentiality algorithms (e.g., AES) o Key transport/agreement algorithms (e.g., RSA PKCS#1 v1.5, ECDH) o HMAC algorithms (e.g., HMAC-SHA1, HMAC-SHA256) o Methods for extracting keys from TLS sessions (e.g., using RFC 5176) o Methods for PKI path validation (e.g., input/output of base64 certificate/CRL blobs) o Methods for generating and processing Cryptographic Message Syntax (CMS) ### -- Peter Saint-Andre https://stpeter.im/
_______________________________________________ apps-discuss mailing list [email protected] https://www.ietf.org/mailman/listinfo/apps-discuss
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
