Subject: Work Queue Rotation #3

From: Tim Bray <[email-masked]>
Date: Tue, 13 Jul 2004 23:08:39 -0700

Here's where I think we are on our current active items from the Public 
Issues List at http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

1. PaceConsistentMimeType - not a peep, roll it in, it's accepted.

2. PaceElementOrder

This is a tough one.  First, we *do* seem to have consensus to add a 
new <feedinfo> (or <head> or some better name) to group all the 
feed-level & default stuff before the first <atom:entry> and that'll be 
in the -01 draft.

Second, the -00 draft says element order is not significant.  This is 
no longer true as we have consensus that <atom:feedinfo> comes before 
<atom:entry>, so -01 needs a change there.

The remaining issue is whether the stuff inside feedinfo has a required 
order.  This Pace actually is written to require no order.  But, it's 
obvious that there is still more work to do here.  So, it seems to me 
like the right thing to do is:

- mark PaceElementOrder as closed
- don't make any changes in the -01 draft aside from <feedinfo>
- Some people, probably including Randy Charles Morin & Dare Obasanjo, 
should pull together a new Pace along the lines of today's discussion, 
pushing for an XSD for use in the context of the Protocol that has 
strict ordering, with associated WSDL, while noting that software that 
receives Atom messages probably won't check the ordering anyhow.  I 
wouldn't be surprised if we could get consensus around that.

If anyone else has a better solution to suggest, let's hear it.

3. PaceSecurityServices

Paul writes: "There was agreement that we want Digest Auth as a SHOULD 
(not a MUST), not to give a SHOULD for the WSSE-like mechanism, and not 
to describe it in the core protocol document. Hopefully, someone 
describes at least one other auth mechanism for Atom, and if the WG 
likes that, we will point to that as a SHOULD as well."

Question to Joe/Rob: is that enough direction for the editors of the 
protocol draft to run with?  If not, you might want to huddle with the 
Security wonks like Paul and MarkP to figure out what should go in the 
-01.

4. PaceFeedSignature

I think we have consensus to reject this one, with the hope that 
someone writes another Pace to say "use XML Digsig", perhaps with some 
Atom-specific guidance.

5. PaceSyntaxGuidelines

Not much discussion, but it looks to me like this one is (sigh) joined 
at the hip to PaceLinkConstruct, thus gets shunted back to the Need To 
Revisit category until that's wrestled to the ground.

==========================

Meta-notes:
1. Ladies and Gentlemen, Boys and Girls, this is progress!  We are 
beginning to approximate what an actual functional working group feels 
like.
2. I think we have enough work done here to produce very solid -01 
drafts of both format and protocol in time for the August IETF 
deadline, which is Monday morning.
3. On the Paces above, it's perfectly possible our perception of 
consensus is wrong, the email volume is terrifying.  If so just say so, 
nobody's going to get mad.  On the other hand, don't panic if you see 
something you don't like go into the draft, it's always OK to suggest a 
change downstream & try to build consensus around it.  There's a reason 
these revs are marked "do not implement."

============================

Next steps: Time for Br'er Sam to turn the crank and rev the issues 
list.  In the meantime, enjoy your continuing permathreads.  I totally 
admire the people who've been grinding away on issued/modified dates 
for like 300 messages now, I assume their understanding of the 
trade-offs is getting razor-sharp.  -Tim

---

From: Robert Sayre <[email-masked]>
Date: Wed, 14 Jul 2004 09:21:29 -0400

> someone writes another Pace to say "use XML Digsig", perhaps with some 

PaceSecurityServices contains a section for the format spec that states:

"Atom consumers MUST be able to parse XMLDSig content to extract the 
Atom content, even if they cannot do any signature validation."

I don't think we have consensus on the part of this Pace that concerns 
the format.

Robert Sayre

[1] http://www.intertwingly.net/wiki/pie/PaceSecurityServices

---

From: Mark Pilgrim <[email-masked]>
Date: Wed, 14 Jul 2004 10:30:07 -0400

> I don't think we have consensus on the part of this Pace that concerns

We absolutely do not have consensus on this part.  XML digital
signatures can be stored in 4 places:

1. Separately, with their own URI
2. As a sibling to the element they are signing
3. As a child to the element they are signing (the signature then
contains an XPath query that identifies the part of the element that
constitutes the signature, so that receiving applications can strip it
out before verifying the hash of the remaining nodes)
4. As a parent to the elmeent they are signing

1 - 3 pose no problems.  In the case of 1, we could have a feed-level
link with @rel of "signature" or similar; this is a separate
discussion.  In the case of 2 and 3, XML digital signatures are stored
within their own namespace, so the Must Ignore rules kick in and
non-digsig-aware clients will simply ignore them.

However, in the case of 4, *all* clients (even clients that do not
implement digital signatures, which would be, um, all of them at the
moment) would need to be aware of the digital signature envelope,
because it would take this:

<feed version="0.3" xmlns="http://purl.org/atom/ns#">
<entry>
<title>foo</title>
<link .../>
</entry>
</feed>

and turn it into this:

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo Id="foobar">
<CanonicalizationMethod 
  Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod 
  Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> 
<Reference URI="http://www.abccompany.com/news/2000/03_27_00.htm">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> 
</Reference>
<Reference 
  URI="http://www.w3.org/TR/2000/WD-xmldsig-core-20000228/signature-example.xml">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue> 
</Reference>
</SignedInfo>
<SignatureValue>MC0E~LE=</SignatureValue>
<KeyInfo>
<X509Data>
<X509SubjectName>CN=Ed Simon,O=XMLSec Inc.,ST=OTTAWA,C=CA</X509SubjectName>
<X509Certificate>
MIID5jCCA0+gA...lVN
</X509Certificate>
</X509Data>
</KeyInfo>
<feed version="0.3" xmlns="http://purl.org/atom/ns#">
<entry>
<title>foo</title>
<link .../>
</entry>
</feed>
</Signature>

In other words, the XPath of the feed changed from /atom:feed/ to
/dsig:Signature/atom:feed/.  All clients would need to be updated to
look for feeds within a dsig:Signature element.  Indeed, all clients
would need to be updated to look for *any element at all* within a
dsig:Signature element (since theoretically any element within an XML
document can be signed individually).

(Those playing along at home will recognize this as the "multiple
envelope problem," and is worthy of its own permathread.  Look, here's
one: http://www.intertwingly.net/blog/2002/12/20/All-the-way-to-SOAP )

Bottom line: XML digital signatures are OK, but we should explicitly
profile the dsig spec to state that enveloped signatures are *not* OK.
 And we should have a standard "Atom-ish" way of linking to externally
stored signatures.

-- 
Cheers,
-Mark

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 14 Jul 2004 10:52:47 -0400

> Security wonks like Paul and MarkP to figure out what should go in the

I think there is enough there to put something in -01. We can
always change it later.

   -joe

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 14 Jul 2004 13:00:23 -0700

>  And we should have a standard "Atom-ish" way of linking to externally

+1

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 14 Jul 2004 22:31:39 +0200

> Revisit category until that's wrestled to the ground.

If that's the consensus, I have no problem with this Pace being written up  
as a non-normative appendix of some sort. I also have to note that it does  
not have anything to do with the link construct, but is a general syntax  
guideline for Atom.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»