Paul:
Since I am going to be out next week, please include Sam Hartman on future
correspondence. If Sam agrees to any [articular wording, I will accept
that wording as a resolution of the DISCUSS issue.
Section 5 does not provide sufficient detail for interoperability.
Unfortunately, the complexity of XML and the variety of contexts in
which it is used made it impossible for the XMLDSIG WG to come up
with one set of canonicalization rules that are "distinguished."
By distinguished, I mean that there is exactly one way to represent
the XML object. There are two canonicalization rule sets: the
Canonical XML and the Exclusive XML Canonicalization. Specify
which one is mandatory-to-implement.
To be added near the end of Section 5.1 of atompub-format:
Section 6.5.1 of [W3C.REC-xmldsig-core-20020212] requires support
for Canonical XML. Atom Processors that sign Atom Documents MUST
use Canonical XML.
I have seen a lot of push-back from the members of the atom-syntax@imc.org
about your proposed wording. However, a mandatory-to-implement
canonicalization algorithm is needed. The creator of a feed / entry needs
a algorithm that is supported by all implementations. I do not care which
of the algorithms you choose to mandate, but you need to pick one of the
defines ones or define a new one.
Section 5 should tell the reader when the use of digital signatures
and encryption are desirable.
To be added near the beginning of Section 5 of atompub-format:
Producers of feeds and/or entries, and intermediaries who aggregate
feeds and/or entries, may have sound business reasons for signing
and/or encrypting otherwise-unprotected content. For example,
a merchant might digitally sign a message that contains a discount
coupon for its products. A bank that uses Atom to deliver customer
statements is very likely to want to sign and encrypt those
messages to protect their customers' financial information and to
assure the customer of their authenticity. Intermediaries may want
to encrypt aggregated feeds so that a passive observer cannot tell
what topics the recipient is interested in. There are hundreds
of other reasons why Atom documents might be signed, encrypted,
or both.
Fine.
Also, I would like to see mandatory-
to-implement algorithms specified.
To be added near the end of Section 5.1 of atompub-format:
Section 4.4.2 of [W3C.REC-xmldsig-core-20020212] requires support
for DSA signatures and recommends support for RSA signatures.
However, because of the much greater popularity in the market of
RSA versus DSA, Atom Processors that verify signed Atom Documents MUST
be able to verify RSA signatures, but do not need be able to verify DSA
signatures. Atom documents MAY use HMACs for signatures, but this
type of signature is not expected to have wide adoption any time soon.
I am not totally happy with this text. Since you do not want to delve into
the key management issues associated with encryption and MACs, you need to
say that MACs SHOULD NOT be used.
To be added near the end of Section 5.2 of atompub-format:
Section 5.1 of [W3C.REC-xmlenc-core-20021210] requires support of
TripleDES, AES-128, and AES-256. Atom Processors that decrypt Atom
Documents MUST be able to decrypt with AES-128.
Please state that AES-128 is used in CBC mode.
If appropriate, use MUST- and
SHOULD+ as they were defined by the IPsec WG to tell implementors
about future algorithm requirements.
I do not think it is appropriate to do that here because we could get out
of sync with the requirements if the W3C documents evolve.
Given the selection of mandatory-to-implement algorithms above, this is fine.
In section 5, please state the order of the nesting if both digital
signature and encryption are used. I believe that signing the
plaintext is the correct ordering in this situation.
To be added to a new subsection 5.3 of atompub-format:
Encryption based on [W3C.REC-xmlenc-core-20021210] does not assure
integrity of the original document. When an Atom Document is to be
signed and encrypted, it is generally a good idea to first sign the
document, then encrypt the signed document. This provides integrity
to the base document while encrypting all the information, including
the identity of the entity that signed the document.
I would prefer a stronger working here. Since MACs might be supported in
the future, the signature MUST be applied before the encryption.
Since XML encryption does not provide integrity, it is important to use
XML digital signature whenever encryption is used. When a digital
signature algorithm is used, this should be straightforward; however,
the XML digital signature specification also supports message
authentication codes (MACs). When MACs are used, the symmetric keys
for the encryption and the MAC calculation need to use the same key
management technique. When digital signatures are used, the recipient
must have a way to verify the public key of the signer. This is
usually done with a certificate.
I believe the somewhat-negative wording on HMACs above should preclude any
need to add (probably-confusing) text about key management for HMACs. If
there is a community that wants to use HMACs, they can write up a document
on how to do secure key management for it in XMLDigSig.
Okay, if the two previous comments associated with MACs are acceptable.
Section 8.5 needs to be expanded. When digital signature or encryption
are used, what threats do they protect against?
Digital signatures provide authentication, message integrity, and
non-repudiation with proof of origin. Encryption provides data
confidentiality.
Fine.
Russ
