R. Moskowitz, ICSA, Inc. Internet Draft Document: June 1999 CMP Interoperability Testing: Results and Agreements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. 1. Abstract This memo describes the results of the first two interoperability tests of public key infrastructure (PKI) implementations based on RFC 2459, RFC 2510, and RFC 2511. PKI implementations fall into three general classes: certification authorities (CAs), registration authorities (RAs), and PKI clients. Interoperability testing focused on transactions to obtain and revoke certificates. Based on the anticipated (and observed) difficulty to get basic interoperability working, the testing scenarios used are very constrained. Workshops for other IETF protocols have found that later workshops expand the testing scenarios until full functionality is met. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 3. Introduction Moskowitz 1 CMP Interoperability Testing: Results and Agreements June 1999 The PKI must be structured to be consistent with the types of individuals who must administer it. Providing such administrators with unbounded choices not only complicates the software required but also increases the chances that a subtle mistake by an administrator or software developer will result in broader compromise. Similarly, restricting administrators with cumbersome mechanisms will cause them not to use the PKI. Management protocols are REQUIRED to support on-line interactions between Public Key Infrastructure (PKI) components. For example, a management protocol might be used between a Certification Authority (CA) and a client system with which a key pair is associated, or between two CAs that issue cross-certificates for each other. More importantly, there MUST be proven interoperability of the management protocols between all of the PKI components. The only way to ensure this is to start with interoperability workshops to prove out the protocols. This report is the findings of the first two CMP/CMRF workshops. The workshop testing revolved around a set of scenarios that were thought would begin to exercise vendors code, and demonstrate the basics for a minimum PKI. No attempt was made to match these scenarios against any published minimum PKI definitions. Rather scenarios that would begin to exercise the protocol and highlight any issues in the protocol were selected. Also some vendor viewpoints in the scenarios was inevitable at this initial phase, as that is the code available for testing. It is fully expected that the next round of workshops will build on these scenarios and move to convergence with other published works. 4. Background With the publishing of RFCs 2459, 2510 and 2511, the IETF has established the basic requirements to create and maintain a PKI. However, until there is joint implementer testing of the technology, the standards cannot advance in the IETF and there can be no user confidence in their ability to deploy a usable PKI. To this end, a series of workshops have been started to achieve product interoperability and to discover and resolve any issues with the RFCs. This document presents the testing scenarios used in the workshops, sample results for the scenarios, and the issues revealed and proposed resolutions. Next steps is to expand the workshops to more participants and more scenarios and for the PKIX workgroup to address the issues revealed by the workshops. 5. Test Scenarios Moskowitz 2 CMP Interoperability Testing: Results and Agreements June 1999 Four scenarios are proposed for initial interoperability testing. These scenarios: Certificate bootstrap, Certificate Revocation, Additional Certificate request with the same Distinguished Name, and Additional Certificate request with a different Distinguished Name (i.e. a qualifying certificate) are sufficient to run a PKI. For the purpose of the interoperability workshops, the qualifying certificate scenario was a stretch goal. Initial testing is done with the file protocol (RFC 2510, sec 5.1). This is followed with Direct TCP-Based (RFC 2510, sec 5.2, Port 829). Thus for Interoperability, these two protocols are considered a MUST to implement. 5.1 Scenario #1 Bootstrap (password based) The End Entity has an out of band (OOB) interaction or transaction with the CA/RA. This transaction establishes the End Entities Distinguished Name (DN), a shared secret, and a CA/RA issued reference number. The EE will use the shared secret along with either the DN or reference number to send its certificate template in a CMP Initialization Request (IR) containing its public key and any other attributes to the CA. This is done 'in band', that is using one of the 4 CMP transports. The CA will respond with a certificate that the EE either accepts or rejects. Since the CMP transport can be asynchronous, or multiple transactions could be in process, the EE SHOULD use a transaction reference number to track the exchange. All clients SHOULD be able to support either IR identity method: Shared Secret and Reference # Shared Secret and DN AuthorĘs Question: After writing this, I see the model of only the Shared Secret is established. The EE proposes its DN and the CA accepts or alters. In this case, there would also not be a reference #. OOB CA/RA --> EE {shared secret information} IB EE --> CA/RA {ir} CA/RA --> EE {ip} EE --> CA/RA {conf} Moskowitz 3 CMP Interoperability Testing: Results and Agreements June 1999 5.1.1 ir Message Contents PKIMessage PKIHeader { pvno = 1, sender = distinguished name of requester, recipient = distinguished name of CA/RA messageTime = time message was generated with a granularity of seconds, in Greenwich Mean Time protection algorithm { Object Identifier = 1.2.840.113533.7.66.13, --PasswordBasedMac -- PBMParameter { salt OCTET STRING, owf AlgorithmIdentifier = 1.3.14.3.2.26 --SHA-1-- , iterationCount=1024, mac AlgorithmIdentifier = 1.3.6.1.5.5.8.12 -- HMAC-SHA-1-- } transactionID = octet string selected by requester } /* end of header */ PKIBody [0] { /* ir */ CertReqMessages { CertReqMsg { certReq { certReqId = integer selected by requester, certTemplate { publicKey { algorithm { algorithm = OID for algorithm of the public key parameters = NULL }, subjectPublicKey = BIT STRING of the public key } }, }, pop { signature [1] { POPOSigningkey { poposkInput { --if present authInfo publicKeyMAC { algId { algorithm = 1.2.840.113533.7.66.13 --PasswordBasedMac--, parameters = --as needed } value = BIT STRING, value is HMAC of public key }, publicKey { algorithm { Moskowitz 4 CMP Interoperability Testing: Results and Agreements June 1999 algorithm = OID for algorithm of the public key , parameters = NULL }, subjectPublicKey = BIT STRING of the public key }, algorithmIdentifier { algorithm = OID for algorithm of the public key , parameters = NULL }, signature = BIT STRING, the signature computed over the DER-encoded value of the certReq message if the subject and subjectPublicKey values are present in the CertTemplate. Use the popoSKInput field if either the subject or subjectPublicKey values/fields are not present. }, } PKIProtection = BIT STRING, is the HMAC value calculated over the PKIHeader and PKIBody } 5.1.2 ip Message Contents PKIMessage PKIHeader { pvno = 1, sender = distinguished name of CA/RA, recipient = distinguished name of requester, messageTime = time message was generated with a granularity of seconds, in Greenwich Mean Time protection algorithm { Object Identifier = 1.2.840.113533.7.66.13, --PasswordBasedMac -- PBMParameter { salt OCTET STRING, owf AlgorithmIdentifier = 1.3.14.3.2.26 --SHA-1-- , iterationCount=1024, mac AlgorithmIdentifier = 1.3.6.1.5.5.8.12 -- HMAC-SHA-1-- } transactionID = transactionID from the ir message } /* end of header */ PKIBody [1] { /* ip */ caPub = X.509 certificate of issuing CA, Moskowitz 5 CMP Interoperability Testing: Results and Agreements June 1999 response { CertResponse { certReqId = certReqId from the ir, status { PKIStatusInfo { Status = integer specifying { granted, rejected, or waiting }, FailInfo = if status = rejected, this bit string specifies the reason [if status != rejected,this field is absent] }, certifiedKeyPair { certOrEncCert { certificate = X.509 certificate of requester } } } } } PKIProtection = BIT STRING, HMAC value calculated over the PKIHeader and PKIBody } 5.1.3 conf Message Contents PKIMessage PKIHeader { pvno = 1, sender = distinguished name of requester, recipient = distinguished name of CA/RA messageTime = time message was generated with a granularity of seconds, in Greenwich Mean Time protection algorithm { Object Identifier = 1.2.840.113533.7.66.13, --PasswordBasedMac -- PBMParameter { salt OCTET STRING, owf AlgorithmIdentifier = 1.3.14.3.2.26 --SHA-1-- , iterationCount=1024, mac AlgorithmIdentifier = 1.3.6.1.5.5.8.12 -- HMAC-SHA-1-- } transactionID = transactionID from the ir message } /* end of header */ PKIBody [19] { /* conf message */ NULL } Moskowitz 6 CMP Interoperability Testing: Results and Agreements June 1999 PKIProtection = BIT STRING, HMAC value calculated over the PKIHeader and PKIBody } 5.2 Scenario #2 Revocation To revoke its certificate, an EE sends a Revocation Request with the revocation reason, signed by its certificate. The CA/RA acknowledges the request by returning a signed Revocation Response. EE --> CA/RA {rr} CA/RA --> EE {rp} 5.2.1 rr Message Contents PKIMessage PKIHeader { pvno = 1, sender = distinguished name of requester, recipient = distinguished name of revoaction processor [this is usually the CA/RA, but could also be an indirect CRL issuer] messageTime = time message was generated with a granularity of seconds, in Greenwich Mean Time protection algorithm { Object Identifier = 1.2.840.10040.4, DSA with SHA-1 } transactionID = octet string selected by requester } /* end of header */ PKIBody [11] { /* rr message*/ RevReqContent { RevDetails { CertTemplate { [1] serial = certificate serial number [5] issuer = distinguished name of the certificate issuer } OR CertTemplate { [3] subject = subject of certificate(s) to be revoked [5] issuer = distinguished name of the certificate issuer } revocationReason = reason certificate(s) should be revoked, badSinceDate = last date use of private key should be trusted } } } Moskowitz 7 CMP Interoperability Testing: Results and Agreements June 1999 PKIProtection = BIT STRING, value is ASN.1 encoded structure as follows: { Dss-Sig-Value { r = 160 bits, one half of DSA signature s = 160 bits, one half of DSA signature } } 5.2.2 rp Message Contents PKIMessage { PKIHeader { pvno = 1, sender = distinguished name of CA/RA, recipient = distinguished name of requester, messageTime = time message was generated with a granularity of seconds, in Greenwich Mean Time protection algorithm { Object Identifier = 1.2.840.10040.4, DSA with SHA-1 } transactionID = transactionID from the rr message } /* end of header */ PKIBody [12] { /* rp message */ RevRepContent { Status { Status { PKIStatusInfo { Status = integer specifying { granted, rejected, or waiting }, FailInfo = if status = rejected, this bit string specifies the reason [if status != rejected, this field is absent] } revCerts [0] { CertID { Issuer = distinguished name of issuer, Serial = serial number of revoked certificate } } } } } PKIProtection = BIT STRING, value is ASN.1 encoded structure as follows: { Dss-Sig-Value { r = 160 bits, one half of DSA signature s = 160 bits, one half of DSA signature } } Moskowitz 8 CMP Interoperability Testing: Results and Agreements June 1999 extraCerts [1] { certificate = CA protocol verification certificate } 5.3 Scenario #3 -- Additional Certificate request, Same DN An EE will need additional certificates throughout its 'life cycle'. Examples of this are: confidentiality certificates, special authenticating certificates, and attribute certificates. Additionally, certificates expire and need to be replaced, or an EE may simply wish to replace a valid certificate with a new key pair. All of these certificates can be obtained with a Certificate Request by the EE. In some cases, the nature of the need for the additional request can be determined by the CA by examining the KeyUsage bits. Although there are other transactions in CMP for renewing keys, particularly kur, for existing certificates, the workshops have used this scenario to allow the use of certificate request for ALL additional certificates to allow for minimum interoperable implementations. This MAY change by the time of the next workshop (if participants expand the scenarios in that direction). Additionally, this scenario was constrained to signature requests. The processing of requests for encryption [or confidentiality] certificates may introduce other considerations not addressed to date in the workshops. EE --> CA/RA {cr} CA/RA --> EE {cp} EE --> CA/RA {conf} 5.3.1 cr Message Contents PKIMessage { PKIHeader { pvno = 1, sender = distinguished name of requester, recipient = distinguished name of CA/RA, messageTime = time message was generated with a granularity of seconds, in Greenwich Mean Time protection algorithm { Object Identifier = 1.2.840.10040.4, DSA with SHA-1 } transactionID = octet string selected by requester } /* end of header */ PKIBody [2] { /* cr message */ CertReqMessages { Moskowitz 9 CMP Interoperability Testing: Results and Agreements June 1999 CertReqMsg { certReq { certReqId = integer selected by requester, certTemplate { publicKey { algorithm { algorithm = OID for algorithm of the public key parameters = NULL }, subjectPublicKey = BIT STRING of the public key } }, }, pop { signature [1] { POPOSigningkey { poposkInput { --if present authInfo publicKeyMAC { algId { algorithm = 1.2.840.113533.7.66.13 --PasswordBasedMac--, parameters = --as needed } value = BIT STRING, value is HMAC of public key }, publicKey { algorithm { algorithm = OID for algorithm of the public key , parameters = NULL }, subjectPublicKey = BIT STRING of the public key }, algorithmIdentifier { algorithm = OID for algorithm of the public key , parameters = NULL }, signature = BIT STRING, the signature computed over the DER-encoded value of the certReq message if the subject and subjectPublicKey values are present in the CertTemplate. Use the popoSKInput field if either the subject or subjectPublicKey values/fields are not present. }, } } PKIProtection = BIT STRING, value is ASN.1 encoded structure as follows: { Dss-Sig-Value { r = 160 bits, one half of DSA signature s = 160 bits, one half of DSA signature Moskowitz 10 CMP Interoperability Testing: Results and Agreements June 1999 } } } 5.3.2 cp Message Contents PKIMessage { PKIHeader { pvno = 1, sender = distinguished name of CA/RA, recipient = distinguished name of requester, messageTime = time message was generated with a granularity of seconds, in Greenwich Mean Time protection algorithm { Object Identifier = 1.2.840.10040.4, DSA with SHA-1 } transactionID = transactionID from the cr message } /* end of header */ PKIBody [3] { /* cp message */ response { CertResponse { certReqId = certReqId from the cr, status { PKIStatusInfo { Status = integer specifying { granted, rejected, or waiting }, FailInfo = if status = rejected, this bit string specifies the reason [if status != rejected, this field is absent] }, certifiedKeyPair { certOrEncCert { certificate = X.509 certificate of requester } } } } PKIProtection = BIT STRING, value is ASN.1 encoded structure as follows: { Dss-Sig-Value { r = 160 bits, one half of DSA signature s = 160 bits, one half of DSA signature } } } extraCerts [1] { certificate = CA protocol verification certificate Moskowitz 11 CMP Interoperability Testing: Results and Agreements June 1999 } 5.3.3 conf Message Contents PKIMessage { PKIHeader { pvno = 1, sender = distinguished name of requester, recipient = distinguished name of CA/RA, messageTime = time message was generated with a granularity of seconds, in Greenwich Mean Time protection algorithm { Object Identifier = 1.2.840.10040.4, DSA with SHA-1 } transactionID = transactionID from the cr message } /* end of header */ PKIBody [19] { /* conf message */ NULL } PKIProtection = BIT STRING, value is ASN.1 encoded structure as follows: { Dss-Sig-Value { r = 160 bits, one half of DSA signature s = 160 bits, one half of DSA signature } } } 5.4 Scenario #4 -- Additional Certificate request, Different DN (qualifying cert) There are some important cases where the additional certificate needed by the EE must have a different DN than the EE's current signing certificate. Examples of this are the OECD model for Qualifying Certificates, and some hardware vendor models to bootstrap one of their devices into a PKI by first getting a device ownership certificate from the hardware manufacturer and then using this to sign requests for usage certificates like IPsec or TLS. EE --> CA/RA {cr} CA/RA --> EE {cp} EE --> CA/RA {conf} 5.4.1 cr Message Contents PKIMessage { PKIHeader { Moskowitz 12 CMP Interoperability Testing: Results and Agreements June 1999 pvno = 1, sender = current distinguished name of requester, recipient = distinguished name of CA, messageTime = time message was generated with a granularity of seconds, in Greenwich Mean Time protection algorithm { Object Identifier = 1.2.840.10040.4, DSA with SHA-1 } transactionID = octet string selected by requester } /* end of header */ PKIBody [2] { /* cr message */ CertReqMessages { CertReqMsg { certReq { certReqId = integer selected by requester, certTemplate { subject = new distinguished name of requester, publicKey { algorithm { algorithm = OID for algorithm of the public key parameters = NULL }, subjectPublicKey = BIT STRING of the public key } }, }, pop { signature [1] { POPOSigningkey { poposkInput { --if present authInfo publicKeyMAC { algId { algorithm = 1.2.840.113533.7.66.13 --PasswordBasedMac--, parameters = --as needed } value = BIT STRING, value is HMAC of public key }, publicKey { algorithm { algorithm = OID for algorithm of the public key , parameters = NULL }, subjectPublicKey = BIT STRING of the public key }, algorithmIdentifier { algorithm = OID for algorithm of the public key , parameters = NULL }, signature = BIT STRING, the signature computed over the DER-encoded value of the certReq message if the subject and Moskowitz 13 CMP Interoperability Testing: Results and Agreements June 1999 subjectPublicKey values are present in the CertTemplate. Use the popoSKInput field if either the subject or subjectPublicKey values/fields are not present. }, } } PKIProtection = BIT STRING, value is ASN.1 encoded structure as follows: { Dss-Sig-Value { r = 160 bits, one half of DSA signature s = 160 bits, one half of DSA signature } } } 5.4.2 cp Message Contents PKIMessage { PKIHeader { pvno = 1, sender = distinguished name of CA, recipient = distinguished name of requester, messageTime = time message was generated with a granularity of seconds, in Greenwich Mean Time protection algorithm { Object Identifier = 1.2.840.10040.4, DSA with SHA-1 } transactionID = transactionID from the cr message } /* end of header */ PKIBody [3] { /* cp message */ response { CertResponse { certReqId = certReqId from the cr, status { PKIStatusInfo { Status = integer specifying { granted, rejected, or waiting }, FailInfo = if status = rejected, this bit string specifies the reason [if status != rejected, this field is absent] }, certifiedKeyPair { certOrEncCert { certificate = X.509 certificate of requester } } Moskowitz 14 CMP Interoperability Testing: Results and Agreements June 1999 } } PKIProtection = BIT STRING, value is ASN.1 encoded structure as follows: { Dss-Sig-Value { r = 160 bits, one half of DSA signature s = 160 bits, one half of DSA signature } } } extraCerts [1] { certificate = CA protocol verification certificate } 5.4.3 conf Message Contents PKIMessage { PKIHeader { pvno = 1, sender = distinguished name of requester, recipient = distinguished name of CA/RA, messageTime = time message was generated with a granularity of seconds, in Greenwich Mean Time protection algorithm { Object Identifier = 1.2.840.10040.4, DSA with SHA-1 } transactionID = transactionID from the cr message } /* end of header */ PKIBody [19] { /* conf message */ NULL } PKIProtection = BIT STRING, value is ASN.1 encoded structure as follows: { Dss-Sig-Value { r = 160 bits, one half of DSA signature s = 160 bits, one half of DSA signature } } } 6. Interoperability Agreements 6.1. DER encoding of PKIMessages Issue: RFC 2510 is ambiguous regarding the encoding of PKIMessage. The text requires DER-encoding the ProtectedPart (a SEQUENCE) before using it as the input to generate PKIProtection values, but does not require DER-encoding PKIMesaage (as opposed to BER-encoding). Moskowitz 15 CMP Interoperability Testing: Results and Agreements June 1999 However, the four protocols defined in section 5 all require DER- encoding of each PKIMessage. Resolution: All messages must be DER-encoded. 6.2. Shared Secret Issue: The salt was handled differently by different participants. Which is the correct answer? Resolution: The salt value is appended to the shared secret as specified in section 3.1.3 of RFC 2510. 6.3. Sender and Receiver Fields Issue: There is no consensus regarding whether sender and receiver fields in the PKIheader should be empty in ir messages. Section 3.1.1 of RFC 2510 explicitly allows an empty sender field, but is ambiguous about empty receiver fields. Resolution: Empty receiver and sender fields are appropriate when a requester appears at an RA in person. Where a client sends a request by another protocol, it must know an identity for itself and the receiver. These may not be the "PKI names" (e.g., the DNs) but could instead be the IP address or email address used in the protocol. In such a case, the sender and receiver should not be empty. 6.4 Proof of Possession Issue: The proof of possession for signing certificate requests is sometimes computed over the DER-encoded value of the certReq, and at other times computed over the popoSKInput field. According to RFC 2510, the proof of possession for signing certificate requests is computed over the DER-encoded value of the certReq message if the subject and subjectPublicKey values are present in the CertTemplate. If either of these values/fields are not present, the popoSKInput field must be used. The popskInput field includes the public key and a choice of "an authenticated identity" or a "password-based MAC of the public key". However, this does not allow for several important scenarios: (1) Where an RA checks a requesterĘs identity and modifies the CertTemplate, it cannot provide proof of possession to the CA, and (2) Where an entity has an "authenticated identity", but is requesting a different DN, it cannot supply all the required information. Moskowitz 16 CMP Interoperability Testing: Results and Agreements June 1999 Resolution: To clarify the situation, the following rules were proposed: (1) The public key must be present in the CertReq certTemplate. (2) If popskInput is present, the sender in the poposkInput must match the sender in the message header. (3) If popskInput is present, the public key must be present in the poposkInput and must match the public key in the CertReq. (4) If the poposkInput is present, it must be used as input to generate the signature for the proof of possession. If the poposkInput is omitted, the certReq must be used as the input to generate the signature for the proof of possession. [This does not entirely resolve the issue. For a more complete solution, see 6.12.] 6.5 Nonces Issue: Nonces are implemented by Entrust and Xeti; the NIST and IBM implementations do not. The Baltimore Technologies implementation does not care/check for nonces. Nonces are required in B.8, B.9, and B.10 of RFC 2510. Although no realistic replay attack was identified it is not clear if nonces are required in rr and rp messages? Resolution: For this testing, request messages may include the senderNonce, but they are not required. Response messages must, at a minimum, include the recipNonce (with the requestĘs senderNonce as the value) if the request included the senderNonce. 6.6 Handling subjectPublicKey Information Issue: There appears to be a problem with RFC 2511 regarding the handling of subjectPublicKey. This field appears in CertTemplate and poposkInput, but it is not clear if it should appear in both places at the same time, either (and under what conditions), or in neither. Resolution: For this testing, the subjectPublicKey should always be in the certTemplate, even if the popskInput field is present in the pop field 6.7 Revocation Details Issue: Is the crlEntryDetails field needed in the revDetails? The contents of this field could be inconflict with other optional fields in revDetails (revocationReason and badSinceDate). According with RFC 2510 (Section 3.3.9), the reason for revocation and best guess of the time of loss or compromise should be represented in the revocationReason and badSinceDate fields, not crlEntryDetails. Moskowitz 17 CMP Interoperability Testing: Results and Agreements June 1999 This leaves only the instructionCode extension and certificateIssuer entry extensions. The former is an "advanced" feature and propbably outisde our scope. The latter is not information the requester should specify. Resolution: For this testing, crlEntryDetails, is not required. If it appears in a revocation request it may ignored. 6.8 Extra Certificates Field Issue: Should the use of extraCerts field be required for interoperability? Resolution: Use of the extraCerts field is recommended, but is not required. Implmenetations must be able to recieve and parse message with an extraCerts field. 6.9 Distinguished Name Encoding vs. String Representation Issue: The agreed convention for distinguished names is start with root and end with the leaf. The agreed convention for the string representation is start with the leaf and end with the root. The use of "@" as a delimiter is forbidden by the LDAP specs. Resolution: DNs shall be encoded starting with the root and ending with the leaf. String representations shall start with the leaf and end with the root. For the string representation, use commas as delimiters and not "@". 6.10 Shared Secret Length Issue: In the case of password-based message authentication codes, how long should the shared secret be? Resolution: TBD 6.11 Using PoPoSigningKey with PoPoskInput Issue: How is the input to the proof-of-possession computation formatted when it is based on poposkInput? Resolution: According to Section 4.4, using poPoSigningKey when the poposkInput field is present, the value of the signature is generated using the complete DER-encoded structure. The outermost SEQUENCE tag must be included, rather than the explicit [0] that replaced it in the actual message. 6.12 Certificate Request and Proof of Possession Issue: The requester is required to provide proof of possession of the corresponding private key material when a signature certificate is requested. It is useful to provide this proof to the CA, even where an RA verifies the requesterĘs identity and modifies the Moskowitz 18 CMP Interoperability Testing: Results and Agreements June 1999 certificate request. The text describing the mechanisms for this purpose in RFC 2510 is somewhat contradictory. Interim Resolution: To clarify the situation, the following rules were proposed: (1) The sender in the poposkInput must match the sender in the message header. (2) The public key must be present in the CertReq certTemplate. (3) The public key must be present in the poposkInput and must match the public key in the CertReq. (4) If the poposkInput is present, it must be used as input to generate the signature for the proof of possession. If the poposkInput is omitted, the certReq must be used as the input to generate the signature for the proof of possession. Long Range Resolution: The interim resolution is an improvement over the current text, but does not constitute a complete solution. The interim resolution also lacks elegance. The following is proposed as a final resolution: PoposkInput ::= CHOICE { Subject name, Sender [0] generalName, publicKeyMAC [1] PKMACValue } The pop is calculated upon the structure popInput, which is defined as follows: PopInput ::= SEQUENCE { CHOICE { otherinput popskInput, subject name }, publicKey subjectpublicKey } If poposkInput is present in the pop field, popInput is constructed with otherinput. If poposkInput is not present, subject is the name from CertTemplate. Note that the encoding of PopInput is intentionally ambiguous. If an RA 6.13 The PKIConfirm Message Issue: Some implementations expect to receive the "conf" message when issuing certificates, others do not. (This applies to scenarios #1 and #3). RFC 2510 requires the conf message in B.8 and B.9. This is straightforward for network-based protocols where the client and CA have a connection. However, this is more problematic in file or electronic-mail based protocols. Resolution: For these trials, participants agreed to generate the conf message, but some CA implementations will not require it. Note: All participants agreed that the CA should not require a conf message for certificate revocation transactions. Moskowitz 19 CMP Interoperability Testing: Results and Agreements June 1999 6.14 OldCertID Issue: When is oldCertID control used? Perhaps kur only? Resolution: Participants agreed that oldCertID will not be used in these trials. 6.15 Using senderKID and transactionID Issue: When establishing an initial relationship (i.e., scenario #1), the end entity obtains a shared secret and either a distinguished name OR a reference code. The shared secret is associated with the end entity through the name or code. Where the reference code is used, there are two "logical" places to insert it. It might be considered the senderĘs key identifier, and placed in the senderKID. The reference code could also be considered a transactionID established by the RA. Both are compromises of sorts. The former solution overloads the senderKID, requiring different processing in different contexts. (In other contexts, the senderKID would correspond to the subject key identifier in certificates.) A transactionID is still required, as well. The latter solution overloads the transactionID. Resolution: TBD. (Note: RFC 2510 supports using the senderKID for this purpose.) 6.16 SHA-1 HMAC Issue: This is really four related questions: (1) What is the correct MAC algorithm for the password-based MAC? (2) Which one-way function should it be used with? (3) How long should the password be? And (4) What iteration count should we use? Resolution: Use SHA1-HMAC, OID={1.3.6.1.5.5.8.12} as the MAC algorithm for IR-message protection. SHA-1 will be the one-way function. The password and the salt should be at least 20-bytes. The iteration count shall be 1024. 6.16 Passphrase Encoding Issue: Because the passphrase for passphrase-based MAC may be entered through a keyboard, it is necessary to convert the user- provided string into an unambiguous string. The purpose is to handle properly specific language nuances (e.g., accents and tildes in certain languages). The options are either encoding of passphrase as a binary (un-transformed) input to the function or performing a well defined transform on the input text. The former requires that the application be able to unambiguously determine the binary data (which may be difficult in the case of a Moskowitz 20 CMP Interoperability Testing: Results and Agreements June 1999 user selected passphrase). The latter requires the use of a possibly difficult to implement, probably not fully standards compliant transform. Resolution: The passphrase should be encoded as a Unicode input using UNICODE normalization rules (See DRAFT Unicode Technical Report #15: Unicode Normalization Forms, version 14, Normalization Form D - specification from sections 3.6, 3.9, and 3.10 of the Unicode Standard ISBN 0-201-48345-9)and encode as a UTF8 string (without tag or length). 6.17 Reason flags for revocation in revocation requests Issue: The use of a bit mask for reason codes may be inappropriate for all possible reasons and the interpretation of reason bit combinations may be ambiguous and inappropriate. Resolution: The reason codes should be placed in the relevant extension of the crlEntryDetails of RevDetails. 6.18 Use of badSinceDate for revocation in revocation requests Issue: Since the crlEntryDetails of RevDetails is going to be used for the reason flags (see 6.17) and badSinceDate is a different field in RevDetails, an optimization can be done by placing the badSinceDate information into the crlEntryDetails. Resolution: The bad since date of a revoked certificate should be placed in the relevant extension of the crlEntryDetails of RevDetails. 6.19 Certificate requests and key usage Issue: The certificate request messages may be used for requesting different types of certificates and there needs to be away to distinguish the request for different certificate types. Resolution: For each certificate requested in the certificate request message, there should be one key usage extension within the certTemplate. 6.20 Signing of messages with a key different from the certificate signing key Issue: A CA may sign a cp and rp messages using a key other than the key used to sign certificates. In order to support this, the CA/RA needs to pass the message signing certificate to the end entity. Moskowitz 21 CMP Interoperability Testing: Results and Agreements June 1999 Resolution: The CA/RA shall pass the message signing certificate, and if necessary all other certificates in the validation chain, in the extraCerts field of the PKIMessage. These certificates shall appear in starting with the message signing certificate followed by the necessary certificates for the chain in reverse order to the top of the chain. The "root" certificate may be omitted since its assumed to the be CA certificate used to sign certificates. 6.21 Use of TCP/IP as the transport protocol Issue: The use of TCP/IP as the transport protocol is under specified in RFC 2510. For example, the polling protocol is incomplete and ambiguous. Resolution: TBD 6.22 Purpose of publicKeyMac in POPOSigningKeyInput Issue: It is unclear what is the purpose of the publicKeyMac in POPOSigningKeyInput. When should it be checked? What attack(s) does it protect against? Should it always be there or is it used in lieu of other mechanisms. Resolution: TBD 7. Security Considerations In PasswordBasedMac, minimum values for the salt, the iterationCount, and the shared secret are not specified. According to PKCS #5 [PKCS5], the salt should be at least 8 octets long. The iterationCount should be at least 1000, and the salt concatenated with the shared secret should be at least as long as the hash value. For our default of SHA1, this is 20 octets; so for interoperability, the shared secret must be at least 12 octets. Since the CA/RA signs almost all responses, it SHOULD have a response signing certificate for this function, and not use its root certificate (see Interoperability Agreements, 6.n). These response signing certificates can be short-lived and have relatively short keys. 8. IANA Considerations No IANA considerations have emerged. 9. References Moskowitz 22 CMP Interoperability Testing: Results and Agreements June 1999 [FIPS-186], US National Bureau of Standards, "Digital Signature Standard (DSS)", Federal Information Processing Standard (FIPS) Publication 186, May 1994, http://www.itl.nist.gov/div897/pubs/fip186.htm. [FIPS-180-1], NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. http://csrc.nist.gov/fips/fip180-1.txt (ascii) http://csrc.nist.gov/fips/fip180-1.ps (postscript) [PKCS5], RSA Laboratories, "Password-Based Cryptography Standard, version 2.0", RSA Data Security Inc., Redwood City, California, March 1999 Release. [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997 10. Acknowledgments The following companies and people participated in the workshops: Baltimore: Keith Brady Cygnacom: Peter Hesse, Carl Wallace Entrust: Ron Chittaro ICSA: Bob Moskowitz IBM/LOTUS/IRIS: Patricia Booth, Mark C. Davis, Shiu-fun Poon, Mike Shanzer, John Wray NIST: Nelson Hastings, Noel Nazario, Tim Polk XETI: Srinivas Pandrangi, Nick Zhang NIST hosted the first workshop, and IBM the second. The NIST team provided the parsed message contents for this report from messages submitted by the various developers. 11. Author's Addresses Robert Moskowitz ICSA, Inc. 1200 Walnut Bottom Rd. Carlisle, PA 17013 Email: rgm@icsa.net Moskowitz 23