[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] XML Encryption guidance issue
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]