RE: Transform Note Design Decisions

Pratik Datta wrote on 2009-03-25:
> That is exactly, how I view the current transform model - it tells you the
> procedural steps for signing and verification, but doesn't say how to
> understand what was really signed. This is a fundamental problem in the
spec
> and it needs to be addressed, and this why we need to move away from a
> procedural model and go to declarative model

I agree, but I also believe that inserting XSLT in the middle means that you
end up in the same place. You could say "then just don't use it for your use
case", but that same argument can be made today. If you constrain the
transforms you allow, you can achieve something better with either the
current or your proposed model.

> I know there are lot of toolkits already implementing the dsig 1.0
standard
> and it is hard to justify a change, but I also know that many applications
> built on top of dsig 1.0 do not even bother to check what is signed. Many
> developers who use dsig Apis, are often new to security - they get so
caught
> up understanding all the concepts - SignedInfo, KeyInfo, Transforms,
> Namespaces, C14N issues ... they forget to do the basic thing of checking
> what is signed.

That's a very excellent point.
 
> So far there have not been any publicized attacks on dsig, but this could
> happen - that might drive people to move away complex signature
technologies
> and go towards basic SSL. We need to proactively think of ways to simplify
> our model, to hope to prevent such a scenario.

That actually is the scenario today (at least in web services, however you
define them). So we're already there.
 
But I think it will take some additional subtraction from even your
simplified proposal to reach the right level of complexity. But the question
is whether that should be limited by the spec itself (which then makes all
implementations easier) or only in profiles (which leaves some of us with
too few implementations to leverage).

-- Scott

Received on Wednesday, 25 March 2009 18:05:07 UTC