Re: Last call comments on XML Encryption specs

Martin,

You've sent excellent feedback as always! I'm going to respond to your 
comments in two parts non-I18N and I18N. This is the non-I18N bit.

[Resulting Document
  http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/
  $Revision: 1.89 $ on $Date: 2001/12/12 22:22:54 $ GMT 
]


> Major point:
> - 2.1.5 forbids the encryption of only part of EncryptedData
>    or EncryptedKey. I don't see any particular reason for
>    forbidding this, except to make some XML Schema issues
>    easier. But I think it would be extremely valuable for the
>    WG and the spec to do this exercise and to show how the
>    Schema has to be changed to allow this.

We didn't do this because of schema issues... Though trying to design a 
schema such that its instance is *arbitrarily* encryptable while remaining 
schema valid is an exercise in complexity and some futility: every single 
element is going to be a choice of the actual element type and the 
EncryptedData structure. In fact, I expect most people in the WG feel that 
when you encrypt something you've broken the schema and that is as it 
should be. Some folks might design encryption aware schema for a few 
element types they know they want to secure. Regardless, we made this 
decision because we had no good reason to make the application processing 
any more complex than we had to. For instance, how should an application 
expect to recurse within an EncryptedData itself? We didn't see *any* 
reason to encrypt parts of an EncryptedData itself except for a key -- and 
we provide an explicit syntax and processing for that: EncryptedKey.

>    Even if this is not changed for EncryptedData or EncryptedKey,
>    there should be an extended discussion of how to change a
>    schema to work with encryption.

We spent a lot of time on this in the requirements and I think this sums it 
up:

    http://www.w3.org/TR/2001/WD-xml-encryption-req-20011018
    2. XML Instance Validity {[66]WS}
         1. Encrypted instances must be well-formed but need not be valid
            against their original definition (i.e. applications that
            encrypt the element structure are purposefully hiding that
            structure.)
         2. Instance authors that want to validate encrypted instances
            must do one of the following:
              1. Write the original schema so as to validate resulting
                 instances given the change in its structure and
                 inclusion of element types from the XML Encryption
                 namespace.
              2. Provide a post-encryption schema for validating
                 encrypted instances.
              3. Only encrypt PCDATA text of element content and place
                 its decryption and key information in an external
                 document. (This requires [67]granular detached /external
                 encryption.)

So we'll let applications play and address concerns as we meet them.

> Small points:
> - 'Bank of the Internet' should be changed to 'Example Bank'

OK.

> - In 2.1.4, change 'octet set' to 'octet sequence'.

OK.

> - I think using 'www.isi.edu' is rather outdated for iana uris.

www.isi.edu is a bit odd, but it's the best we have IMHO and IANA refers to 
it.

  http://www.iana.org/numbers.htm
  In the past, these numbers were documented through the RFC
  document series, the last of these documents was RFC 1700, which is also
  now outdated.  Since that time, the assignments have been listed in this
  directory as living documents, constantly updated and revised when new
  information is available and new assignments are made.
  [Media Types Directory] -->
     http://www.isi.edu/in-notes/iana/assignments/media-types/

> - Citing the obsolete RFC 1738 will confuse many people.

We also cite URI/URN, and I don't think any draft has superceded RFC1738 in 
whole.

> - Reference XML-MT is obsoleted by RFC 3023.

OK.

> - In the 'Schema definition' at the start of 3., there are
>    entities p and s defined, but they never get used.
>    There is also a spurious &xenc; in 2.2.2.

But the schema spec itself defines them with defaults, so if you don't want 
them you need to cancel them.

> - In the first paragraph of 4.3, "that octets' semantics"
>    isn't very clear. There seems to be a reference, but it's
>    not clear to what. Octets as such don't really have any
>    semanics anyway.

Deleted.

> - 5.2.1 and others: please change the space after "<EncryptionMethod"
>    to a line break to increase the chance that the identifier is
>    complete in printouts.

There were code elements within the pre's, I've removed them and hopefully 
that will help.

-- 

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Wednesday, 12 December 2001 17:26:54 UTC