Signing form data on the Web Presented on NIST’s PKI Workshop 5:th of April, 2006 Anders Rundgren Principal Engineer RSA

1. Signing form data on the Web Presented on NIST’s PKI Workshop 5:th of April, 2006 Anders RundgrenPrincipal EngineerRSA Security arundgren@rsasecurity.com, + 46 709 41 48 02 Disclaimer: This paper only represents the author’s own opinions and should not be taken as a statement by RSA Security

2. Signing form data on the web - Why and how? Legal requirements for digital signatures inmany e-government and e-health applications+The web has proved to be the media of choicefor mass market IT solutions    “WebSigning” is already used by millions of consumersfor on-line banking and e-government services in the EU SAFE, a recent BioPharma authentication initiative, is alsotargeting WebSigning as a primary delivery mechanism

3. Message toGovernment How do you send signed and encrypted* messages to a government agency? *) It is rather confidentiality that is wanted. This can be achieved through message encryption, but also through transport (channel) encryption.

4. Using “WebSigning” Message toGovernment By using https (for achieving confidentiality) and web signatures, it becomes comparatively easy to create secure, form-based applications. The minute application shownabove, is a basic version of a typical citizen-to-government (C2G), “data input” application on the web. The right-most display shows a web-signature dialog box, where theconsolidated and typically “frozen” message data can be reviewed, before signing and submission. “WebSigning” (when standardized and built-in), offers full user mobilitysince it does not require any additional locally installed software, here assuming that smart card drivers and similar are in place.

5. Using e-mail and S/MIME Message toGovernment N/A (more or less...) • The user have to understand and activate the security (policy) • Few S/MIME PKIs support the concept of a “department”or an “organization” only* • No easy way of retrieving encryption keys, have rathermade PGP the most widely used e-mail encryption scheme *) Due to this discrepancy between typical PKIs and the actual organization structure, the sender must know in advance who is actually going to process a message. This may not always be the case and is also not entirely logical either since there is typically more than one person in a department that processes incoming messages and tasks. In addition, if the designated individual is on vacation or similar, the message will be left unprocessed

6. StructuredMessaging How do you create, secure and sendstructured*messages? *) Structured messages in this presentation, denote messages that are intended for consumption by computer systems, rather than by humans

7. Using e-mail and S/MIME StructuredMessaging To create and validate complex XML messages in a stand-alone mode, is hard for users, in addition to being highly error-prone.

8. Using “WebSigning” StructuredMessaging “Guidance” “Missing”(added by backend) Internal only Internal + External The screen dump above shows the final display of a session where a purchaser has put goods into a virtual “shopping cart” utilizing standard web techniques. Using the web makesit possible not only to specify simple products, but to conveniently configure arbitrarily complex items such as computers and airline tickets. Note that the purchaser simultaneously signs some information that only is intended for internal use (Cost center), as well as information intended for both internal and external consumption (Order data). That buying organization, date and order number seem to be missing, is because these items are preferably added by backend processes. Order numbersare typically not created until orders are ready for transmission to suppliers. Order requests like above, may need further authorization by managers, who can also dismiss requests. Note that user signatures stay within the information system boundaries (as proofs of action), since outgoing purchase orders are, when fully authorized, created and secured by the purchasing system, not by end-users. This architectural principle is a de-facto standard for many types of business and information systems, including the payment networks usedby the financial industry, rather than being limited to purchasing systems.

9. Using “WebSigning”, continued StructuredMessaging Information system,typically based on Web Servers, SQL data-bases and “Business Logic” Outgoing messages*, using acommunity-specific messageformat (e.g. XML, EDI, ASCII),transport, and security solution Validation + Archiving Introduced by WebSigning User-oriented data and presentation format (e.g. HTML) Signature returned by the WebSigner(e.g. XML DSig) • When the user indicates he or she is ready, the information systemgenerates a signature request in a format that invokes the WebSigner. • When the user has completed the signature process, the WebSignerreturns a matching signature to the requesting information system. • After signature validation and archival, the information system maycreate an outgoing message based on the data associated with thesignature. This data is typically kept in an internal format during theweb session. Before transmitting an external message, it is securedusing a community-specific method. Invocation * Although highly interesting, how possible outgoing messages are secured is generally out-of-scope for web-signing schemes. Note though that there are use-cases, particularly in the government-to-government (G2G) space, where user signatures may indeed need to be exchanged between different parties. Such uses include citizen permit applications which involve more than one government agency. In this case, a citizen signature and associated document data, would typically only be a “payload” of an embedding message, holding agency-related data associated with the permit application.

10. The upside +Highest possible functionality and performance + For frequently used applications more or less a necessityThe somewhat darker side of fat clients… Often 3-10 times more expensive to develop, deploy and support than web solutions Hundreds of unique clients needed in a large enterprise Inflexible and static Usually highly platform dependentNot applicable in a C2G-environment StructuredMessaging The Alternative – “Fat” Clients

11. SignatureValidation How do you validate and representa signed message for a user?

12. Using e-mail and S/MIME SignatureValidation A prerequisite for performing signature validation is that trust anchors are available. The S/MIME way of communicating, implicitly creates a huge number of CAs, which makes trust anchor management less straightforward except within a “community” like provided by the US Federal PKI. Old signatures with expired certificates, also create difficulties for users. Another hurdle is that the financial sector have on some markets, begun to issue certificates requiring the verifier to have a contract and licensed validation software, which is incompatible with end-user based e-mail. Currently, few ordinary users understand how to deal with PKI and trust anchor management.

13. Using “WebSigning” SignatureValidation Using WebSigning, a service provider performs validation once, preferably immediately after receival of the signed message. How much signature information a service provider makes available for end-users vary, but is typically limited to a mark of some kind. The information system centric approach to signature validation, enables a service provider to unilaterally set policy rather than pushing down policy and trust decisions on their users. This scheme also facilitates highest possible mobility, since a user only has to carry around his/her own certificates.

14. Problem: Current WebSigning solutionsare both proprietary, non-interoperable,and all-over-the map • Basic technology choices include: • ActiveX plugins for MSIE • Platform independent Java applets • Platform dependent Java applets • Local signing web proxies Summary: There are numerous reasonsfor a standardization effort…

15. The WASP (Web Activated Signature Protocol) standards proposal • Operating system independence. WASP only relies on standard web technologies such as XML, MIME and X.509 • Device independence. WASP is designed to run on smartphones to workstations • Document format independence. Signs any browser-viewable media like TXT, HTML, JPEG, MS-Word, Adobe-PDF, etc., as well as attachments in arbitrary formats • Unified signature procedure. WASP unifies on-line signature procedures in the same way as is already the case for signed e-mail • Multiple signature formats. WASP supports XML DSig and ETSI’s XAdES (specifiable by the signature requester) • What you see is what you sign (WYSIWYS). In harmony with legal and user requirements • Thin client design. A browser distribution would be about 200K bigger in order to support WASP