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

[Bob Wyman]

James M Snell wrote:

b. recommended inclusion of a source element in signed entries.

   +1

   bob wyman

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

[Danny Ayers]

+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

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

[Dave Pawson]

On Fri, 2005-07-01 at 16:13 -0400, Sam Hartman wrote:
> 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.

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

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

[James Cerra]

--- Paul Hoffman <[EMAIL PROTECTED]> wrote:
> No and no. My new proposed wording is:
> 
> Atom Processors that verify signed Atom Documents MUST
> be able to canonicalize with Canonical XML.
> 
> 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.

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

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

[James M Snell]

Paul Hoffman wrote:

Does this requirement restrict our ability to use exclusive c14n on 
individually signed entries within a feed document?



No and no. My new proposed wording is:

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

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
--Internet Mail Consortium

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

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

[Paul Hoffman]

At 1:45 PM -0700 7/1/05, James M Snell wrote:

Paul Hoffman wrote:


  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.


  Section 5 does not provide sufficient detail for interoperability.

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.


Does this requirement restrict our ability to use exclusive c14n on 
individually signed entries within a feed document?


No and no. My new proposed wording is:

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

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
--Internet Mail Consortium

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

[James M Snell]

Paul Hoffman wrote:


  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.


  Section 5 does not provide sufficient detail for interoperability.

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.


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

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

[Sam Hartman]

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.

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

[Russ Housley]

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
  

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

[The Purple Streak, Hilarie Orman]

Using this bare sentence:

> "There are many application scenarios where Atom users will wish to  
> 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
>of other reasons why Atom documents might be signed, encrypted,
>or both.

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


  

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

[Mark Nottingham]

+1

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




At 4:44 PM +0900 7/1/05, Martin Duerst wrote:



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.

The rest of your changes looked reasonable, but the MUST above
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







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



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

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

[Tim Bray]

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

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

[James M Snell]

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


Walter Underwood wrote:


--On July 1, 2005 4:44:23 PM +0900 Martin Duerst <[EMAIL PROTECTED]> wrote:
 


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



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


 

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

[Walter Underwood]

--On July 1, 2005 4:44:23 PM +0900 Martin Duerst <[EMAIL PROTECTED]> wrote:
>
> 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).

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

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

[A. Pagaltzis]

* Eric Scheid <[EMAIL PROTECTED]> [2005-07-01 11:25]:
> On 1/7/05 7:01 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> 
> >   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,
-- 
Aristotle Pagaltzis // 

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

[Paul Hoffman]

At 4:44 PM +0900 7/1/05, Martin Duerst wrote:

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.

The rest of your changes looked reasonable, but the MUST above
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

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

[Eric Scheid]

On 1/7/05 7:01 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:

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

e.

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

[A. Pagaltzis]

* Martin Duerst <[EMAIL PROTECTED]> [2005-07-01 09:55]:
> 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."

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

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

[A. Pagaltzis]

* Paul Hoffman <[EMAIL PROTECTED]> [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,
-- 
Aristotle Pagaltzis // 

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

[Martin Duerst]

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. 

Clearing a "discuss" vote on the Atom format

[Paul Hoffman]

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