Document Encryption - Discussion

Introduction

This page captures discussion items related to the development of the IHE Document Encryption (DEN) profile. Specifically it holds the closed issues list which was removed from the DEN supplement when it went to Trial Implementation.

Closed Issues

Closed Issue 1: Multiple encrypted documents in same transaction / submission set / medium / etc.

Status: added recommendation to key management section in case of encryption of multiple documents that are together to 1) apply same algorithms and other parameters, and 2) use same keys/passwords for a recipient in (the unlikely) case there is choice for such recipient.

Closed Issue 2: Policy aspects out of scope

Status: added statement in security considerations section and/or introduction that policy aspects are out of scope. Policy aspects may be general (regulatory, organizational) policies defining when encryption must take place or relate to e.g. consent policies (BPPC). In later stage may consider appendix to discuss profiles combination to obtain certain result, e.g. BPPC and Document Encryption.

Closed Issue 3: Key Management out of scope

Key management is in general out of scope of this profile. However, this profile acknowledges that key management is an important aspect of any encryption solution. For this purpose this profile puts requirements on the minimal key management hooks that the encryption solution should provide for. Also, certain key management solutions like password-based encryption are so straightforward that they are typically integral part of an encryption solution with little keys to manage. On the other side, more advanced or flexible key management solutions typically have to be carefully chosen in relation to the applicable environment, which may already have a particular infrastructure. For this purpose, this profile does not choose a particular technology but limits itself to the hooks / interfaces to key management.

Status: added text to abstract/introduction and key management section

Closed Issue 4: Selective encryption of documents in (XDM/XDR/XDS) submission set

Status: added use case “Partial encrypted submission set”

Closed Issue 5: XDM Media Encryption option

XDM over media lacks a means to protect the XDM media content like for XDS, XDR and XDM Zip-over-E-mail. Document Encryption can encrypt individual XDM payload documents, but not transactional data and transaction structure, submission set metadata, document metadata. Such data is typically used to route the document(s). XDM uses a file system structure to organize the data in files:

<< image >>

Conclusion:

• Supplement includes “XDM Media Encryption” option that extends the XDM profile to protect XDM media content on physical media (similar to XDM Zip-over-E-mail). Where possible the solution will be technically aligned with the new Document Encryption profile which can protect generic documents.
• Supplement discusses application of Document Encryption profile in context of XDM (and XDR) to encrypt individual documents within XDM media content. Supports cases where complete XDM media content encryption is too course.
• Separate (partial) encryption of metadata, etc., is out of scope for this supplement. It integrates too deep with the XDM specification and would enlarge the scope of this work too much. Similar arguments hold for encryption of submission sets within XDM media content. The two options above (XDM Media Encryption and Document Encryption) have sufficient scope to address a broad range of use cases.

Closed Issue 6: Profile type selection

Options:

• Transaction Profile
  • representative examples: XUA, ATNA (,PDI)
• Content Profile
  • representative examples: BPPC
• Change Proposal
  • representative examples: n/a

Actor and dynamic behavior requirements:

• Algorithm support (e.g. design for future backwards compatibility)
• Encryption and decryption process and responsibilities (e.g. ensure proper and secure handling)
• Key management (e.g. like password derivation requirements in PDI)
• Above aspects are also seen in e.g. PDI, ATNA and XUA

Through the virtual actors (Content Creator actor and Content Consumer actor) and default transaction (Share Content) also content profiles can constrain the behavior of its actors for Document Encryption. Consequently, the required functionality can be described without the introduction of new actors.

Conclusion:

• This supplement outputs to two profiles
• The Document Encryption profile takes the form of a content profile
• The XDM Media Encryption option takes the form of a change to the XDM profile

Closed Issue 7: Base technology selection for Document Encryption

Criteria:

• Functional soundness
  • Encryption functionality
  • Key management hooks
  • Crypto algorithm support
• Maturity and availability
• Standard (openness)
• Efficiency
• Architectural fit
  • Consistency with other IHE profiles
  • Embedding with XD*
  • Generic payload (no bias for document type)
• Well-defined technology package (constrain vs compose)
• Functional extensibility (e.g. partial document encryption)

Technology	CMS	XML Encryption	Proprietary Methods	Open License	Open Implementations	WS-* on media
example / note			Secure ZIP	PGP, Secure TAR	TrueCrypt-SingleFileMode	Implies XDR/XDS (or equivalent) to carry doc on top of SOAP. Inherits encryption functionality from XML Encryption. SOAP binding to media instead of HTTP.
Pro	• Encryption • PDI uses CMS • XDM email option uses CMS • Standard (RFC), publically controlled • Hooks for flexible key management • Mature & supported • Intrinsically supports password-based keys • Efficient handling of binary data • Well-defined package for desired functionality (few RFCs)	• Encryption • ATNA WS-Security option uses XML encryption • DSG uses XML encryption family • Standard (W3C), publically controlled • Hooks for flexible key management • Mature &supported	• Basic encryption • Password, certificate support	• Basic file encryption support	• Basic file encryption support	• ATNA for XDS/XDR allows for WS-* • Inherits pro’s from ‘XML Encryption’
Con		• Password-based keys only supported with extension (PKCS#5v2 Amendment1) • Complexity to overcome size explosion • Combination of several parts/standards required (instead of well-defined package)	• Not a publically controlled specification (especially for encryption; tight control of PKWare) • No consensus regarding encryption method (industry partitioned in PKWare and WinZip camp) • Less flexible key mgt (limited to password, possibly PKI depending on APPNOTE versionno symmetric) • Limited vendor support for APPNote implementation of strong encryption	• Not a publically controlled specification • No integrated encryption / no consistent solution package • Limited key management hooks	• Not a publically controlled specification (code = spec) • • Limited hooks for key management options	• Non-standard SOAP binding to media • SOAP and WS-* overhead for individual documents • Well-defined support for documents requires extra standard such as XDR to embed document on protocol. Creates complexity. • Inherits con’s from ‘XML Encryption’; especially password-based encryption; exception: binary data attachments are well-defined in the WS-* stack
Neutral	• Tooling support seems okay although not all implementations are clear on all features (e.g. password)	• Tooling support seems okay although not all implementations are clear on all features; no PKCS#5v2 Amendment1 (password) support

Discussion and technical findings:

• Two options to avoid 30% overhead with base64 encoding with XML encryption:
  • XOP (XML-binary Optimized Packaging, W3C):
    • “A XOP package is created by placing a serialization of the XML Infoset inside of an extensible packaging format (such a MIME Multipart/Related, see [RFC 2387]). Then, selected portions of its content that are base64-encoded binary data are extracted and re-encoded (i.e., the data is decoded from base64) and placed into the package. The locations of those selected portions are marked in the XML with a special element that links to the packaged data using URIs.” http://www.w3.org/TR/xop10
    • “at the conceptual level, this binary data can be thought of as being base64-encoded in the XML Document”
    • [Background: MTOM is XOP applied in context of SOAP; used in e.g. XDR/XDS]
  • Keep encrypted data separate from XML using <CipherReference> instead of <CipherValue>.
    • Potentially more efficient than XOP as it avoids base64 encoding and decoding altogether
    • Requires container format to combine both, e.g. mime-container (like XOP). Issue: although technically not complex, it is not specified somewhere separate (i.e. functionality covered in sections 3-5 of the XOP specification) and therefore does not come in a well-defined package
  • [In comparison: CMS does not suffer from this]
• Password key derivation for XML encryption is not integral part of the current XML encryption specification. The relevant base specification in all cases is PKCS#5v2.
  • RSA released PKCS#5v2 Amendment 1 which defines the XML schema for PKCS#5v2 in context of XML encryption. ftp://ftp.rsa.com/pub/pkcs/pkcs-5v2/pkcs-5v2-0a1.pdf
  • The work-in-progress W3C working draft for XML Encryption 1.1 is going to (release date unknown) include PKCS#5v2 based on but also technically slightly different from Amendment 1. http://www.w3.org/TR/xmlenc-core1/
  • [In comparison: CMS uses PKCS#5v2 (which defines the ASN.1 module) as standardized in RFC3211 and RFC2898]
• Symmetric keys, public/private keys, out-of-band key retrieval are supported by both CMS and XML Encryption through RecipientInfo and <KeyInfo> structures respectively.

Decision: CMS