Quel est le XML approprié canonicalisation exclusif?

Question

J'utilise xmlseclibs pour essayer de signer un document SOAP, mais il semblent pas canoniser les choses de la même manière selon que je signe ou valider.

Je vais vous donner un exemple. C'est le XML que je suis en train de signer:

<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>

Je suis un code de travail en PHP pour le signer en utilisant une combinaison de la clé publique et les certificats de clé privée, et il semblait fonctionner. Il a ajouté l'élément <ds:Signature> avec tous les trucs bon, et il avait l'air super. Mais je l'ai testé en essayant de valider immédiatement après l'avoir signé, encore une fois avec xmlseclibs (et le certificat de clé publique), mais la validation a échoué. Ainsi, la bibliothèque même code exact fait à la fois la signature et de validation, mais les deux processus ne sont pas d'accord pour une raison quelconque.

J'ai ajouté un code de débogage xmlseclibs pour savoir ce qu'il fait, et je me suis aperçu que la raison pour laquelle la clé de signature, il arrive avec et la clé de validation, il arrive avec sont différentes sont parce qu'il canonise les choses différemment dans les deux situations . Quand je dis à signer l'élément <samlp:Response>, c'est la forme canonique, il signe (j'ai ajouté des nouvelles lignes ici pour la lisibilité):

<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>

Cependant, quand il va valider la signature, c'est la forme canonique, il calcule pour valider contre (encore une fois, j'ai ajouté des sauts de ligne ici):

<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>

Comme vous pouvez le voir, cette version omet l'attribut xmlns:saml de l'élément <samlp:Response>, alors que le premier ne fonctionne pas. (Notez que ceci est différent de l'attribut xmlns:samlp, qui est inclus dans les deux.) Cela semble assez clairement comme un bogue dans xmlseclibs, mais néanmoins il est celui que je serais heureux de me corriger si je savais quelle forme canonique était correct un. Au cas où cet attribut est omis par canonicalisation exclusif? Ou devrait-il être inclus? Laquelle est la forme canonique correcte exclusive?

Answer 1

Vous créez le document DOM de manière incorrecte et d'essayer d'utiliser l'arbre en mémoire non valide. Soit sérialisation et utiliser le résultat sérialisé ou de créer correctement les déclarations d'espace de noms dans l'arbre avant d'essayer de signer. Voir le rapport de bug pour plus d'informations: http://code.google. com / p / xmlseclibs / questions / détail? id = 6

Answer 2

Ni sont la forme canonique correcte!

Le XML de signature a une déclaration d'espace de noms qui vient après les attributs non-espace, ce qui enfreint la règle Ordre Document:

  

des espaces de noms ont une position de commande moins de documents que les noeuds d'attributs.

Le fichier XML de vérification est le nœud manquant complètement d'espace de noms saml. Canonicalisation ne supprime pas des espaces de noms simplement parce qu'il n'y a pas de contenu des enfants qui les références. Il ne supprime que des espaces de noms redondants (ie. Namespaces qui étaient déjà en vigueur sur le parent).

Je ne connais pas assez xmlseclibs dire pourquoi cela se passe, mais il est certainement tort dans les deux. FWIW la fonction C14N sur mon DOM dit ici:

<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: Je viens de regarder xmlseclibs.php dans le SVN, et il n'y a pas une solution facile pour ce que son approche actuelle est fondamentalement erronée. Il essaie de créer un « canonicalised » DOM et sérialise puis avec le vieux saveXML() plaine. Comme il y a des règles de sérialisation de C14N sur ordre des attributs et le caractère échappe à cette saveXML ne promet pas à suivre, il n'y a aucun moyen cela peut éventuellement fonctionner.