RE: Keybinding etc

This sounds reasonable to me.  A couple comments:

1. On the NotBoundAuthentication, I assume the idea is that the value
element contains an authentication token that's opaque so far as XKMS is
concerned.  If its bound to the XKMS message, it done by integrity
mechanisms provided by the protocol used to transport the XKMS message.
So, it might be bound to the message, just not by an XKMS defined
mechanism.  I suggest some wording to this effect and a ref to the
protocol bindings spec.

2. re: the PKCS#1 v2 issue.  I would like to see this specified as a
separate algorithm as you suggest.

3. Excellent choice on your ordering of private key parameters.

Blair

> -----Original Message-----
> From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] 
> Sent: Wednesday, July 17, 2002 8:50 AM
> To: www-xkms@w3.org
> Subject: Keybinding etc
> 
> 
> 
> All, 
> 
> 	I am working on the schema for the keybindings, some points
> 
> 1 I really think that a keybinding has to have a keyinfo so I 
> am putting that in the toplevel abstract type 2 <any> is 
> probably a liability someone extending keybinding might want 
> to avoid or tweak so I put it on the derrived types 3 I added 
> in a PrototypeKeyBinding for registration 4 I changed the 
> name of ResultKeyBinding to simply KeyBinding since that 
> structure is actually used in some XKRSS requests 5 I changed 
> the name of RequestKeyBinding to QueryKeyBinding since it is 
> not used in XKRSS requests at all
> 
> 
> On the Passphrase etc confusion I propose the following:
> 
> RevocationCodeIdentifier
> 	= H ( H ( passphrase ) )
> 	The value used in registration
> 
> RevocationCode
> 	= H (passphrase)
> 	The value used in the revoke request
> 
> Of course if we change the scheme because of possible patent 
> trolls we will have to revisit this.
> 
> 
> Then with PassPhraseAuthentication I propose:
> 
> Authentication structure is changed to the following:
> 
> <Authentication>
> 	<KeyBindingAuthentication> *
> 	<ProofOfPossessionAuthentication>
> 	<NotBoundAuthentication> *
> 
> <NotBoundAuthentication>
> 	<Protocol> URI
> 	<Value> Base64 string
> 
> The not bound element is used to indicate that the 
> authentication is not bound to the XKMS message in any way
> 
> 
> The other issue that comes up is whether we should do PKCS#1 
> v2 or v2.1 for the RSA Key parameters. V2 adds in the 
> parameters for multiprime which is patented by tandem, would 
> it be more appropriate to regard this as a separate algorithm 
> (my preference) needing its own private key parameter blob?
> 
> I have re-ordered and renamed the private key parameters to 
> match those used by .NET to store private keys, I don't see 
> that there is any advantage to introducing a different set of 
> parameter tags at this point. I can't find a java XML crypto 
> schema at the moment.
> 
> 		Phill
> 
>

Received on Wednesday, 17 July 2002 20:13:43 UTC