RE: XML Sig 2.0: What protection is gained by the <dsig2:IDAttributes> element?

> OK, I am fine with that, I was not seeing any new security risks here,
> I rather did not see what it was good for in terms of security.

Well, "not failing" is good for security. ;-) One might see people dropping the whole idea of signing if they can't get it to verify, as things like OAuth demonstrate.

> If it is a usability service only, I would suggest to clearly state this usability
> purpose in the standard, as for the other additions
> (<dsig2:DigestDataLength>, <dsig2:PositionAssertion>) I clearly see several
> security reasons for using them.

I'm ok with that. The point of the Verifications element really is to aid in verification, I think, not purely to mitigate attacks.

> If, for whatever reason it stays optional, I would like to see the standard to
> provide a secure solution by adding something like the following and
> highlight it like a note:
> "In order to force a check of the position of a signed element during the
> verification process, the signer MUST use a <dsig2:Selection> element which
> MUST contain a <dsig2:IncludedXPathXPATH> for referencing."

I think that amounts to the same solution, since if you didn't want to process the XPath in one place, you're not going to be willing to do so in the other.

But I'll let the WG decide how they want to handle it. I'm not in a position to advocate because there is no XPath implementation my code can use, so I don't expect to be able to conform regardless.
 
-- Scott

Received on Thursday, 13 January 2011 23:29:14 UTC