[OpenID] Signing method for XRD

Mon Jun 15 18:23:08 UTC 2009

 Thanks, just some side notes:

John Bradley wrote:

John,
 We spent a lot of time looking at ways of simplifying canonicalization by
having the signature in a separate doc.

 This minimally requires a separate network access to get the
signature document if one wants to check it.

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.

 It also presumes that XRD will only be used in applications using http:.

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.

One solution proposed by Google was to include the signature in the
headers, to reduce accesses.

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

Hmm.  I just configured this with static files at my personal virtual Apache
host, at http://www.johnpanzer.com/t/test.xrd, using a single line .htaccess
file:

Header add X-Signature "blah blah blah"
Output:
-------------------------------------------------------------------
HTTP/1.1 200 OK
Date: Mon, 15 Jun 2009 16:24:55 GMT
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
Last-Modified: Mon, 15 Jun 2009 16:14:28 GMT
ETag: "39c3f140-13-5a38a100"
Accept-Ranges: bytes
Content-Length: 19
X-Signature: blah blah blah
Content-Type: text/plain

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.

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.

What were the concerns about proxies?  (I don't know of any, at least when
using X- headers.)

 For simplicity of
deployment of the files having a single static file seems to be the
preference.

 We looked at using HTLM form encoding with the XRD body base64 encoded but
that added unnecessary complexity for people not wanting signatures.
S/MIME PKCS7 and other options were considered but had no clear advantage
over a constrained form of XML normalization.

 Being able to keep the signature and document together has advantages for
audit logs,

How much of an advantage is this?

  creating XRDS documents for XRI,  using XRD for protocols other than HTTP.

 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.

Is it much easier to use
openid.ax.mumble=my.xrd

than to use
openid.ax.mumble=my.xrd
openid.ax.mumble.signature=blah blah blah
?

 Infocard pushing a XRD discovery document as the value of a claim also
benefits from the single document approach.

Can Infocard handle multi-valued claims?

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).

 Peter is not unusually looking farther down the road.

 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.
X.509 was designed to be flexible and contain may types of meta-data.

 It has never really lived up to the design goal.  In practice they are not
useful for conveying arbitrary meta-data.

 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.

 People on the Shibboleth side of the world are considering such things with
SAML meta-data.

 I will leave the required rant about overthrowing the evil CA oppressors to
others.

Darn.

 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.

 The question is a single human readable document that can be consumed both
by signature aware and unaware applications the way to go?

 Is being compatible with existing XMLDsig libraries and being reasonably
easy to implement in scripting languages compatible?

 XRD has broader use cases than just openID.  We are honestly trying to
provide a good balance.

 John B.
 On 14-Jun-09, at 12:47 PM, John Panzer wrote:

 John Bradley wrote:

Peter,
 Yes some of us see the possibility of XRD as signed meta-data being
a useful alternative to X.509 eventually.

 If we
have an signature method that supports enveloping signatures,  XRD
will be more useful for those applications.

 We can opt for the simplest signing, that of signing the binary
representation of the XRD and keeping the signature in a detached file.
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.

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?

 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.

 John B.
 On 10-Jun-09, at 12:10 PM, general-request at openid.net wrote:

Date: Wed, 10 Jun 2009 09:10:44 -0700
From: Peter Williams <pwilliams at rapattoni.com>
Subject: Re: [OpenID] Signing method for XRD
To: Santosh Rajan <santrajan at gmail.com>, "general at openid.net"
 <general at openid.net>
Message-ID:
 <BFBC0F17A99938458360C863B716FE46398DCE8FDD at simmbox01.rapnt.com>
Content-Type: text/plain; charset="us-ascii"

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).

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.

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.

 ------------------------------

_______________________________________________
general mailing listgeneral at openid.nethttp://openid.net/mailman/listinfo/general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090615/ffe0740f/attachment.htm>