Greetings again. Russ Housley, one of the two Security Area
Directors, has placed a "discuss" vote on the Atom format document.
You can read it at
<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=36890>>.
Fortunately, it seems reasonably easy to clear this discuss.
Below is what Russ asks for, and my suggested changes. The WG should
let me know if they agree or disagree with my wording. I'm Cc'ing
Russ on this thread so he can agree or disagree that the suggested
wording is sufficient for him.
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.
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.
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.
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.
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.
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.
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.
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.
That text is lifted directly from the abstract of the S/MIME spec.
There was no parallel text in the Security Considerations section of
the S/MIME spec that I could re-purpose.
--Paul Hoffman, Director
--Internet Mail Consortium
