W3C home > Mailing lists > Public > www-xkms@w3.org > June 2002

RE: 2.0 Draft 9

From: Hallam-Baker, Phillip <pbaker@verisign.com>
Date: Mon, 24 Jun 2002 09:31:54 -0700
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40CC89E1E@vhqpostal.verisign.com>
To: reagle@w3.org, pbaker@verisign.com
Cc: www-xkms@w3.org

Here are my responses to the issues that require some discussion:

>    36 Each XKMS response message contains a MajorResult code that
>    determines whether the response is final or further processing is
>    required. The protocol is specified in the CSP formalism [CSP] as
>    follows:
> 
> I'm unfamiliar with CSP and the reference " [CSP] C. A. R. 
> Hoare" doesn't 
> help me.

Communicating Sequential Processes. I will add in the reference
later. It is a pretty standard calculus for describing async
protocols.

>    40 Conforming XKMS services MAY support the use of encryption to
>    ensure message confidentiality and MUST support the use of
>    authentication to ensure message integrity as follows:
>      * The use of XML Signature to authenticate the message 
> payload MUST
>        be supported.
>      * The use of TLS [TLS] to support authentication and 
> encryption of
>        the entire SOAP transaction SHOULD be supported
> 
>    Service <C2> [Required]
>           The URI of the Web Service port to which the request is
>           addressed
> 
> I presume this URI also is associated with the terms of the 
> "trust" service 
> policy. Should this be stated? Is there a processing 
> requirement that the 
> service check this value corresponds to the policy it's 
> actually operating 
> under? (For example, I send a signed Validate Request with a 
> low liability 
> URI but include a high liability URI in the request to get 
> more bang for my 
> buck.)

Yes there is a requirement, it is stated later in the doc but 
it should be stated upfront with the rest...

>    3.3 Using Locate and Validate
> 
> I'm glad this section is here to explain the difference. If 
> we agree about 
> the Service attribute, perhaps something could be said here 
> on that note.

I think that belongs in section 2 as it is common to XKISS and
XKRSS.

>   4.2.2 Element <KeyInfo>
> 
>    163 The following schema defines the <KeyInfo> element of the
>    KeyInfoType type imported from the XML Signature Specification:
>    <!-- KeyInfo -->
>    <element name="KeyInfo" type="ds:KeyInfoType" />
>    <!-- /KeyInfo -->
> 
> Why is this not ds:KeyInfo? Is its semantic or processing 
> different from 
> that defined by ds?

That is simply to get arround the schema problem with any #other
and the ambiguous references complaint...

>    180 The <KeyUsage> element specifies one or more intended uses of
>    the key. If no <KeyUsage> is specified all uses are permitted.
> 
>    xkms:Encryption
>           The key pair may be used for encryption and decryption
> 
>    xkms:Signature
>           The key pair may be used for signature and verification
> 
>    xkms:Exchange
>           The key pair may be used for key exchange
> 
> Perhaps more needs to be said about this. For instance, what 
> if I have a 
> key that can be used in Encryption and Signature? How would 
> you specify 
> this, two KeyUsage elements? If it can be used for both, but 
> the service 
> only vouches for Signing, what does it mean if I violate the 
> directive?

The <KeyBinding> element allows for up to 3 <KeyUsages>. The
explanation of what to do with multiple keyusagess should
probably be stated there.

The RSA algorithm allows any key to be used for encryption
or signing so someone can always do something that is not
specified, however it should not be expected to work...

The service can only make a definitive statement about a 
key not being trusted for some purpose if it is registered
and then revoked.


>                            8 Security Considerations
> 
>    307 A generally applicable means of preventing a replay 
> attack is to
>    place a token in each message that demonstrates to the 
> recipient that
>    the message is 'fresh', for example:
>      * A message origination time that the recipient verifies 
> by checking
>        that it is sufficiently recent.
>      * A nonce, that is a piece of random data that was 
> previously issued
>        by the user.
>      * A message serial number
> 
> I'm a little confused on this note. The RequestID is REQUIRED, so, as 
> mentioned earlier, a service that makes sure not to respond 
> to a previously 
> requested response within a time interval should be 
> straightforward. We are 
> also specifying a 2-phase challange response too, right? Do 
> we know both of 
> these will need to be used? Are both mandatory to implement, 
> but optional 
> to use?

There are two replay attacks, one performed on the server, the
other on a client. The RequestID mechanism only protects the client.

A server could use the RequestID alone to protect against replay 
attacks but that would require the service to maintain an 
ever-increasing scoreboard of Request IDs which would not
be practical. There really needs to be some additional mechanism
to bound the length of the scoreboard.


> Another consideration worth noting (perhaps) is that while client 
> authentication is important to both reading (locate/validate) 
> and writing 
> (registration) to the database, its especially so to 
> regisrations. How do 
> you deal with folks populating your service with malicious 
> data. (Nothing 
> to say on that in this spec aside from warn about it -- if that.)

I think we just note it as an issue.
Received on Monday, 24 June 2002 12:30:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:39:16 GMT