- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Tue, 25 Jan 2005 17:59:28 +0000
- To: Seung-wook Jung <seung-wook.jung@uni-siegen.de>
- Cc: www-xkms@w3.org
Hi, Seung-wook Jung wrote: > Dears, > > 1. Key Usage > The KeyUsage defined in XKMS can be Encryption, Signature, and > Exchange. I wonder what criterion is applied to divide the > key usages. These three are afaik the only *cryptographically relevant* key usages in widespread use. > How do you know the signature key will be use for authentication > service, specially challenge-response protocol, and non-repudiation, > both? We explicitly decided not to ever mention, nor conisder the N-R thing. (Also note that x.509 is moving slowly that way too, that bit will be called "contentCommitment" in future ITU-T docs, whatever that means.) Basically, we don't discuss N-R in XKMS. Its not a cryptographic operation. See the many, many pkix mails on this topic for why. If you still want to talk about N-R, I'd suggest looking to the ABA or maybe the ETSI group who believe in such things. > How do you sure that any XKMS users will not sign over a > hash value of a document, which says you give me 10000$, > rather than a random challenge by challenge-response protocol? That's not relevant for XKMS. Applications which care, must care themselves. An xkms responder implementation/configuration which cares, can do so without affecting the protocol, e.g. via UseKeyWith or any other preferred mechanism (e.g. different responder URLs or some ad-hoc implementation wizardry). In any case, there's no way the xkms protocol can check or enforce what the document signature covers - you just have to depend on the application for that. > Even though UseKeyWith helps somehow, in my opinion KeyUsage > and UseKeyWith seem to be analogy of Key Usage and Extended > Key Usage of RFC 3280 and seem to be independent. Should > KeyUsage follow X.509 or RFC 3280 (PKIX) in order to have > readers, users, XKMS servers, and trust infrastructures > behind XKMS understand clearly? No. XKMS is not X.509. We have our own clearly defined protocol elements which are documented in the spec and the earlier requirements document and on the mailing list. > 2. Attribute Certificate > Is XKMS only for the key certificate? Yes and no, I'm afraid;-) Yes, XKMS does not cover X.509 ACs, we handle key bindings not other bindings. If someone wanted to suggest that XKMS be extended for other purposes (e.g. attribute attestation or perhaps more likely kerberos ticket unwrapping), then they will be able to suggest that very soon (see separate mail). No, XKMS is not *only* for X.509 public key certificates, we can work fine with spki, pgp or with bare key pairs as well as with X.509 based PKI. > For distributing asserted attributes such as attribute > certificate, cannot XKMS be used alone? No, sorry. Regards, Stephen.
Received on Tuesday, 25 January 2005 17:59:26 UTC