Re: Comments on XML Key Management (2.0) Requirements -closed

Denis

Thank you for your comments on the XKMS requirements (they did not 
appear in the archive, but are attached and included here).

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 ):

Denis Pinkas wrote:
> Comments on XML Key Management (2.0) Requirements
> 
> Author: Denis PINKAS. Bull.
> 
> General comment
> 
> The specification includes many detailed implementation
> requirements, while the overall functional goal is not clear.
> 
>>From the introduction it seems that two main categories of functions
> need to be supported:
> 
> 1) the creation of a binding between a key, an identifier and some
> other information, like a key usage. Using the PKIX vocabulary this
> means the creation of a public key certificate. Using the PKIX
> vocabulary, it seems to be the support of CMP using XML syntax,
> instead of ASN.1 syntax. It seems that retrieval of that information
> and revocation of the certificate should also be supported, but this
> is unclear.
> 
There is no specific requirement indicating that a Locate should be able 
to return a certificate, but it is implicit in 2.4.8

"a server MUST be able to return key information corresponding to a 
KeyInfo returned in a registration response from the same server"

Revocation is addressed in 2.4.2
"The specification MUST describe how to revoke a registered key binding."

> 2) validation of a key against a policy, whereas this concept is
> insufficient: it should be validation of a certificate against a
> validation policy. The PKIX WG is currently attempting to finalize a
> requirements specifications, which includes much more functionality
> than this one. Many of the requirements which are in that other
> specification could be imported. Even this requirement is not clear.
> 
> The document should be clarified to identify what kind of functions
> need to be supported.
> 
> 
> Detailed comments
> 
> 1. The introduction does not capture sufficiently the goals of this
> specification. The functions to be supported should be described to
> a finer level of granularity.
> 
> 
> 2. [Deferred Request Authentication] The current text is: "For
> example, a client request might be directed to a particular URI so
> that a specific policy will be enforced as part of the service
> processing the request. Inclusion of the URI in the response ensures
> that the expected server policy was followed and that the request
> was conveyed correctly".
> 
> This example is incorrect. A validation policy is not necessarily
> tight with a particular validation server. A validation server may
> indeed support different validation policies that may have their own
> URI belonging to a different name space. Thus a response shall
> include both the URI of the validation server *and* the URI of the
> validation policy. In some cases, it may be from the same name
> space.
> 

We discussed this at the F2F and the consensus is that external 
mechanisms such as WSDL and UDDI are appropriate for establishing the 
binding between policy information and the URL used to access the XKMS 
server. Implicitly that URL is associated with the underlying policies.
The URL used to access the service is returned in the response.

A server supporting different policies may also expose different web 
service interfaces with different urls.


> 
> 3. [Key Validation]. Key validation is defined as : "A service that
> verifies the binding of information to a public key and also
> determines the current status of that binding".
> 
> The determination of the current status of a binding is done using
> the OCSP protocol in the PKIX world. It is not the validation of
> certificate up to a root key or trust anchor but simply a check on
> the revocation status of the certificate.
> 

The mechanism used by the trust server to validate key bindings is out 
of scope for the requirements document. It could be implemented using 
PKI techniques or in some other manner.


> The term "Key Validation" is confusing since :
> 
> a) the term "key" (instead of "certificate") is used and the same
> public key MAY be bound to more than one identifier (name) so
> validating a key does not mean anything unless the whole information
> associated with that key is also validated at the same time.
> 

XKMS has a focus on keys rather than certificates. A validation request 
may request the validation of the binding of specific information to a 
key, so the meaning is clear despite the possibility of binding a 
variety of information to a key. Issues such as this must be made clear 
in the specification rather than the requirements.


> b) the term "validation" is used and in the PKIX world "validation"
> means to validate a certificate up to a root key, which is not what
> is said in the explanations. So neither the use of the term "key"
> nor "validation" is adequate (or would be very confusing for the
> PKIX community).
> 

The details of how validation is performed is trust server dependent and 
  implicit in the policies associated with the URL.

> If the term "certificate" is deliberately avoided, then "Key binding
> status check" would be a better wording for that service.
> 

We retained the original wording since a key itself may have an 
expiration (validity period), in addition to the validity of information 
  bound to the key. In PKI terms, both the key and certificate may have 
independent validity periods.


> Now, it is unclear if in addition (or as a replacement ?) of this
> service, an equivalent of a "certificate validation", using the PKIX
> terminology, is also required. Since the definition of this service
> by the PKIX WG is close to completion, it might be interesting to
> consider to import some of the sentences used in that document.
> Should an equivalent of that service be a goal of this
> specification, then it could be named: "Key binding validation".
> 

No requirements change is necessary. We agree that if an XKMS trust 
server does not implement the necessary functionality use of direct PKIX 
technology would be necessary.

> 
> 4.  [Trust Service]  A Trust Service is defined as "a service that
> is capable of registering public keys and/or providing key
> information services, including key validation and location.".
> 
> It should be made clear that these functions may be offered by
> different Trust Service Providers, in particular the registration of
> a public key with its associated information can be done with one
> service while the "key binding status check" can be provided by a
> different Trust Service Provider.
> 

We revised/added an explicit requirement, 2.3.1
"A server MAY be deployed that implements a subset of XKMS service 
functionality, such as Locate but not Validate, for example."

We also have the requirement 2.1.13
"An XKMS server SHOULD be able to pass requests to another XKMS server 
for processing with minimal overhead."

> 
> 5.  [Trust Service]  A Trust Service is defined as "a service that
> is capable of registering public keys and/or providing key
> information services, including key validation and location.".
> 
> There is not sufficient information to understand what a "key
> location" service is.
> 

Added definitions of Key Location and Key Validation to the glossary.

> 
> 6. [2.1 Universality and Usability. Item 2]
> 
> In order to allow some interoperability with PKIX, it should be said
> that some PKIX structures should be able to be encapsulated in XML
> structures (e.g. certificates, CRLs and OCSP responses).
> 
> 


Done. In 2.1.2:
"Note that common PKIX structures such as X.509 certificate and CRL 
structures may be embedded as binary (base64 encoded) data within XML 
elements as indicated by the KeyInfo definition [ XMLDSig ].Applications 
which expect to process X.509 certificates will require ASN.1 and 
certificate processing capabilities."


> 7. [Transaction Security. Item 5]. Including a hash of the request
> is fine to detect substitutions of some request parameters, but is
> not convenient to be able to prove to someone else that the response
> was correct, without the need to memorize the whole request. In many
> cases only some parameters of the request are sufficient and thus
> should be copied in the response in addition to the inclusion of the
> hash of the request. This avoids to memorize the whole request.
> 
> The text should be changed to: "The trust server response MUST
> include both a digest of the request payload and the request URL,
> and a copy of the relevant parameters of the request so that a
> response used in isolation may unambiguously determine what the
> request was about."
> 

We did not change this requirement, but discussed this issue at the F2F.
Determining the relevant parameters is difficult in an interoperable 
manner since it is based on both client and server. To maintain a simple 
  interoperable approach we left the definition alone. This looks like a 
possibility for XML extensibility.

> 
> 8. [Transaction Security. Item 6]. The current text is: "Techniques
> for protection against replay attacks MUST be recommended in the
> security considerations section. Specific techniques SHOULD be
> defined, such as nonce, origination time, and serial numbers in
> requests, for example"
> 
> This wording does not follow the meaning of RFC 2116. "MUST be
> recommend" is self-contradictory. Either it is recommended or it is
> a must. It is important to provide a replay protection mechanism and
> thus the requirement should be changed into: "Techniques for
> protection against replay attacks MUST be supported, whether the
> client has a clock synchronized with UTC or not.
> 
change to "MUST be defined" (in current editors draft, not on web yet)

> 
> 9. [Trust Service Trust. item 8]. The wording being used is a door
> opened to any interpretation: "The specification SHOULD support
> different means of establishing a trust relationship with the trust
> service, and not be limited to client caching of a trusted
> certificate or trusted key." Which are these "other" means ?
> 

We added the following:
"Other possibilities include key establishment using a shared secret, 
for example."

> 
> 10. [Capabilities. Item 2]. The current text says: "The
> specification MUST describe how to revoke a registered key binding."
> 
> This requirement is not very explicit. It should be said: "The
> specification MUST describe how revocation of a registered key
> binding can be requested". Then it be explained how/if the
> revocation is advertised. Is it through the use of "key binding
> status check" request and/or a "key binding validation" request ?
> 
> If there were some explanations about the architecture, the answers
> to these questions would probably be evident.
> 
> 
> 11. [Capabilities. Item 3]. The current text says: "The
> specification MUST describe how to update registered public key
> information". Does this function maps to a key binding (i.e.
> certificate) revocation followed by the issuance of a new key
> binding (i.e. certificate) ? If so, why such a combined function
> should be supported instead of two separate functions, since anyway
> the first one is needed ?
> 

Avoiding the trust server implementation (which may or may not include 
certificates), it means an update to all or a portion of the properties 
associated with a key.  An atomic update is valuable when no revocation 
period is desired.

> 
> 12. [Capabilities. Item 8 and 9]. This list of 10 items lists first
> the functions related to key binding registration and revocation,
> and finally introduce in the last two items what is specific to
> validation or status check. This should be separated.
#

Added new subsections: [Registration Capabilities] and
[Key Information Service Capabilities]

> 
> Now item 8 is confusing since it considers "validating the status of
> a public key and additionally validating the binding between a
> public key and other related information". Validating a public key
> alone, without he binding information does not mean anything. 

It can mean validating that the key is within the key validity period.

 > The
> text could be reworded to say: "This specification MUST define a
> protocol for validating the status of a key binding", but this would
> still be confusing: is the revocation status of a key binding being
> checked or the validity of a key binding against a validation policy
> ? This is not the same.
> 


>>From the next item, one possible interpretation could be: "This
> specification MUST define a protocol for validating a key binding
> against a particular context".
> 
> 
> 13. [Capabilities. Item 9]. Another example of a "context" would be
> a validation policy as meant by the PKIX WG. Adding such an example
> would be appreciated.
> 

The requirement includes the following explanation:
"Context enables 4-corner model support for example. As another example, 
the context may include the trust anchors and certificate policies the 
client wants the server to use for validation. [List(Yassir Elley)]"

> 
> 14. [Formats. Item 11]. The current text says: "The specification
> MUST define how to convey application context in requests/responses,
> e.g. transaction amount, arbitrary XML".
> 
> Conveying arbitrary XML from the applications both in the request
> and in the response has a drawback: interoperability. This should be
> changed into: "The specification MUST be able to support extensions
> to convey application context in requests/responses, e.g.
> transaction amount, arbitrary XML". These extensions SHALL be
> defined in further specifications". It should also be noticed that
> these extensions may add additional service to the basic service.
> 

We believe the use of XML namespaces and XML extensibility allows the 
ability to add XML extensions without harming interoperability

> 
> 15. [Formats. Item 14]. The current text says: "The specification
> MUST permit opaque data to be associated with a request and returned
> with the corresponding response." Conveying opaque data in the
> request has a drawback: interoperability. This requirement SHALL be
> deleted.
> 

We retained the requirement - applications and servers which do not need 
to process opaque data may ignore it.

> 
> 16. [2.5. Objects and Processing. Item 1]. The current text says:
> "The specification SHOULD define how to register a key for specific
> uses and how to update the allowed uses over time". This relates to
> the comment made for [Capabilities. Item 3] where the current text
> says: "The specification MUST describe how to update registered
> public key information". Why such a combined function should be
> supported instead of two separate functions, since anyway revocation
> is first needed ?
> 

The ability to provide an atomic update is sometimes necessary, as well 
as the ability to change information bound to a key without invalidating 
the key.

> 
> 17. [2.5. Objects and Processing. Item 2]. The current text says:
> "The specification SHOULD enable finer granularity of key usage
> definition to support compliance requirements. Signatures may be
> supported for specific purposes, such as approval, authorship or
> integrity for example. One possible way of meeting this requirement
> is to define a <Purpose> subtype for the <KeyUsage> element. "
> 
> There is a fully different way to address this issue, which does not
> require to support a new element or extension in a PKIX certificate.
> Signature will be verified against a signature policy ("signature
> validation context" seems to be the equivalent term that could be
> used by the XML community). The signature policy may define which
> "purposes" like approval or authorship are recognized under the
> policy. Then signers may indicate the "purpose" of the signature
> when they sign. The main advantage is that a single key binding can
> be used for many different "purposes", thus avoiding the creation of
> multiple key bindings.
> 
> The current requirement is in fact a solution to a problem. It is
> really questionable whether this requirement should be maintained at
> all. Supporting it in the way that is described above means no
> change on the key usage definition, but the support of a specific
> signed property in the XML DigSIG format.
> 

We removed this requirement, replacing it with the following
"A key registration request MUST be able to specify the appropriate key 
usage of a key."



> In the ETSI documents this property is called a "commitment type".
> See RFC 3125 and RFC 3126 for more information where this concept
> has been first used. Also see the definition of a format for
> electronic signature defined in XML and based on XML DigSIG: ETSI TS
> 101 903 XML Advanced Electronic Signatures (XAdES)
> available from: http://portal.etsi.org/sec/el-sign.asp
> 
> 
> 18.  [2.5. Objects and Processing. Item 4]. The current text says:
> "The following KeyInfo formats MUST be supported by a trust server
> if the service claims interoperability with PX509: X509Cert,
> X509Chain and X509CRL."
> 
> In order to provide interoperability with RFC2459bis, OCSP MUST also
> be supported (see section 4.2.2.1 Authority Information Access).
> 

We added to OCSP to the list in the following revised wording discussed 
at the F2F:

"The following KeyInfo formats MUST be supported: KeyName, KeyValue, 
RetrievalMethod and MgmtData. The X509Cert KeyInfo format MUST be 
supported by a trust server if the service claims interoperability with 
PKIX X.509. Additional KeyInfo formats such as X509Chain, OCSP, and 
X509CRL MAY be supported. X509Chain MUST be defined in the XKMS 
specifications. The other KeyInfo formats are defined in the XML 
Signature recommendation. The XKMS registration Private format MUST be 
supported if the service supports either service generated key pairs or 
key recovery. [List(SÈbastien Pouliot)]"


> 
> 19. [2.5. Objects and Processing. Item 10]. The current text says:
> "The specification MUST describe how to provide proof of possession
> of private keys.". This requirement should be mentioned as being
> optional: The specification SHOULD describe how to provide proof of
> possession of private keys."
> 

The consensus is that requirements on the specification should be MUST 
to have an impact on the specification. The need to implement or use 
proof of possession not implicit in this requirement.


> Proof of possession of a private key is not needed for decryption
> keys used for confidentiality purposes. If someone registers a
> public key and does not possess the corresponding private key, it
> will not be able to decipher. So there is no security threat.
> 

The concern of impersonation is raised - what if one registers a public 
key as ones own when it isn't.

Regardless, we believe it is reasonable to require the specification to 
describe how to use proof of possession.

> If the key is used for authentication, data origin authentication or
> non repudiation, then, if the "key binding information" (alias the
> certificate itself or an unambiguous reference of the certificate)
> is protected under the private key, then proof of possession will be
> done at the time of use of the key private rather than the time of
> registration of the key. It is even safer. PKIX has mandated proof
> of possession of private keys because of backward compatibility with
> some old protocols which were omitting to protect the certificate or
> a certificate identifier (and which otherwise would have been
> insecure). Since the XML community is building new protocols, these
> protocols should be built secure from the beginning.
>

We don't think this implies a requirement change.

> 
> 20. [3. Out of Scope. Item 2]. The current places in this list :
> "Issues of non-repudiation, including but not limited to 'technical
> non-repudiation' and 'contractual non-repudiation". This is
> contradictory with [2.5. Objects and Processing. Item 2 ] which
> mentions" Signatures may be supported for specific purposes, such as
> approval, authorship ". After having done such a signature, the
> signer will not be able to deny that he did it. This is called
> non-repudiation. If non repudiation was indeed out of the scope,
> then such purposes would not be supported or an authorship which
> could be denied would be of no interest. This item should be removed
> from the list.
> 

We eliminated this contradiction by changing 2.5.2 to be more specific:
"A key registration request MUST be able to specify the appropriate key 
usage of a key."

> 
> 21. [3. Out of Scope. Item 2]. The current places in this list :
> "Expression of existing PKI data structures in XML". This item
> should be removed from the list. It does make sense to encapsulate
> X509certificates in an XML container. See ETSI TS 101 903 .
> 

We reworded this out of scope item to clarify this issue:
"Redefining existing PKI structures using an XML syntax, such as 
redefining certificates in XML. Existing PKI structures may be 
encapsulated within XML elements however."

We also added to 2.1.2 the following:
"Note that common PKIX structures such as X.509 certificate and CRL 
structures may be embedded as binary (base64 encoded) data within XML 
elements as indicated by the KeyInfo definition [ XMLDSig ].Applications 
which expect to process X.509 certificates will require ASN.1 and 
certificate processing capabilities."



> Denis
> 
> 

We believe these issues are closed.  Do you agree?

(We may want to discuss adding an explicit requirement that Locate be 
able to return a X.509 certificate, but this may not be necessary).

Thank you.


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