<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Cloudy Identity</title>
	<atom:link href="http://jens.mooseyard.com/2008/04/cloudy-identity/feed/" rel="self" type="application/rss+xml" />
	<link>http://jens.mooseyard.com/2008/04/cloudy-identity/</link>
	<description>Little boxes made of words, by Jens Alfke</description>
	<lastBuildDate>Sun, 14 Mar 2010 11:32:26 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Sam Roberts</title>
		<link>http://jens.mooseyard.com/2008/04/cloudy-identity/comment-page-1/#comment-2583</link>
		<dc:creator>Sam Roberts</dc:creator>
		<pubDate>Sat, 03 May 2008 18:05:19 +0000</pubDate>
		<guid isPermaLink="false">http://mooseyard.com/Jens/2008/04/cloudy-identity/#comment-2583</guid>
		<description>You don&#039;t have to canonicalize data to sign it. Canonicalization code is usually buggy, and causes interop problems. Standards developers like it, because they define a signature over an abstraction. Unfortunately, abstractions aren&#039;t crptographically digestable, only bit sequences, but rather than admitting this, they go down the canonicalization route. Aka &quot;the long road to hell that starts in a green and peaceful valley&quot;.

I worked with large PKI toolkits written under the assumption that you could actually read signed DER (s/mime and x509) into internal data structures, then write it out, and the signatures would match. That assumption was wrong in the Real World (TM).

What we eventually found was that even if it works with perfectly encoded data, the approach doesn&#039;t work with badly encoded data. In your case, if somebody uses a leading TAB when your canonical rule says it should be 4 spaces, and they sign it, the signature will be valid. Until you read the data, then write it out again reformatting it correctly. People will report bugs to you, and you will tell them their data is wrong, and its not your fault. There are lots of symptoms of this. x.509 cert numbers encoded as negative numbers, unwittingly, there are a dozen DER string types, most programming languages only support 2, and neither are ancient teletype character sets, extensions that aren&#039;t supported by the decoding app, so it doesn&#039;t handle them and write them correctly. etc.

Then they will tell you that the data was output by a 3rd party vendor they have no control over, and that it works with product X, and they aren&#039;t going to buy your toolkit anymore... Oops. But at least you have the comfort of being &quot;right&quot;.

Anyhow, short story is that robust commercial cryptographic toolkits do NOT modify signed data. They decode it into internal data structures so they can query it, but they keep the original data around in it&#039;s original encoding, and when they need the encoded representatio of the data, they use the original.

Marshall Rose talks about this in the BEEP justification RFC, IIRC, where he talks about it as playing telephone.

Ok, back to my own projects.

Cheers</description>
		<content:encoded><![CDATA[<p>You don&#8217;t have to canonicalize data to sign it. Canonicalization code is usually buggy, and causes interop problems. Standards developers like it, because they define a signature over an abstraction. Unfortunately, abstractions aren&#8217;t crptographically digestable, only bit sequences, but rather than admitting this, they go down the canonicalization route. Aka &#8220;the long road to hell that starts in a green and peaceful valley&#8221;.</p>
<p>I worked with large PKI toolkits written under the assumption that you could actually read signed DER (s/mime and x509) into internal data structures, then write it out, and the signatures would match. That assumption was wrong in the Real World (TM).</p>
<p>What we eventually found was that even if it works with perfectly encoded data, the approach doesn&#8217;t work with badly encoded data. In your case, if somebody uses a leading TAB when your canonical rule says it should be 4 spaces, and they sign it, the signature will be valid. Until you read the data, then write it out again reformatting it correctly. People will report bugs to you, and you will tell them their data is wrong, and its not your fault. There are lots of symptoms of this. x.509 cert numbers encoded as negative numbers, unwittingly, there are a dozen DER string types, most programming languages only support 2, and neither are ancient teletype character sets, extensions that aren&#8217;t supported by the decoding app, so it doesn&#8217;t handle them and write them correctly. etc.</p>
<p>Then they will tell you that the data was output by a 3rd party vendor they have no control over, and that it works with product X, and they aren&#8217;t going to buy your toolkit anymore&#8230; Oops. But at least you have the comfort of being &#8220;right&#8221;.</p>
<p>Anyhow, short story is that robust commercial cryptographic toolkits do NOT modify signed data. They decode it into internal data structures so they can query it, but they keep the original data around in it&#8217;s original encoding, and when they need the encoded representatio of the data, they use the original.</p>
<p>Marshall Rose talks about this in the BEEP justification RFC, IIRC, where he talks about it as playing telephone.</p>
<p>Ok, back to my own projects.</p>
<p>Cheers</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Superdotman</title>
		<link>http://jens.mooseyard.com/2008/04/cloudy-identity/comment-page-1/#comment-2576</link>
		<dc:creator>Superdotman</dc:creator>
		<pubDate>Thu, 17 Apr 2008 02:50:06 +0000</pubDate>
		<guid isPermaLink="false">http://mooseyard.com/Jens/2008/04/cloudy-identity/#comment-2576</guid>
		<description>Half the stuff here is technobabble to me, and I&#039;m excited anyway. Do go on!</description>
		<content:encoded><![CDATA[<p>Half the stuff here is technobabble to me, and I&#8217;m excited anyway. Do go on!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ydna (LJ)</title>
		<link>http://jens.mooseyard.com/2008/04/cloudy-identity/comment-page-1/#comment-2582</link>
		<dc:creator>ydna (LJ)</dc:creator>
		<pubDate>Wed, 16 Apr 2008 20:00:57 +0000</pubDate>
		<guid isPermaLink="false">http://mooseyard.com/Jens/2008/04/cloudy-identity/#comment-2582</guid>
		<description>No need to quote the word thrilling! I&#039;m on the edge of my seat waiting for the next chapter. I&#039;m am just loving watching the layers being peeled back. It&#039;s like a nerdy mystery novel. Gosh! What will Jens do next? Arbitrary objects are afoot and they have a calling card!</description>
		<content:encoded><![CDATA[<p>No need to quote the word thrilling! I&#8217;m on the edge of my seat waiting for the next chapter. I&#8217;m am just loving watching the layers being peeled back. It&#8217;s like a nerdy mystery novel. Gosh! What will Jens do next? Arbitrary objects are afoot and they have a calling card!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jens Ayton</title>
		<link>http://jens.mooseyard.com/2008/04/cloudy-identity/comment-page-1/#comment-2581</link>
		<dc:creator>Jens Ayton</dc:creator>
		<pubDate>Wed, 16 Apr 2008 18:32:19 +0000</pubDate>
		<guid isPermaLink="false">http://mooseyard.com/Jens/2008/04/cloudy-identity/#comment-2581</guid>
		<description>The use of numbers for &lt;i&gt;stat&lt;/i&gt;, &lt;i&gt;algorithm&lt;/i&gt; and &lt;i&gt;format&lt;/i&gt; strike me as a bit of a wart. String identifiers would be my preference for that sort of thing, for much the same reason as constants or enums in code. It also provides a straightforward path for decentralized extensions to the system.

Nice stuff apart from that, though.</description>
		<content:encoded><![CDATA[<p>The use of numbers for <i>stat</i>, <i>algorithm</i> and <i>format</i> strike me as a bit of a wart. String identifiers would be my preference for that sort of thing, for much the same reason as constants or enums in code. It also provides a straightforward path for decentralized extensions to the system.</p>
<p>Nice stuff apart from that, though.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gordon Meyer</title>
		<link>http://jens.mooseyard.com/2008/04/cloudy-identity/comment-page-1/#comment-2580</link>
		<dc:creator>Gordon Meyer</dc:creator>
		<pubDate>Wed, 16 Apr 2008 15:09:42 +0000</pubDate>
		<guid isPermaLink="false">http://mooseyard.com/Jens/2008/04/cloudy-identity/#comment-2580</guid>
		<description>Nicely written, Jens. Thanks for the education and I&#039;m looking forward to the next installment.</description>
		<content:encoded><![CDATA[<p>Nicely written, Jens. Thanks for the education and I&#8217;m looking forward to the next installment.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff LaMarche</title>
		<link>http://jens.mooseyard.com/2008/04/cloudy-identity/comment-page-1/#comment-2579</link>
		<dc:creator>Jeff LaMarche</dc:creator>
		<pubDate>Wed, 16 Apr 2008 14:10:25 +0000</pubDate>
		<guid isPermaLink="false">http://mooseyard.com/Jens/2008/04/cloudy-identity/#comment-2579</guid>
		<description>This is very cool stuff, Jens... I can&#039;t wait to se what the front end of this thing looks like. I&#039;m forming ideas of what it might be, but they&#039;re probably a bit off-base....

Thanks again for sharing!</description>
		<content:encoded><![CDATA[<p>This is very cool stuff, Jens&#8230; I can&#8217;t wait to se what the front end of this thing looks like. I&#8217;m forming ideas of what it might be, but they&#8217;re probably a bit off-base&#8230;.</p>
<p>Thanks again for sharing!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eben Bruyns</title>
		<link>http://jens.mooseyard.com/2008/04/cloudy-identity/comment-page-1/#comment-2578</link>
		<dc:creator>Eben Bruyns</dc:creator>
		<pubDate>Wed, 16 Apr 2008 08:27:08 +0000</pubDate>
		<guid isPermaLink="false">http://mooseyard.com/Jens/2008/04/cloudy-identity/#comment-2578</guid>
		<description>I think I can see where you are heading with this, it&#039;s got me thinking in a million different directions and you potentially have something great on your hands here.

Keep the info coming, I hope I&#039;m right about what you&#039;re doing, exciting to say the least!!!</description>
		<content:encoded><![CDATA[<p>I think I can see where you are heading with this, it&#8217;s got me thinking in a million different directions and you potentially have something great on your hands here.</p>
<p>Keep the info coming, I hope I&#8217;m right about what you&#8217;re doing, exciting to say the least!!!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Elliott Harris</title>
		<link>http://jens.mooseyard.com/2008/04/cloudy-identity/comment-page-1/#comment-2577</link>
		<dc:creator>Elliott Harris</dc:creator>
		<pubDate>Wed, 16 Apr 2008 07:27:19 +0000</pubDate>
		<guid isPermaLink="false">http://mooseyard.com/Jens/2008/04/cloudy-identity/#comment-2577</guid>
		<description>The plot thickens! Interesting use of YAML, I&#039;d really like to see that YAML-Cocoa interface of yours. ;) Can&#039;t wait for the next part -- it&#039;s building and building, like some kind of wicked nerdy novel.

And the teaser! Profiles, Neighbors, and Relationships? Delicious.

Also, welcome back to Twitter. :)</description>
		<content:encoded><![CDATA[<p>The plot thickens! Interesting use of YAML, I&#8217;d really like to see that YAML-Cocoa interface of yours. ;) Can&#8217;t wait for the next part &#8212; it&#8217;s building and building, like some kind of wicked nerdy novel.</p>
<p>And the teaser! Profiles, Neighbors, and Relationships? Delicious.</p>
<p>Also, welcome back to Twitter. :)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
<!-- WP Super Cache is installed but broken. The path to wp-cache-phase1.php in wp-content/advanced-cache.php must be fixed! -->