OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Non X.509 public key

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" 
  <SignerID pkeyurl="url of the public key">Unique_identifier</SignerID>
  <SubjectPublicKey type="SSH2-RSA" 
Comment: "rsa-key-20080129"

etc. Note, I have intentionally changed <CanonicalID> in the wiki example to 

Signature Validation is simple in the sense that it computes the RSA-SHA 
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 
it is a good copy. If this third party Signer (perhaps a domain owner) is 
trusted than the Subject, then this will be more valuable -- A third party 
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 
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 

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 
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 
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?



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]