1 ABSTRACT The XML Key Management Specification [XKMS] aims at providing a PKI independent interface to key management including discovery and validation of keys as well as support for certain aspects of the key life cycle management including registration, reissuance and revocation. XKMS employs XML Signature [XMLSIG] for the purpose of providing message security in the form of authentication and integrity. In addition, XKMS is based on the use of ds:KeyInfo as a means of transporting/specifying key information used as templates for the various operations it specifies. This technical note addresses some of the issues related to the use of XKMS in conjunction with PGP [RFC 2440]. 2 INTRODUCTION One of XKMS main objectives is to facilitate the use of XML Signature and XML Encryption [XMLENC] without mandating the use of any one specific public key infrastructure. Section 4.4.5 of XML Digital Signature [XMLSIG] Specification - Lacks specifics required for unambiguous interpretation of PGP packet types that are used in ds:KeyInfo/ds:PGPData/ds:PGPKeyPacket. - Excludes packet types that are useful in the establishment of trust in a key. - A PGP specific XMLSIG sample indicating the valid content of a PGPKeyPacket. All of the above mentioned deficiencies in the XML Digital Signature Specification were clearly noticed in the XKMS Interoperability activity [link to XKMS Interoperability and any email corresponding to the same] The objective of this document is to: - Recommend exactly what packet types should be used in ds:KeyInfo/PGPData/PGPKeyPacket. - Recommend behavior in relation to the treatment/handling of public keys pertaining to algorithms not supported by the XMLSIG vocabulary, specifically ElGamal. - Provide XMLSIG samples and XKMS sample message exchanges that include PGP artifacts. - Provide some usage scenarios involving XKMS and PGP to help understand the support for primitives and mechanisms provided by XKMS and its underpinning technologies. Some of the scenarios have implications related to out of band arrangements made between a requestor and a service. For example, full support for ValidateRequest requires information related to the requestors trust in another key owner/holder. It is not our intention to speculate over, or try to determine how meaningful or suitable certain scenarios are for PGP - this note simply discusses the support of primititves and mechanisms provided by XKMS and its underpinning technologies. [We will only make reference to and distinguish between the different versions of PGP document in RFC 2440 when required by the context.] 3 PGP PACKET TYPES FOR PGPKeyPacket (WITH XMLSIG SAMPLES) Section 4.4.5 in XMLSIG states that ds:PGPKeyPacket contains a Key Material Packet as defined in [PGP, section 5.5]. Apart from the obvious constraint that only public key packets and public subkey packets must be used, in order to be useful for establishing trust in a key, packets of other types, mainly Signature and UserID packets, are required Instead of using [PGP, section 5.5] we find that [PGP Section 10.1] entitled [Transferable Public Keys] recommends composing the content of a ds:PGPKeyPacket, with one exception: the last section of [PGP Section 10.1] which states that "Transferable public key packet sequences may be concatenated to allow transferring multiple public keys in one operation." This conflicts with the requirement in [XMLSIG 4.4] that multiple declarations within KeyInfo must refer to the same key and should therefore not be followed. While we don't find the tagname "PGPKeyPacket" optimally descriptive for its intended purpose, it is not our intention to propose an alternative name, nor is it our intention to introduce additional PGP specific markup intended to carry additional PGP artifacts. 7/XTsHaBSOnJ/jXD5v0zL6VKYsk= ov3HOoPN0w71N3DdGNhN+dSzQm6NJFUB5qGKRp9Q986nVzMb8wCIVxCQu+x3vMtq p4/... some text 7/XTsHaBSOnJ/jXD5v0zL6VKYsk= ov3HOoPN0w71N3DdGNhN+dSzQm6NJFUB5qGKRp9Q986nVzMb8wCIVxCQu+x3vMtq p4/... some other text 4 INCOMPATIBLE ALGORITHM SUPPORT RFC2440 supports, in addition to DSA and RSA, the ElGamal asymmetric cipher. XML Signature on the other hand only defines markup for DSA and RSA. This presents both a limitation and an opportunity. It is a limitation in the sense that not all combinations of and are meaningful. To illustrate the point, consider a client that tries to discover the from a containing an ElGamal key. As there is no ElGamal syntax defined, this is not possible. [Tommy: As ElGamal is "based" on Diffie-Hellman I checked if the would offer a possible solution/workaround for this issue. Given the schema fragment of in combination with the fact that an ElGamal public key (when in transit betweeb PGP entities) is defined by the values P, G(enerator) and Y (Public) I have reached the conclusion that a more suitable definition may be A more cryptographically minded person may want to correct me on this, not only for the sake of using ElGamal keys in XMLSIG/XKMS but for the more general case. ] Inability to act on an unsuppored algorithm should ideally be backed up by the existence of a ResultMinorEnum enumeration value such as http://www.w3.org/2002/03/xkms#AlgorithmNotSupported. In the absence of such a code a service has little choice but to rely on a more general result code pair such as ResultMajor http://www.w3.org/2002/03/xkms#{Sender,Receiver} and ResultMinor http://www.w3.org/2002/03/xkms#Failure. On the other hand, because the ds:PGPKeyPacket element is of type #base64Binary an ElGamal key may be passed to a client in this form. This is the case when e.g. a client requests the service to RespondWith PGP. The same limitations apply to registration of an ElGamal key; the key must be included in ds:PGPKeyPacket as there is no ds:KeyValue syntax available for ElGamal keys. 5 PGP USAGE SCENARIOS (WITH XKMS SAMPLES) This section provides selected usage scenarios involving XKMS and PGP, accompanied by sample request/response messages. The messages are based on interactions between the following entities:
The following sub-sections describe the individual usage scenarios. 5.1 Scenario 1 An XKMS client requests a PGP artifact based on e-mail address. The service returns only a single PGPKeyPacket as the client specifies a RespondWith of #PGP. http://www.w3.org/2002/03/xkms#PGP http://www.w3.org/2002/03/xkms#Encryption ... ... http://www.w3.org/2002/03/xkms#Encryption 5.2 Scenario 2 An XKMS client requests a collection of PGP artifact's based on e-mail address. The service returns multiple PGPKeyPacket's as the client specifies a RespondWith of #PGPWeb. http://www.w3.org/2002/03/xkms#PGPWeb http://www.w3.org/2002/03/xkms#Encryption ... ... http://www.w3.org/2002/03/xkms#Encryption 5.3 Scenario 3 TODO: Validate 5.4 Scenario 4 TODO: Register 5.5 Scenario 5 TODO: Reissue 5.6 Scenario 6 TODO: Revoke 5.7 Scenario 7 TODO: Recover [7 IMPLICATIONS OF DIFFERENCES BETWEEN A HIERARCHICAL TRUSTMODEL AND A WEB-OF-TRUST] XKMS defines a schema type for the purpose of expressing a key's binding status and reasons for which a key has a particular status. XKMS distinguishes between three values for binding status namely Valid, Invalid and Indeterminate. Reason codes are defined for - artifact signature validity - validity interval - revocation status - issuer trust The XKMS specification provides a table in section 5.1.8 that shows how these values relate to an hierarchical X509 based PKI. In the case of PGP, which uses a web-of-trust model, some of the reason codes imply that the service has knowledge of a clients trust relationships. While XKMS does not directly support communication of this [trust information] from the client to the service, it could be achieved out of band or by implementing an xkms:MessageExtension. Another possibility is that, implied in the use of an XKMS service, (through policy or service agreement) is that the service decides what key-signers/introducers are trustworthy. [Tommy: It seems that some XKMS message types are less useful than others in a traditional PGP environment in which the user ultimately decides on trust issues and that delegating such functionality is not meaningful in the general case - ValidateRequest is an example.] [Tommy: Is it meaningful to attempt producing a table similar to that in 5.1.8 for PGP?] References [XMLSIG] [XMLENC] [RFC 2440] [...]