- From: Ed Simon <ed.simon@entrust.com>
- Date: Fri, 17 Mar 2000 10:15:08 -0500
- To: "'w3c-ietf-xmldsig@w3.org'" <w3c-ietf-xmldsig@w3.org>
I think Kent is arguing that from an implementor's point of view, requiring minimal canonicalization is a real pain not because minimal canonicalization is hard to implement, but because by making support for minimal canonicalization REQUIRED, it means that an implementor cannot use XML parsing to parse SignedInfo when verifying a Signature. If my app receives a Signature with a SignedInfo element that was canonicalized using minimal-c14n, I cannot use an XML parser to isolate the SignedInfo element and then go on. After my app has figured out that minimal-c14n was used, I have to use some sort of character-by-character algorithm to ensure I've got the right bytes in the right order. Having always used XML-c14n in my code because I've always thought minimal-c14n was generally a bad idea, I never realized just how bad an idea it was to require supporting minimal-c14n as a SignedInfo canonicalization algorithm. Kent, who is implementing a full XML Signature Toolkit, has run into this problem directly. (Kent if any of the above assertions are invalid, let me know.) In summary, by making support for minimal-c14n canonicalization of the SignedInfo element, the spec really makes things painful for XML Signature toolkit implementors. If there is someone out there who has actually implemented code that can support minimal-c14n canonicalization of the SignedInfo element, I'd like to hear about it. I'm not saying it is impossible, just a pain. If it has been implemented in a robust, non-painful, way, we need to know about it. The upshot of this may in fact be that support for Canonical XML really should be REQUIRED and from an implemenation point of view, should be mandatory for SignedInfo (eg. we don't even need a Canonicalization child element, because XML-c14n is mandatory. Kent, do you agree with this paragraph. Everyone, I know this is a radically different paradigm than what we've believed for months but in my current "Eureka!" state, I'm not sure there isn't a better solution. Perhaps after I send this note, I'll be in a "Doh!, why didn't I see that" state but right now I'm not. If someone can show me some elegant pseudo-code showing me how one would extract, without XML parsing, the SignedInfo element from an XML Signature, I would be grateful. eg. Extract the XML Signature <SignedInfo> element from the following Signature without using XML parsing. -- Start of example -- <Signature xmlns="http://www.w3.org/2000/02/xmldsig#"> <!-- <SignedInfo Id="MyFirstSignature"> <CanonicalizationMethod Algorithm="http://www.w3.org/2000/02/xmldsig#minimal"> </CanonicalizationMethod> <SignatureMethod Algorithm="http://www.w3.org/2000/02/xmldsig#dsa"> </SignatureMethod> <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/02/xmldsig#c14n"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/02/xmldsig#sha1"> </DigestMethod> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> </SignedInfo> --> <?x <SignedInfo Id="MyFirstSignature"> <CanonicalizationMethod Algorithm="http://www.w3.org/2000/02/xmldsig#minimal"> </CanonicalizationMethod> <SignatureMethod Algorithm="http://www.w3.org/2000/02/xmldsig#dsa"> </SignatureMethod> <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/02/xmldsig#c14n"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/02/xmldsig#sha1"> </DigestMethod> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> </SignedInfo> ?> <SignedInfo Id="MyFirstSignature"> <CanonicalizationMethod Algorithm="http://www.w3.org/2000/02/xmldsig#minimal"> </CanonicalizationMethod> <SignatureMethod Algorithm="http://www.w3.org/2000/02/xmldsig#dsa"> </SignatureMethod> <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/02/xmldsig#c14n"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/02/xmldsig#sha1"> </DigestMethod> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> </SignedInfo> <Stuff xmlns="http://www.edsimon.com/Stuff"> <SignedInfo Id="MyFirstSignature"> <CanonicalizationMethod Algorithm="http://www.w3.org/2000/02/xmldsig#minimal"> </CanonicalizationMethod> <SignatureMethod Algorithm="http://www.w3.org/2000/02/xmldsig#dsa"> </SignatureMethod> <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/02/xmldsig#c14n"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/02/xmldsig#sha1"> </DigestMethod> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> </SignedInfo> </Stuff> <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> <KeyInfo> <KeyValue>MIIBtzCCASw...</KeyValue> </KeyInfo> </Signature> -- end of example -- OK, I admit the above is probably a worst case scenario, but Toolkits, particularly security Toolkits, have to be able handle worst case scenarios. Regards, Ed -----Original Message----- From: TAMURA Kent [mailto:kent@trl.ibm.co.jp] Sent: Friday, March 17, 2000 3:51 AM To: 'w3c-ietf-xmldsig@w3.org' Subject: Re: Comments on last call draft > <insert> ... > </insert> > > which from my point of view basically says if the XML-encoded data is > going to go through some form of XML parsing during its processing, > then one really needs to do XML-aware canonicalization (eg. XML-c14n) > before signing it. > > It seems to me what Kent is saying is in accordance with the above fragment > from the spec. Kent, John, would you agree or disagree? This insertion is acceptable for me though I hope XML Signature could be processed on only XML Information Set. Anyway, remove the minimal c14n, or change requirement of the minimal c14n: REQUIRED -> RECOMMENDED, please. -- TAMURA Kent @ Tokyo Research Laboratory, IBM
Received on Friday, 17 March 2000 10:15:42 UTC