- From: Hallam-Baker, Phillip <pbaker@verisign.com>
- Date: Wed, 17 Jul 2002 08:50:11 -0700
- To: www-xkms@w3.org
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 11:48:44 UTC