<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{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;}
/* List Definitions */
@list l0
{mso-list-id:908198674;
mso-list-type:hybrid;
mso-list-template-ids:228353600 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.0in;
text-indent:-.25in;
font-family:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</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'>Ok! <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'>Let me assume we now BELIEVE we actually COULD leverage the (highly
least-privilege-centric) .NET platform (operating in a constrained IIS7 data
center hosted environment) to build our “custom” cert trust models,
suiting openid discovery (operating in an UCI threat environment). That is: we
have at least removed the status quo barrier. <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'>We can now get back to design issues. What _<i>should</i>_ the
custom chain validation logic be, and how should it cooperate with cert-based namespace
controls invoked by the vanity https URLs used during discovery and any redirects
to https. (And, for folks in .Net land, how can one also leverage .NET
namespace controls for URL bindings, when further leveraging the .NET security model
to provide assurance?)<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>
<p class=MsoListParagraph style='margin-left:1.0in;text-indent:-.25in;
mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;
font-family:Symbol;color:#1F497D'><span style='mso-list:Ignore'>·<span
style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>How do we know public keys are valid and authorized today? We verify
they are signed by a trusted authority, and the authority roots back to a trusted
store. The trusted stored in (1) enterprise PKI and (2) H323 call agent signaling
between distributed call clusters …is usually the ldap directory (probably
with its own cross-forest trust on the cross-references between the ldap private
directory management domains). There, group policy registers the root certs “authorized”
by the organization, per OU. The big point is not to talk about ldap
resolvers (which competes with xri resolvers) but to focus on the fact CA
management is ...”not a browser list”, updated by WindowsUpdate. <o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoListParagraph style='margin-left:1.0in;text-indent:-.25in;
mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;
font-family:Symbol;color:#1F497D'><span style='mso-list:Ignore'>·<span
style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Now, the suspected compromise of the VeriSign Trust Network (or one
of its sub brands, rather) has just this week taught lots of folks about
PKI features not that well known previously – how to manually configure the
URL of the validation service (OCSP responder), so one can FOR ONESELF run
an OCSP server which overrides the status service of the trust network. Running
that server _<i>locally</i>_ is Microsoft’s own recommendation just this to
its customer - to provide for full “compromise recovery”. So, we
are on good solid ground, when we take some trust away from (a) the CAs, and
(b) the root distribution authorities.<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoListParagraph style='margin-left:1.0in;text-indent:-.25in;
mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;
font-family:Symbol;color:#1F497D'><span style='mso-list:Ignore'>·<span
style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>But, ignoring OCSP ( now we understand the <i>idea</i> of taking
“final decision/enforcement” power _<i>away</i>_ from the CA) Windows
also allows you to specify for a stored root a “cross-cert” URL,
even in those cert stores that are based on host registry (vs a DoD smartcard,
or DISA ldap directory). Its this area where OpenID discovery can copy well
established theory from the PKI world. Without describing all that cross-certs
do (but imagine cross-forest trust models from ldap applying to CAs) “One
authority domain can bootstrap another.” <o:p></o:p></span></p>
<p class=MsoListParagraph><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoListParagraph style='margin-left:1.0in;text-indent:-.25in;
mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;
font-family:Symbol;color:#1F497D'><span style='mso-list:Ignore'>·<span
style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>So the idea is, rather than useX.509 cross-certification (where
on CA root signs another CAs root), view the private association the RP has with
the OP as the means by which a USER “cross-certifies” the
certificate/CA being delivered to the RP in a positive assertion. This is
obviously a user<->SP trust model (since that’s what openid
assertions are!). The OP is not involved in that trust model formulation -
except as a means of setting up the authenticated delivery of the user’s AX
values via the assertion.<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=MsoListParagraph style='margin-left:1.0in;text-indent:-.25in;
mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;
font-family:Symbol;color:#1F497D'><span style='mso-list:Ignore'>·<span
style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Lets now use the OP as the BEARER doing the “forward”
cross-certification of user<<CA>> - in a user-RP “trust setup”
handshake. That is, once the OP releases a user’s choices of cross-certified
CA certs to the RP (under the control of the user’s choice of release-profile,
of course, per the normal (UCI) consent model of openid auth which happens in
any case during identity verification), the RP SHOULD consider that the user has
just cross-certified that CA cert.<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=MsoListParagraph style='margin-left:1.0in;text-indent:-.25in;
mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;
font-family:Symbol;color:#1F497D'><span style='mso-list:Ignore'>·<span
style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Now, if we want to go a bit further, it’s obviously
trivial in several instances of an AX attribute to even be communicating each
of the user’s vanity URLs, to be bound to https endpoints using those certs
that the RP has now registered, per openid. <o:p></o:p></span></p>
<p class=MsoListParagraph><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoListParagraph style='margin-left:1.0in;text-indent:-.25in;
mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;
font-family:Symbol;color:#1F497D'><span style='mso-list:Ignore'>·<span
style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>If we let the attribute value type of an AX attribute instance
be a multi-valued ordered set, we can go even further: the set can be the
very sequence of https redirects that the user has authorized a discovery
client to follow, when aiming for the openid and its XRDS.<o:p></o:p></span></p>
<p class=MsoListParagraph><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoListParagraph style='margin-left:1.0in;text-indent:-.25in;
mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;
font-family:Symbol;color:#1F497D'><span style='mso-list:Ignore'>·<span
style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The above obviously recourses, if the XRDS/HTML has delegation
settings.<o:p></o:p></span></p>
<p class=MsoListParagraph><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>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Ok I’m getting a bit fanciful with the later points, but I’m
sure in a WG, folks can be simplifying it all down, focus on the
holes etc.<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'>As to acts of poisoning by third parties, the user is doing above
nothing more that wifi https users do today on setting up the routers https admin
port – using ALL the main browsers. As the new https CA is encountered, what
does the user do? The user sets an override to “register” the new
CA in the user’s personal root trust list (on that host, only). With
the above procedures , that same set of overrides (and the cert itself) is recorded
at the OP in AX attributes, and is simply communicated to the SPs
of the users choice using openid assertions extended with AX. OpenID’s
release semantics act as the “authority” (cross-certification
act). Being UCI, the final trust authority is the user.<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>
<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-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<div>
<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"'> Andrew Arnott
[mailto:andrewarnott@gmail.com] <br>
<b>Sent:</b> Sunday, January 04, 2009 8:05 AM<br>
<b>To:</b> Peter Williams<br>
<b>Cc:</b> general@openid.net<br>
<b>Subject:</b> Re: [OpenID] The HTTPS in the OpenID (Re: Bug in OpenID RP
implementations)<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Peter,<o:p></o:p></p>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>These are great resources. Can you help me understand
one issue that I think I see with your initial discovery phase that you
explained?<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>It seems to me that if during discovery the RP is required
to (temporarily) accept SSL certs that are not signed by a known good CA, and
at the end of discovery or authentication the public keys for these certs are
sent from OP to RP so the RP can match each cert it encountered with the known
good list from the OP or identifier, (Am I understanding this correctly??) it
seems to me a wide open door for someone to DNS poison the RP, redirecting
traffic to his own server with his own certs, and his own OP which will send
approval messages for those certs.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br clear=all>
--<br>
Andrew Arnott<br>
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - Voltaire<br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal>On Sun, Jan 4, 2009 at 1:06 AM, Peter Williams <<a
href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p><span style='font-size:11.0pt'>CTLs are not the whole story, but are a good
place to start to see where the security constraints in the hosted
environment are imposed by the hoster's core setup. It's also interesting to
glimpse from the following how .NET has evolved the trust management framework
since the IIS4 days I once knew well, and see how the modern ACS is going
further (rant on. in ways that are no longer being enforced solely within the
crypto boundary, relying more on trusted systems theory like AuthMan RBAC. rant
off). </span><o:p></o:p></p>
<p><span style='font-size:11.0pt'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt'>I'm starting to envy Dick. This modern trust
stuff looks like so much fun! Microsoft core platform engineering on crypto has
always been classy, though can tend to become somewhat obscure and
overly-professionalized – particularly as native code is mapped into the
VM, as we see in the first resource:-</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'><a
href="http://blogs.msdn.com/gproano/archive/2005/03/22/400645.aspx"
target="_blank">http://blogs.msdn.com/gproano/archive/2005/03/22/400645.aspx</a>
(fiddling with CTLs programmatically in early .NET)</span><o:p></o:p></p>
<p><span style='font-size:11.0pt'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt'>If GoDaddy has console access, <a
href="http://www.leastprivilege.com/CertificateBasedAuthenticationAndWCFTransportSecurity.aspx"
target="_blank">http://www.leastprivilege.com/CertificateBasedAuthenticationAndWCFTransportSecurity.aspx</a><span
style='color:#1F497D'>. gives you a start on the core CTL ideas in an IIS
context, but is obviously not dynamic.</span></span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'><a
href="http://www.leastprivilege.com/SslStreamSample.aspx" target="_blank">http://www.leastprivilege.com/SslStreamSample.aspx</a>
(lowlevel access to the SSL client library, presumably applying http.sys, with
validation callback interface)</span><o:p></o:p></p>
<p><span style='font-size:11.0pt'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt'>WCF model on app-based certificate trust
constructs <a
href="http://www.leastprivilege.com/CertificateBasedAuthenticationAndWCF.aspx"
target="_blank">http://www.leastprivilege.com/CertificateBasedAuthenticationAndWCF.aspx</a>
</span><o:p></o:p></p>
<p><span style='font-size:11.0pt'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt'>custom validation <a
href="http://www.leastprivilege.com/CertificateBasedAuthenticationAndWCFMessageSecurity.aspx"
target="_blank">http://www.leastprivilege.com/CertificateBasedAuthenticationAndWCFMessageSecurity.aspx</a>.</span><o:p></o:p></p>
<p><span style='font-size:11.0pt'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt'>Looks like the peer trust model may be good
for an openid ID RP doing what I suggested (to enhance https openid discovery .
It can then collect all the asserted certificates from an OP, and then custom
validation logic binds a particular cert to the inbound openid, for use next
time with a vanity https URL that ultimately resolves during discovery to that
OP-provisioned openid (via redirect, via delegation, or whatever)</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt'><a
href="http://www.leastprivilege.com/FederatingWithLiveIDUsingTheAccessControlService.aspx"
target="_blank">http://www.leastprivilege.com/FederatingWithLiveIDUsingTheAccessControlService.aspx</a>
(modern clue on how folks MAY? address the issue of trust in a .NET host (of
which IIS7 is only one option, recall). See notion of ACS. Only relevant to the
distant future tho. Will probably be highly relevant to OP/RP white-listing
too, tho.</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p><b><span style='font-size:10.0pt'>From:</span></b><span style='font-size:
10.0pt'> <a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>
[mailto:<a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>]
<b>On Behalf Of </b>Andrew Arnott<br>
<b>Sent:</b> Saturday, January 03, 2009 7:06 PM<br>
<b>To:</b> Peter Watkins<br>
<b>Cc:</b> <a href="mailto:general@openid.net" target="_blank">general@openid.net</a><o:p></o:p></span></p>
<div>
<p class=MsoNormal><span style='font-size:10.0pt'><br>
<b>Subject:</b> Re: [OpenID] The HTTPS in the OpenID (Re: Bug in OpenID RP
implementations)<o:p></o:p></span></p>
</div>
</div>
</div>
<p> <o:p></o:p></p>
<p>On Sat, Jan 3, 2009 at 4:34 PM, Peter Watkins <<a
href="mailto:peterw@tux.org" target="_blank">peterw@tux.org</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p><br>
Can't you "just" add the CAs to trusted roots for the Windows account<br>
that the <a href="http://asp.net" target="_blank">asp.net</a> app
runs as? <o:p></o:p></p>
<div>
<p> <o:p></o:p></p>
</div>
<p>Not while that <a href="http://ASP.NET" target="_blank">ASP.NET</a> app is
running with medium trust. <o:p></o:p></p>
<div>
<p style='margin-bottom:12.0pt'><br clear=all>
--<br>
Andrew Arnott<br>
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - Voltaire<o:p></o:p></p>
<div>
<p>On Sat, Jan 3, 2009 at 4:34 PM, Peter Watkins <<a
href="mailto:peterw@tux.org" target="_blank">peterw@tux.org</a>> wrote:<o:p></o:p></p>
<p><br>
Can't you "just" add the CAs to trusted roots for the Windows account<br>
that the <a href="http://asp.net" target="_blank">asp.net</a> app runs as? I
supposed it'd be tougher for folks<br>
using integrated auth & impersonation, but I also expect most <a
href="http://asp.net" target="_blank">asp.net</a><br>
webapps doing OpenID auth aren't using impersonation. Similarly, I'd<br>
expect to be able to remove CA certs from the <a href="http://asp.net"
target="_blank">asp.net</a> webapp user's<br>
profile in order to shorten the CA whitelist.<br>
<br>
I don't know how tough it is to edit the root certs for the profiles of<br>
app pool-type accounts, and hope you'll forgive my not firing up<br>
Studio on a Saturday night to see if there's an obvious API. :-)<br>
<br>
On *nix it's usually pretty straightforward -- find the keystore<br>
holding root certs and manipulate it via OpenSSL, Java keytool,<br>
or whatever app is appropriate for the environment. Is it not the<br>
same in Windows?<br>
<span style='color:#888888'><br>
-Peter</span><o:p></o:p></p>
<div>
<div>
<p><br>
On Sat, Jan 03, 2009 at 03:24:37PM -0800, Andrew Arnott wrote:<br>
> Definitely some interesting thoughts in there.<br>
> I'll add one more: while it makes a sensible default for Microsoft to
cause<br>
> .NET connections to HTTPS servers without a signed cert by a known good CA<br>
> to fail, it doesn't seem like it should require the whole machine to trust<br>
> the individual web site if that web site wishes to go ahead and make a<br>
> connection. Crying out loud: if a partial trust web site can
initiate an<br>
> HTTP connection to a random server (which it can, with GoDaddy's small<br>
> deviation to Medium Trust), why couldn't it also open an HTTPS connection
in<br>
> order to encrypt the traffic, and decide to be its own judge on the
validity<br>
> of that certificate?<br>
><br>
> I'm going to poke around Microsoft and see if I can't get this policy<br>
> changed so that .NET clients can approve of these certs signed by<br>
> lesser-known CAs.<o:p></o:p></p>
</div>
</div>
</div>
<p> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>