<div bgcolor="#ffffff" text="#000000">
Thanks, just some side notes:<br>
<br>
John Bradley wrote:
<blockquote type="cite">John,
<div><br>
</div>
<div>We spent a lot of time looking at ways of simplifying
canonicalization by having the signature in a separate doc.</div>
<div><br>
</div>
<div>This minimally requires a separate network access to get the
signature document if one wants to check it. <br>
</div>
</blockquote>
In the use case I'm most concerned with (site-meta + XRD), both
documents are highly cacheable and I hope UAs would cache them
aggressively (per HTTP cache control directives of course). So this
doesn't seem like a huge issue.<br>
<br>
<blockquote type="cite">
<div><br>
</div>
<div>It also presumes that XRD will only be used in applications using http:.</div>
</blockquote>
It covers only the HTTP transport case, yes. I don't think it's at all
a bad thing to start with the 80% case and make sure it works really
well before moving on to broader cases. It would be a good thought
experiment at least to see how e.g., OpenID and XMPP could handle
separate-doc signatures and how complex it would be.<br>
<blockquote type="cite">
<div><br>
</div>
<div>One solution proposed by Google was to include the signature in the headers, to reduce accesses. </div>
<div><br>
</div>
<div>However this makes deployment at the OP end more difficult, because you no longer have just static files, and may also behave unpredictably with proxy's</div>
</blockquote>
Hmm. I just configured this with static files at my personal virtual
Apache host, at <a href="http://www.johnpanzer.com/t/test.xrd" target="_blank">http://www.johnpanzer.com/t/test.xrd</a>, using a single
line .htaccess file:<br>
<br>
Header add X-Signature "blah blah blah"<br>
Output:<br>
-------------------------------------------------------------------<br>
HTTP/1.1 200 OK<br>
Date: Mon, 15 Jun 2009 16:24:55 GMT<br>
Server: Apache/2.0.54 (Unix) mod_perl/1.99_09 Perl/v5.8.0
mod_ssl/2.0.54 OpenSSL/0.9.7a DAV/2 FrontPage/5.0.2.2635 PHP/4.4.0
mod_gzip/2.0.26.1a<br>
Last-Modified: Mon, 15 Jun 2009 16:14:28 GMT<br>
ETag: "39c3f140-13-5a38a100"<br>
Accept-Ranges: bytes<br>
Content-Length: 19<br>
X-Signature: blah blah blah<br>
Content-Type: text/plain<br>
<br>
Of course this requires hosting providers to support .htaccess, but I
would suspect that most serious ones do. And if signatures become
important it's a trivial httpd.conf change to start supporting
.htaccess. <br>
<br>
There are probably much more sophisticated ways to do this of course.
My main point is that I don't think requiring a custom header is
particularly onerous.<br>
<br>
What were the concerns about proxies? (I don't know of any, at least
when using X- headers.)<br>
<blockquote type="cite">
<div><br>
</div>
<div>For simplicity of
deployment of the files having a single static file seems to be the preference. </div>
<div><br>
</div>
<div>We looked at using HTLM form encoding with the XRD body base64
encoded but that added unnecessary complexity for people not wanting
signatures.</div>
<div>S/MIME PKCS7 and other options were considered but had no clear
advantage over a constrained form of XML normalization.</div>
<div><br>
</div>
<div>Being able to keep the signature and document together has
advantages for audit logs,</div>
</blockquote>
How much of an advantage is this? <br>
<br>
<blockquote type="cite">
<div> creating XRDS documents for XRI, using XRD for protocols
other than HTTP.</div>
<div><br>
</div>
<div>If I want to send a XRD as a AX Attribute because some of the
endpoints are private sending the signature in the document makes life
much easier.</div>
</blockquote>
Is it much easier to use<br>
openid.ax.mumble=my.xrd<br>
<br>
than to use<br>
openid.ax.mumble=my.xrd<br>
openid.ax.mumble.signature=blah blah blah<br>
?<br>
<blockquote type="cite">
<div><br>
</div>
<div>Infocard pushing a XRD discovery document as the value of a
claim also benefits from the single document approach.</div>
</blockquote>
Can Infocard handle multi-valued claims?<br>
<br>
It's true that it's more work to handle 2 pieces of data separately,
transport them, store them, etc. On the other hand the signature
really is metadata about the document and there are often good reasons
to separate the two. The signature is also optional in all the
proposals I've seen. And getting embedded signatures right seems like
it's significantly harder than getting detached signatures right (based
on prior discussions and feedback).<br>
<blockquote type="cite">
<div><br>
</div>
<div>Peter is not unusually looking farther down the road. </div>
<div><br>
</div>
<div>X.509 is a ASN.1 meta-data document that has an enveloped
signature. Probably not something you want to parse from scratch in
Ruby.</div>
<div>X.509 was designed to be flexible and contain may types of
meta-data.</div>
<div><br>
</div>
<div>It has never really lived up to the design goal. In practice
they are not useful for conveying arbitrary meta-data.</div>
<div><br>
</div>
<div>I think Peter is imagining that if we have a well understood
extensible meta-data container XRD, with an enveloped signature like
X.509 it could replace X.509 certificates.</div>
<div><br>
</div>
<div>People on the Shibboleth side of the world are considering such
things with SAML meta-data.</div>
<div><br>
</div>
<div>I will leave the required rant about overthrowing the evil CA
oppressors to others.</div>
</blockquote>
Darn.<br>
<blockquote type="cite">
<div><br>
</div>
<div>It is possible that signed XRD could play a valuable role in
expanding trust on the internet in areas where traditional PKI has not
stepped up to the challenge.</div>
<div><br>
</div>
<div>The question is a single human readable document that can be
consumed both by signature aware and unaware applications the way to go?</div>
<div><br>
</div>
<div>Is being compatible with existing XMLDsig libraries and being
reasonably easy to implement in scripting languages compatible?</div>
<div><br>
</div>
<div>XRD has broader use cases than just openID. We are honestly
trying to provide a good balance. </div>
<div><br>
</div>
<div>John B.</div>
<div>
<div>
<div>On 14-Jun-09, at 12:47 PM, John Panzer wrote:</div>
<br>
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000"> John Bradley wrote:
<blockquote type="cite">Peter,
<div><br>
</div>
<div>Yes some of us see the possibility of XRD as signed
meta-data being a useful alternative to X.509 eventually.</div>
<div><br>
</div>
<div>If we
have an signature method that supports enveloping signatures, XRD will be more useful for those applications.</div>
<div><br>
</div>
<div>We can opt for the simplest signing, that of signing the
binary representation of the XRD and keeping the signature in a
detached file. </div>
<div>This may make life simpler for scripting languages dealing
with cannonicalization but at the cost of making it awkward to deal
with in other environments where having the signature in the same
document is very useful.</div>
</blockquote>
For the record, and for those of us not versed in X.509, can provide
some use cases and details on how having the signature in the XRD doc
is necessary/useful for for XRD?<br>
<br>
<br>
<blockquote type="cite">
<div><br>
</div>
<div>Full XMLDsig is ugly because of qnames and other issues.
We are proposing a constrained implementation that eliminates most of
the cannonicalization complexities, but is still compatible with
existing libraries.</div>
<div><br>
</div>
<div>John B.<br>
<div>
<div>On 10-Jun-09, at 12:10 PM, <a href="mailto:general-request@openid.net" target="_blank">general-request@openid.net</a>
wrote:</div>
<br>
<blockquote type="cite"><span style="font-family: monospace;">Date: Wed, 10 Jun 2009 09:10:44 -0700<br>
From: Peter Williams <<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>><br>
Subject: Re: [OpenID] Signing method for XRD<br>
To: Santosh Rajan <<a href="mailto:santrajan@gmail.com" target="_blank">santrajan@gmail.com</a>>, "<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>"<br>
<span style="white-space: pre;"> </span><<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><br>
Message-ID:<br>
<span style="white-space: pre;"> </span><<a href="mailto:BFBC0F17A99938458360C863B716FE46398DCE8FDD@simmbox01.rapnt.com" target="_blank">BFBC0F17A99938458360C863B716FE46398DCE8FDD@simmbox01.rapnt.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
<br>
my first reaction was ugh - xml-dsig has its own inband mechanism for
referencing keying material - and here is openid/xrd doing yet another
standard for verifying signatures and validating the supporting keying
material (probably poorly).<br>
<br>
My second reaction on reflection was that xml-dsig is rarely used to
its full potential. Its typically used as a PKCS7 signing and sealing
emulation modes, with an XML centric view of the world - with no
particular benefit. But, if xml dsig fully uses its external
references, and the references are to a world of XRD files which are
TRUSTED to act as a key distribution mechanism, things get rather more
interesting. In that world, the XRD is becoming a certificate, as we
know it - and one whose format and semantics would enable it to go
beyond the staid ol X.509 cert chains and benefit the full expression
power of xri queries and XRI resolution.<br>
<br>
What the X.509 v3 format work took part (divorcing asymmetric key
management from dap/ldap resolution), XRI/XRD may be putting back
together: query-based named-key resolution supporting trust fabric
meshes.<br>
<br>
</span></blockquote>
</div>
<br>
</div>
<pre><hr size="4" width="90%">
_______________________________________________
general mailing list
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>