Registration requests Authentication

Hello group,

[Note: this mail was first posted to the XKMS Developer mailing-list, but 
did not get any response, maybe because it's more CAs' and clients' 
policies-oriented than development-oriented. We would greatly appreciate 
any insight on these questions!]

My name is Clement Seveillac, and I am working with Philippe Mezger on XKMS 
integration in the card division of SchlumbergerSema. As you probably know, 
SchlumbergerSema, as a smart card vendor, is offering the service of 
producing PKI personalized card (i.e : cards loaded with credentials and 
keys/certificates ). To do so, we always try to implement the most 
appropriate interface with CAs to submit public keys & receive certificates.

The specific concern we have is to find a way to exchange with a high level 
of security keys & certificates as bulk requests, as we usually produce 
from thousands to millions of cards per batch. Since such strong 
authentication features require implementation of crypto calculation on 
dedicated hardware (e.g. HSM, smart card), we need some clarification on 
the registration request authentication features that XKMS offers, and how 
they will be implemented in the real world.

So our question is: what would be the most realistic authentication 
scenario, according to your existing infrastructure and policies?

Considering the latest XKMS v2.0 draft, I see this list of possible 
authentication schemes:

I. Scenarios with an HMAC Signature (that needs an exchange of a shared 
secret) in the KeyBindingAuthentication element

   1/ The CA sends to the client (or the client sends to the CA) a 
clear-text shared secret (maybe in a PGP or S/MIME encrypted e-mail, it has 
no importance)

   2/ The CA sends to the client (or the client sends to the CA) a shared 
secret encrypted with a Key Exchange Key (previously established TripleDES 
key or other type of symmetric key)

   3/ The CA sends to the client (or the client sends to the CA) a shared 
secret encrypted with a one of its partner's public Key

   4/ The CA sends to the client (or the client sends to the CA) a 
clear-text shared secret in several parts using different channels (for 
example using three key components and a key check value, the final key 
being an XOR -- or other algorithm produce -- of the three key components)


II. Scenarios with a RSA (or DSS) Signature in the KeyBindingAuthentication 
element

   1/ The client already has a CA-trusted key pair, and uses it to sign its 
XKMS requests

   2/ The client "securely" sends a RSA public key to the CA (no further 
details are needed here)

   3/ The CA "securely" sends a RSA key pair to the client (no further 
details are needed here)


III. Other scenarios

   1/ XML signature outside the KeyBindingAuthentication (may be useful, 
for example, if we must register 1000 key bindings but we want to make a 
single authentication signature), for example an enveloped Signature of the 
top-level element (RegisterRequest)

     1.a/ with a HMAC Signature (see. I.)
     1.b/ with an asymmetric algorithm Signature (see II.)

   2/ Detached XML signature, but I am neither familiar with SOAP nor with 
WS-Security, could you explain me how it would differ, and maybe be better, 
than an enveloped signature?

   3/ Authentication outside XML and SOAP (for example TLS/SSL, or private 
network...)

Thanks in advance,

Clement Seveillac
Personalization & Test Development Team
SchlumbergerSema