Closed XKMS requirements issues

Frederick

Thank you for your comments on the XKMS requirements at

http://lists.w3.org/Archives/Public/www-xkms/2002Mar/0083.html

These issues are addressed in the May 7, 2002 Editors copy of the XKMS 
requirements ( http://www.w3.org/2001/XKMS/Drafts/xkms-req.html ):

1) 2.3.1 This should be made into a requirement with language like
"Trust servers MAY provide introspection..."
I don't think MUST would be appropriate here.

Changed requirement to "A Server MAY be deployed that implements a 
subset of XKMS service functionality, such as Locate but not Validate 
for example.". This was a revision based on discussion at the F2F.

2) we might want to add language that although ASN.1 tools aren't
required by XKMS, applications which deal with X.509 certs will need to
deal with ASN.1 if they operate on the certs...

Added language to 2.1.2 ("Applications which expect to process X.509 
certificates will require ASN.1 and certificate processing capabilities.")

3) I'm not sure I'm comfortable with the wording in 2.2.1 saying "no
security" is the third option when the third option is really security
by alternative means. This may require an editorial pass.

Revised 2.2.1 to state
"Every trust service MUST support TLS and payload security. Trust 
services MAY support secure networks such as IPSec for integrity and 
confidentiality. Every client MUST support at least one of these 
mechanisms appropriate for the servers contacted."

4) Is requiring support for bulk (MUST) ok, even if not addressed in the
first XKMS spec? I believe so but thought I'd mention it.

We agreed at the F2F that 2.4.5 can be kept, especially since it is a 
requirement on the specification
"The specification MUST describe how to register more than one public 
key in a single registration request, supporting bulk registration."

We included the editorial comments in revising the wording and grammar.

We believe these issues are now closed, and thank you for your comments.

Frederick and Mike
--
Frederick Hirsch (hirsch@fjhirsch.com)
Mike Just (mike.just@entrust.com)

Received on Thursday, 9 May 2002 22:30:55 UTC