[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Non X.509 public key
-----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-----
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]