I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft is a bis for 2560 and 6277 and updates 5912 as well. Most of the text is adopted wholesale from the obsoleted rfcs. Many of my comments below apply to text that passed muster in the obsoleted RFCs, so take that into consideration. --Sandy sec 1 p 4 In general, I am unsure what it means to say "as specified in rfc6277" when this draft is supposed to obsolete rfc6277. I also found the "as specified in" language to be ambiguous as to whether the referenced work was the original use that this draft changes or the extended/changed use that this draft adopts or copies. o Section 2.2 extends the use of the "revoked" response to allow this response status certificates that has never been issued. That second line is missing something, perhaps "response status to refer to certificates that have never". o Section 4.2.1 and 4.2.2.3 states that a response may include state revocation status information for certificates that were not included in the request I could find no reference in 4.2.1 to including info on un-requested certificates. o Section 4.2.2.3 clarify that the ResponderID field corresponds clarifies o Section 4.3 changes set of cryptographic algorithms that ^the clients must support and the set of cryptographic algorithms that clients should support as specified in [RFC6277]. Section 4.3 is NOT as specified in RFC6277. It updates what RFC6277 mandates. o Section 4.4.7 specifies a new extension that may be included in a request message to specify signature algorithms the client would prefer the server use to sign the response as specified in [RFC6277]. This use of "as specified" was particularly unclear. I think it means o Section 4.4.7 specifies a new extension, originally specified in RFC6277, that may be included in o Section B.2 provides an ASN.1 module using the 2008 syntax of ASN.1 which updates [RFC5912] Sounds like the 2008 syntax updates RFC5912. "Section B.2, which updates rfc5912, provides"? sec 2.1 p 6 An OCSP request contains the following data: -- protocol version -- service request -- target certificate identifier -- optional extensions which MAY be processed by the OCSP Responder There is no separate "service request" field in the request - the cert id and the extensions are the service request. Maybe they are intended to be indented to show structure? I.e., -- protocol version -- service request +++ target certificate identifier +++ optional extensions which MAY be processed by the OCSP Responder Upon receipt of a request, an OCSP Responder determines if; 1. the message is well formed, 2. the responder is configured to provide the requested service, and; There is no hint later that there might be multiple oscp services that a responder might be providing, so not sure what this means. sec 2.1-2.2, p 6 If any one of these conditions are not met, the OCSP responder produces an error message; otherwise, it returns a definitive response. 2.2 Response OCSP responses can be of various types. An OCSP response consists of a response type and the bytes of the actual response. There is one basic type of OCSP response that MUST be supported by all OCSP servers and clients. The rest of this section pertains only to this After some reading, I decided that the "definitive response" and the "basic type of OCSP response" are the same thing, and it is (they are) distinct from error messages. If so, then section 2.2's title really should be "Definitive Response" or "Basic Response". sec 2.2 p 7 The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued ... The "revoked" state indicates ... This state MAY also be returned if the associated CA has no record of ever having issued a certificate with the certificate serial number in the request, ... The "unknown" state indicates that the responder doesn't know about the certificate being requested. If I read this right, a request for a non-issued cert might produce any status - good, revoked, or unknown. There is a lot of discussion of provisions for responding with "revoked" for a non-issued certificate and some additional detail that might give the client a clue that "revoked" meant "non-issued". But a response of "good" and "unknown" are IMPLICIT NULL - so there is no way to provide any such clue. Am I reading the intent (and the ASN.1) right? sec 2.2 p 8 the SingleResponse related to this non-issued certificate; SingleResponse is not defined yet and will not be until p 14. sec 2.3, p 9 The response "sigRequired" is returned in cases where the server requires the client sign the request in order to construct a "requires that the client sign" or "requires the client to sign" sec 2.4 p 9 Responses can contain three times in them - thisUpdate, nextUpdate and producedAt. I was not sure what "can contain" meant - any of the three? a choice of just one of the three? etc. According to sec 4.2.1, p 14, the thisUpdate and producedAt are required, nextUpdate is optional. This statement could be clearer. sec 2.5 p 10 field of the response. The time at or before which newer information will be available is reflected in the nextUpdate field, might be MAY be unless you are saying that in pre-production the nextUpdate field is not optional. sec 2.6 p 10 A certificate's issuer explicitly delegates OCSP signing authority by issuing a certificate containing a unique value for extendedKeyUsage I wondered whether this meant any unique value would do or a specific unique well-known value. section 4.2.2.2.2 p15 says it is a well-known unique value. It would be great to clear up this text to make that clear (e.g., a reference to 4.2.2.2). sec 3.1 p 10 In order to convey to OCSP clients a well-known point of information access, CAs SHALL provide the capability to include the AuthorityInfoAccess extension (defined in [RFC5280], section 4.2.2.1) Is it sufficient to "provide the capability to include"? Then who (and why and when) makes use of that capability? I.e., who actually includes the capability? I think maybe this means "CAs SHALL include the AuthorityInfoAccess extension". in certificates that can be checked using OCSP. Some certificate a CA issues can be checked using OCSP and some can not? CAs that support an OCSP service, either hosted locally or provided by an Authorized Responder, MUST provide for the inclusion of a value for a uniformResourceIndicator (URI) [RFC3986] accessLocation and the OID value id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE. Is it OK to just "provide for the inclusion of a value" but never actually include the value? I.e., does this actually mean a responder MUST include a (value for a) URI accessLocator with/and an accessMethod with the value ... I'm not sure what the intent is here, much less the proper way to talk about ASN.1 structures. sec 3.2 p 11 1. The certificate identified in a received response corresponds to that which was identified in the corresponding request; I was never sure how a response was mapped to a request. The transport mechanisms mentioned aren't always connection oriented. p 18 says that a repsonse must include status for every cert in the request, so it is important to be able to map response to request. Is this a stop-and-wait protocol so the client never has more than one outstanding request? 3. The identity of the signer matches the intended recipient of the request. Sec 4.4.6 says that it is possible for the client to send a request to one server and have the request forwarded to another. And there's the possibility of getting a response from an Authorized Responder rather than the CA for the certificate. So who is the "intended recipient"? sec 4.1.1 p 12 issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING, -- Hash of Issuers public key Issuer's <> sec 4.2.1 p 13 An OCSP response at a minimum consists of a responseStatus field indicating the processing status of the prior request. "*the* prior request" - further evidence that this is a stop-and-wait protocol? If the value of responseStatus is one of the error conditions, responseBytes are not set. MUST NOT be set? For a basic OCSP responder, responseType will be id-pkix-ocsp-basic. response? If I read this right, a basic (aka definitive) response means the status is "successful". So if the status is "successful", is it that the responseType *MUST* be id-pkix-ocsp-basic? sec 4.2.1 p 14 The value for signature SHALL be computed on the hash of the DER encoding ResponseData. ^of CertStatus ::= CHOICE { good [0] IMPLICIT NULL, revoked [1] IMPLICIT RevokedInfo, unknown [2] IMPLICIT UnknownInfo } ... UnknownInfo ::= NULL So there is no way for a status of "good" or "unkown" to indicate that the certificate was never actually issued. sec 4.2.2.1 p 15 The thisUpdate and nextUpdate fields define a recommended validity interval. This interval corresponds to the {thisUpdate, nextUpdate} interval in CRLs. Responses whose nextUpdate value is earlier than the local system time value SHOULD be considered unreliable. Responses whose thisUpdate time is later than the local system time SHOULD be considered unreliable. What about the relationship between producedAt and {thisUpdate, nextUpdate}? I would think that thisUpdate <= producedAt <= nextUpdate, but is it an error if it is not? What about the relationship of producedAt to the local time? sec 4.2.2.2 p 15-16 The CA SHOULD use the same issuing key to issue a delegation certificate as was used to sign the certificate being checked for revocation. ... clients are not required to recognize a responder with such certificate as an authorized responder. If I read this right, clients must map an authorized responder's delegation certificate to a CA only if the CA uses the same key to issue its certs and the authorized responder's delegation certificate, but the clients are permitted to ignore a mismatch and accept the authorized responder anyway. (So if the clients might accept anyway, why require that they check?) only if the delegation certificate and the certificate being checked for revocation was signed by the same key. were sec 4.2.2.2 p 16 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage extension and is issued by the CA that issued the certificate in question as stated above." ^ (don't think this is a quote) sec 4.2.2.2 p 17 revocation. This can be done using CRL Distribution Points if the check should be done using CRLs or CRL Distribution Points, ^^^^^^^^^^^^^^^^^^^^^^^^^^ I don't understand this - use CRL Distr Points if the check should use CRL Distr Points? I wonder if that "or DRL Distribution Points" part is supposed to be there. sec 4.2.2.3 p 17 find the certificate used to sign a signed OCSP response. Therefor, Therefore, The purpose of the ResponderID information is to allow clients to find the certificate used to sign a signed OCSP response. Therefor, the information MUST correspond to the certificate that was used to sign the response. There are those in the pkix community who object to this sort of expression that a cert is used to sign anything, and insist that language instead say the cert is used to validate signatures. (I wonder how this paragraph got past such people.) That is "find the certificate to be used (that could be used) to validate the signature on a signed OCSP response" and "MUST correspond to the certificate that could (should) be used to validate the signature on the signed response". sec 4.2.2.3 p 18 The response MUST include a SingleResponse for each certificate in the request and SHOULD NOT include any additional SingleResponse elements. More about associating request and response. May a response include SingleResponses for certs mentioned in more than one request, as long as it includes a response for all the certs in each request? sec 4.4.1 p 18 The nonce cryptographically binds a request and a response to prevent replay attacks. The nonce is included as one of the requestExtensions in requests, while in responses it would be included as one of the responseExtensions. MUST the nonce be included in a response if it is included in the request? (See previous comments about associating response with request). Is the response invalid if it includes a nonce but the request did not include a nonce? sec 4.4.3 An OCSP client MAY wish to specify the kinds of response types it understands. There is only one response type defined right now, right? Is this included just in case other response types are eventually supported? sec 4.4.6 p 20 ServiceLocator ::= SEQUENCE { issuer Name, locator AuthorityInfoAccessSyntax OPTIONAL } Appendix B p 33 does not say OPTIONAL sec 4.4.7 p 20 it's algorithm preferences, there is always a risk that a server its ^ (no comma) sec 4.4.7 p 21 o Rules for signature algorithm selection that maximizes the maximize sec 4.4.7.1 p 22 PreferredSignatureAlgorithm ::= SEQUENCE { sigIdentifier AlgorithmIdentifier, pubKeyAlgIdentifier SMIMECapability OPTIONAL } This agrees with 6277 but does not agree with Appendix B p 33, which says PreferredSignatureAlgorithm ::= SEQUENCE { sigIdentifier AlgorithmIdentifier, certIdentifier AlgorithmIdentifier OPTIONAL } sec 4.4.7.1 p 22 The syntax of AlgorithmIdentifier is defined in section 4.1.1.2 of RFC 5280 [RFC5280] The syntax of SMIMECapability is defined in RFC . (missing period) 5751 [RFC5751] . (missing period) sec 4.4.7.2 p 22-23 4.4.7.2 Responder Signature Algorithm Selection RFC 2560 [RFC2560] did not specify a mechanism for deciding the signature algorithm ... by selecting a supported signature algorithm using the following ... 1. Select an algorithm specified as a preferred signing algorithm in ... 2. Select the signing algorithm ... 3. Select the signing algorithm ... 4. Select a signature algorithm ... 5. Select a mandatory or recommended signing algorithm Consistency being the hobgoblin of little minds, I wonder if there's a need for consistent use of "signature algorithm" and "signing algorithm". (Once I noticed this, I saw it lots of other places.) 5. Select a mandatory or recommended signing algorithm specified for the version of the OCSP protocol in use A responder SHOULD always apply the lowest numbered selection mechanism that results in the selection of a known and supported algorithm that meets the responder's criteria for cryptographic algorithm strength. Suppose an algorithm is mandatory to *use*? sec 5 p 25 Unsigned error responses open up the protocol to another denial of service attack, where the attacker sends false error responses. I did wonder about this when I saw that error responses need not be signed. I would expect that the security considerations section would include recommendations of appropriate ways to mitigate the threat of false error responese. You can rate limit floods of queries (or floods of responses from spoofed queries) but this DoS takes just one response. The use of precomputed responses allows replay attacks in which an old (good) response is replayed prior to its expiration date but after the certificate has been revoked. Does "its expiration date" refer to the expiration of the cert in the request or the expiration of the response (i.e, current time is past the nextUpdate time) Requests do not contain the responder they are directed to. This allows an attacker to replay a request to any number of OCSP responders. The risk being an amplification attack where the client receives a flood of responses? The reliance of HTTP caching in some deployment scenarios may result on? (caching doesn't do any relying, does it) in unexpected results if intermediate servers are incorrectly configured or are known to possess cache management faults. Implementors are advised to take the reliability of HTTP cache mechanisms into account when deploying OCSP over HTTP. ^^^^^^^^^ I don't think implementers are the ones doing deploying, so I suspect this should say "implementing". Responding with a "revoked" state to certificate that has never been status to a 5.1 Preferred Signature Algorithms The mechanism used to choose the response signing algorithm MUST be See previous comments about consistency of terms. sec 5.1.1 p 26 Such a certificate might employ a signing method that is no longer considered acceptably secure. In such circumstances the responder MUST NOT generate a signature using a signing mechanism that is not considered acceptably secure. Do "signing method" or "signing mechanism" mean the same thing as signing/signature algorithm, or do method/mechanism imply something distinct from algorithm? sec 5.1.3 p 27 Algorithm agility mechanisms defined in this document introduces a introduce sec 7 p 28-29 7.1. Normative References ... [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. ... 7.2. Informative References ... [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. I don't think rfc2616 can be in both sections. 7.1. Normative References ... [RFC6277] Santesson, S. and P. Hallam-Baker, "Online Certificate Status Protocol Algorithm Agility", RFC 6277, June 2011. ... 7.2. Informative References [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999. This draft obsoletes both rfc6277 and rfc2560. Why is rfc2560 considered informative but rfc6277 is considered normative? App B p 33 ServiceLocator ::= SEQUENCE { issuer Name, locator AuthorityInfoAccessSyntax } This does not agree with sec 4.4.6 p 20. PreferredSignatureAlgorithm ::= SEQUENCE { sigIdentifier AlgorithmIdentifier, certIdentifier AlgorithmIdentifier OPTIONAL } This does not agree with sec 4.4.7.1 p 22. App C p 40 Published specification: IETF PKIX Working Group Draft on Online Certificate Status Protocol - OCSP ... Published specification: IETF PKIX Working Group Draft on Online Certificate Status Protocol - OCSP I don't quite know the reason why this mentions the wg draft rather than the published rfc - will the eventual registration point to the new published RFC? The requirements for media type registration (RFC4288) say that a standards track RFC is required.