[OpenID] Signing method for XRD
John Bradley
john.bradley at wingaa.com
Mon Jun 15 12:17:05 UTC 2009
Good points but moot if we cant decide on a cannonicalization method
for the XML.
Are you in favor of a normalization that
1 supports an enveloped signature so that the document is an XRD and
can be used by non signature aware apps.
2 one that base64 encodes the XRD and makes it an element of some
other XML document.
3 one that base64 encodes the XRD and makes it part of a HTML form for
the signature
4 one that relies on applications not to modify the binary
representation of the XRD and keep the signature in a separate file.
Those are the options we are discussing at this point.
John B.
On 14-Jun-09, at 11:30 PM, Peter Williams wrote:
> 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
>
>
>
More information about the general
mailing list