Fwd: [OpenID] Signing method for XRD

[Santosh Rajan]

Ok let me put my thoughts on this together.

Once you digitally sign a document, though physically the document remains
in tact and retains its content type, after the act of signing, it is really
a frozen bunch of bits. And if you dont make that distinction you get into
all sorts of tangles. And that was the mistake made by XMLDSig. In other
words after signing the Content-Type should be binary, whatever you want to
call it. After verification it takes up its original Content-Type. 

It is also better to have both the signed and unsigned docs as the same. So
the signature will have to be detached. Signature procedure will be.

1) Insert Links to the signature and cert into the XRD
2) Sign it and give it a new Content-Type (a binary content type and new
filename extension)
3) Applications on the way will not muck with this document anymore.
4) Get the document signature and cert and verify
5) Change Content-Type and extension to original

So the Content-Type and file extension should give a clue on what type of
document it is at each stage.



David Recordon wrote:
> 
> The specs list feels like a better home for this thread. :) 
> 
> 
> --David 
> 
> ----- "Nat Sakimura" <sakimura at gmail.com> wrote: 
>> Hi all: 
>> 
>> At XRI TC of OASIS Open, we are talking about the signing method for XRD. 
>> The current trend in the TC is that to use a constrained form of XML
>> DSig, 
>> which is found in the SAML Core spec. We are almost deciding on it, 
>> but I would like to hear from the community that if it would be OK. 
>> 
>> The reason I ask this was that when we started to discuss the 
>> signing method for XRD back in November last year, we were 
>> hearing from the community that XML DSig is too complex and 
>> hard to use by some developers. That's why we came up with 
>> "Simple Sign" which basically signes the blob without any 
>> cannonicalization. 
>> 
>> e.g., 
>> 
>> <SXRD sig="signature" sigalg=" http://www.w3.org/2000/09/xmldsig#rsa-sha1
>> " certuri="pem file location" data="BASE64 of the payload" /> 
>> 
>> 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. 
> 
>> When we started writing spec on such thing, we found that we are
>> re-writing a lot of things that are already in XML DSig. 
>> As the result, XML DSig with new canonicalization
>> method=no-canonicalization was discussed and in the end, 
>> it seems the discussion precipitated to "After all, constrained XML DSig
>> would be good enough." 
>> Theoretically, it looks good. 
>> 
>> The remaining question is then the reality check, such as: 
>> 
> 
>     • Is it widely implementable, in each scripting language and hosting
> environment including Google AppEngine, Force.com, etc.? 
>     • Would the community feel that this is simple enough? > 
> 
> I would appreciate your insight/opinion/input into this matter. 
>> 
>> Best, 
>> 
>> -- 
>> Nat Sakimura (=nat) 
>> http://www.sakimura.org/en/ 
>> 
>> _______________________________________________ general mailing list
>> general at openid.net http://openid.net/mailman/listinfo/general
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
> 
> 


-----

Santosh Rajan
http://santrajan.blogspot.com http://santrajan.blogspot.com 
-- 
View this message in context: http://www.nabble.com/Fwd%3A--OpenID--Signing-method-for-XRD-tp23967750p23968271.html
Sent from the OpenID - Specs mailing list archive at Nabble.com.