Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25)
James M Snell wrote: Ignoring the overhead that it adds for now, isn't this the kind of situation digital signatures are designed to handle? Yes. Norm and I have mentioned this as well. I do not think we can solve this problem by patching the Atom level, ensuring that the Atom level can be ex-canonicalised and signed is sufficient. If I put out an entry with a given ID and digitally sign it, and someone comes along and attempts to publish an entry with a duplicate ID and updated timestamp and it is NOT signed with the same key my original was signed with, then hey, Houston we've got a problem. Without any kind of cryptographic guarantee of this sort, the best you could do is make an educated guess. Would it make sense to include some language along these lines? Belongs in the security sections. I would trust the editors to add the text if they were willing. cheers Bill
Re: Semantics and Belief contexts - was: PaceDuplicateIdsEntryOrigin posted
Part of the reason I went into the detailed explanation I did, is because not everyone here may be familiar with mathematical logic. What I was explaining is a heavy condensation of what I learned in my BA in philosophy. I am not plucking these thoughts out of a hat. So let me apply these a little more directly to your proposal. I very much agree with the spirit of what you are saying. But I think that the danger is that by looking at the problem the way you are, we may end up confusing things a lot more than we are clarifying them. On 25 May 2005, at 21:06, Antone Roundy wrote: == Rationale == * The accepted language for allowing duplicate IDs in a feed document speaks only multiple atom:entry elements with the same atom:id describing the same entry if they exist in the same document--of course, we intend for them to describe the same entry whether they're simultaneously in the feed document or not If we put this in terms of ontology, what we want is to state simply that an ID refers to one and only one entry. There is not much to add by the way, other than that the ID is a URI, since the whole role of URIs is to identify one and only one thing. * The accepted language does not speak of the origin feed of the entries. Ideally, an atom:id should be univerally unique to one entry resource, and we rightly require publishers to mint them with that goal. However, in reality, malicious or undereducted publishers might duplicate the IDs of others. Therefore, it is proposed to modify the specification to state that the atom:entry elements describe the same entry (resource) if they originate in the same feed. When you say 'ideally', I say ontologically. Let us imagine that instead of creating an ontology for a atom entry, we were creating one for a gun. We could say that guns have a number of properties, one of them being that they are physical objects. Physical objects can only be at one place at a time. So a gun can only be at one place at a time. Now you can see how it won't help the definition of a gun if someone were to introduce the following reasoning. When a policeman asks someone where they put the gun, some people are honest and tell them where, but many people (the most interesting ones) will lie to them. The policeman has to report the facts as he sees and hears them. He may hear two conflicting reports on where the gun is. Are guns therefore weird objects that have a position relative to the person who speaks about them? This is confusing semantics and the way people speak about the world. It is confusing our concepts about the world, and the context in which sentences containing those concepts about the world appear. * Aggregators wishing to protect against DOS attacks are not unlikely to perform some sort of safety checks to detect malicious atom:id duplication, regardless of whether the specification authorizes them to or not. The policeman is not unlikely to do a lot of safety checks to find out where the gun is. He may for example scan the person who told him he has not gun anyway, just to make sure. On 25 May 2005, at 22:57, Antone Roundy wrote: On Wednesday, May 25, 2005, at 02:26 PM, Henry Story wrote: Since the referents of Superman and Clark Kent are the same, what is true of the one, is true of the other. When speaking directly about the world, we can replace any occurrence of Superman with Clark Kent, and still say something true. Clark Kent is the secret identity of Superman. - Superman is the secret identity of Superman. Whether they're perfectly interchangeable or not depends on whether the name is referring to the object or some a facet of the object. The second sentence actually works if the first Superman refers to the persona, and the second to the person. But getting back to Atom... There are a lot of corner cases. I was trying to give an overview of a complicated field. I was restricting myself to sentences where words clearly identify objects. If you use Superman to refer to a persona then we are speaking about something else. Other cases are Superman is so called because he is strong. Well known, but it does not undermine the distinction I was making. [snip] So to prevent a DOS attack, best is to have aggregator feeds such as: feed !-- aggregator feed -- feed src=http://true.org; idtag://true.org,2005/feed1/id entry titleEnter your credit card number here/title ... /entry /feed feed src=http://false.org; idtag://true.org,2005/feed1/id entry titleEnter your credit card number here/title ... /entry /feed /feed Here all the aggregator feed is claiming is that he has seen entries inside other feeds. ... It will be up to the consumer of such aggregated feeds to decide which to trust. From the end user's point of view, it's not much
Re: atom:type, xsl:output
* James Cerra [EMAIL PROTECTED] [2005-05-26 05:35]: Yes, but MSIE^H^H^H^Hsome xml processors (cough cough) still inappropriately use comments for that purpose. Then there are example XML documents (i.e. for tutorials) that sometimes require comments be preserved. Entities can be flattened. Again, as with comments, I agree in principle, but in practice some processors depend on them. I do not consider it at all wise to legislate anything in the Atom spec to address these cases. Nothing prevents anyone from writing a generator or pre- or postprocessor for Atom documents to cater to the needs of their particular brand of broken software. Wrangling that particular piece of broken software however is their job; not ours nor the Atom specs. Regards, -- Aristotle
Re: atom:type, xsl:output
* Henri Sivonen [EMAIL PROTECTED] [2005-05-26 10:20]: On May 26, 2005, at 06:23, James Cerra wrote: Yes, but MSIE^H^H^H^Hsome xml processors (cough cough) still inappropriately use comments for that purpose. I am not familiar with that. What purpose exactly? Why should Atom support it? http://msdn.microsoft.com/workshop/author/dhtml/overview/ccomment_ovw.asp They are parsed in HTML documents; I have no idea if IE actually respects these in XML documents. Regards, -- Aristotle
Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25)
On Wednesday, May 25, 2005, at 06:14 PM, James M Snell wrote: Ignoring the overhead that it adds for now, isn't this the kind of situation digital signatures are designed to handle? Sure, but how many publishers are going to be using digital signatures in the near term (and more importantly, how many aren't?), and who knows how many consuming applications will support them. Until digital signatures start providing more help with this kind of thing, let's provide a warning to developers so that they can at least consider what they might do to safeguard the quality of their users' experience. And I just thought of another thing (I don't know how digital signatures work in this case, so I may be missing something, but I'm pretty sure the following is at least partially valid): if I get an entry with a valid digital signature and one with no signature (both with the same atom:id, of course), then what? Do I always accept the one with the signature? If so, then DOSing/spoofing unsigned entries will be even easier, because all you'd have to do is sign your fake entry. So even in that case, some extra checking might have to be done before concluding that the entries are duplicates, and that the unsigned one is the one that's disposable. Without any kind of cryptographic guarantee of this sort, the best you could do is make an educated guess. Wouldn't that be better than nothing until digital signatures become more ubiquitous? Would it make sense to include some language along these lines? Sure.
Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25)
On Thursday, May 26, 2005, at 08:04 AM, A. Pagaltzis wrote: * Graham [EMAIL PROTECTED] [2005-05-25 23:00]: How is this a Denial of service attack? Isn't it just ordinary spoofing/impersonation? Indeed; Id like to see this reworded to refer to spoofing, as thats what it is. I presume the specific wording can be left to the discretion of the editors.
Re: PaceDuplicateIdsEntryOrigin posted (was Re: Consensus snapshot, 2005/05/25)
On Wednesday, May 25, 2005, at 01:06 PM, Antone Roundy wrote: == Abstract == State the atom:entries from the same feed with the same ID are the same entry, whether simulateously in the feed document or not. I'm retracting this proposal in preference for PaceAtomIdDos, which I like better and is getting more support.
Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25)
Antone Roundy wrote: On Wednesday, May 25, 2005, at 06:14 PM, James M Snell wrote: Ignoring the overhead that it adds for now, isn't this the kind of situation digital signatures are designed to handle? Sure, but how many publishers are going to be using digital signatures in the near term (and more importantly, how many aren't?), and who knows how many consuming applications will support them. Until digital signatures start providing more help with this kind of thing, let's provide a warning to developers so that they can at least consider what they might do to safeguard the quality of their users' experience. Oh, absolutely, I was simply making an observation and thinking a bit about whether or not it would make sense to have some language as part of the warning that mentioned the potential application of digital signatures to solving this problem. I dunno, just thinking out loud here a bit. And I just thought of another thing (I don't know how digital signatures work in this case, so I may be missing something, but I'm pretty sure the following is at least partially valid): if I get an entry with a valid digital signature and one with no signature (both with the same atom:id, of course), then what? Do I always accept the one with the signature? If so, then DOSing/spoofing unsigned entries will be even easier, because all you'd have to do is sign your fake entry. So even in that case, some extra checking might have to be done before concluding that the entries are duplicates, and that the unsigned one is the one that's disposable. Well, it comes down to whether the signature is trusted by the reader or not. If the signature in the entry is not from the trusted, expected source, the user should be able to reject it in favor of the unsigned entry. Without any kind of cryptographic guarantee of this sort, the best you could do is make an educated guess. Wouldn't that be better than nothing until digital signatures become more ubiquitous? Absolutely... see my first response above ;-) Would it make sense to include some language along these lines? Sure.
Last and final consensus pronouncement
co-chair-mode On behalf of Paul and myself: This is it. The initial phase of the WG's work in designing the Atompub data format specification is finished over, pining for the fjords, etc. Please everyone reach around and pat yourselves on the back, I think the community will generally view this as a fine piece of work. Stand by for announcements on buckling down on Atom-Protocol. Note that this is a pronouncement, not a call for further debate. Here are the next steps: 1. Editors take the assembled changes and produce a format-09 I-D. Sooner is better. 2. They post the I-D. 3. Paul sends Scott a message, cc'ing the WG, that we're done. 4. At this point there may be objections from the WG. We decide whether to accept the objections and pull the draft back, or tell the objectors they'll have to pursue the appeal process. 5. The IESG process takes over at this point and we'll eventually hear back from them. Last two draft changes: 1. PaceAtomIdDOS We think that the WG has consensus that it is of benefit to add a warning to section 8 Security Considerations. The language from PaceAtomIdDos is mostly OK, except that the late suggestion of talking about spoofing instead of DOS seemed to get general support. I reworded slightly. We'll leave it up to the editors to decide whether a new subsection of section 8 is required. Atom Processors should be aware of the potential for spoofing attacks where the attacker publishes an atom:entry with the atom:id value of an entry from another feed, perhaps with a falsified atom:source element duplicating the atom:id of the other feed. Atom Processors which, for example, suppress display of duplicate entries by displaying only one entry with a particular atom:id value, perhaps by selecting the one with the latest atom:updated value, might also take steps to determine whether the entries originated from the same publisher before considering them to be duplicates. 2. PaceAtom10 http://www.intertwingly.net/wiki/pie/PaceAtom10 We just missed this one in the previous consensus call; seeing lots of +1's and no pushback, it's accepted. /co-chair-mode
Re: Last and final consensus pronouncement
The atom:author element name is embarrassing. Make it atom:creator. There were no objections to that. wunder --On May 26, 2005 10:26:54 AM -0700 Tim Bray [EMAIL PROTECTED] wrote: co-chair-mode On behalf of Paul and myself: This is it. The initial phase of the WG's work in designing the Atompub data format specification is finished over, pining for the fjords, etc. Please everyone reach around and pat yourselves on the back, I think the community will generally view this as a fine piece of work. Stand by for announcements on buckling down on Atom-Protocol. Note that this is a pronouncement, not a call for further debate. Here are the next steps: 1. Editors take the assembled changes and produce a format-09 I-D. Sooner is better. 2. They post the I-D. 3. Paul sends Scott a message, cc'ing the WG, that we're done. 4. At this point there may be objections from the WG. We decide whether to accept the objections and pull the draft back, or tell the objectors they'll have to pursue the appeal process. 5. The IESG process takes over at this point and we'll eventually hear back from them. Last two draft changes: 1. PaceAtomIdDOS We think that the WG has consensus that it is of benefit to add a warning to section 8 Security Considerations. The language from PaceAtomIdDos is mostly OK, except that the late suggestion of talking about spoofing instead of DOS seemed to get general support. I reworded slightly. We'll leave it up to the editors to decide whether a new subsection of section 8 is required. Atom Processors should be aware of the potential for spoofing attacks where the attacker publishes an atom:entry with the atom:id value of an entry from another feed, perhaps with a falsified atom:source element duplicating the atom:id of the other feed. Atom Processors which, for example, suppress display of duplicate entries by displaying only one entry with a particular atom:id value, perhaps by selecting the one with the latest atom:updated value, might also take steps to determine whether the entries originated from the same publisher before considering them to be duplicates. 2. PaceAtom10 http://www.intertwingly.net/wiki/pie/PaceAtom10 We just missed this one in the previous consensus call; seeing lots of +1's and no pushback, it's accepted. /co-chair-mode -- Walter Underwood Principal Architect, Verity
Editorship announcement
co-chair-mode As we get ready to buckle down on the Atom Publishing Protocol draft, we're doing some editor-shuffling. With thanks to Rob Sayre for his excellent work up through protocol-04, we're shifting from Rob-and- Joe to Joe Gregorio and Bill de hÓra as co-editors of the Atom protocol draft. -Tim (on behalf of myself and Paul) /co-chair-mode
Re: extension elements inside link elements?
David Powell wrote: I'm also a bit confused about the terminology in Section 6.3: It might be the case that the software is able to process the foreign markup correctly and does so. Otherwise, such markup is termed unknown foreign markup. So unknown foreign markup is foreign markup that software is unable to process? Yes, something in a namespace that is not understood by the Atom Processor. But then 6.3 goes on to explain how to process it. This sounds like a contradiction? No, why? Say I am an Atom Processor and I find these extensions elements: !-- defined before: xmlns:geo=http://www.w3.org/2003/01/geo/wgs84_pos#; -- geo:lat26.58/geo:lat geo:long-97.83/geo:long Is this something I know how to process? * yes: this is known foreign markup, I process it * no: this is unknown foreign markup, I ignore it without failing or signaling an error Also, in what cases would software be able to process foreign markup other than by ignoring it as described in section 6.3 or treating it as a 6.4 extension? Treating it as a 6.4 extension *is* processing it as described in section 6.3. There is no other case (this is technically implied by section 6.4, see below) So I don't see how the term foreign markup and unknown foreign markup are any different? unknown foreign markup is the subset of foreign markup that an Atom Processor ignores because it doesn't know what do do with it (i.e. how to process it). Also, if 6.4 extensions are a subset of unknown[?] foreign markup, 6.4 extensions are not a subset of foreign markup or unknown foreign markup. 6.4 extensions are the whole foreign markup set (except it doesn't deal with foreign attributes, but the whole section 6 and the whole spec doesn't deal with them). If you read carefully the section 6.4, you'll notice that what is not a Simple Extension Element is a Structured Extension Element. A Simple Extension Element is an element with no attribute and is either empty or has text-only content. A Structured Extension Element is an element with at least an attribute or a child. These are Simple Extension Elements: my:ext/ my:ext/my:ext my:extfoo/my:ext These are Structured Extension Elements: my:ext attr=val / my:ext attr=val/my:ext my:ext attr=valfoo/my:ext my:ext attr=valfoo:bar//my:ext my:ext attr=valbazfoo:bar/baz/my:ext my:extfoo:bar//my:ext my:extbazfoo:bar/baz/my:ext Is there any other construct I missed? -- Thomas Broyer
Re: extension elements inside link elements?
Thursday, May 26, 2005, 7:20:23 PM, Thomas Broyer wrote: But then 6.3 goes on to explain how to process it. This sounds like a contradiction? No, why? Ok, I'd interpreted ignoring it to be processing it, as opposed to failing. I'll concede that I misinterpreted that. Say I am an Atom Processor and I find these extensions elements: !-- defined before: xmlns:geo=http://www.w3.org/2003/01/geo/wgs84_pos#; -- geo:lat26.58/geo:lat geo:long-97.83/geo:long Is this something I know how to process? * yes: this is known foreign markup, I process it * no: this is unknown foreign markup, I ignore it without failing or signaling an error So known 6.4 extensions are known foreign markup, and unknown extensions are unknown foreign markup? Ok. Also, if 6.4 extensions are a subset of unknown[?] foreign markup, 6.4 extensions are not a subset of foreign markup or unknown foreign markup. 6.4 extensions are the whole foreign markup set 6.2 says that new elements and attributes can be added. Earlier discussion in this thread suggested that these may be inside atom:link elements. Isn't this a type of markup that isn't a 6.4 extension? 6.4 extensions can only appear in atom:feed, atom:entry, and Person constructs. [BUG ALERT - they should blatantly be allowed inside atom:source too, and the inheritance needs explaining] For the people who were proposing that atom:link shouldn't ban content, can they tell me which type of Section 6 markup they regard it to be? Or were they proposing that Section 6.4 should be extended to allow Link Extensions. (except it doesn't deal with foreign attributes, but the whole section 6 and the whole spec doesn't deal with them). Yes it does, section 6.2 says that future versions of Atom can add new attributes. If you read carefully the section 6.4, you'll notice that what is not a Simple Extension Element is a Structured Extension Element. A Simple Extension Element is an element with no attribute and is either empty or has text-only content. A Structured Extension Element is an element with at least an attribute or a child. Yep, I understand Section 6.4, but these rules only apply directly inside atom:entry, atom:feed, and Person constructs [and atom:source]. Foreign markup in other places isn't 6.4 markup, so what is it? Is there any other construct I missed? * Elements in places that they aren't banned such as atom:category, and depending on the outcome of this thread, atom:link - presumably intended for future versions of Atom. Allowed by Section 6.2. [BUG ALERT!!! The RNG says that the content is empty, the text doesn't] * Attributes on any existing elements. Allowed by Section 6.2. -- Dave
Re: extension elements inside link elements?
David Powell wrote: Thursday, May 26, 2005, 7:20:23 PM, Thomas Broyer wrote: Say I am an Atom Processor and I find these extensions elements: !-- defined before: xmlns:geo=http://www.w3.org/2003/01/geo/wgs84_pos#; -- geo:lat26.58/geo:lat geo:long-97.83/geo:long Is this something I know how to process? * yes: this is known foreign markup, I process it * no: this is unknown foreign markup, I ignore it without failing or signaling an error So known 6.4 extensions are known foreign markup, and unknown extensions are unknown foreign markup? Ok. Yes, though known foreign markup is not used in the spec (or I missed it). And actually, you're right (see below) saying 6.4 extensions do not describe the whole foreign markup set (see below). 6.4 extensions are not a subset of foreign markup or unknown foreign markup. 6.4 extensions are the whole foreign markup set 6.2 says that new elements and attributes can be added. 6.2 deals with the Atom vocabulary, which is the markup in the Atom namespace or un prefixed attributes on Atom-namespaced elements (this is my interpretation, it's not clearly stated in the spec, and I'm quite sure I already raised this in the past two weeks). 6.1 deals with foreign markup, that is (still not clearly stated by the spec text) markup in a namespace different from the Atom namespace. Earlier discussion in this thread suggested that these may be inside atom:link elements. Isn't this a type of markup that isn't a 6.4 extension? 6.4 extensions can only appear in atom:feed, atom:entry, and Person constructs. [BUG ALERT - they should blatantly be allowed inside atom:source too, and the inheritance needs explaining] You're right, 6.4 extensions are the subset of foreign markup known as Metadata Elements, they' do not represent the whole foreign markup set. For the people who were proposing that atom:link shouldn't ban content, can they tell me which type of Section 6 markup they regard it to be? Or were they proposing that Section 6.4 should be extended to allow Link Extensions. If future versions of Atom adds (unprefixed) attributes or (Atom-namespaced) elements inside atom:link, they will be Extensions to the Atom Vocabulary per section 6.2. If someone defines extensions (attributes or elements in a namespace other than the Atom namespace) inside atom:link, they will be Extensions From Non-Atom Vocabularies, per section 6.1. As they won't match section 6.4 criteria (not inside atom:feed, atom:entry or a Person Construct), they won't be Metadata Elements and thus their role is undefined (per section 6.4, last sentence of the single 6.4 paragraph). (except it doesn't deal with foreign attributes, but the whole section 6 and the whole spec doesn't deal with them). Yes it does, section 6.2 says that future versions of Atom can add new attributes. You're right. Although you should have refered to section 6.1. Their role is just undefined by the spec. If you read carefully the section 6.4, you'll notice that what is not a Simple Extension Element is a Structured Extension Element. A Simple Extension Element is an element with no attribute and is either empty or has text-only content. A Structured Extension Element is an element with at least an attribute or a child. Yep, I understand Section 6.4, but these rules only apply directly inside atom:entry, atom:feed, and Person constructs [and atom:source]. Foreign markup in other places isn't 6.4 markup, so what is it? It is just foreign markup, per section 6.1. Its role is undefined by the spec. What the spec says is only how to process it (the MustIgnore in section 6.3). Markup which the section 6.2 deals with is markup inside the Atom namespace. It is not foreign markup, though it must be considered as such by Atom 1.0 Processors for the purposes of this discussion. If it matches 6.4 criteria, it is Metadata Elements markup, otherwise, it is just Atom markup which is considered foreign markup for the purposes of this discussion. I must however agree that the spec is not as clear as it could be... it doesn't for example clearly define Atom Vocabulary on which definition of foreign markup is relying. -- Thomas Broyer
Re: extension elements inside link elements?
Thursday, May 26, 2005, 11:16:05 PM, Thomas Broyer wrote: David Powell wrote: Thursday, May 26, 2005, 8:50:04 PM, Thomas Broyer wrote: 6.2 deals with the Atom vocabulary, which is the markup in the Atom namespace or un prefixed attributes on Atom-namespaced elements (this is my interpretation, it's not clearly stated in the spec, and I'm quite sure I already raised this in the past two weeks). Yes, I proposed that we fix this here too: http://www.imc.org/atom-syntax/mail-archive/msg15743.html It'd be still be necessary to define the term vocabulary somewhere, in section 6 or in the introduction (section 1). As vocabulary is only used only in sections 6.1 and 6.2, I suggest using namespace instead: [ 6.1 Extensions From Non-Atom Namespaces This specification describes Atom's XML markup namespace. Markup from other namespaces (foreign markup) can be used in an Atom document. Note that the atom:content element is designed to support the inclusion of arbitrary foreign markup. 6.2 Extensions To The Atom Namespace Future versions of this specification could add new elements and attributes to the Atom markup namespace. Software written to conform to this version of the specification will not be able to process such markup correctly and, in fact, will not be able to distinguish it from markup error. For the purposes of this discussion, unrecognized markup from the Atom namespace will be considered foreign markup. ] This sounds good, but 6.2 ought to also include unprefixed attributes on atom elements as well as atom: prefixed ones. This however doesn't prevent us adding your sentence to 6.4 to make it clearer. I think 6.3 would be much easier to understand if its position was swapped with 6.4. When you read 6.3 you assume that everything not mentioned so far must be unknown foreign markup, then when you read 6.4, it redefines some of that as metadata elements. They are intended to be disjoint, but the ordering suggested to me that 6.4 was a subset. Paragraph 2 of 6.3 reinforced my misconception that 6.4 markup is subset of unknown foreign markup, especially as it didn't mention markup on other elements or attributes as 6.2 proposed. If 6.3 and 6.4 were swapped, then I think paragraph 2 of 6.3 could be trimmed down to avoid this. Replace paragraph 2 3 of 6.3, with: When unknown foreign markup is encountered in a Text Contruct or atom:content element, software SHOULD ignore the markup and process any text content of foreign elements as though the surrounding markup were not present. When unknown foreign markup is encountered elsewhere, software MAY bypass the markup and any textual content and MUST NOT change its behavior as a result of the markup's presence. -- Dave
Re: Signatures - I blog, therefore I am...
At 7:16 PM -0400 5/26/05, Bob Wyman wrote: The only mechanism that we would need in order to allow feeds to sign their content would be a means to associate a signing key with a feed or set of feeds. This could be done in one of two ways: * The traditional indirect manner of having a certificate authority create a certificate for someone once they prove administrative control over a feed. * The much simpler method of the feed including an extension element that identifies its signing keys -- it could either point to a file or to a key server. Much simpler, but completely insecure. :-) It's a self-signed attestation that has to be verified by out-of-band means that, from a security standpoint, are equivalent to the first if done right and horribly dangerous if done wrong. Having said that, I support the latter more than the former, and believe that 90% of signed feeds that people actually use will follow that model. The second method above has the downside that one would either have to be familiar with the feed and thus have memory of its statements concerning keys or one would have to fetch the feed as part of the signature verification process. However, the fact that the second method dispenses with the need for a certificate authority may make it appear quite appealing... Also, the second method allows one to do things like replace, expire, and cancel keys simply by changing the associations in the feed. And, to do any of those securely, you need to do the same things you did to get the keys in the first place, using the same security mechanism. One of the really interesting side-effects of having feeds, not people, be the owners of keys... Wait, stop. There is no such thing as an owner of a key. There are things that control the private key of a key pair. That is *always* a computer of some sort, and that computer is *always* controllable by at least one person. If you're careful/lucky, everyone who has access to the private key is someone who should have access. It is much better to say ..having feeds, not people, be associated with keys That is, the identifier that is associated with the key is a URI of the feed, not a person or company name. is that we might then find that it makes sense to allow feeds to issue certificates to their owners. (Yes, I know that this probably sounds odd...) Basically, the idea is that instead of giving keys to a person and then doing things to associate the feed with the person, we might turn things around and give keys to the feed and then associate the person with the feed. An intriguing aspect of doing this is that any measures of the authority of the feed could be passed on to the owner of the feed. Your personal authority, popularity, identity, etc. might be derived from your feed... So, instead of having to go through the sometimes great nuisance of presenting birth certificates, SSNs, and other evidence of personhood to a certificate authority, we could simply assert our personal existence by linking to the blogs we own... I blog, therefore I am. Stated another way, the anchor of the key hierarchy is identified by the URI of a feed, and the leaves might be identified by human names. A different method would be to have multiple identities associated with keys. My key might be identified with Paul Hoffman and http://lookit.proper.com; and http://saladwithsteve.com/osx/; and so on. Another interesting question would be what is that role of intermediaries like PubSub or search engines in signing things? Some such services might be trusted when they make statements like I found this entry in the feed identified in the source element. If this is the case, there could be value in having such trusted services sign the entries that that pass on. Then, if you found a copy of an entry that carried such a signature, you could have just as much faith in its correctness as if you had retrieved the entry directly from the intermediary rather than from someone who had copied it from the intermediary. Exactly right. Intermediary validation is what drives security folks crazy (witness the more-than-five-year history of SCVP in the PKIX WG), but it is exactly what most people use every day. There are a number of interesting possibilities here +1 --Paul Hoffman, Director --Internet Mail Consortium
Re: Editorship announcement
On 27/5/05 4:14 AM, Tim Bray [EMAIL PROTECTED] wrote: protocol-04 btw, where can we find it? e.
