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 cov
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 signe
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
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
p
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 potential security risk
Fully disagree. We are s
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 encryption
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 t
Another possible alternative approach would be to have signed entries
include a special container for metadata additions that is expressly not
covered by the Signature via a Transform. (the name "annotations" for
the tag is just a strawman for discussion purposes)
e.g.
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. I
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 mak
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
>[W3C.REC-xmldsig-core-2002
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 abse
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
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 n
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
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 the
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 individually
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 individually signed?
There are man
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
James M Snell wrote:
the ability to omit the author element from a contained 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 reasons th
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, th
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 elements can be pulled as is out of a
containing element and passed around independently of it.
That's basically the idea, yes.
That really doesn't seem to
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
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 essentia
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 essential for a couple
of Ato
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 d
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
unders
At 2:25 PM -0700 6/16/05, James M Snell wrote:
So perhaps we should limit XML encryption to
a) The entire feed
b) individual entries and
c) the content of content elements. (examples 2, 4 and 5 in my
original note).
Or less. Sections 5.1 and 5.2 of the current spec clearly only cove
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
Bill de hÓra 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 ch
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 yo
31 matches
Mail list logo
