Encryption profile (DSSE) Hot Stuff
Work on hot spots
For details see EncryptionProfile. The remaining issues are (by order of criticality):
EncryptedDocument inheritance? Find a way to include EncryptedDocument as DocumentWithSignature document child [CRITICAL]
By default, sign before encryption. Introduce dsse:DetachedSignature element to change default behaviour. dss:SignedReferences (other elements?) imply signature operation (and new element is ignored?)
Discuss use cases for InsertEncryptedDataType. Do we really need this (keep it simple)? (value for EncryptedData@Type? omit, 'content', new value?)
- Insertion of xmlenc-decrypt transformation only if requested in signedreferences? (difficult when using xpointer?)
[?] ds:Reference URI attribute for detached signatures?
- [?] discuss use case enveloping signature prior to encryption
- The combination of CMS signature and CMS encryption was not yet further investigated. Any experts in CMS present?
- Definition of URNs. (profile, cms, ...), profile versioning
- DONE Different encryption formats (XMLEnc, CMS, CCE, ...) will be supported
SelectorNamespace: how to provide context for XPath expressions?
DSSE namespace and Profile URI differ? version? urn:oasis:names:tc:dss:1.0:profiles:encryption:schema:1.0
EncryptionContent: attribute name=CipherReference type=xs:anyURI or attribute name=CipherValueId type=xs:string?
- provide decryption and verifysignature combination? (probably only verifysignature + decryption?)
-> decrypted document in optional outputs (if it was requested)
- OR decrypt only as specified in transforms (xmlenc-decrypt)
- in any case streaming is NOT supported (if nested decryptions requested)
- CMS decryption + verificytion?
Impact on other profiles
What other profiles can potentially be combined with the encryption profile?
Impact on Core Version 1.0
RESOLVED(?): The dss:SignedReferences element merely groups the individual dss:SignedReference elements. It could be removed in order to allow the arbitrary combination of signing and encryption operations. dss:SignedReference could appear directly in dss:OptionalInput.  This is not an issue, the dss:SignedReferences is atomic for the signature; encryption is done before or after the signature operation.
RESOLVED(f2f) Make dss:KeySelectorType a top level type, so that dsse:EncryptionKeySelectorType can extend it.
In order to stay consistent with DSS core, the DestinationSelectorType should be adjusted. The provided solution with an optional FirstChild boolean attribute seems simpler than a choice between XPathAfter and XPathFirstChildOf (see dss:SignaturePlacement). For backwards compatibility, this should probably rather be changed in DSSE.