Subject: PaceFeedSignature: not cooked

From: Ken MacLeod <[email-masked]>
Date: 12 Jul 2004 23:36:52 -0500

-1.

Reviewing PaceFeedSignature[1] and rereading its thread[2], I believe
this Pace should not be incorporated, it's not cooked.

The thread never really discussed PaceFeedSignature (atom:security),
as it quickly moved into authentication issues and
PaceSecurityServices.

In <[email-masked]>[3],
James Snell wrote:
> Atom security in general is something that needs to be discussed as
> part of the core.  If nothing else, in the core the security issues
> need to be covered and a plan for addressing those issues discussed.

The Atom specs do need Security Considerations sections, but
atom:security doesn't seem to propose or address anything that might
appear in such a section, largely because it makes no concrete
proposal for its use.

James followed up later in
<[email-masked]>[4]:
> I have no problem, however, with content encryption and integrity
> being pushed off into a separate RFC as long as it is as least
> discussed and considered as a requirement.

I agree with this in principle and would suggest a new Pace for it.

I believe PaceFeedSignature should be closed (incomplete) or should go
back into the pile until it contains something that specs or
references some use(s) that are implementable and testable.

  -- Ken

[1] http://intertwingly.net/wiki/pie/PaceFeedSignature
[2] http://imc.org/atom-syntax/mail-archive/msg05684.html
  Currently contained wholly on the "second" by-thread index page, if
  that helps scanning the messages.
[3] http://imc.org/atom-syntax/mail-archive/msg05723.html
[4] http://imc.org/atom-syntax/mail-archive/msg05726.html

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 12 Jul 2004 21:56:10 -0700

-1 (or +1 to not cooked)

I think we would be better off re-using XMLDigSig on whole root 
objects than inventing our own signature mechanism or trying to allow 
little bits to be signed.

--Paul Hoffman, Director
--Internet Mail Consortium