Re: AW: [dss-x] Re: AW: encryption profile

[Clemens Orthacker <clemens.orthacker@a-sit.at>]

Hi Detlef,

Thanks for your input. See my comments below. I will provide the updated 
schema in the documents area.

Am Donnerstag, 8. November 2007 schrieb Huehnlein, Detlef:
> 1. a) The "SimpleContent" and "ComplexContent" choices in the
> EncryptRequest should be part of the InputDocuments-element (either
> directly - if
>       we could manage the change the DSS-Core at this point or define a
>       new dsse:InputDocuments-element, which especially contains these
>       alternatives - or as child of the Other-element).
>    b) In a similar fashion the documents to be decrypted (either
> EncryptedDataDocument or CipherData) in DecryptRequest should be part of
> the (redesigned?) InputDocuments-element. 

I basically agree. However, in order to stay consistent with the DSS 
architecture (separating commands in OptionalInputs from data in 
InputDocuments), I propose to put the encryption structures 
(SimpleContent/ComplexContent) in the OptionalInputs and reference the actual 
data from InputDocuments. The combination of encryption and signing can be 
achieved by taking into account the order of signing and encryption elements 
in OptionalInputs, similarely to what WS-Security (order in wss:Security 
header) does. Of course we must introduce a possibility to bypass the DSS 
Basic (signing) Processing (e.g. some kind of <SkipBasicProcessing/> switch 
in OptionalInputs) for encryption only requests.

To allow for Encryption-only implementations, I however strongly recommend the 
additional definition of an Encryption protocol (En/DecryptRequest/Response 
message). The structure of such a request basically consists of 
OptionalInputs and InputDocuments, just as the dss:SignRequest; its 
processing definition however allows encryption relevant structures only.

Now, the nice thing is that we could basically include any "enc command" 
(Opaque/StructuredData for encryption, or EncryptedOpaque/StructuredData for 
decryption) in the OptionalInputs of any request (whether dss:Sign- or 
dss:VerifyRequest) and combine them with signature creation and verification. 
(Usually, you would combine signature and encryption requests, but who says 
that a VerifyRequest also has to decrypt the provided data?)
Of course we need some further discussion here. I will provide examples, 
anyway.

> 2. It might be better to derive 
> the dsse:SimpleContentType from
>    dss:DocumentBaseType instead of xs:base64Binary. Furthermore it
>    should be discussed, whether this also should happen for the
> CipherDataType or whether our CipherDataType might better be derived from
> xenc:CipherDataType. 

OpaqueDataType (formerly SimpleContentType) does not directly contain the 
base64 payload, but references either dss:Base64Data (which extends 
xs:base64Binary) or dss:TransformedData (which contains Base64Data)

> 3. "SimpleContent" and "ComplexContent" might be 
> renamed to
>    "OpaqueData" and "StructuredData" respectively.

Done. I also renamed EncryptedDataDocType and CipherDataType to 
EncryptedStructuredDataType and EncryptedOpaqueDataType, resp.
I also renamed InsertContentType to InsertOpaqueDataType, however I left the 
element names (ReplaceContent and InsertContent) within StructuredDataType as 
they were.
Renamed EncryptedStructuredData/EncryptedContentSelector to 
EncryptedDataSelector.


> 4. a) The encryptionAlgorithm-Attribute in EncryptRequestType should be
>       renamed to ContentEncryptionMethod to better reflect the fact that
>       it specifies the (usually symmetric) algorithm to encrypt the
> content. b) Furthermore it should be discussed whether having a URI here is
> sufficient for all cases. How would we distinguish between 2-key Triple-DES
> and 3-key Triple-DES in this case or define a specific IV to be used for
> encryption? Hence we should think about using an element of type
> xenc:EncryptionMethodType here, which contains among other optional
> elements the URI for the algorithm. c) In a similar fashion it might be
> necessary to explicitely specify the KeyEncryptionMethod as one could want
> to use OAEP instead of PKCS#1 v1.5 for the same RSA-certificate, which
> would be specified in the ds:KeyInfo within the EncKeySelector-element.

I inserted optional Key/ContentEncryptionMethod elements (of type 
xenc:EncryptionMethod) in EncKeySelectorType and EncryptRequestType, resp.
ContentEncyptionMethod should go to the OptionalInputs rather than to 
EncryptRequest, however. (TODO)

> 5. 
> Within the EncKeySelectorType (should it better be called
> RecipientsKeyInfo?) it would be nice, if one could use other elements
> directly without having the Other-element (cf. #1). Furthermore the
> certValidation-Attribute should probably better be specified as URI to
> allow (e.g. in profiles) different (and more sophisticated) verification
> policies, which might include returning a more comprehensive verification
> report structure as optional output. 

I didn't rename EncKeySelectorType to RecipientsKeyInfo in order to avoid 
confusion with the Recipients in dss:IntendedAudience.
The certValidation was changed to xs:anyURI, defaulting to a (to be defined) 
URN for the warning policy.

+1 for the removal of the dss:Other element, and again I would propose to make 
the type of dss:KeySelector public so that we can extend it here.

> 6. Should it be possible to 
> explicitely specify the key which shall be used for decryption (as some
> sort of optional KeySelector-element) in the DecryptRequest-element?

Definetely. (TODO)


Regards
Clemens




>
> I'm looking forward to further discussing the above issues.
>
> Best regards,
>    Detlef
>
> > -----Ursprüngliche Nachricht-----
> > Von: Clemens Orthacker [mailto:clemens.orthacker@a-sit.at]
> > Gesendet: Dienstag, 16. Oktober 2007 10:24
> > An: dss-x@lists.oasis-open.org
> > Betreff: [dss-x] Re: AW: encryption profile
> >
> > Hi Detlef,
> >
> > Am Montag, 15. Oktober 2007 schrieben Sie:
> > > Hi Clemens,
> > >
> > > to define a DSS-like interface for encryption (of (parts of) XML
> > > documents or other binary data) is a great idea and I hope that we
> > > will be able to standardize such an interface in DSS-X soon.
> >
> > Thanks a lot for your interest and the comments.
> >
> > > Below you will find some questions and comments concerning
> >
> > the raised
> >
> > > issues.
> > >
> > > [...]
> > >
> > > The necessity of the first two use cases is clear to me,
> >
> > but I'm not
> >
> > > sure, whether we really need the third use case (INSERT).
> > > It seems to me that one may first insert the binary data into an
> > > XML-document and then get the relevant parts encrypted (as in the
> > > first use case, REPLACE).
> > >
> > > Is there a particular reason, why we need to support the third use
> > > case in the interface? It seems that an interface, which
> >
> > only covers
> >
> > > the first two cases might be equally powerful, but considerably
> > > simpler and more DSS-like.
> >
> > I think there are two arguments for the INSERT use case:
> > First, one might want to keep the content to be encrypted out
> > of the target document's context. For XML content to be
> > encrypted, for example, consider contained ID attributes that
> > conflict with the target document or certain namespace issues.
> > Second, to facilitate transmission, the inserted content
> > (e.g. a logo image) could be referenced (see the schema for
> > details) and cached for later re-use.
> > (Further, we might allow SwA references in the request
> > element holding the content to be encrypted, which of course
> > is outdated and using MTOM transport we anyway could include
> > the content in the target document. Still this would allow
> > for some backwards compatibility...) Anyway, I'm quite
> > convinced that there are many cases where it makes no sense
> > to include the plaintext data in the target document which
> > justifies the INSERT use case. (Probably we should make it
> > optional - a profile to the encryption protocol? however,
> > there is not much overhead in implementing it, so I advocate
> > leaving it in.)
> >
> > > Yes, therefore it might be better to define a separate encryption
> > > protocol. However I'm not sure, whether this would cause a conflict
> > > with the defined scope of DSS-X.
> >
> > I should have mentioned this on yesterday's telcon. The TC
> > has to decide. I will post a message on that specific issue
> > on the list. Probably we could decide on this on the next meeting.
> >
> > > Wouldn't it be possible to use the URI
> > > http://www.w3.org/TR/xmlenc-core/ for XMLEnc and
> > > urn:oid:1.2.840.113549.1.7.3 (i.e. the OID of EnvelopedData) or (as
> > > the encryption-context is clear) even urn:ietf:rfc:3369 for
> > > CMS-encryption?
> >
> > I just noticed there was some discussion on this in the
> > former DSS TC, so I wanted to have this discussed here. I
> > think instead of http://www.w3.org/TR/xmlenc-core/ we should
> > use the xenc namespace URI http://www.w3.org/2001/04/xmlenc#
> >
> > > Yes, but the Core should stay fixed, right?
> >
> > We're currently discussing several additions/amandements to
> > the Core. I will post a message on that issue as well.
> >
> > > > EP4. Should <dss:IntendedAudience> be used to specify the
> >
> > encryption
> >
> > > > keys to be used (in addition/alternative to EncKeySelector)?
> > >
> > > This would imply that the encryption service needs to have this
> > > "directory capability". Hence this should probably better
> >
> > be optional.
> >
> > Right.
> >
> > > > EP5. alternative propositions for element/type names:
> > > >  - SimpleContentType
> > > >  - ComplexContentType
> > > >  - InsertContentType (Base64Content)
> > > >  - CipherData
> > > >  - EncryptedDataDocument
> > >
> > > If we would confine ourselves to the first two use cases (REPLACE,
> > > CREATE) then (as far as I see it right now) we do not need these
> > > additional structures. The Input and Output objects would be entire
> > > documents.
> >
> > We still would need them (encryption of non-XML binary data,
> > XMLEnc referenced cipher data via xenc:CipherReference, ...)
> >
> >
> > Thank you
> > Clemens
> >
> >
> > --
> > Clemens Orthacker  A-SIT, Graz University of Technology
> > Inffeldgasse 16a, 8010 Graz, Austria
> > Tel: +43 316 873 5512         Web: http://www.a-sit.at/



-- 
Clemens Orthacker  A-SIT, Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria
Tel: +43 316 873 5512         Web: http://www.a-sit.at/