XML Encryption guidance issue

[<Frederick.Hirsch@nokia.com>]

This message is in response to the discussion on XML Encryption
guidance, and is also to close an action item from the 24 August Focus
group call [1], item #4 
"Frederick to get it started with a message summarizing some of the
relevant fields."

Note that I sent a separate message regarding mandatory algorithms [2].

The proposed schema revision from Scott [3] should be helpful, because
it clarifies that an EncryptedKey element may be associated with a
single EncryptedData element in the EncryptedElement type. This
clarifies how an EncryptedKey may be associated with an EncryptedData
element. For this reason we could indicate that an EncryptedKey
ReferenceList is not required, nor is an EncryptedKey CarriedName, but
it does not seem necessary and could preclude deployments where these
are useful for other reasons.. Because the EncryptedKey is optional we
may wish to state when it is recommended to use.

I am not aware of use cases that require a more complicated usage
involving multiple recipients since the specifications outline the
recipients of encrypted items.  

Super-encryption, which means encrypting content that includes encrypted
content, is not specified in the SAML specifications, but this does not
mean it couldn't occur in a SOAP messaging component of the system - but
the SAML specifications are silent on the topic and I believe this is
appropriate.

Key management is something very specific to deployments and I am
hesitant to suggest restrictions. Thus general restrictions on
ds:KeyInfo should be out of scope, although clearly the topic needs to
be addressed for specific deployments.

We can re-iterate the XML Digital Signature recommendation against use
of MgmtData but this doesn't seem particularly useful or necessary.

Thus I do not see need for specific recommendations regarding XML
Encryption apart from the algorithms conformance and the clarification
of when we expect EncryptedKey to be generally used for EncryptedData
and conveyed together as noted in the schema. We should remain silent on
Key exchange, identification and management.


thanks

regards, Frederick

Frederick Hirsch
Nokia

[1]
http://lists.oasis-open.org/archives/security-services/200408/msg00199.h
tml

[2]
http://lists.oasis-open.org/archives/security-services/200408/msg00214.h
tml

[3]
http://lists.oasis-open.org/archives/security-services/200408/msg00218.h
tml


-----Original Message-----
From: ext Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Monday, August 23, 2004 11:54 AM
To: 'de Freitas, John'; security-services@lists.oasis-open.org
Subject: RE: [security-services] comments on SAMLCore CD 01
...
> In general - There is little guidance with regards to XML Encryption. 
> It would help to offer some guidelines in areas like recommended 
> algorithms (as is done with SSL/TLS), encryption by different parties,

> super-encryption, etc. Some
> (non-normative) examples would be especially useful.

The SSL algorithm stuff should be in conformance as it is. There are no
use cases for encryption by different parties, although I suppose
nothing precludes it and I don't know what we would need to say. Not
sure what guidance would be needed for super-encryption either.

As far as I could tell, the only profiling needed that isn't
conformance-related is how to use some of the referencing options and
key-passing elements. As it is, it's not a big deal because there aren't
really security implications to any of that the way there were with
signature transforms.

I would be hesitant to start heavily profiling XML Encryption at this
stage, and as long as we aren't changing schema, it's something that
could be done in a future revision.

-- Scott


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/security-services/members/l
eave_workgroup.php.