Non X.509 public key

[Nat Sakimura <n-sakimura@nri.co.jp>]

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