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

From: Martin Duerst <[email-masked]>
Date: Fri, 01 Jul 2005 16:44:23 +0900

At 10:26 05/07/01, Paul Hoffman wrote:

 >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.

Hello Paul,

The rest of your changes looked reasonable, but the MUST above
looks too strong to me. What about something like
"Atom Processors that sign Atom Documents MUST support the use
of Canonical XML." or even
"Atom Processors that sign Atom Documents MUST use Canonical XML
by default; they MAY use other canonicalizations at user request."

The reason for this is to make sure we have interoperability
with a mandatory-to-implement (and default-to-use) canonicalization,
but that we don't disallow other canonicalizations that for one
or the other as of now not yet clear reason may be preferable in
some cases in the future (but in your wording would prohibit
the result to be called Atom at all).

Regards,     Martin.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 1 Jul 2005 11:04:09 +0200

> by default; they MAY use other canonicalizations at user request."

I agree, but I think the second wording is confusing. It doesn’t
actually say anything different from the first wording, even
though it seems to imply more.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 1 Jul 2005 11:01:38 +0200

* Paul Hoffman <[email-masked]> [2005-07-01 03:40]:
> Below is what Russ asks for, and my suggested changes. The WG
> should let me know if they agree or disagree with my wording.

+1 to all changes, except that

    Atom Processors that sign Atom Documents MUST use Canonical XML.

should be

    Atom Processors that sign Atom Documents MUST support the use
    of Canonical XML.

Regards,

---

From: Eric Scheid <[email-masked]>
Date: Fri, 01 Jul 2005 19:14:08 +1000

>   Atom Processors that sign Atom Documents MUST support the use

what about Atom Processors that are not signing stuff, but is instead
reading/validating those signatures?

e.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 Jul 2005 08:36:37 -0700

At 4:44 PM +0900 7/1/05, Martin Duerst wrote:
>looks too strong to me.

Good catch. I think we can make the requirement for canonicalization 
like we do for encryption and signing: put the onus on the receiver. 
That would change the wording to:

    Atom Processors that verify signed Atom Documents MUST
    be able to canonicalize with Canonical XML.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 1 Jul 2005 13:54:24 +0200

* Eric Scheid <[email-masked]> [2005-07-01 11:25]:
> >   Atom Processors that sign Atom Documents MUST support the
> >   use of Canonical XML.
> 
> what about Atom Processors that are not signing stuff, but is
> instead reading/validating those signatures?

What about them? They too MUST support the use of Canonical XML.

Regards,

---

From: Walter Underwood <[email-masked]>
Date: Fri, 01 Jul 2005 09:06:12 -0700

> the result to be called Atom at all).

A potential future reason that we can't even characterize isn't
enough reason for me to support this.

If we discover weaknesses in the canonicalization, we'll need
to change Atom anyway. Explicitly making room for future incompatible
canonicalizations doesn't make any sense to me.

What is the point of calling something "Atom" when it uses a 
canonicalization which prevents interop with legal Atom implementations?

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: James M Snell <[email-masked]>
Date: Fri, 01 Jul 2005 09:19:41 -0700

+1 on Paul's suggested changes and +1 on wunder's comments below.

---

From: Tim Bray <[email-masked]>
Date: Fri, 01 Jul 2005 11:32:28 -0700

On Jun 30, 2005, at 6:26 PM, Paul Hoffman wrote:

>
> 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.

I'm +1 on Paul's changes. One editorial comment:

> 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.

I'd cut this back to one sentence saying.

"There are many application scenarios where Atom users will wish to  
apply digital signature, encryption, or both to Atom documents."

The examples are non-comprehensive now and will probably look  
hopelessly quaint before too long.

But if people prefer Paul's language I can live with it. -Tim

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 1 Jul 2005 11:52:15 -0700

+1

On 01/07/2005, at 8:36 AM, Paul Hoffman wrote:

> Good catch. I think we can make the requirement for  
> canonicalization like we do for encryption and signing: put the  
> onus on the receiver. That would change the wording to:
>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

--
Mark Nottingham     http://www.mnot.net/

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Fri, 1 Jul 2005 13:15:42 -0600

> apply digital signature, encryption, or both to Atom documents."

is not useful.  One cannot read the sentence without asking "What are
they?  Can you tell me what inspired the assertion?  Please, a hint!"
For example, I couldn't imagine why a feed would be encrypted, and
I'm still skeptical that anyone would actually get the key management 
in place for doing this.

I'd take the scenarios and put them into the usual security categories:

   1. The feed producer may want to assure the consumers of the authenticity
      and integrity of the data.
   2. The feed may contain information that must be protected from
      eavesdroppers.  Such sensitive or confidential data may be encrypted
      so that only the intended recipients can read it.
   3. Both of the cases 1 and 2 may apply at once, and the data will be
      signed and encrypted.

I think Paul's examples are good, but I'd scotch 
>    There are hundreds

because, gosh, maybe there are thousands, or dozens, or a few.  Who knows?
It's better to let the reader's imagination, now sparked by both general
scenarios and a few example, run rampant.

Hilarie

---

From: Russ Housley <[email-masked]>
Date: Fri, 01 Jul 2005 15:20:40 -0400

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.
>

I have seen a lot of push-back from the members of the [email-masked] 
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.
>

Fine.

>>   Also, I would like to see mandatory-
>>   to-implement algorithms specified.
>
>    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

---

From: Sam Hartman <[email-masked]>
Date: Fri, 01 Jul 2005 16:13:51 -0400

Paul, two points.

For me to be happy, your specification must mandate that xmldsig be
used whenever encryption is used.

As a consequence of this and your decision not to support MACs, then
in order to encrypt a document, you must sign it.  In addition, in
order to accept this encrypted document, the recipient must be able to
verify your signature.

Please confirm with the working group that these requirements are
acceptable.  In particular this forbids the case where I submit an
entry encrypted to some third party who I don't share a PKI with.

---

From: James M Snell <[email-masked]>
Date: Fri, 01 Jul 2005 13:45:07 -0700

>    for Canonical XML. Atom Processors that sign Atom Documents MUST

Does this requirement restrict our ability to use exclusive c14n on 
individually signed entries within a feed document?  If so, that's a 
definite problem.

- James

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 Jul 2005 13:56:18 -0700

At 1:45 PM -0700 7/1/05, James M Snell wrote:
>individually signed entries within a feed document?

No and no. My new proposed wording is:

That requires that a recipient, at a minimum, be able to handle 
messages that are canonicalized with Canonical XML. It does not limit 
the kinds of canonicalization that the sender can choose: it only 
says that the sender can only assume the recipient can do Canonical 
XML unless they have other out-of-band knowledge.

--Paul Hoffman, Director

---

From: James M Snell <[email-masked]>
Date: Fri, 01 Jul 2005 14:06:57 -0700

Paul Hoffman wrote:

> the kinds of canonicalization that the sender can choose: it only says 
> that the sender can only assume the recipient can do Canonical XML 
> unless they have other out-of-band knowledge.
>
> --Paul Hoffman, Director
Excellent. The new wording is definitely better. 

Another thing to throw out here: with this extended coverage on dsig, 
also adding a bit of information on how to handle signed entry envelopes 
would pretty much eliminate the need for me to produce a separate doc.  
There are basically only two remaining requirements: a. use of ex-c14n 
when signing individual entries within a feed and b. recommended 
inclusion of a source element in signed entries.  What are your thoughts 
on including these in the changes?  Is that possible / desirable at this 
point?

- James

---

From: James Cerra <[email-masked]>
Date: Fri, 1 Jul 2005 23:58:30 -0700 (PDT)

> XML unless they have other out-of-band knowledge.

Why not add that entire explanation to the section as well?  I understand specs
should be concise, but that really clarifies the meaning and some of the
intended concequences of the statement.

--
Jimmy Cerra
https://nemo.dev.java.net

____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com

---

From: Dave Pawson <[email-masked]>
Date: Sat, 02 Jul 2005 09:51:17 +0100

> entry encrypted to some third party who I don't share a PKI with.

An aweful lot of 'must's there Sam, for one persons view?
I see no reason to using signing, just because I choose to encrypt?

Sounds a bit too corner case for my liking.

DaveP

---

From: Danny Ayers <[email-masked]>
Date: Sat, 2 Jul 2005 19:02:11 +0200

+1 to Paul's suggestions, with the adjustments as suggested, worded as
the editors feel comfortable.

Without deployment of signed Atom to draw on this is unlikely to be
perfect. Just do whatever it takes to satisfy the "discuss".

-- 

http://dannyayers.com

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 4 Jul 2005 15:55:58 -0400

James M Snell wrote:
> b. recommended inclusion of a source element in signed entries.
    +1

        bob wyman