Subject: [secdir] secdir review of draft-ietf-pkix-rfc2560bis

From: "Murphy, Sandra" <[email-masked]>
Date: Tue, 2 Apr 2013 22:12:39 +0000

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
<<picky, picky, picky. I know, I know, this is copied from the old
RFC so it got by the RFCEditor once.>>

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.