Internet DRAFT - draft-ietf-moskowitz-cmpinterop
draft-ietf-moskowitz-cmpinterop
R. Moskowitz, ICSA, Inc.
Internet Draft
Document: <draft-ietf-moskowitz-cmpinterop-00.txt> 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
