Participants

Joseph Reagle, W3C

Blair Dillaway, Microsoft

Ed Simon, XMLsec

Christian Geuer-Pollmann, University of Siegen

Eric Cohen, PwC

News

Status of documents

Last Call ended November 9th. I've sent a nagmail to SOAP, SAML, and
Schema WGs since I got them to agree to consider the Last Call, but they
never responded with a date of response -- nor comments obviously.

Should we add a warning into section "3.1 EncryptedType" that it is
not allowed (or could cause problems) if an EncryptedData element
becomes the DocumentElement of a new Document with
@Type="ElementContent" ?

ACTION Reagle: add warning text on this point if it doesn't
already exist, "decrypted content may not be well-formed XML."

Should a nonce be associated with an EncryptedKey? A nonce cannot
be used for encrypting a key, right? So I just thought that, if a
user was trying to use a nonce for encrypting a key, it would be
helpful to warn the user of the illegal use of nonce. Our
implementation just ignores such a nonce, though.

Reagle: I expect I'm not understanding the issue well, while I
appreciate the algorithm itself might provide for a nonce, how would
this redundancy hurt anything?

Dillaway: agrees with Takeshi, EncryptedKey shouldn't have a nonce
because it can complicate the algorithms. For example, some
algorithms expect particular key sizes that this would confuse.

Does this support "new combined "encryption+integrity" modes of
operation

Yes, one can specify the approriate algorithm and identifier."

"You have provisions for referring to some elements indirectly
(e.g. through a URI), but you may need some way to ensure that what
you retrieve is what was intended (e.g. through a hash of the element
to be retrieved). Perhaps this is implicitly handled already..."

Dillaway: this might be accomplished via a Transform that contains
a digest within a CipherReference.

ACTION Simon: send email to a list exploring this scenario.

"There are of modes of encryption that won't fit your model, but
which are very useful. For example, "secret-sharing" allows
encryption of a document into several pieces, or shares, in such a
way that a requisite number of them are required to
decrypt/reconstruct the document. Just be sure you don't preclude
somehow expansion to handle this sort of thing later on."

Dillaway: way back when, we decided not to address threshold
schemes. When Barb Fox asked the question, there was a resounding
"no." However, I don't have a prolbem with someone layering it on top
of what we specified.

Reagle: do we then have some obligation to show how it can be
done? Is anyone interested in this enough to take that on?

Dillaway: Might have time in three weeks time.

Simon: Perhaps we could ask Rivest to point out if it can't be
done.

"I'm very uncomfortable with allowing the encryption algorithm to
be "understood" between the sender and the recipient; you should
force the sender to be explicit. Non-explicitness is the cause of
very many protocol failures."

Reagle: we made SignatureMethod optional in xmldsig...

Dillaway: Agrees it can be dangerous, but its difficult to keep
people from doing it in their protocol if they always use a
particular algorithm, just seems redundant to them then.

Reagle: Do people on this call support any scenarios presently
where this information isn't sent?

Dillaway: Not yet, but I can think of a couple of protocol
scenarios where this is unnecessary overhead.

ACTION Reagle: add warning text if there's a place where it seem
approriate, assume they both know and they are wrong.

Reagle: is there a security problem when it relates to signing,
where someone signs the ciphertext, but subsitutes a different
message with different algorith?... Suppose not, as we already say if
people want to secure plain text, that's what they need to sign.

Nonce and Key Wrap Algorithm: "It seems to me that with the key
wrap algorithm specified in section 5.6.2, there is no way a nonce
can be used, although you may still set up one in the corresponding
CipherData element by the document."

<AgreementMethod> question. "it doesn't look like XML
Encryption actually specifies the logistics to perform the key
agreement without also specifying actual encrypted data, which is
impossible because the shared key hasn't been generated "