Re: [xri] XRD Signing and Trust

[Nat Sakimura <n-sakimura@nri.co.jp>]

Now that people are talking about using XML Dsig, it may not be relevant 
anymore but...

Actually, SignedXRD idea appeared long time ago as SXRD.
There were some discussion on whether it should be attribute or element.
On wiki (http://wiki.oasis-open.org/xri/XrdOne/SimpleSign), it is captured 
as

<XRD sig="signature" sigalg="http://www.w3.org/2000/09/xmldsig#rsa-sha1"; 
certuri="pem file location" data="BASE64 of the payload" />

(Apparently, we stopped using SXRD in favour of XRD at some point...)

where:

XRD/@data : Base64 encoded XRD to be signed.

XRD/@sig : Signature taken over the original data (before Base64 encoding).

XRD/@certuri: (Optional) Certificate location.Either XRD/@certuri or 
XRD/@certs MUST be present.

XRD/@certs : (Optional) The content of XRD/@certuri.If both XRD/@certuri and 
XRD/@certs are present, XRD/@certs takes precidence.

XRD/@sigalg : (Optional) Signature Algorithm. Defaults to rsa-sha1.

BTW, I have no preference on attributes or elements.

=nat



--------------------------------------------------
From: "Will Norris" <will@willnorris.com>
Sent: Saturday, May 23, 2009 4:07 AM
To: "XRI TC" <xri@lists.oasis-open.org>
Subject: [xri] XRD Signing and Trust

> So to try and recap what was discussed yesterday with respect to
> signing and trust...
>
> ## Trust ##
>
> Eran managed to convince everyone that we did in fact need to add an
> additional element under <Link> that would represent the authority
> that signed the XRD document of the related resource.  Especially in
> Google's case, this could be different than the <Subject> of the
> resource, so it necessitates a new element.  We agreed on
> <TargetAuthority> for this new element to coincide with
> <TargetSubject>.  This is the same as <NextAuthority> in Google's XRDS
> example.
>
> There was also a desire to designate these two elements as being used
> for the purposes of trust, both to alert consuming applications that
> they can ignore them if they don't care about trust, but also to
> dissuade publishers from abusing them by shoving other stuff into
> them.  We considered nesting the two elements beneath a <Trust>
> element, but didn't like adding the extra layer.  Instead, we agreed
> to move these two elements to a separate XRD Trust namespace.  So you
> would end up with a Link element looking like...
>
> <Link>
>   <Rel>http://www.iana.org/assignments/relation/describedby</Rel>
>   <MediaType>application/xrd+xml</MediaType>
>   <URITemplate>https://www.google.com/accounts/o8/user-xrds?
> uri={%uri}</URITemplate>
>   <trust:TargetSubject>http://my-hosted-domain.com</
> trust:TargetSubject>
>   <trust:TargetAuthority>hosted-id.google.com</trust:TargetAuthority>
> </Link>
>
> If TargetAuthority is not defined, the value of TargetSubject is used
> for authority verification.  If TargetSubject is not defined, the URI
> value is used as both the TargetSubject and TargetAuthority.  The
> current XRD working draft has been updated to include these new
> elements, though I still need to write out this inheritance stuff.
>
>
> ## Signing ##
>
> We spent quite a bit of time talking about different ways to return a
> signed XRD.  There were already two proposed solutions on the table:
> including a <SignatureLocation> element in the XRD which contains the
> URL of a resource whose content is the signature of the XRD, and
> including the Signature in an HTTP header.  Everyone liked the ability
> to include the signature and XRD in a single payload, but there were
> concerns about using an HTTP Header.  The concerns were both
> philosophical (binding the signature delivery to a specific transport
> protocol) as well as practical (not being able to distribute a pre-
> signed static file out to file servers which can be served as-is).
>
> This led to a new proposal for delivery of a signed XRD -- an x-www-
> form-urlencoded response body which contains two parameters.
> 'signature' which is the base64-encoded and url-encoded signature, and
> 'xrd' which is the base64-encoded and url-encoded string whose value
> is the XRD document.  This is the same approach OAuth takes for
> responding to token requests and is very similar to SAML SimpleSign,
> except that it is in the response instead of the request.  Advantages
> of this approach -- everything can be included in the message body,
> making it transport agnostic and easy to distribute among many web
> servers in large deployments.  Disadvantages -- it's a bit more
> difficult for developers to debug, since they can't read the XRD on
> the wire... they'd need to manually base64-decode it.
>
> To prevent confusion if multiple signing methods are used (ie. x-www-
> form-urlencoded body AND a Signature header), we decided to make the
> <SignatureLocation> element required (but still single-valued).  We
> will define two special URIs which instruct consuming applications to
> retrieve the signature from the HTTP Header or the message body,
> respectively.
>
> There was also talk of a wrapper element for XRD which could contain
> the signature and data in XML:
> <SignedXRD>
>   <Signature /> (Required, Signature value)
>   <Data /> (Required, base64 encoded XRD)
> </SignedXRD>
>
> This will be particularly useful for XRDS, which is still necessary
> for XRI resolution.  But because it would change the root element (and
> therefore the schema, content type, etc), we opted NOT to include this
> format in the XRD spec itself.  With the x-www-form-urlencoded
> approach, it's really just another transport binding(?) with no
> changes to the schema at all.
>
>
> ## Feedback ##
>
> Thoughts on any of this?  For people that were at the face to face
> yesterday, did I miss anything?  For those that weren't, does this
> make sense?  Particularly from Google folks, what do you think of this
> new method for delivering signed XRDs?  Would this obviate the need
> for the signature HTTP header, or is there still value in having both
> methods available to XRD publishers?
>
> -will
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>