Chair: Joseph Reagle
Note Taker: Joseph Reagle [text]
- Joseph Reagle, W3C
- Blair Dillaway, Microsoft
- Ed Simon, Entrust
- Shivaram Mysore, Sun Microsystems
- Frederick Hirsch, Zolera
- Katherine Betz, IBM
- Eric E. Cohen, PricewaterhouseCoopers LLP
- Daniel Toth, Ford
- Donald Eastlake 3rd, Motorola
- Mark Scherling, RSA
Status of documents < 5 minutes
- Requirements - Waiting on W3C process to publish as a W3C
- Syntax and Processing - still needs a lot of editing work.
- Eastlake: draft a more complete algorithm section include
algorithm profiles and IV checksum cipher text values.
- Maruyama: update the Encryption/Signature Transform. Update
Security Considerations, add a scenario or two (and maybe borrow
"enc:DataRef" instead of using "EncryptedReference").
- Maruyama: an email exploring the question of our processing
model and the relationship between DOM, Infoset, and serialization
and the issue related to using current parsers to get a pointer to
a byte where element starting "<" is.
- Reagle: "Review the use of a URI versus an ID and NameKey
in an EncryptedKey element?"
Reagle: Write an email describing options with respect
to reuse of dsig KeyInfo.
- Reagle: Inform Don Davis of new requirements document when
complete and that issue 6.2 was dropped.
Amir's request for OEAP: "furthermore using MAC may not be
feasible if we use public key encryption and the parties do not
(wish to) share a key.... However this does not address the problem
for public key encryption; in this what is needed really is
plaintext-aware encryption such as RSA-OEAP, already specified for
key transport. "
- Dillaway: Ok with this specification as long as it remains
- Reagle: I don't recall if at the
FTF when we said, "4.2.7 ... at least one encryption + checksum
category will be included; AES with SHA1 and 3DES with SHA1"
whether it was optional or required to implement?
- (Group's recollection was that it was optional.)
- Resolution: if someone specified it, we'll consider it.
- Also, can anyone provide me a pointer to an OEAP definition in
- (Eastlake finds
- (Reagle: I've run into this problem before, is it OAEP or
DSIG schema reuse
- Action: Reagle/Dillaway/(everyone): try to get schema experts
to have a look at the 3 options outlined.
Data/Processing Model (Infoset or DOM)
- Reagle: we have to choose a data model, should we do Infoset,
DOM, XPath/C14N/ XML Query, etc.? Need to consider what information
the data model provides, does it have URIs to identify its
structures, and does it have a specified serialization (or we have
to do our own?)
- Reagle: One easy issue, I proposed that we encrypt XML
documents as a bag of bits with text/xml. Resolution: no
- DOM or Infoset?
- Simon: the serialization needs to be
- Reagle: DOM
Level 3 is supposed to have a serialization method.
- Dillaway: (later) found DOM Load and
DOMWriter interface with as-is formatting.
- Reagle: If we use this, how much of DOM do we have to support?
(Similar question to use schema for our structures, does that
necessitate complete schema implementation/compliance: hopefully
not.) Could we still work with an event based parser?
- Reagle: Also, minimal c14n from dsig might do
- Eastlake: minimal c14n did character and line feed
normalization. Also, full canonicalization could be an option?
- Reagle: no optionality, the application does what it wants
(including full Canonical XML) to the XML before it Encrypts. The
encryption itself should have a mandatory single/simple
- Reagle: If we went the simple route, do I need to preserve that
information (like a namespace from its parents) or not?
- Simon: Again, the application should tweak the XML as it
requires including any namespace normalization prior to
- Eastlake: If we take an element and encrypt it, do you need to
know what character encoding of it was?
- Blair: the draft says always convert to UTF-8 prior to
encoding, when decrypt put it in its parents form.
- (Everyone agrees this still sounds like the right
- Group: No advocate for changing syntax yet (plus no specific
proposal on table), instead feel this is an application issue
people need to be careful with.
- Simon: encrypting references to hide the fact that the same
symmetric key is used sounds like security through obscurity.
- Dillaway: agree, someone could still try their symmetric key
against other EncryptedData objects and see what falls out.
- Reagle: so what text are we happiest with.
- Group: supports inclusion of text 3 and 4, while leaning
Signing and Encrypting
- Reagle: any thoughts on the Wang, Ashwood, Herzberg
- Group: no comments, will wait for specific proposals resulting
from its conclusion.
- Reagle: Next call on the16th. I will be in Asia April 25 - May
8 for WWW10/W3C-AC and Europe from May 22 -May 29th for XML 2001
Europe. So my productivity and ability to convene teleconferences
will be low but discussion can happen on list and I can still have
a bridge made available for discussion.
- Reagle: Also, reminder to ourselves to think about FTF in