<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I was taught this (general) business nearly 15 years ago by
someone who insisted we learned to write up the specific threats/countermeasures
facing CAs/OPs/IDPs in their mission formally …as ITSEC (nowadays: common
criteria) controls. Then, he (being an advanced student of the art) showed how
one could up the constraints formally (using a formal functional language
called Z, which allowed theorem proving in relatively popular algebra). The
hardest constraint to capture, specific to TTPs, concerning the (ITSEC) threat
of “abuse of system high privileges” (and then “abuse of
delegated namespace rights”). These two characterizations were deemed
sufficient to address the “security objective” dealing with the problem
of “mutual suspicion between authorities”<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>This is where PKI comes into its own, where - in a network of
such authorities who must address the “mutual suspicion” (that an
insider operating another authority will exploit the system high privilege to
abuse their authority level) – the imposition of a graph of (a) namespace
delegation and (b) formal asymmetric key management controls allows one to address
the main risks flowing from the mutual suspicion of authorities object. <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>UsingX.509 PKI (or any XML metadata doing the same job as PKI)
the risks are usually addressed in a quite intuitive way: 1. that the
authority is given only limited scope to do damage (and the namespace controls
represent that scope), and 2. the asymmetric key management controls concerning
‘authority compromise handling’ can not only remove the keys of
the malevolent authority from use in the trust system but also one can demonstrate
that the distributed network of cooperating authorities can QUICKLY purge from
the overall system all keys/names issued by the malevolent authority, within
its naming scope.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>This is not a new problem, and its well researched
academically (and in formal security analysis for a high-assurance military/intel
systems)<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Operational controls such as dual key arming, multi-key escrow,
n of m key splitting, countersigning by n authorities… address failure
modes of the system – and allow an evaluator to give a rating to the
system’s ability to perform “trusted recovery”. This is not the
same issue set as those issues associated with mutual suspicion.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
general-bounces@openid.net [mailto:general-bounces@openid.net] <b>On Behalf Of </b>David
Fuelling<br>
<b>Sent:</b> Saturday, November 29, 2008 10:42 AM<br>
<b>To:</b> OpenID List<br>
<b>Subject:</b> [OpenID] 2-Headed OpenID Auth for Increased Security?<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'>Hey List,<span
style='color:#1F497D'><o:p></o:p></span></p>
<p class=MsoNormal style='margin-bottom:12.0pt'>One issue that I keep coming
back to is that my OP (or a rogue employee at my OP) could masquerade as me at
OpenID-enabled RP's across the web since the OP is a single authentication
point in the OpenID ecosystem.<br>
<br>
I suppose there are several ways to make this happen, but I'd appreciate any
feedback on this idea...<br>
<br>
<br>
<span style='color:#1F497D'><o:p></o:p></span></p>
</div>
</body>
</html>