Re: [xri] Non X.509 public key

[Joseph Anthony Pasquale Holsten <joseph.holsten@cordance.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

+1 PGP

The openid key stuff seems like a full PKI. Is there a reason X.509  
and PGP certs & PKI aren't enough?

http://josephholsten.com

On Jan 21, 2009, at 6:52 AM, Nat Sakimura wrote:

> Up to now, we have been talking entirely in terms of X.509 certs.
>
> Conceptually, the signing can be done by something like GPG or  
> simple RSA key as well.
>
> I am writing this mail to kick off some discussion on it. (In a  
> sense, this mail is like thinking
> loud in the public ML.)
>
> For example,
>
> <XRD sig="URI of the signature file" sigalg="http://www.w3.org/ 
> 2000/09/xmldsig#rsa-sha1">
>  <SubjectID>Unique_identifier</SubjectID>
>  <SignerID pkeyurl="url of the public key">Unique_identifier</ 
> SignerID>
>  <SubjectPublicKey type="SSH2-RSA" rurl="http://example.com/nat/ 
> revokelist">
> ---- BEGIN SSH2 PUBLIC KEY ----
> Comment: "rsa-key-20080129"
> AAAAB3NzaC1yc2EAAAABJQAAAIBpnxOsy94Rd/oROMYgTBdE3YkFyCBZIgK6+jBy
> 9YmKAkla5qAMmDkpSJiDEVHg5Yqf7q0SPuu3pGgX+6Jag2v5xGv42k1i/JZ6vI9r
> m25R6f7s6GgwwpZ90YVcR6X1pkekPfWuBSibaekkXJrbFcdjNr2e4CgDiE6VRRnD
> F97qCw==
> ---- END SSH2 PUBLIC KEY ----
>  </SubjectPublicKey>
>  <Service>
>    <ProviderID>https://example.com/server#14235435672</ProviderID>
>    <Type>http://specs.openid.net/auth/2.0/signon</Type>
>    <Type>http://specs.openid.net/tx/1.0</Type>
>    <URI>https://example.com/server</URI>
>  </Service>
>  <Service>
>    <ProviderID>https://sts.equifax.com/#20081203000000</ProviderID>
>    <Type>http://schemas.informationcard.net/@ics/age-18-or-over/ 
> 2008-11</Type>
>    <URI>https://sts.equifax.com/</URI>
>  </Service>
> </XRD>
>
> etc. Note, I have intentionally changed <CanonicalID> in the wiki  
> example to <SubjectID>
>
> Signature Validation is simple in the sense that it computes the  
> RSA-SHA signature
> on the entire file and compares it with the signature provided.
> If SubjectID==SignerID, then the Subject is claiming that this is  
> his authoritative copy
> of XRD. If SubjectID!=SignerID, then the Signer is claiming that he  
> believes that
> it is a good copy. If this third party Signer (perhaps a domain  
> owner) is more
> trusted than the Subject, then this will be more valuable -- A  
> third party attested
> information in many cases are more trusted than a first party one.
>
> Now, let us think of a truly user centric OpenID system.
> User generates his own ID. He generates his own key pair, and signs  
> XRD.
> I.e., SubjectID==SignerID.
> In this case, CanonicalID (unique id) should be SubjectID 
> +SubjectPublicKey.
> (Let's forget about key rotation for the moment.) This is going to  
> be unique.
> The authentication service may use challenge that is signed by the
> private key to authenticate the Subject, and produce an assertion  
> that is
> signed by the AuthN service's key.
>
> Now, introduce key rotation, e.g., key expiration. SubjectID stays  
> the same.
>
> Then, the CanonicalID will be different. So, we need some way of  
> migrating it.
>
> One way of doing it, I suppose, is to sign the new SubjectID 
> +SubjectPublicKey pair
> with the old PrivateKey, and keep the outdated SubjectPublicKey in  
> XRD as well.
> Then, when an RP received the XRD, it can update its database so that
> new pair will be used in future to identify the user.
>
> Obvious problem here is the case of key compromise. When the old  
> key got
> compromised, then somebody else may be able to claim his identity.
> Thus, we need some point that the key revocation information can be
> obtained from. (OK, it's starting to look like designing PKI again...)
> This URI, rurl, should be in the original XRD as well, and MUST be  
> stored
> with the SubjectID/SignerID at the RP so that RP checks it when
> doing the key migration.
>
> What if he loses is own private key. It is easy to say that it is  
> his problem,
> but people do these stupid things from time to time.
> So, he might want to elect a trusted identity re-proofing service,
> that RP can migrate to a new key should the user loses key by
> obtaining an assertion from the service. Obviously, this service  
> URI also
> must be stored with the user identity at RP.
>
> Next, think about the case SubjectID!=SignerID.
> Obviously, to verify the signature, it has to go to Signer's
> public key, which is probably stored somewhere else.
> The rest is the same.
>
> It could also be that there is no SubjectPublicKey,
> i.e., there is no key-pair for the Subject.
> Then, the Signer must create a CanonicalID which he guarantees that
> it is going to be unique. Then, what an RP must store to
> identify the user is going to be SubjectID+SignerID+SignerPublicKey.
>
> Also, for this kind of third party Signer,
> the Signer's XRD must be in the form of SubjectID==SignerID.
> (It could form a multiple chain, but that will really look like a  
> PKI.)
>
> OK. I stop my rant here.
>
> Any discussion?
>
> =nat
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkl4xiYACgkQrPgSa0qMrmFO4QCeOfnNekELXntzvzFAkZDejgiW
O3oAmwYunMqtsuHzaBRm8C4B0U7E0NOy
=+qDF
-----END PGP SIGNATURE-----