Fwd: [OpenID] Signing method for XRD

[David Recordon]

Some parts of this message have been removed. Learn more about Nabble's security policy.

The specs list feels like a better home for this thread. :)

--David

----- "Nat Sakimura" <sakimura@...> 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/@... 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@... http://openid.net/mailman/listinfo/general

_______________________________________________
specs mailing list
specs@...
http://openid.net/mailman/listinfo/specs

[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" <[e-mail]> 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 [e-mail] http://openid.net/mailman/listinfo/general
_______________________________________________
specs mailing list
[e-mail]
http://openid.net/mailman/listinfo/specs