Thanks guys for great feedback!
Now I am feeling better in sticking with XML DSig. In the previous spec, we used XML DSig and turned out that most people did not implement/use it. If the community feels better about XML DSig now than several years ago, that is very reassuring. Thanks! =nat On Wed, 10 Jun 2009 08:44:06 -0700 (PDT), Zhihong <zhih...@gmail.com> wrote: > > SimpleSign had the same key rotation issue. Their solution is to add > another Based-64 encoded KeyInfo. That's problematic for us because > KeyInfo is part of XMLDSig and it's not trivial to process without a > library. So we implemented it without KeyInfo. To get around the key > rotation issue, we don't check expiration on the cert. We only have a > handful of partners using this and we accept the risks. > > Zhihong > > On Jun 10, 10:16 am, Love Hörnquist Åstrand <l...@kth.se> wrote: >> How do you handle multiple signatures to enable key migration (key >> rollover, new and signature algs) ? >> >> Love >> >> 9 jun 2009 kl. 23:43 skrev Nat Sakimura: >> >> > 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 x...@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/ > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
