WebSigning PKI Workshop 2006

1
Signing form data on the Web Presented on NISTs
PKI Workshop 5th of April, 2006 Anders
RundgrenPrincipal EngineerRSA
Security arundgren_at_rsasecurity.com, 46 709 41
48 02
Disclaimer This paper only represents the
authors 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
  departmentor 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)

1. When the user indicates he or she is ready, the
   information systemgenerates a signature request
   in a format that invokes the WebSigner.
2. When the user has completed the signature
   process, the WebSignerreturns a matching
   signature to the requesting information system.
3. 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 Alternative Fat Clients
StructuredMessaging

• The upside
• Highest possible functionality and performance
• For frequently used applications more or less a
  necessity The 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

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