comments on xkms-req-20020108.html

http://www.w3.org/2001/XKMS/Drafts/xkms-req-20020108.html


   Key Validation
          A service that verifies the binding of elements to a public key
          and also determines the validity status of the public key. For
          example, key validation may be performed based on elements
          secured to a public key in an X.509 certificate as in RFC 2459.

r: When we mean validation, do we always mean validation? Do we ever mean 
verification?
http://www.ietf.org/rfc/rfc2828.txt

   Trust Service
          A service that is capable of registering public keys and/or
          providing key information services, including key validation
          and location.

r: Any chance of calling this a "key" service. Particularly as multiple 
tiers might be referred to as a "trust service" right, for the lower ones, 
that might seem more inapproriate.

2 -- Design Principles and Scope
  1. Universality and Usability

    1. Request and response messages should be extensible.
    2. All messages and data structures must be specified in XML, using
       XML Schema [45]XMLSchema].

r: I presume like xmldsig and xenc we do not require validation?

    3. Element cardinality not equal to one, must be justified in the
       specification. Similarly, the use of optional elements should be
       justified.

r: I'm happy to constrain optionality, but the "cardinality not equal to 
one" is a little awkward. (What justifications will be necessary in the 
spec).  Perhaps if we said the use of optional features is discouraged 
(instead of focussing on elements).

    4. The specification must provide a binding to SOAP 1.1  [46]SOAP ]
       and migrate to XML Protocol [47]XMLProtocol] once defined
       List([48]Blair Dillaway)]. Interoperable SOAP support is
       required, e.g. Document literal encoding for compatibility with
       KeyInfo.

r: We will profile SOAP? Does this require an XKMS to conform to all of the 
SOAP spec? (I'm not saying it shouldn't just wondering.)

    7. Privacy considerations must be addressed.

r: To make this more substantive, should we say in the "Security Concerns" 
section?

   12. Support for legacy formats such as PKCS#10 and PKCS#7 should be
       defined.

r: I'm not sure what this entails? XML structures that emulate these 
formats? That the key service be able to work with them?


  3. Protocol Design

    5. The specification must describe how to register more than one
       public key in a single registration request.
    7. The specification must describe how to support template bulk
       registration with server generation. {Verisign}
       [54]WorkshopMinutes]

r: Are 5 and 7 distinct?

    8. The specification must define a request for retrieving a public
       key, given a <Ds:KeyInfo> element containing one or more key

r: Is that <ds:KeyInfo>? (instead of Ds?)

3 -- Requirements

  2. Payload and Protocol Definition

   11. The specification must allow the server to return a subset or
       superset of the elements requested by the clients. {Reagle}
       [63]WorkshopMeeting]

r: Well, I'd like to be clear on this. This might be possible, but I'm very 
concerned about the security implications of returning less (or more) 
information as well. I'd like a requirement that we consider the security 
concerns related to the respond of the query with respect to this. [1]

[1] 
http://lists.w3.org/Archives/Public/www-xkms-ws/2001Dec/att-0029/01-09-proposal.html
  [05-06] Will this return keys with KeyName and  KeyValue, or
  KeyName or KeyValue? I presume the query is conjunctive: all
  MUST match for a return. What about the Respond? If the only
  some of the requested data can be returned for the matched
  key, I assume they will be returned. I presume the respond is
  disjunctive: all data that can be returned will be. I believe that
  thinking of this as a simple protocol and a simple query/lookup
  will be important to the design and its security, we should
  probably look at the literature on securely designing database
  queries.

  4. Processing
    7. The specification should allow use of user-generated pass phrases
       as a means of proving ownership of a key(s) previously registered.
    8. The specification should provide a means of employing a secret,
       arranged out-of-band, between the registration service and
       end-user as a means of authorizing a registration action.
       List([69]Blair Dillaway)]

r: I'm not sure if these bullets belong in the "processing" section, or 
maybe we should distinguish between xml and security processing?

4 -- Coordination

   To ensure the above requirements are adequately addressed, the XML Key
   Management specification must be reviewed by a designated member of
   the following communities:
    1. XML Signature WG
    2. XML Encryption WG
    3. [74]XML Protocol
    4. XML Schema WG
    5. XML Core WG
    6. Internationalization IG

r: I don't think it is necessary to procure review from schema or core for 
XKMS.

5 -- Intellectual Property

   The specification should be free of encumbering technologies:
   requiring no licensing fees for implementation and use.

r: I suggest excerpting and reference the text in the charter to avoid 
nuanced legal conflicts between terms:

r: As required by the [Charter], "Any intellectual property essential to 
implement specifications produced by this Activity must be at least 
available for licensing on a royalty free license."


-- 

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Wednesday, 16 January 2002 12:15:07 UTC