INTERNET-DRAFT Paul Lloyd Intended Category: Standard Track Hewlett-Packard Company Expires: 21 September 2001 21 March 2001 A Framework for Cryptographically Protected Attribute Values Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract As enterprises make increasingly sophisticated use of LDAP-accessible directories, particularly in inter-enterprise scenarios, classic approaches to achieving confidentiality and integrity requirements for sensitive data stored in these directories can become unscalable, unmanageable, or at odds with overall security requirements. This document defines a framework in which the accessors of directory data, both producers and consumers, can utilize cryptographic protection of selected attributes to achieve their required levels of confidentiality and integrity. This framework can be used as a complement to any native access control mechanisms offered by a directory instance, or it may be used as a complete replacement. Lloyd [Page 1] INTERNET-DRAFT draft-lloyd-protectedattrs-00.txt 21 March 2001 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" used in this document are to be interpreted as described in [RFC2119]. 1. Overview Traditionally, a directory instance can conveniently be viewed as both the storage tier and the business logic tier of a distributed application. For use cases representing typical directory data and associated transactions, this model is sufficient. This has especially been the case in intra-enterprise deployments. In intra-enterprise deployments, there is usually a single producer, or very few, centralized producers, of directory attributes; for example, authoritative personnel data bases and email management tools are often used to populate the directory entries. The security goals of such a system are readily addressed with present technology. Confidentiality requirements can be met with a combination of TLS [RFC2246] on the wire, access control based on client authentication and authorization checks using ACLs, and even network firewalls. Integrity requirements can be met with a combination of stringent operational controls on the centralized population mechanism and TLS on the wire. As directories become more pervasively deployed among large enterprises and as enterprises perform more transactions over the Internet, other use cases suggest themselves. For many of these use cases, a directory instance is most valuable when viewed as primarily a storage tier in a multi-tier distributed application rather than as an application in its own right; other aspects of the business logic are best moved to other parts of the transaction flow. When a directory is used in this capacity, traditional approaches to securing selected directory attributes can encounter barriers. Achieving confidentiality goals can become difficult for several reasons. A wire protocol like TLS invites exposures unless the directory server enforces proper usage for all operations. If most attributes are not highly sensitive, it is reasonable to allow access using the LDAP protocol [RFC2251] directly over TCP, possibly with anonymous Binds; sadly, careless applications or active attackers could result in the exposure of highly sensitive attributes. Furthermore, some form of access control is still required for each directory operation. If only selected attributes require special protection, the complexity of maintaining these very fine-grained ACLs can become unscalable and unmanageable; this is especially true when many different applications wish to leverage the directory and share access to its objects. Finally, none of these measures can protect against a compromised or malicious directory. Lloyd [Page 2] INTERNET-DRAFT draft-lloyd-protectedattrs-00.txt 21 March 2001 Achieving integrity goals can become difficult as well. Although a wire protocol like TLS can protect the network traffic, it can not ensure consumers that the values are exactly as written by the producers. Also, it can not protect against a compromised or malicious directory. It is also important to recognize that, increasingly, these security goals are being driven from areas such as public policy requirements and financial institution guidelines that are outside of the control of the enterprise. Enterprises simply find themselves mandated to apply specific, stringent controls to their collection, storage, and use of sensitive information. Fortunately, there are well-established cryptographic techniques that can be employed. These techniques are appropriate and adequate in their ability to achieve protection; they can be utilized efficiently; and standards exist to facilitate interoperability. This document defines a framework in which the accessors of these selected directory attributes can achieve their confidentiality and integrity goals through the use of cryptography. 2. Sample Use Cases 2.1. B2C Scenario Consider an enterprise that conducts E-Commerce over the Internet. In the B2C case, the enterprise may collect and maintain a variety of customer information. This information may be used by a variety of business applications throughout the enterprise, such as online purchasing, order fulfillment, targeted marketing, and support. For many enterprises, establishing a directory of customer information is more compelling than simply establishing a database of customer information; this is readily seen when one considers the scalability and availability of current directory offerings, along with the largely read-only nature of the data. Security savvy enterprises also realize that for highly sensitive customer attributes, such as financial data and payment instrument data, current approaches to securing data may not be adequate. The confidentiality and integrity requirements may demand that the online purchasing application apply sufficiently stringent safeguards to ensure that no other accessors, or even the directory administrators, can access the information. A recognized safeguard is for the online purchasing application to encrypt the highly sensitive data before writing it and to decrypt it after reading; the online purchasing application maintains all cryptographic keys. Lloyd [Page 3] INTERNET-DRAFT draft-lloyd-protectedattrs-00.txt 21 March 2001 If other, selected business applications require access, they can obtain the necessary cryptographic keys using a key transport protocol with the online purchasing application. 2.2. B2B or Partnership Scenario Now consider B2B or partnership interactions between two or more enterprises. One of the enterprises may wish to utilize services of the other enterprises. For reasons of cost, performance, or agility of execution, this enterprise may desire to grant access to its directory. If the enterprise stores a few highly sensitive attributes in the directory, the enterprise may consider such access to represent a vulnerability with unacceptable risk. A recognized safeguard is to store the highly sensitive attributes in encrypted form so that the partners can never gain access to the attributes in plain text form. 2.3. Outsourced Directory Scenario Finally, consider an enterprise that wishes to outsource the operation of its directory read-only replicas for economic reasons. As above, if the enterprise stores a few highly sensitive attributes in the directory, the enterprise may consider the outsourcing to represent a vulnerability with unacceptable risk. Once again, a recognized safeguard is to store the highly sensitive attributes in encrypted form so that the outsource supplier can never gain access to the attributes in plain text form. 3. Elements of the Framework 3.1. The "protected" AttributeDescription Option The framework defines a new option that can be included in an AttributeDescription to indicate cryptographic protection of the AttributeValue; the option is represented by the token "protected". For example, the AttributeDescription 'creditCardNumber;protected' indicates that the actual AttributeValue has been cryptographically protected using this framework. If the "protected" option is present in an AttributeDescription, it overrides any string-based encoding representation defined for that attribute in [RFC2252]. Instead the attribute MUST be stored and transferred as a binary value representing the BER encoding of the 'Protected' syntax defined in section 3.3.1. Unlike the "binary" option defined in [RFC2251], the "protected" option mandates requirements for both storage and transfer. Servers MUST store and transfer the AttributeValue exactly as received in Add Lloyd [Page 4] INTERNET-DRAFT draft-lloyd-protectedattrs-00.txt 21 March 2001 and Modify operations. Servers MUST NOT return values in this form unless explictly requested by clients in the Search operation. If the attribute is multi-valued, each of the individual values in the set MUST be individually protected as defined by the 'Protected' syntax. Clients specifying the "protected" option in Add and Modify operations MUST apply the cryptographic protection before transfer. Clients specifying the "protected" option in Search operations MUST correctly process the cryptographic protection in order to gain access to the ultimate AttributeValue. This might involve additional transactions against the directory or other application servers in order to obtain the requisite keys. Clients MUST NOT specify the "protected" option in Compare operations, and servers MUST return unwillingToPerform if they receive an errant Compare operation. Because the "binary" option is implicit and redundant, servers SHOULD treat the combination of the "binary" and "protected" options to be equivalent to the "protected" option. 3.2. Attribute Types 3.2.1. The contentEncryptionKey Attribute Type This attribute is used to store Content Encryption Keys (CEK) in the directory as actual data. ( OID.tbd.1 NAME 'contentEncryptionKey' SYNTAX 1.3.6.1.4.1.1466.115.121.1.not-yet-assigned-1 ) This attribute MUST be stored and transferred in the binary form, as in 'contentEncryptionKey;binary'. 3.2.2. The messageAuthenticationKey Attribute Type This attribute is used to store Message Authentication Keys (MAK) in the directory as actual data. ( OID.tbd.2 NAME 'messageAuthenticationKey' SYNTAX 1.3.6.1.4.1.1466.115.121.1.not-yet-assigned-1 ) This attribute MUST be stored and transferred in the binary form, as Lloyd [Page 5] INTERNET-DRAFT draft-lloyd-protectedattrs-00.txt 21 March 2001 in 'messageAuthenticationKey;binary'. 3.2.3. The KeyId Attribute Type This attribute is used to associate a unique identifier with a cryptographic key. ( OID.tbd.15 NAME 'keyId' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) This attribute SHOULD contain human-readable text. 3.3. Attribute Syntaxes In accordance with the LDAP v3 Attribute Syntax Definitions [RFC2252], the framework defines new attribute syntaxes to represent cryptographically protected attributes and cryptographic keys. 3.3.1. The Cryptographically Protected Attribute Syntax ( 1.3.6.1.4.1.1466.115.121.1.not-yet-assigned-2 DESC 'Protected' ) Values in this syntax are encoded using a subset of the Cryptographic Message Syntax (CMS) [RFC2630]. This subset is selected in order to * keep focus on the anticipated confidentiality and integrity requirements, * allow ease of use by clients during both development and deploy- ment, * facilitate flexible and efficient key management. Confidentiality SHOULD be achieved using the EnvelopedData syntax; for applications who have very minimal key management concerns or who wish to keep all aspects of key management completely external, confidentiality MAY be achieved using the EncryptedData syntax. Although the framework places no actual restrictions on the usage of the RecipientInfos field, the framework does recommend certain usage; these recommendations are presented in section 5.1.1.1. Integrity MAY be achieved using either the AuthenticatedData syntax or the SignedData syntax. The same recommendations regarding the use of the RecipientInfos field apply. Although the framework places no actual restrictions on the usage of the SignedData fields, the framework does recommend certain usage; these recommendations are presented in section 5.1.1.2. Lloyd [Page 6] INTERNET-DRAFT draft-lloyd-protectedattrs-00.txt 21 March 2001 Although CMS permits arbitrary nesting, the framework specifies restrictions. If only confidentiality is desired, the attribute value MUST be the content of an instance of EnvelopedData or Encrypted Data. If only integrity protection is desired, the attribute value MUST be the content of an instance of AuthenticatedData or SignedData. If both confidentiality and integrity are desired, the attribute value MUST be the content of an instance of AuthenticatedData or SignedData, and the encoding of this instance MUST be the content of an instance of EnvelopedData or EncryptedData. The contentType of the inner content SHOULD represent the type of the original, unencrypted attribute value. The framework places no restrictions on algorithm selection or usage. To faciliate the use of the directory as a Key Distribution Center (KDC), the framework defines certain attributes for use in the unprotectedAttrs field of the EncryptedData syntax. These KDC features are described in section 5.2. An unprotected attribute of type DN from [RFC2252] MUST only be used to indicate the DN from which a key exchange operation can be used in order to obtain the key from the directory. An unprotected attribute of type KeyID MUST only be used to indicate a specific key during a key exchange operation. We note that the unprotected nature of these attributes renders them susceptible to active attacks. 3.3.2. The Cryptographic Key Attribute Syntax ( 1.3.6.1.4.1.1466.115.121.1.not-yet-assigned-1 DESC 'Cryptographic Key' ) Values in this syntax are encoded using the following: CryptographicKeyValue ::= SEQUENCE { version INTEGER, -- this is version 0 keyId DirectoryString, CHOICE { transport [0] SET OF KeyTransRecipientInfo, -- from CMS agreement [1] SET OF KeyAgreeRecipientInfo, -- from CMS kek [2] SET OF KEKRecipientInfo, -- from CMS rawKey [3] OCTET STRING } } The first three choices allow for the key management mechanisms Lloyd [Page 7] INTERNET-DRAFT draft-lloyd-protectedattrs-00.txt 21 March 2001 defined in CMS. These choices ultimately use an asymmetric or symmetric Key Encryption Key to encrypt a Content Encryption Key (CEK) or a Message Authentication Key (MAK); it is the CEK or MAK that is used to achieve confidentiality protection or integrity protection of the attribute value. The final choice allows the directory to store the actual CEK or MAC as an attribute value. The framework assumes that other forms of protection, such as TLS and ACLs, are used during directory operations involving these attribute values. 3.4. Object Classes 3.4.1. The Cryptographic Key Object Class This object class enables a directory object to serve as a repository of cryptographic keys. ( OID.tbd3 NAME 'cryptographicKey' SUP top STRUCTURAL MAY (contentEncryptionKey $ messageAuthenticationKey) ) 3.5. Controls 3.5.1. The Dynamic Protection Control As an alternative to storing attributes in protected form, some client applications may simply wish for an efficient way to retrieve selected attributes in protected form; in such cases the server dynamically adds the protection during the Search operation. The Dynamic Protection Control allows clients to inform servers of this desire and to provide the necessary parameters. The controlType is OID.tbd.4. The criticality is selected by clients, and servers MUST interpret the value is specified in [RFC2251]. The controlValue is the encoding of DynamicProtectionControl ::= SEQUENCE { version INTEGER, -- this is version 0 desiredProtection ENUMERATED { confidentiality (1), integrity (2), Lloyd [Page 8] INTERNET-DRAFT draft-lloyd-protectedattrs-00.txt 21 March 2001 confidentialityAndIntegrity (3) }, recipient IssuerAndSerialNumber, -- as used in CMS attributes AttributeDescriptionList } The client uses the desiredProtection field to indicate the cryptographic protection that the server should apply. The client uses the recipient field to indicate a particular certificate that the server can use to perform key exchange. The client uses the attributes field to indicate the selected attributes that are to be protected; clients MUST NOT specify the "protected" option in any element of the list. This control is only valid in authenticated sessions. The recipient field MUST correspond to a valid userCertificate value stored in the client's directory object. This certificate MUST have sufficient information in the form of certificate extensions to permit the server to determine the actual key exchange mechanism. Note that the KEK mechanism is not supported. This control can appear in Search operations and Bind operations. In Search operations, the server MUST apply the request only to the particular search and only to the specified attributes. In Bind operations, the server MUST apply the request to every subsequent Search operation that does not contain an overriding instance of this control. Servers MUST return AttributeDescriptions containing the "protected" option. 3.6. Key Management Extensions The framework defines three extensions that enable a directory to function as a Key Distribution Center (KDC). These extensions require authenticated sessions. 3.6.1. The Key Transport Extension The Key Transport Extension enables the directory to distribute keys using an asymmetric key transport algorithm. The requestName of this extension is OID.tbd.7. The requestValue of this extension is the encoding of KTKDCOperation ::= SEQUENCE { version INTEGER, -- this is version 0 keyId DirectoryString, recipient IssuerAndSerialNumber } Lloyd [Page 9] INTERNET-DRAFT draft-lloyd-protectedattrs-00.txt 21 March 2001 The keyId field specifies the key that the client wishes to obtain. The recipient field specifies the certificate that is to be used for the transport. The recipient field MUST correspond to a valid userCertificate value stored in the authenticated client's directory object. This certificate MUST be appropriate for a key transport function. The responseName of this extension is OID.tbd.37. The responseValue of this extension is the encoding of the CryptographicKeyValue syntax. This instance MUST use the transport choice. 3.6.2. The Key Agreement Extension The Key Agreement Extension enables the directory to distribute keys using an asymmetric key agreement algorithm. The algorithm produces a Key Encryption Key that is used to wrap the actual key. The requestName of this extension is OID.tbd.8. The requestValue of this extension is the encoding of KAKDCOperation ::= SEQUENCE { version INTEGER, -- this is version 0 keyId DirectoryString, recipient IssuerAndSerialNumber } The keyId field specifies the key that the client wishes to obtain. The recipient field specifies the certificate that is to be used for the transport. The recipient field MUST correspond to a valid userCertificate value stored in the authenticated client's directory object. This certificate MUST be appropriate for a key agreement function. The responseName of this extension is OID.tbd.38. The responseValue of this extension is the encoding of the CryptographicKeyValue syntax. This instance MUST use the agreement choice. 3.6.3. The Key Encryption Key Extension The Key Transport Extension enables the directory to distribute keys using a symmetric key algorithm and Key Encryption Keys. Lloyd [Page 10] INTERNET-DRAFT draft-lloyd-protectedattrs-00.txt 21 March 2001 The requestName of this extension is OID.tbd.9. The requestValue of this extension is the encoding of KEKKDCOperation ::= SEQUENCE { version INTEGER, -- this is version 0 keyId DirectoryString, kekId DirectoryString } The keyId field specifies the key that the client wishes to obtain. The kekId field specifies the KEK that is to be used to wrap the desired key. The framework does not specify how servers determine if clients have access to the KEK. Servers MAY store KEKs in the directory objects of clients in a similar manner to the storage of certificates. The responseName of this extension is OID.tbd.39. The responseValue of this extension is the encoding of the CryptographicKeyValue syntax. This instance MUST use the kek choice. 4. Key Management Considerations 4.1. Extra-Directory Key Management Some clients may choose to manage keys in a manner that is completely outside the boundaries of the directory. The framework's incorporation of the key management mechanisms of CMS provides these clients with an excellent foundation. 4.2. The Directory as Key Distribution Center (KDC) Flexible, efficient key management can be realized if features are added to the directory in order to allow the directory to function as a KDC. The framework defines several such features. The first feature is the cryptographicKey Object Class and the contentEncryrptionKey and messageAuthenticationKey Attribute Types. These items allow the directory to store keys in directory objects. The second feature is the set of Key Managment Extensions. These extensions allow the directory to distribute keys to clients using the mechanisms defined in CMS. It is important to note that enterprises MAY use a separate directory instance to implement these extensions. Lloyd [Page 11] INTERNET-DRAFT draft-lloyd-protectedattrs-00.txt 21 March 2001 Proper use of the directory as a KDC requires especially stringent operational controls. These controls are outside the scope of this document. 4.3. Key Lifecycle Issues Ultimate success with cryptography will require the accessors to consider many traditional aspects of the key life cycle that are beyond the scope of the framework. Users of the framework are referred to the appropriate sections of the "Handbook of Applied Cryptography" [HAC] for a full treatment of this topic. Some of these lifecycle aspects, such as key backup and key recovery, represent future opportunities for the framework to embrace. 5. Using the Framework 5.1. Manipulating Data 5.1.1. Constructing Protected Attributes The construction of protected values MUST be performed as specified in CMS. This section discusses implications for scalability and manageability and makes several recommendations. 5.1.1.1. The RecipientInfos Field Construction of the RecipientInfos field of the EnvelopedData and the AuthenticatedData syntax requires careful consideration. First, if the producer does not know in advance the specific consumers of the protected attribute, the producer can not fully construct the field. Furthermore, even if the list of consumers is known, construction still requires knowledge of the certificates or KEKs that the consumers will use to exchange keys. Second, in those cases where producers do have full knowledge of the consumers and their key exchange credentials, consideration must be given to the resulting size of this field. Third, key exchange credentials usually have validity periods that are significantly less than the lifecycle of the protected attribute value. As a result, these syntaxes are generally most useful when specific conditions apply. Examples of such conditions are presented above in Lloyd [Page 12] INTERNET-DRAFT draft-lloyd-protectedattrs-00.txt 21 March 2001 section 2. Basically, use of these syntaxes is most applicable to those attributes that are utilized by a single business application or small, fixed collection of business applications. The KEK mechanism does provide for increased scalability, and clients SHOULD use this mechanism in situations where they also have the required key management infrastructure in place. The key management features included in the framework represent one possible infrastructure. 5.1.1.2. The SignedData Fields The framework makes several recommendations regarding the construction of instances of SignedData. These recommendations are meant to simplify processing. There SHOULD be only one signer in the signerInfos SET. The certificates field SHOULD contain the full certificate path for the single signer. The crls field SHOULD NOT be used. The signedAttrs field of SignerInfo SHOULD only contain the SigningTime attribute. The unsignedAttrs field of SignerInfo SHOULD NOT be used. 5.1.2. Protected Attributes in Add Operations The client constructs the protected form for each attribute that is to be transferred and stored with protection. The client adjusts the AttributeDescription to include the "protected" option. The client sets the values to the BER encoding. 5.1.3. Protected Attributes in Modify Operations For the add form, the client constructs the protected form for each attribute that is to be transferred and stored with protection. The client adjusts the AttributeDescription to include the "protected" option. The client sets the values to the BER encoding. The delete form is not supported. Clients MUST use the replace form with no values. For the replace form, the client constructs the protected form for each attribute that is to be transferred and stored with protection. The client adjusts the AttributeDescription to include the Lloyd [Page 13] INTERNET-DRAFT draft-lloyd-protectedattrs-00.txt 21 March 2001 "protected" option. The client sets the values to the BER encoding. 5.1.4. Retrieving Protected Attributes To retrieve attributes stored in protected form, clients MUST include the "protected" option in the AttributeDescription. Servers MAY apply native access control features, but it is crucial that the server not be configured such that these features interfere with the framework. Once the protected values are retrieved, clients MUST process the Protected syntax in order to gain access to the actual values. Clients MUST properly destroy all keying material after use. 5.1.5. Retrieving Attributes With the Dynamic Protection Control Clients MAY request dynamic protection of attributes that are not stored in protected form. Clients indicate such requests by including the Dynamic Protection Control in the Bind or Search operations during authenticated sessions. Dynamic protection MUST NOT be applied to attributes stored in protected form. Servers MUST apply all native access control features before applying any dynamic protection. Once the protected values are retrieved, clients MUST process the Protected syntax in order to gain access to the actual values. Clients MUST properly destroy all keying material after use. 5.2. Manipulating Keys 5.2.1. Transporting a Key Clients can obtain a particular CEK or MAK by requesting transport of the key with the KTKDCOperation extension. 5.2.2. Agreement of a KEK Clients can obtain a particular CEK or MAK by requesting wrapping of the key with a KEK that is obtained using the KAKDCOperation extension. Lloyd [Page 14] INTERNET-DRAFT draft-lloyd-protectedattrs-00.txt 21 March 2001 5.2.3. Key Exchange Using KEK Clients can obtain a particular CEK or MAK by requesting wrapping of the key with a particular KEK using the KEKKDCOperation extension. 5.2.4. Retrieving Raw Keys Raw keys stored as the rawKey choice of the CryptographicKeyValue syntax may be retrieved using the Search operation. Servers SHOULD utilize authenticated sessions and native access control features to restrict access to the keys. Servers SHOULD enforce use of a mechanism like TLS to protect the network traffic. 6. Samples to be added 7. Security Considerations This entire document is about security. This document defines a framework in which the producers and consumers of sensitive directory data can achieve specific confidentiality and integrity goals through the application of cryptography to selected directory attributes in a manner that is independent of any security features of the directory server. This has several interesting implications. First, we note that cryptography is not a magic bullet. The framework ultimately replaces one problem with another problem, key management. Failure to control the access to keys renders the protection pointless. A complex or cumbersome key management scheme may introduce unacceptable performance or economic penalties; it may also provoke untrained or frustrated developers and administrators to indulge in shortcuts with disastrous consequences. Furthermore, the accessors must also address traditional cryptographic issues such as algorithm selection and regulations regarding the use of cryptography. Second, we note that the framework can not address any availability requirements for the data. If the directory servers are unavailable because of malicious activity or simple network outages, then the data is also unavailable. It is also true that the availability of the data depends heavily on the availability of the required keys. Lloyd [Page 15] INTERNET-DRAFT draft-lloyd-protectedattrs-00.txt 21 March 2001 Third, it is imperative that any native access control features of the directory not be configured to interfere with the use of the framework. Finally, we note that the framework provides no protection for sensitive data at the points in the transaction flow that are outside of the directory. If enterprises do not approach their data security requirements in a holistic sense spanning the entire transaction flow, the benefits of applying cryptography to data stored as directory attributes can be minimal or non-existant. 8. References [HAC] A. Menezes, P. van Oorschot, S. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1997. [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 1999. [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [RFC2630] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999. 9. Author's Address Paul Lloyd Hewlett-Packard Company 3000 Hanover Street, MS 20CX Palo Alto, CA 94304 USA Phone: (650) 236-3704 EMail: paul_lloyd@hp.com Lloyd [Page 16]