RE: Proposed spec changes

Phill,

Great list.  Some comments in-line.

> -----Original Message-----
> From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] 
> Sent: Wednesday, March 06, 2002 12:33 PM
> To: 'www-xkms@w3.org'
> Subject: Proposed spec changes
> 
> 
> I propose making the following changes to the spec
> 
> 1. Removal of unnecessary design justification & explanatory material
> 	In particular the sections 'Design Philosophy' and 
> 'Tiered Service Model'
> 
> 	Remove all reference to Tier 0
> 	Change references to Tier 1 and Tier 2 to XKISS Locate 
> and XKISS Validate.
> 
> 	[These were useful in the early stages of the draft but 
> really refer to the overarching TAXI design and are not 
> really required here]

I concur, Tiers as an organizing concept aren't particularly useful at
this point.

> 
> 2. Reorganization of USER/SERVER Auth nonsense.
> 	This needs to be greatly streamlined.
> 
> 	Introduce an attribute of <RegisterRequest 
> GenerateKeyPair="True">
> 		Although presence of PoP can be used to decide 
> this being explicit has value.
> 
> 3. Add in UseKeyWith Element

Is the idea to have an 'any' as children since this is advisory info, or
should we define how to encode a usage expectation for common
applications

> 
> 4. Add in Service URI
> 
> 5. Add in bounds exceeded fault
> 
> 6. Add in explanation of the version identifiers [Copy from 
> SAML so we can knife the whole package in one go if necessary.
> 
> 7. Some additional explanation of the interpretation of 
> Validity Interval, wrt what it means if an 'invalid' response 
> is returned. Here I am anxious to avoid making the text too 
> X.509 centric.
> 
> 	We do need to do some additional explanation as to what 
> to do with specific requests and responses.

Let's not build in assumptions on X509 semantics.  I think we can keep
this general per the other discussion thread on this topic.

> 
> 8. Use XML Encrypt for encrypting the private key
> 
> Outstanding Issues
> 
> [I-PayloadAuth]
> 	Require decision on how payload authentication is to be 
> handled, in particular whether by a SOAP header or a 
> signature within the Request packet.

What type of authentication do we think is necessary here?  Is this a
POP using the private key, demonstrating knowledge of an out-of-band
secret using a keyed mac, some external auth mechanism like Passport or
Liberty?  Since other folks are solving the general SOAP security
problem we should define one mechanism that is minimally acceptable.
I'm pretty sure this won't involve support for external authentication
systems.

Use of a header may be easier for implementors.  If authentication is
required and the header is missing you can stop processing without
parsing through the body.  You also eliminate the need to transform the
body element when the authentication is added.


> 
> [I-PayloadHash]
> 	For establishing correspondence of response to a 
> specific request.

To minimize the implementation overhead we should be using the same
hashes computed for integrity or authentication signatures for this
value.

> 
> [I-RespondWith]
> 	Need to decide on the format of the identifiers here, I 
> am still unsure as to what QNames do. In particular note that 
> there are three types of query that return <X509Data>; 
> X509Cert, X509Chain and OCSP.

I'm leaning toward Joseph's suggestion of namespace qualified names.
For the last 3 items can't we just define these in the xkms namespace?

> 
> [I-FaultHandling]
> 	We need to address this, how is XP getting on here?
> 
> [I-KeyID]
> 	I forget can we delete this now?
> 
> [I-Passphrase]
> 	Needs to become Base64 data at the very least.

Yup.

> 
> [I-SOAP]
> 	Introduce section in the request/respons section that 
> discusses the SOAP binding issues, in particular SOAP faults.
> 
> 
> Phillip Hallam-Baker FBCS C.Eng.
> Principal Scientist
> VeriSign Inc.
> pbaker@verisign.com
> 781 245 6996 x227
> 
>

Received on Wednesday, 6 March 2002 18:50:28 UTC