Loading in 2 Seconds...
Loading in 2 Seconds...
Signing form data on the Web Presented on NIST’s PKI Workshop 5:th of April, 2006 Anders Rundgren Principal Engineer RSA Security email@example.com , + 46 709 41 48 02. Disclaimer: This paper only represents the author’s own opinions and should not
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Presented on NIST’s PKI Workshop 5:th of April, 2006
Anders RundgrenPrincipal EngineerRSA Security
firstname.lastname@example.org, + 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
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
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.
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.
N/A (more or less...)
*) 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
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
To create and validate complex XML messages in a stand-alone mode, is hard for users, in addition to being highly error-prone.
“Missing”(added by backend)
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.
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)
* 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.
+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 dependentNot applicable in a C2G-environment
StructuredMessagingThe Alternative – “Fat” Clients
How do you validate and representa signed message for a user?
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.
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.
Problem: Current WebSigning solutionsare both proprietary, non-interoperable,and all-over-the map
Summary: There are numerous reasonsfor a standardization effort…