Re: Question on Key usages and Attribute Certificate

Dears, 

<stephen farrell wrote:>
> These three are afaik the only *cryptographically relevant*
> key usages in widespread use.

> 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.
</stephen farrell wrote:>

IMHO, the standards must be extensible or generalized, it does not 
limited only for widespread usage at this moment. 
Also, the extensibility is a virtual of eXtensible Markup Language. 
The key usage can be divided cryptographic service, mechanism, 
and whatsoever according to the policy of organization. 
In that sense, KeyUsageType in XKMS schema is too limited to be extensible or 
too coarse-grained. 
 
<seung-wook jung wrote> 
>> 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?
</seung-wook jung wrote> 

<stephen farrell answered:>
> 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.
</stephen farrell answered:>

Of course, XKMS protocols itself cannot check or enforce what you can sign. 
IMHO, XKMS should not be limited to only authentication with digital signature mechanism. 
At the same time, XKMS should not consider all possible applications such as XAdES.
Therefore, what I wanted to say was how the security whole can be made due to the coarse-grained 
or un-extensible key usages. Also, coarse-grained and limited key usages makes ambiguous. 

IMHO, the keyusage includes N-R or extensible in order to more clarify usage of key 
and make the key usage independent on applications according to policy of trust third party. 

Best Regards, 
S. Jung

==========================================================
Seung-Wook Jung

University of Siegen
- Institute for Data Communications Systems -

Hoelderlinstrasse 3
D-57068 Siegen / Germany
Phone:     +49-271-740-2332
Fax:       +49-271-740-2536
e-mail:    seung-wook.jung@uni-siegen.de
URL:       http://www.dcs.uni-siegen.de

============================================================

Received on Thursday, 27 January 2005 08:04:52 UTC