ietf-xml-mime
[Top] [All Lists]

RE: draft-reagle-xenc-mediatype-01.txt

2002-08-08 15:07:07

Let me try to be more specific.


The charset reference isn't to RFC 3023, it is to the charset
parameter
defined in RFC 3023 for the application/xml media type. I  believe
that's
specific enough; if it isn't surely that would mean that the
definition
for application/xml isn't specific enough either...

As Ned and Martin point out, the intent is to express the fact that 
"application/xenc+xml" is XML, and consequently shares the same
charset and 
encoding semantics/processing as that defined in RFC 3023.


What it actually says is:

# Optional parameters: charset

#  Same as charset parameter of application/xml as
#  specified in RFC 3023 [XML-MT] or the most recent
#  specification that supersedes it.

I admit I was a little confused on this one, and misread
what it said. However, I don't understand
"or the most recent specification that supersedes it",
though, since a specification may supercede RFC 3023
but not be appropriate for a reference to a particular
section. None of the other references (to XML, DES, 
HTTP, MIME, etc.) have this qualification (that they
refer to either the current version or anything that
supersedes it.)

I would prefer if the reference were more specific about
what was the "same": the same syntax, the same set of
allowable values, the same recommendation for use of
particular values, the same interpretation of defaults,
or all of the above. Assuming you mean 'all of the above',
you could be more explicit:

 Optional parameters: charset

  The allowable and recommended values for, and interpretation
  of the charset parameter are identical to those given
  for 'application/xml' in section 3.2 of RFC 3023.


I'm a little concerned about allowing arbitrary charset
values for the entire application/xml+enc body, though,
when any encrypted data are always UTF-8 encoded.
Is it expected that the decryption algorithm do transcoding?
Shouldn't the behavior of the processor with non-UTF-8
encoded xml+enc bodies be discussed?

the 'encoding considerations'

http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/#sec-MediaType-Regi
stration

Again, I would prefer if the reference were more explicit
about exactly was 'the same'. You might even note that because
encrypted data is encoded in base64 that encrypted data
may have different encoding requirements than the data
it replaces.

the "Security Considerations" section contains a vague
reference ('many of those described in') to a section
of the document that doesn't actually do a threat analysis
of the MIME type.

Ned and Larry, can you indicate what you mean by this? I 
looked at other encrypted data formats included S/MIME and PGP; on
this 
point I relied upon the example of application/pgp-encrypted [1] which

references [2] in the same way I have done. I haven't been able to
find any 
example of a  "MIME type threat analysis".

Encrypted content may be unsafe content. XML with encrypted data
might be a way of transmitting virus or trojan containing media
in a way that would not be detectible by ordinary virus scanning
filters on firewalls, for example. So application/xml+enc is
as unsafe as the unsafest content it can transport, and yet
transporting the data in a way that makes it immune to most of
the virus-detection and protection mechanisms that companies employ.

An analysis of this threat and the implementation techniques
necessary to mitigate the threat should be part of the description.


The 'public specification' reference isn't

Do you mean, "published specification" -- I'm not sure what you are 
referring to.

Yes, the problem is that the reference inside the template
doesn't point specifically enough. The 'template' itself says

# Published specification: this document.

If you are trying to find what the media type means, you follow
the link from the template. What part of 'this document'
is the published specification? Section 8.1 (which contains
the words you quote) is labeled 'Introduction', rather than
'Definition', so I skipped it when I was scanning for where
application/xml+enc is defined.

I think you might just put it inline:

  Published specification:
       This document. The application/xenc+xml media type
       may be used with XML documents in which the EncryptedData
       and EncryptedKey element types, in the XML Encryption
       namespace, appear as the root element of the XML document.