W3C home > Mailing lists > Public > www-xkms@w3.org > January 2005

Re: Question on Key usages and Attribute Certificate

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Tue, 25 Jan 2005 17:59:28 +0000
Message-ID: <41F68900.8040206@cs.tcd.ie>
To: Seung-wook Jung <seung-wook.jung@uni-siegen.de>
Cc: www-xkms@w3.org


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

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.

Received on Tuesday, 25 January 2005 17:59:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:43 UTC