RE: [security-services] XML Encryption guidance issue

["Scott Cantor" <cantor.2@osu.edu>]

See inline...

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

It did occur to me that we might want to enable an issuer to encrypt
multiple elements (say, attributes) with a single key, and then pass the
wrapped key only once within one of the elements, and in such a case, some
kind of signal that this was happening could be useful.

But in separate discussions with various people, this idea wasn't received
well anyway for security reasons.

If we expect people to use distinct encryption keys for encrypting multiple
elements in the same message, I think we should say that though. Gary
Ellison noted that usng an OOB symmetric key to encrypt the encryption keys
used is likely to be useful in such a case to make the process efficient.

But all of this convinces me that somebody with more background in this area
than me should be making these kinds of calls.

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

Well, it could happen with SAML quite easily such as an encrypted assertion
that contains an EncryptedID or EncryptedAttribute. The question is, do we
need to say anything about it? I'm not sure why encrypting an element that
happens to have stuff from the XMLEnc spec in it is different from any other
element.

Of course, the base64 issue comes up if you're validating, but this isn't
specific to super-encryption.

-- Scott