[OpenID] Signing method for XRD

[John Bradley]

inline

On 15-Jun-09, at 2:23 PM, John Panzer wrote:

> 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.
>
Caching will benefit OP's and RP's.  I think it will be a while before  
User Agents (Browsers) start using XRD.
Though we have started to see signs of it with Identity in the browser  
plugins reading sites XRD.

So yes Caching is important.  That is one reason I prefer the single  
file approach.

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

We really don't want to be difining diffrent signature methods for  
each protocol if we can avoid it.

>>
>> 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:
>
Yes you can add a single header to every page easily.  George Fletcher  
thought the idea of adding a different header to each page  
significantly harder.  It might be possible to do it in some hosting  
environments.

Remember this needs to work for user XRD as well as sites.

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

There was a concern that not all proxies would preserve them.  I did  
see problems with that several years ago but don't know what the  
current state  of transparent web caching as used in cable networks  
etc is.

>>
>> 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?
A big one if you want to do it. The workaround is base64 encode the  
document and store it in another XML element.
>
>>  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
> ?
Sending it as two peaces is possible and was discussed.
>>
>> 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?
>
Not yet.

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

With the fully detached signature we need to treat the XRD as a binary  
object, base64 encoding it etc if it is to be preserved.  That  
potentially makes life harder if it is also used by non signature  
aware apps.

The nice thing about the XML signature approach is that non signature  
aware apps can just ignore the signature and don't need to do anything  
special to preserve it.

John B.
>>
>> 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 list
>>>> general at openid.net
>>>> http://openid.net/mailman/listinfo/general
>>>>
>>>
>>
>