RE: Question about XKMS 2.0

Mike,
 
    Yes, that was certainly my intention, the section in which is headed
'Example'. I have changed this wording to
 
"The policy of this particular registration service is to revoke a private
key whenever key recovery is performed. The service returns the revoked key
binding and the private key parameters"
 
The reason why the service does this is that the circumstances of key
recovery may prevent the service from considering the recovered key to be
acceptably secure in that application. If a key is used for key exchange
(i.e. authentication) and encryption you may well want to revoke the use for
authentication purposes after recovery.
 
        Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


-----Original Message-----
From: Mike Just [mailto:Mike.Just@entrust.com]
Sent: Monday, December 03, 2001 8:33 AM
To: 'Dournaee, Blake'; www-xkms-ws@w3c.org
Subject: RE: Question about XKMS 2.0


Hi Blake,
 
I remember reading this from the 1.1 draft as well.  My interpretation was
that Phil was giving an example of a particular X-KRSS service's policy
(i.e. Joe's X-KRSS Web Service policy) rather than something general that
applied to all key recovery requests.
 
Mike

 

-----Original Message-----
From: Dournaee, Blake [mailto:bdournaee@rsasecurity.com]
Sent: Sunday, December 02, 2001 4:28 PM
To: www-xkms-ws@w3c.org
Subject: Question about XKMS 2.0


Hello All,
 
I have been reading through the XKMS draft and noticed the following
sentence in the Key Recovery sub-section (after the first example) under the
Key Registration Service Protocol Overview:
 
"The registration service policy is to revoke a private key whenever key
recovery is performed."
 
I don't understand this. If I am performing key recovery, what use is it to
to revoke the key? This means I wouldn't be able to perform any signing
operations (although I could decrypt messages sent to me).
 
Does key recovery always imply key revocation for XKMS?
 
Thanks,
 
Blake Dournaee
Toolkit Applications Engineer
RSA Security
 
"The only thing I know is that I know nothing" - Socrates
 
 

-----Original Message-----
From: Mike Just [mailto:Mike.Just@entrust.com]
Sent: Friday, November 30, 2001 12:05 PM
To: 'Jeremy Epstein'; www-xkms-ws@w3c.org
Subject: RE: URL-level trust (was: Re: XKMS)



Hi Jeremy, 

A comment on your last point. 

> So I think it's important that a given XKMS server needs a 
> way of providing 
> different grades of service to its clients.  I don't know whether this 
> should done by the client saying "please validate this 
> certificate as a 
> grade 73B certificate" or whether the XKMS server should 
> recognize a request 
> as coming from the business payments server and hence enforce 
> a different 
> certificate policy.  If the former, the protocol needs some way of 
> expressing a request for a policy ("grade 73B"), but *not* 
> sending a list of 
> trusted root certificates.  If the latter, it's a feature of the XKMS 
> server, and probably doesn't need to be standardized (i.e., 
> the XKMS server 
> could determine the trusted roots to use based on the signature on the 
> request). 
> 

It seems that there is a convergence toward accepting that the "policy" or
"context" or "trust model" can be specified by reference as part of the
request.  Whether this is as part of the URL and/or part of the X-KISS
request is another question; as part of the URL is probably fine though. 

You raise another interesting point regarding validation based on the origin
of the request and suggest that this could be done based on the signature of
the requestor.  I suspect you cite the use of a signed request as an example
since it is certainly not necessary. As a matter of fact, I might prefer to
see an element that allows the requestor to specify some "name" or
"identifier" as part of the request. So long as this field is returned as
part of the authenticated response, the requestor can ensure that the
correct identifier was used. Thus, authentication of the request is not
required. (As a matter of fact, even if the request were signed, you'd still
need to include the name of the signer in the authenticated response.  If
you didn't an attacker could just resubmit an altered request and sign on
their own.)

Such an identifier could arguably just be included in the URL, e.g.
http://xkms.xmltrustcenter.org/us_gov_bridge_ca_confidential?name=Mike_Just
<http://xkms.xmltrustcenter.org/us_gov_bridge_ca_confidential?name=Mike_Just
>  but it seems more reasonable to add a separate element (in case the name
exceeds the length of URL accepted by some servers).  Although I use a
personal name in this example, this name might be the name of an application
(as Jeremy highlights above or the name of a role).

Mike