Welches ist die richtige XML exklusive Kanonisierung?

Question

Ich bin mit xmlseclibs zu versuchen und ein SOAP-Dokument unterschreiben, aber es tut nicht scheint die Dinge auf die gleiche Weise canonicalize je nachdem, ob ich unterzeichnen oder zu validieren.

Ich gebe Ihnen ein Beispiel. Dies ist der XML ich zu unterzeichnen versuchen:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header/>
<soapenv:Body>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" MinorVersion="1" IssueInstant="2010-02-04T15:27:43Z" ResponseID="pfxe85313e6-e688-299a-df06-30f55e24f65a">
<samlp:Status>
<samlp:StatusCode Value="samlp:Requester"/>
</samlp:Status>
</samlp:Response>
</soapenv:Body>
</soapenv:Envelope>

Ich habe einige Code in PHP arbeiten, es zu unterzeichnen eine Kombination von öffentlichen und privaten Schlüsseln Zertifikate verwenden, und es schien zu funktionieren. Er fügte hinzu, das <ds:Signature> Element mit all den richtigen Sachen, und es sah toll aus. Aber dann habe ich getestet es von sofort versuchen, es zu überprüfen, nachdem es der Unterzeichnung wieder mit xmlseclibs (und dem öffentlichen Schlüsselzertifikat), aber die Validierung fehlgeschlagen ist. Also genau die gleiche Code-Bibliothek ist sowohl die Unterzeichnung tun und Validierung, aber die beiden Prozesse aus irgendeinem Grunde nicht einverstanden ist.

Ich habe einige Debug-Code zu xmlseclibs, um herauszufinden, was es tut, und ich erkannte, dass der Grund der Signaturschlüssel mit aufkommt und die Bestätigungstaste es kommt mit verschieden sind, weil sie die Dinge anders in den beiden Situationen Kanonisiert . Als ich ihm sagen, das <samlp:Response> Element zu unterschreiben, das ist die kanonische Form es unterzeichnet (Ich habe hier hinzugefügt newlines zur besseren Lesbarkeit):

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" IssueInstant="2010-02-04T15:27:43Z" MajorVersion="1" MinorVersion="1" ResponseID="pfxe85313e6-e688-299a-df06-30f55e24f65a" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<samlp:Status>
<samlp:StatusCode Value="samlp:Requester">
</samlp:StatusCode>
</samlp:Status>
</samlp:Response>

Allerdings, wenn es um die Signatur zu validieren geht, dann ist dies die kanonische Form sie gegen validieren berechnet (wieder, ich habe hinzugefügt newlines hier):

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" IssueInstant="2010-02-04T15:27:43Z" MajorVersion="1" MinorVersion="1" ResponseID="pfxe85313e6-e688-299a-df06-30f55e24f65a">
<samlp:Status>
<samlp:StatusCode Value="samlp:Requester">
</samlp:StatusCode>
</samlp:Status>
</samlp:Response>

So wie Sie sehen können, läßt diese Version das xmlns:saml Attribut aus dem <samlp:Response> Elemente, während die ersten nicht. (Beachten Sie, dass dies unterscheidet sich von der xmlns:samlp Attribut, das in beiden enthalten ist.) Das in xmlseclibs ziemlich klar wie ein Bug scheint, aber dennoch ist es ein ich glücklich sein würde, mich zu beheben, wenn ich wusste, dass nur die kanonische Form war die richtige einer. Sollte das Attribut durch exklusive Kanonisierung weggelassen werden? Oder sollte es enthalten sein? Welches ist die richtige exklusive kanonische Form?

Answer 1

Sie erstellen das DOM-Dokument nicht ordnungsgemäß und zu versuchen, den ungültigen In-Memory-Baum zu verwenden. Entweder serialisiert und das serialisierte Ergebnis verwenden oder richtig die Namespace-Deklarationen in dem Baum erstellen, bevor zu unterzeichnen versuchen. Sehen Sie den Fehlerbericht für weitere Informationen: http://code.google. com / p / xmlseclibs / Themen / detail? id = 6

Answer 2

Weder sind die korrekte kanonische-Form!

Die Unterzeichnung XML hat eine Namespace-Deklaration, die der Nicht-Namespace kommt nach Attributen, die die Dokumentbestell Regel bricht:

  

Namespace-Knoten hat eine geringere Dokument Auftragslage als Attributknoten.

Die Überprüfung XML fehlt der saml Namespace-Knoten vollständig. Kanonisierung nicht entfernen Namensraum-Knoten, nur weil es kein Kind Inhalt ist, die sie verweist. Es entfernt nur redundanten Namespace-Knoten (dh. Namespaces, die auf dem übergeordneten bereits in Kraft waren).

Ich weiß nicht genug über xmlseclibs zu sagen, warum dies geschieht, aber es ist definitiv falsch in beiden Punkten. FWIW die C14N Funktion auf meinem DOM hier sagt:

<samlp:Response xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" IssueInstant="2010-02-04T15:27:43Z" MajorVersion="1" MinorVersion="1" ResponseID="pfxe85313e6-e688-299a-df06-30f55e24f65a">
<samlp:Status>
<samlp:StatusCode Value="samlp:Requester"></samlp:StatusCode>
</samlp:Status>
</samlp:Response>

eta: Ich sah sie nur an xmlseclibs.php im SVN, und es gibt keine einfache Lösung für diese als aktuelle Ansatz ist grundsätzlich fehlerhaft. Es wird versucht, einen „canonicalised“ DOM zu erstellen und dann serialisiert es mit einfachen alten saveXML(). Da es C14N Serialisierung Regeln über Attribut Ordnung und Charakter entkommt, dass saveXML nicht zu folgen verspricht, gibt es keine Möglichkeit, dies möglicherweise funktionieren kann.