[OpenID] Signing method for XRD

[Peter Williams]

my gut (vs my brain) tells me the following:

go with a minimum to implement scheme. Don't assume folks use xml dsig libraries. Assume they custom code, and call crypto directly. This reflects the nature of the openid community, which is not w3c traditional (its not sun, microsoft, ibm, etc)

DO use modern w3c efforts in derivedKey types from xml dsig 1.1. Allow the signature algorithm to be keyed by a derived key, which may even thus be derived from a kerberos token (meaning xrd signing avoids the limits of public key). This learns from what ws* secureconversation techniques taught us.

Relying on derived keys, and custom software at the app layer, nicely decouples how one trusts the verification key from that which openid/XRI really need to do: get authenticated XRDs out there, without relying on full XRI Resolution and saml tokens.  Specifying all the legitimate ways of deriving keys from authenticated keying material is not something XRD signing spec need be concerned with. A non-normative annex might however specify how one can derive  a symmetric hmac-signing key from an openid association handle's master secret, illustrating how even openid auth itself may provide the underlying basis for verifying signatures on SEP discovery documents.

________________________________
From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of John Bradley [john.bradley at wingaa.com]
Sent: Sunday, June 14, 2009 10:26 AM
To: jpanzer at acm.org
Cc: general at openid.net
Subject: Re: [OpenID] Signing method for XRD

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.

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

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

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

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

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.

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<mailto:general-request at openid.net> wrote:

Date: Wed, 10 Jun 2009 09:10:44 -0700
From: Peter Williams <pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>>
Subject: Re: [OpenID] Signing method for XRD
To: Santosh Rajan <santrajan at gmail.com<mailto:santrajan at gmail.com>>, "general at openid.net<mailto:general at openid.net>"
<general at openid.net<mailto:general at openid.net>>
Message-ID:
<BFBC0F17A99938458360C863B716FE46398DCE8FDD at simmbox01.rapnt.com<mailto: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<mailto:general at openid.net>
http://openid.net/mailman/listinfo/general