Paul Hoffman wrote:
At 12:47 PM -0700 6/29/05, James M Snell wrote:
1. After going through a bunch of potential XML encryption use cases,
it really doesn't seem to make any sense at all to use XML Encryption
below the document element level. The I-D will not cover anything
about
At 3:16 PM -0600 6/30/05, Antone Roundy wrote:
On Thursday, June 30, 2005, at 12:58 PM, James M Snell wrote:
6. If an entry contains any enclosure links, the digital
signature SHOULD cover the referenced resources. Enclosure links
that are not covered are considered untrusted and pose a
At 11:58 AM -0700 6/30/05, James M Snell wrote:
3. When signing complete Atom documents (atom:feed and top level
atom:entry), Inclusive Canonicalization with no pre-c14n
normalization is required.
There seems to be many more interoperability issues with Inclusive
Canonicalization than with
Paul Hoffman wrote:
Same as above. Even though it is included-by-reference, the referenced
content is still a part of the message.
No, it isn't. The reference is part of the message.
+1
The signature should only cover the bits that are actually in the
element (feed or entry) that is
Ok, this is fine. I'll back this out of the draft.
Bob Wyman wrote:
Paul Hoffman wrote:
Same as above. Even though it is included-by-reference, the
referenced content is still a part of the message.
No, it isn't. The reference is part of the message.
+1
The signature should only
Ok, I've been going back through all of the discussion on this thread
and use scenarios, etc and should have an I-D ready for this by this
weekend. Here's the summary (in no particular order)
1. After going through a bunch of potential XML encryption use cases, it
really doesn't seem to
On Wednesday, June 29, 2005, at 01:47 PM, James M Snell wrote:
8. Aggregators and Intermediaries MUST NOT alter/augment the content
of digitally signed entry elements.
Just mulling over things...
Obviously, we don't have any way to annotate signed entries without
breaking the signature.
At 12:47 PM -0700 6/29/05, James M Snell wrote:
1. After going through a bunch of potential XML encryption use
cases, it really doesn't seem to make any sense at all to use XML
Encryption below the document element level. The I-D will not cover
anything about encryption of Atom documents as
On Tue, 2005-06-21 at 17:13 -0700, James M Snell wrote:
The root of an Atom document (i.e., atom:feed in an Atom Feed
Document, atom:entry in an Atom Entry Document) MAY have an Enveloped
Signature, as described by XML-Signature and Syntax Processing
James M Snell wrote:
I am becoming increasingly convinced that a c14n algorithm is
the *only* way to accomplish the goal here.
The need for C14N should never have been questioned. Where there are
signatures, there *must* be C14N (Canonicalization). In the absence of
explicitly defined
Bob Wyman wrote:
James M Snell wrote:
I am becoming increasingly convinced that a c14n algorithm is
the *only* way to accomplish the goal here.
The need for C14N should never have been questioned. Where there are
signatures, there *must* be C14N (Canonicalization). In the
On Jun 20, 2005, at 11:17 PM, James M Snell wrote:
The thought here then is that feeds would not be considered atomic
units and that entry / elements can be pulled as is out of a
containing feed / element and passed around independently of it.
That's basically the idea, yes.
That really
OK, so given the arguments I previously posted in my response to Dan +
the assertion that digitally signing individual entries will be
necessary, the only real possible solution would be to come up with a
canonicalization scheme for digitally signed Atom entries. When applied
to an entry,
James M Snell wrote:
the ability to omit the author element from a contained entry / if the
containing feed has an author...
Signed entries should include a source element and that source element
should contain any of the feed level elements that the entry depends on.
This is one of the
On Monday, June 20, 2005, at 11:33 PM, James M Snell wrote:
OK, so given the arguments I previously posted in my response to Dan +
the assertion that digitally signing individual entries will be
necessary, the only real possible solution would be to come up with a
canonicalization scheme for
Paul Hoffman wrote:
At 2:15 PM -0700 6/20/05, James M Snell wrote:
The spec already allows enveloped XML signatures for the document.
Question: should we only allow signing of the entire document or are
there valid use cases for allowing each individual entry in the feed
to be
Here's a use-case:
I aggregate entries from several sources and create a composite feed. I
want entries that were signed in the source feeds to still carry their
original signatures in the composite feed, so that parsers can check
that the entry has not been modified since it was issued by
On 22/6/05 1:39 AM, Paul Hoffman [EMAIL PROTECTED] wrote:
One would also have to contend with the potential problems
introduced by namespace declarations with the feed. The bottom line
of this is that an entry with a signature could not simply be copied
over to a new containing feed
Eric Scheid wrote:
On 22/6/05 1:39 AM, Paul Hoffman [EMAIL PROTECTED] wrote:
One would also have to contend with the potential problems
introduced by namespace declarations with the feed. The bottom line
of this is that an entry with a signature could not simply be copied
over to a new
OK, thanks to the feedback that has already been offered in this thread
I've been able to make progress on the XML Encryption side of this. Now
to the digital signature side. I'd like to get some opinions on the
following question:
The spec already allows enveloped XML signatures for the
Dan Sandler wrote:
On Jun 20, 2005, at 4:15 PM, James M Snell wrote:
Question: should we only allow signing of the entire document or are
there valid use cases for allowing each individual entry in the feed
to be individually signed?
I believe that individually signed entries are
James M Snell wrote:
Question: should we only allow signing of the entire document or are there
valid use cases for allowing each individual entry in the feed to be
individually signed?
We definitely need to be able to sign each entry. This is necessary so
that we can passed signed content
The plus side to the third option is that it is really no different than
an Atom feed that uses content payloads of any other arbitrary XML media
type (section 4.1.3.3 item #4). The current spec is silent on what an
Atom implementer needs to do with content media types that they don't
James M Snell wrote:
Thoughts?
The mot straightforward way (imo) to deal with encoded fragments is to
use two attributes, ie @type and @enc. So defining a new extension
attribute would work for me.
I'm not sure you need to deal with signalling the type of a fully
encrypted document in
Bill de hra wrote:
James M Snell wrote:
Thoughts?
The mot straightforward way (imo) to deal with encoded fragments is to
use two attributes, ie @type and @enc. So defining a new extension
attribute would work for me.
See my comments below on the type identification.
Here's another
I didn't see any requirement to encrypt feeds.
Please note my email re keyinfo and identification of signer from a few
weeks ago.
Hilarie Orman
26 matches
Mail list logo
