Subject: Clearing a "discuss" vote on the Atom format

From: Paul Hoffman <[email-masked]>
Date: Thu, 30 Jun 2005 18:26:08 -0700

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