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
* 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
* 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
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.
* Mark Nottingham [EMAIL PROTECTED] [2005-06-30 22:15]:
The problem I'm solving is how to reconstruct the *entire*
state of the logical feed, not just one partial representation
of it; although RFC3229 could be used to do that, it would
require feed authors to post the entire content of
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
* 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
--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
+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)
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_commentid=36890.
On 01/07/2005, at 5:28 AM, A. Pagaltzis wrote:
No, that’s not necessary. For fetches which don’t supply any
RFC3229 headers, you can simply return the partial feed that you
always return.
How do you figure that? HTTP delta encoding is a generic mechanism
layered into HTTP; if you do a bare
+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
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
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
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
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
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
17 matches
Mail list logo
