[OpenID] google non spec on secure discovery with namespace delegation

Peter Williams pwilliams at rapattoni.com
Sat Jul 18 05:30:56 UTC 2009 

Rather than try to analyze new security services and semantics, Ive tried to crystallize the intended assertions and controls from the Google writeup in terms of existing standards. The idea was to use sound reasoning. Seeing as this is a coding vs formal methods culture, I wrote bits of code.



Google/XRI-TC certify XRDs. The semantics seem identical with the XRI Resolution V2 semantics for an identified "provider" - a entity that seems essentially equivalent to the "master" DC for a domain, in ActiveDirectory land.  In that standard, folks had the provider issue a SAML assertion around an XRD, with no supporting ws-trust or SAML authnReq protocols support. In Google's case, they seem to have simply disposed of the SAML markup from XRI Resolution, using xmldsig as a certification scheme. The main point is.. that the certifier is the "provider" of the XRD -  a party different to the agent _distributing_ the XRD.



Below, I too sign a couple of XRDs in an XRDS, certifying each of them separately, acting as 1 provider of both. I happen to attach the enveloped signature to the XRD value being certified, much like one postfixes a sig to an id-cert or a PAC. One XRD even has a public key attribute, making it play the role of a X.509 cert .. and be used in the TLS 1.2 handshake's "client cert" message



Googe/XRI-TC then sign the HTTP response, transport a mime object with XRDS/XRD within. Rather than get confused with http/https "identifer semantics", I opted to sign the ordered sequence of XRDs at the XML level , where there may be 1 or more XRDs in the sequence. I use ws-security markup rather than certification markup, so the "session" semantics of a communication channel are clearly distinct from the certification semantics. The intent is that the agent makes classical representations of "data origin authentication" -  where the originator may be a caching or a syndication agent. The binary security token shown happens to be an old cert path type , but could just as easily be a kerberos ticket or a security context token using modern markup. And, as with all ws-security concepts, each hop in the relay chain (from google-OP to tenant-OP, to recursing XRI server, to XRI proxy, to other XRI proxy, to RPX-tenant-RP, to RP, ....) may rewrite the ws-security security elements, each hop.



Then , I sought to characterize the authoritative relationship between the 2 XRDs in terms of namespace delegation semantics -  noting that XRD#1 has the SEP that locates the/a server responsible for supplying the other . Per XRI-Resolution notion of "trusted resolution", the keying material for verifying the CERTIFICATION of #2 comes from the SEP of #1.  That keying material source is NOT used for ws-security services, though.



Finally, the initial ws-security token has specifically multiple references, one per XRD. This is currently using refs within the signature area, to convey order and "authoritive standing". The idea was to capture the notion that the XRD bearing the SEP (once certification is verified) MUST  be accessible to the party verifying the certification of the leaf XRD. That is.. its not enough that one has some or other keying material to verify the certification signature on XRD#2 but one MUST also have assurance of the currency (and validity AND authorized standing) of certification-verification keys from XRD#1. It's just not good enough to use a cached copy of XRD#1!



Semantically, I may be breaking some rules, in this final part. Perhaps I really ought to take the references out of the Signature, and have them in supporting Manifest - so that the canonical-id verification and canonical-equiv-id verification semantics can be signaled, using a manifest's ability to convey  "application"-specific validation logic.



Just playing around! Since, it occurred to me that the template-URI SEP is really only an ENUM-like NAPTR, its seems ever clearer that the security concept for RPS needs to explicitly consider just WHO is doing the identifier rewriting - so the RP is not duped.

<?xml version="1.0" encoding="UTF-8"?>
<XRDS xmlns="xri://$xrds">
 <XRD xml:id="9b4d6b4b-7355-11de-bcd7-4dfc48c48930" xmlns="xri://$xrd*($v*2.0)">
  <Query>*peter2</Query>
  <Status ceid="off" cid="off" code="100">Success</Status>
  <ServerStatus code="100">Success</ServerStatus>
  <ProviderID>@!E459.819D.771.7990!5B62.6F13.7602.5176</ProviderID>
  <LocalID>!0</LocalID>
  <CanonicalID>@!E459.819D.771.7990!5B62.6F13.7602.5176!0</CanonicalID>
  <Service>
   <ProviderID>@!E459.819D.771.7990!5B62.6F13.7602.5176!0</ProviderID>
   <Type select="true">xri://$res*auth*($v*2.0)</Type>
   <MediaType select="false">application/xrds+xml</MediaType>
   <URI append="none" priority="2">http://localhost:80/server/resolve/ns/@!E459.819D.771.7990!5B62.6F13.7602.5176!0/</URI>
   <URI append="none" priority="1">https://localhost:443/server/resolve/ns/@!E459.819D.771.7990!5B62.6F13.7602.5176!0/</URI>
  </Service>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
   <ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
    <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
    <ds:Reference URI="#9b4d6b4b-7355-11de-bcd7-4dfc48c48930" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
     <ds:Transforms xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
      <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
     </ds:Transforms>
     <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
     <ds:DigestValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">sY00iyOsqyoYeaju3pySwle5BmI=</ds:DigestValue>
    </ds:Reference>
   </ds:SignedInfo>
   <ds:SignatureValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">QAdHndgtuqDu72/TIxUyjrmrgvdoLKGfPGoMxdqHSqYm98nnQjE05Q==</ds:SignatureValue>
   <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
     <ds:X509Certificate xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
MIICXTCCAhugAwIBAgIESmDQCzALBgcqhkjOOAQDBQAwEjEQMA4GA1UEAxMHb3BlbnhyaTAeFw0w
OTA3MTcxOTI0NTlaFw0wOTEwMTUxOTI0NTlaMBIxEDAOBgNVBAMTB29wZW54cmkwggG3MIIBLAYH
KoZIzjgEATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAiUftZPY1Y
+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7V+fGqKYVDwT7g/bT
xR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCPFSMLzLKSuYKi64QL8Fgc9QKBgQD3
4aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wLPQeCZ1FZV4661FlP5nEHEIGAtEkWcSPoTCgWE7fP
CTKMyKbhPBZ6i1R8jSjgo64eK7OmdZFuo38L+iE1YvH7YnoBJDvMpPG+qFGQiaiD3+Fa5Z8Gkotm
XoB7VSVkAUw7/s9JKgOBhAACgYBVC4Q787QxNiHyFXnKm8nMoijbHlEPLLjt802JmZZTRFj8gP3Y
SJj2zolxrQJG1V9IVIzk/XDdtvcwT5Gcpug0nMFBy0iIVJWk3wPhnjoJRsTxDCus5sZqnPEGKb+R
3o1VsBvkckuhOIGM9GVAAmc7Y800V8QL988kpQHU0Q6OZjALBgcqhkjOOAQDBQADLwAwLAIUN2dh
0/yR3bX8Hz5FHNHyElx8E3ICFG1LhHEjeipBGPuK8Y0kKI6gKvWm
</ds:X509Certificate>
    </ds:X509Data>
   </ds:KeyInfo>
  </ds:Signature>
  <Server>OpenXRI</Server>
 </XRD>
 <XRD xml:id="9b784bdc-7355-11de-bcd7-4dfc48c48930" xmlns="xri://$xrd*($v*2.0)">
  <Query>*peter3</Query>
  <Status ceid="off" cid="off" code="100">Success</Status>
  <ServerStatus code="100">Success</ServerStatus>
  <ProviderID>@!E459.819D.771.7990!5B62.6F13.7602.5176!0</ProviderID>
  <LocalID>!0</LocalID>
  <CanonicalID>@!E459.819D.771.7990!5B62.6F13.7602.5176!0!0</CanonicalID>
  <Service>
   <Type select="true">xri://$certificate*($x.509)</Type>
   <Path match="default"/>
   <MediaType match="default"/>
   <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:X509Data>
     <ds:X509Certificate>MIICdjCCAd+gAwIBAgIBADANBgkqhkiG9w0BAQUFADCBgDELMAkGA1UEBhMCVVMx
ETAPBgNVBAgTCE1hcnlsYW5kMREwDwYDVQQHEwhCZXRoZXNkYTENMAsGA1UEChME
RXBvazEUMBIGA1UECxMLRW5naW5lZXJpbmcxJjAkBgNVBAMTHVNBTUwgVGVzdCBD
ZXJ0IC0gRE8gTk9UIFRSVVNUMB4XDTA0MDYxNjIyMjYzNloXDTA0MDcxNjIyMjYz
NlowgYAxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNYXJ5bGFuZDERMA8GA1UEBxMI
QmV0aGVzZGExDTALBgNVBAoTBEVwb2sxFDASBgNVBAsTC0VuZ2luZWVyaW5nMSYw
JAYDVQQDEx1TQU1MIFRlc3QgQ2VydCAtIERPIE5PVCBUUlVTVDCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAtAJhWjqiydiYSNFtpdkLLuOCQhA09FGj1s9SAc63
kFVqHB5BILm6kHHqFQgIqs/qFpfT7qmaVNUNlVF3/MLMZgd+F1IkhFgjozhqV7Nb
GSjHSaxQJVm+U4xhPyBxWDtu/IrVzc6aii4m0JVkXOdv49/uK/+HwZaaPKbjdZiH
D1kCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBlGbHiHeRqi5JHC/X045E9fCGZVmSW
glbnxsEdQ4ZXwN1fg4WwGym/p3tGaE/XGingMcU+x5f2lkfvvBCxSKV+e4ujatUY
QvyQjqIE6ddBODkdAnNdBQrH6N7MZHShpoiy5WluogXwi9WLODPxcPwVrzXZVk6V
KTTee8qdP3Gjtg=</ds:X509Certificate>
    </ds:X509Data>
   </ds:KeyInfo>
  </Service>
  <Service>
   <ProviderID>@!E459.819D.771.7990!5B62.6F13.7602.5176!0!0</ProviderID>
   <Type select="true">xri://$res*auth*($v*2.0)</Type>
   <MediaType select="false">application/xrds+xml</MediaType>
   <URI append="none" priority="2">http://localhost:80/server/resolve/ns/@!E459.819D.771.7990!5B62.6F13.7602.5176!0!0/</URI>
   <URI append="none" priority="1">https://localhost:443/server/resolve/ns/@!E459.819D.771.7990!5B62.6F13.7602.5176!0!0/</URI>
  </Service>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
   <ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
    <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
    <ds:Reference URI="#9b784bdc-7355-11de-bcd7-4dfc48c48930" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
     <ds:Transforms xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
      <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
     </ds:Transforms>
     <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
     <ds:DigestValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">NN4MMcO8/2gNvBjVqpQNIGEjt8Y=</ds:DigestValue>
    </ds:Reference>
   </ds:SignedInfo>
   <ds:SignatureValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">V6lv6l3XqyHlJc7DvNDzBsXUVokzSj7Uv8nnheL05udUgeM48+FnaQ==</ds:SignatureValue>
   <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
     <ds:X509Certificate xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
MIICXTCCAhugAwIBAgIESmDQCzALBgcqhkjOOAQDBQAwEjEQMA4GA1UEAxMHb3BlbnhyaTAeFw0w
OTA3MTcxOTI0NTlaFw0wOTEwMTUxOTI0NTlaMBIxEDAOBgNVBAMTB29wZW54cmkwggG3MIIBLAYH
KoZIzjgEATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAiUftZPY1Y
+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7V+fGqKYVDwT7g/bT
xR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCPFSMLzLKSuYKi64QL8Fgc9QKBgQD3
4aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wLPQeCZ1FZV4661FlP5nEHEIGAtEkWcSPoTCgWE7fP
CTKMyKbhPBZ6i1R8jSjgo64eK7OmdZFuo38L+iE1YvH7YnoBJDvMpPG+qFGQiaiD3+Fa5Z8Gkotm
XoB7VSVkAUw7/s9JKgOBhAACgYBVC4Q787QxNiHyFXnKm8nMoijbHlEPLLjt802JmZZTRFj8gP3Y
SJj2zolxrQJG1V9IVIzk/XDdtvcwT5Gcpug0nMFBy0iIVJWk3wPhnjoJRsTxDCus5sZqnPEGKb+R
3o1VsBvkckuhOIGM9GVAAmc7Y800V8QL988kpQHU0Q6OZjALBgcqhkjOOAQDBQADLwAwLAIUN2dh
0/yR3bX8Hz5FHNHyElx8E3ICFG1LhHEjeipBGPuK8Y0kKI6gKvWm
</ds:X509Certificate>
    </ds:X509Data>
   </ds:KeyInfo>
  </ds:Signature>
  <Server>OpenXRI</Server>
 </XRD>
 <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
  <wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#X509PKIPathv1" wsu:Id="9b9040ad-7355-11de-bcd7-4dfc48c48930" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">MIICejCCAnYwggHfoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgYAxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNYXJ5bGFuZDERMA8GA1UEBxMIQmV0aGVzZGExDTALBgNVBAoTBEVwb2sxFDASBgNVBAsTC0VuZ2luZWVyaW5nMSYwJAYDVQQDEx1TQU1MIFRlc3QgQ2VydCAtIERPIE5PVCBUUlVTVDAeFw0wNDA2MTYyMjI2MzZaFw0wNDA3MTYyMjI2MzZaMIGAMQswCQYDVQQGEwJVUzERMA8GA1UECBMITWFyeWxhbmQxETAPBgNVBAcTCEJldGhlc2RhMQ0wCwYDVQQKEwRFcG9rMRQwEgYDVQQLEwtFbmdpbmVlcmluZzEmMCQGA1UEAxMdU0FNTCBUZXN0IENlcnQgLSBETyBOT1QgVFJVU1QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQCYVo6osnYmEjRbaXZCy7jgkIQNPRRo9bPUgHOt5BVahweQSC5upBx6hUICKrP6haX0+6pmlTVDZVRd/zCzGYHfhdSJIRYI6M4alezWxkox0msUCVZvlOMYT8gcVg7bvyK1c3OmoouJtCVZFznb+Pf7iv/h8GWmjym43WYhw9ZAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAZRmx4h3kaouSRwv19OORPXwhmVZkloJW58bBHUOGV8DdX4OFsBspv6d7RmhP1xop4DHFPseX9pZH77wQsUilfnuLo2rVGEL8kI6iBOnXQTg5HQJzXQUKx+jezGR0oaaIsuVpbqIF8IvVizgz8XD8Fa812VZOlSk03nvKnT9xo7Y=</wsse:BinarySecurityToken>
 </wsse:Security>
 <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  <ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
   <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
   <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
   <ds:Reference URI="#9b4d6b4b-7355-11de-bcd7-4dfc48c48930" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
    <ds:DigestValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">ka/FDaYVTId5fhnKIPeNng6s1X0=</ds:DigestValue>
   </ds:Reference>
   <ds:Reference URI="#9b784bdc-7355-11de-bcd7-4dfc48c48930" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:Transforms xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
     <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
     <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
    </ds:Transforms>
    <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
    <ds:DigestValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">3VhkPVPshWyHYkIPUBTvtwOB3jg=</ds:DigestValue>
   </ds:Reference>
  </ds:SignedInfo>
  <ds:SignatureValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">LK6nvQCFonrABJ4sSwEcUyl6eEh+UZ7fYBp1HZ+qLghu5qIasczLsg==</ds:SignatureValue>
  <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
   <wsse:SecurityTokenReference xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <wsse:Reference URI="#9b9040ad-7355-11de-bcd7-4dfc48c48930"/>
   </wsse:SecurityTokenReference>
  </ds:KeyInfo>
 </ds:Signature>
</XRDS>

More information about the general mailing list