<?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"
	>
<channel>
	<title>Comments on: Public Key Cryptography</title>
	<atom:link href="http://www.snell-pym.org.uk/archives/2008/06/03/public-key-cryptography/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.snell-pym.org.uk/archives/2008/06/03/public-key-cryptography/</link>
	<description>Sarah and Alaric Snell-Pym living in interesting times</description>
	<pubDate>Wed, 19 Nov 2008 22:17:47 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: alaric</title>
		<link>http://www.snell-pym.org.uk/archives/2008/06/03/public-key-cryptography/#comment-75973</link>
		<dc:creator>alaric</dc:creator>
		<pubDate>Mon, 07 Jul 2008 09:53:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.snell-pym.org.uk/?p=790#comment-75973</guid>
		<description>&lt;p&gt;I have an additional feature I think a MacOS/GPG integration should have, actually, purely to foster better adoption in commercial environments.&lt;/p&gt;

&lt;p&gt;The X.509 model is actually fairly appropriate for corporate use - a central corporate CA can issue certificates for their employees. Such centralised operation is entirely correct in such an environment.&lt;/p&gt;

&lt;p&gt;However, the neat thing about the web-of-trust model is that it's more general than hierarchial trust; a hierarchy is, in fact, a restricted form of a web.&lt;/p&gt;

&lt;p&gt;So there should be a simple tool built into the directory services stuff used to maintain a centralised organisational user database (I must confess I've never come across Macs configured to operate in this way; I suspect most organisations will really be running Windows with Active Directory in the core; but a Mac can talk to that, which is sufficient for this purpose). It would simply manage an X.509-esque certificate hierarchy. Users who are connected to a directory service would be given the option, when they have created a private key, to submit it to The Directory for signing. In which case, the key management system (actually alongside the directory) would check the details on the key strictly match those on the user account that's submitting the key, and if so, sign it with a master key (to publish the fact that it's done the check), then slip the signed public key into the directory - and into public keyservers so that other organisations can then see that the new employee is, in fact, a certified employee of BigCorp when they start sending emails from their BigCorp address.&lt;/p&gt;

&lt;p&gt;Oh, and when an account is deleted from the directory, the key management system would notice this and immediately publish a revocation of the organisation's signature of the key.&lt;/p&gt;

&lt;p&gt;The &lt;em&gt;next&lt;/em&gt; version of the thing could also support role/group keys. Administrators could grant a keypair to a user group, then a proxy system could ensure that outgoing email from members of that group (as long as the signature matches a real group member!) is also signed automatically by the group's key, optionally removing the original author's signature. This would enable digital identities to be assigned to roles or teams within an organisation, even as members come and go. Exactly how to implement the proxying is an intereting question; for emails, how do you know if an email is semantically from its author, or from a role the author holds? If you use a mail client that supports multiple sending accounts it becomes easy. But what about signing files and the like?&lt;/p&gt;

&lt;p&gt;Incoming encrypted emails to the role/group are easy to handle - the mail system can decrypt them, then re-encrypt them for the members of the group and distribute it to them.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>I have an additional feature I think a MacOS/GPG integration should have, actually, purely to foster better adoption in commercial environments.</p>

<p>The X.509 model is actually fairly appropriate for corporate use - a central corporate CA can issue certificates for their employees. Such centralised operation is entirely correct in such an environment.</p>

<p>However, the neat thing about the web-of-trust model is that it's more general than hierarchial trust; a hierarchy is, in fact, a restricted form of a web.</p>

<p>So there should be a simple tool built into the directory services stuff used to maintain a centralised organisational user database (I must confess I've never come across Macs configured to operate in this way; I suspect most organisations will really be running Windows with Active Directory in the core; but a Mac can talk to that, which is sufficient for this purpose). It would simply manage an X.509-esque certificate hierarchy. Users who are connected to a directory service would be given the option, when they have created a private key, to submit it to The Directory for signing. In which case, the key management system (actually alongside the directory) would check the details on the key strictly match those on the user account that's submitting the key, and if so, sign it with a master key (to publish the fact that it's done the check), then slip the signed public key into the directory - and into public keyservers so that other organisations can then see that the new employee is, in fact, a certified employee of BigCorp when they start sending emails from their BigCorp address.</p>

<p>Oh, and when an account is deleted from the directory, the key management system would notice this and immediately publish a revocation of the organisation's signature of the key.</p>

<p>The <em>next</em> version of the thing could also support role/group keys. Administrators could grant a keypair to a user group, then a proxy system could ensure that outgoing email from members of that group (as long as the signature matches a real group member!) is also signed automatically by the group's key, optionally removing the original author's signature. This would enable digital identities to be assigned to roles or teams within an organisation, even as members come and go. Exactly how to implement the proxying is an intereting question; for emails, how do you know if an email is semantically from its author, or from a role the author holds? If you use a mail client that supports multiple sending accounts it becomes easy. But what about signing files and the like?</p>

<p>Incoming encrypted emails to the role/group are easy to handle - the mail system can decrypt them, then re-encrypt them for the members of the group and distribute it to them.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: alaric</title>
		<link>http://www.snell-pym.org.uk/archives/2008/06/03/public-key-cryptography/#comment-75232</link>
		<dc:creator>alaric</dc:creator>
		<pubDate>Wed, 04 Jun 2008 00:18:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.snell-pym.org.uk/?p=790#comment-75232</guid>
		<description>&lt;p&gt;Yeah. Sadly, I don't think X.509 is the way to go...&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Yeah. Sadly, I don't think X.509 is the way to go...</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Ben</title>
		<link>http://www.snell-pym.org.uk/archives/2008/06/03/public-key-cryptography/#comment-75213</link>
		<dc:creator>Ben</dc:creator>
		<pubDate>Tue, 03 Jun 2008 16:21:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.snell-pym.org.uk/?p=790#comment-75213</guid>
		<description>&lt;p&gt;Did you know Mail.app supports the X.509 stuff? Search for "certificates" in Mail.app's help for info. It's not exactly advertised, though.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Did you know Mail.app supports the X.509 stuff? Search for "certificates" in Mail.app's help for info. It's not exactly advertised, though.</p>]]></content:encoded>
	</item>
</channel>
</rss>
