Quelle est la bonne canonicalisation XML exclusive?

Question

J'utilise xmlseclibs pour essayer de signer un document SOAP, mais cela ne semble pas canaliser les choses de la même manière selon que je signe ou que je valide.

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 a semblé fonctionner. Il a ajouté l'élément <ds:Signature> avec tout ce qu'il fallait, et ça avait l'air génial. Mais ensuite je l'ai testé en essayant immédiatement de le valider après l'avoir signé, toujours avec xmlseclibs (et le certificat de clé publique), mais la validation a échoué. Donc, la même bibliothèque de codes fait à la fois la signature et la validation, mais les deux processus ne sont pas d'accord pour une raison quelconque. J'ai ajouté du code de débogage à xmlseclibs pour savoir ce qu'il fait, et j'ai réalisé que la raison pour laquelle la clé de signature et la clé de validation sont différents sont parce que ça 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 clair comme un bogue dans xmlseclibs, mais néanmoins c'est un que je serais heureux de réparer moi-même si je savais juste quelle forme canonique était correcte un. Cet attribut devrait-il être omis par une canonisation exclusive? Ou devrait-il être inclus? Lequel est la forme canonique exclusive correcte?

Answer 1

Vous créez incorrectement le document DOM et essayez d'utiliser l'arborescence en mémoire non valide. Soit sérialiser et utiliser le résultat sérialisé ou créer correctement les déclarations d'espace de noms dans l'arborescence avant d'essayer de signer. Pour plus d'informations, voir le rapport de bogue: http://code.google.com/p/xmlseclibs/issues/detail?id=6

Answer 2

Ni la forme canonique correcte!

Le XML de signature a une déclaration d'espace de noms qui vient après les attributs non-espace de noms, 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 code XML de vérification manque complètement le noeud d'espace de noms saml. La canonisation ne supprime pas les nœuds d'espace de noms simplement parce qu'il n'y a pas de contenu enfant qui les référence. Il supprime uniquement les nœuds d'espace de noms redondants (c'est-à-dire les espaces de noms qui étaient déjà en vigueur sur le parent). Je ne connais pas assez xmlseclibs pour dire pourquoi cela se produit, mais c'est complètement faux sur les deux plans. 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 essaye de créer un DOM "canonicalisé" puis le sérialise avec du vieux saveXML(). Comme il existe des règles de sérialisation C14N concernant l'ordre des attributs et les fuites de caractères que saveXML ne promet pas de suivre, il est impossible que cela fonctionne.