The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments
draft-ietf-pkix-lightweight-ocsp-profile-11

[Ballot comment]
This may be subject to some of the issues in RFC 3143.  I suspect the
Vary header should not be used, for example.

I'd also like to see an anaylsis of the impact of HTTP Request Smugging
in the security considerations section as this profile suggests
aggressive caching and use of proxies.

I do think this profile would be improved by applying BCP 56 (at the very
least assigning a port other than port 80), but I'm willing to just
abstain if that isn't fixed.

[Ballot discuss]
Some of the example HTTP headers in section 4 are not valid headers --
they use "=" instead of ":".  Also, HTTP does not use the
"Content-Transfer-Encoding" header (RFC 2616 section 19.4.5) so that
should be removed.

This may be subject to some of the issues in RFC 3143.  I suspect the
Vary header should not be used, for example.

I'd also like to see an anaylsis of the impact of HTTP Request Smugging
in the security considerations section as this profile suggests
aggressive caching and use of proxies.

I do think this profile would be improved by applying BCP 56 (at the very
least assigning a port other than port 80), but I'm willing to just
abstain if that isn't fixed.

[Ballot discuss]
Some of the example HTTP headers in section 4 are not valid headers --
they use "=" instead of ":".  Also, HTTP does not use the
"Content-Transfer-Encoding" header (RFC 2616 section 19.4.5) so that
should be removed.

This may be subject to some of the issues in RFC 3143.  I suspect the
Vary header should not be used, for example.

I'd also like to see an anaylsis of the impact of HTTP Request Smugging
in the security considerations section as this profile suggests
aggressive caching and use of proxies.

I do think this profile would be improved by applying BCP 56 (at the very
least assigning a port other than port 80), but I'm willing to just
abstain if that isn't fixed.

[Ballot discuss]
Some of the example HTTP headers in section 4 are not valid headers --
they use "=" instead of ":".  Also, HTTP does not use the
"Content-Transfer-Encoding" header (RFC 2616 section 19.4.5) so that
should be removed.

This may be subject to some of the issues in RFC 3143.  I suspect the
Vary header should not be used, for example.

I'd also like to see an anaylsis of the impact of HTTP Request Smugging
in the security considerations section as this profile suggests
aggressive caching and use of proxies.

A lot of hotels (and similar access points) have HTTP interception
proxies running on port 80.  Often those proxies require use of https
to initially pay the bill with certificates that a client might wish
to check.  As this is running on port 80 as well, there would seem to be
a bootstrap problem that might not be present if a much more restricted
protocol was used on a different port.  I suppose this problem is also
true for OCSP, so I won't insist this be addressed.

I do think this profile would be improved by applying BCP 56 (at the very
least assigning a port other than port 80), but I'm willing to just
abstain if that isn't fixed.

[Ballot discuss]
Some of the example HTTP headers in section 4 are not valid headers --
they use "=" instead of ":".  Also, HTTP does not use the
"Content-Transfer-Encoding" header (RFC 2616 section 19.4.5) so that
should be removed.

This may be subject to some of the issues in RFC 3143.  I suspect the
Vary header should not be used, for example.

I'd also like to see an anaylsis of the impact of HTTP Request Smugging
in the security considerations section as this profile suggests
aggressive caching and use of proxies.

A lot of hotels (and similar access points) have HTTP interception
proxies running on port 80.  Often those proxies require use of https
to initially pay the bill with certificates that a client might wish
to check.  As this is running on port 80 as well, there would seem to be
a bootstrap problem that might not be present if a much more restricted
protocol was used on a different port.  That may have security
implications as well.

I do think this profile would be improved by applying BCP 56 (at the very
least assigning a port other than port 80), but I'm willing to just
abstain if that isn't fixed.

[Ballot discuss]
Some of the example HTTP headers in section 4 are not valid headers --
they use "=" instead of ":".  Also, HTTP does not use the
"Content-Transfer-Encoding" header (RFC 2616 section 19.4.5) so that
should be removed.  Please add an RFC editor note to fix this.

This may be subject to some of the issues in RFC 3143.  I suspect the
Vary header should not be used, for example.

I'd also like to see an anaylsis of the impact of HTTP Request Smugging
in the security considerations section as this profile suggests
aggressive caching and use of proxies.

A lot of hotels (and similar access points) have HTTP interception
proxies running on port 80.  Often those proxies require use of https
to initially pay the bill with certificates that a client might wish
to check.  As this is running on port 80 as well, there would seem to be
a bootstrap problem that might not be present if a much more restricted
protocol was used on a different port.  That may have security
implications as well.

I do think this profile would be improved by applying BCP 56 (at the very
least assigning a port other than port 80), but I'm willing to just
abstain if that isn't fixed.

[Ballot discuss]
Some of the example HTTP headers in section 4 are not valid headers --
they use "=" instead of ":".  Also, HTTP does not use the
"Content-Transfer-Encoding" header (RFC 2616 section 19.4.5) so that
should be removed.  Please add an RFC editor note to fix this.

This may be subject to some of the issues in RFC 3143.  I suspect the
Vary header should not be used, for example.

I'd also like to see an anaylsis of the impact of HTTP Request Smugging
in the security considerations section as this profile suggests
aggressive caching and use of proxies.

I do think this profile would be improved by applying BCP 56 (at the very
least assigning a port other than port 80), but I'm willing to just
abstain if that isn't fixed.

[Ballot discuss]
Some of the example HTTP headers in section 4 are not valid headers -- they use "=" instead of ":".  Also, HTTP does not use the "Content-Transfer-Encoding" header (RFC 2616 section 19.4.5) so that should be removed.  Please add an RFC editor note to fix this.

This may be subject to some of the issues in RFC 3143.  I suspect the
Vary header should not be used, for example.

I'd also like to see an anaylsis of the impact of HTTP Request Smugging in the security considerations section as this profile suggests aggressive caching and use of proxies.  This should probably lead to specific advice about the strictness of the HTTP parsers on the server and how HTTP persistent connections are used when error conditions occur.

I do think this profile would be improved by applying BCP 56 (at the very least assigning a port other than port 80), but I'm willing to just abstain if that isn't fixed.

[Ballot discuss]
Some of the example HTTP headers in section 4 are not valid headers -- they use "=" instead of ":".  Also, HTTP does not use the "Content-Transfer-Encoding" header (RFC 2616 section 19.4.5) so that should be removed.  Please add an RFC editor note to fix this.

I'd also like to see an anaylsis of the impact of HTTP Request Smugging in the security considerations section as this profile suggests aggressive caching and use of proxies.  This should probably lead to specific advice about the strictness of the HTTP parsers on the server and how HTTP persistent connections are used when error conditions occur.

I do think this profile would be improved by applying BCP 56 (at the very least assigning a port other than port 80), but I'm willing to just abstain if that isn't fixed.

[Ballot discuss]
Some of the example HTTP headers in section 4 are not valid headers -- they use "=" instead of ":".  Please add an RFC editor note to fix this.

I'd also like to see an anaylsis of the impact of HTTP Request Smugging in the security considerations section as this profile suggests aggressive caching and use of proxies.  This should probably lead to specific advice about the strictness of the HTTP parsers on the server and how HTTP persistent connections are used when error conditions occur.

I do think this profile would be improved by applying BCP 56 (at the very least assigning a port other than port 80), but I'm willing to just abstain if that isn't fixed.

[Ballot discuss]
Assume that the relying party has a certification path to validate, and
two of the certificates in the path contain AIA extensions that point to
the same OCSP Responder.

The relying party generates an OCSP request, including both of the
certificates.  RFC 2560 allows one or more certificate to be named in
the OCSP Request (SEQUENCE OF Request), and I could not find any text to
indicate that support for more than one element in this sequence is not
mandatory.

The OCSP Responder generates an OCSP response for both of the
certificates (SEQUENCE OF SingleResponse).  This response is covered
by one signature.

So, there are three cases to consider:

(1) OCSP Responder with a signature key - there is not a concern here.
    The OCSP Responder builds the response and signs it.

(2) OCSP Responder that can relay to a server with a signature key - there
    is not a concern here.  The OCSP Responder forwards the request to
    the server with a signature key, the server builds the response and
    signs it, and then the signed response is sent back to the original
    responder.

(3) OCSP Responder with a bunch of cached responses - there is a concern
    here.  The responder cannot respond to the multi-certificate request
    unless responses for every possible combination of requested
    certificates is computed and cached.  This would be computationally
    prohibitive for a certificate population of any significant size.

I see two ways forward: RFC 2560bis, or include a very small update to
RFC 2560 in this document to explain the possible meanings of the error
codes.

[Ballot discuss]
Assume that the relying party has a certification path to validate, and two of the certificates in the path contain AIA extensions that point to the same OCSP Responder.

The relying party generates an OCSP request, including both of the certificates.  RFC 2560 allows one or more certificate to be named in the OCSP Request (SEQUENCE OF Request), and I could not find any text to indicate that support for more than one element in this sequence is not mandatory.

The OCSP Responder generates an OCSP response for both of the certificates (SEQUENCE OF SingleResponse).  This response is covered by one signature.

So, there are three cases to consider:

(1) OCSP Responder with a signature key - there is not a concern here.  The OCSP Responder builds the response and signs it.

(2) OCSP Responder that can relay to a server with a signature key - there is not a concern here.  The OCSP Responder forwards the request to the server with a signature key, the server builds the response and signs it, and then the signed response is sent back to the original responder.

(3) OCSP Responder with a bunch of cached responses - there is a concern here.  The responder cannot respond to the multi-certificate request unless responses for every possible combination of requested certificates is computed and cached.  This would be computationally prohibitive for a certificate population of any significant size.

I see two ways forward: RFC 2560bis, or include a very small update to
RFC 2560 in this document to explain the possible meanings of the error
codes.

[Ballot discuss]
Assume that the relying party has a certification path to validate, and two of the certificates in the path contain AIA extensions that point to the same OCSP Responder.

The relying party generates an OCSP request, including both of the certificates.  RFC 2560 allows one or more certificate to be named in the OCSP Request (SEQUENCE OF Request), and I could not find any text to indicate that support for more than one element in this sequence is not mandatory.

The OCSP Responder generates an OCSP response for both of the certificates (SEQUENCE OF SingleResponse).  This response is covered by one signature.

So, there are three cases to consider:

(1) OCSP Responder with a signature key - there is not a concern here.  The OCSP Responder builds the response and signs it.

(2) OCSP Responder that can relay to a server with a signature key - there is not a concern here.  The OCSP Responder forwards the request to the server with a signature key, the server builds the response and signs it, and then the signed response is sent back to the original responder.

(3) OCSP Responder with a bunch of cached responses - there is a concern here.  The responder cannot respond to the multi-certificate request unless responses for every possible combination of requested certificates is computed and cached.  This would be computationally prohibitive for a certificate population of any significant size.

The only way forward that I see is RFC 2560bis.

[Ballot discuss]
>  It is intended that the normative requirements defined in this
>  profile will be adopted by OCSP clients and OCSP responders
>  operating in very large scale (high volume) PKI environments or PKI
>  environments that require a lightweight solution to minimize
>  bandwidth and client side processing power (or both), as described
>  above.  As OCSP does not have the means to signal responder
>  capabilities within the protocol, clients need to rely on out of
>  band mechanisms to determine when a responder operates according to
>  this profile and, as such, when the requirements of this profile
>  apply.  In the case where an out of band mechanisms may not be
>  available, this profile ensures that interoperability will still
>  occur between a fully conformant OCSP 2560 client and a responder
>  that is operating in a mode as described in this specification.

First, I'm nervous about the spec claiming to make normative
requirements when it is being published off the standards track.
However my primary concern at this point is that I don't see how the claim of the last sentence is actually guaranteed.  For example  what happens when a client includes multiple certificates in a request?  Will this actually work?


Perhaps one way forward is to note that servers cannot assume that
clients will follow the MUSTS of this profile.  They can only assume
the behavior of 2560.

[Ballot comment]
Comments received by Frank Kastenholz from the Ops Directorate:

as this is a profile ('how to make it work') document, i'd make
the same points that i made for draft-ietf-pki4ipsec-ikecert-profile-10.txt.

one added question, section 1.1.1 of the document
says that clients must use SHA1 to authenticate some data.
Is it wise to mandate a crypto algorithm in this manner?
given the history that shows that crypto-algorithms
eventually weaken and then succumb to attacks of various forms,
so won't sha1 also succumb?

i don't know how to solve this problem; perhaps
there should be an ietf-web-page someplace
that shows the status of algorithms?xo

[Ballot discuss]
I share some of Sam's concerns that this document appears to be making normative requirements that affect OCSP itself.  My own reading is that this text from the Introduction is the core of the issue:

  As OCSP does not have the means to signal responder
  capabilities within the protocol, clients need to rely on out of
  band mechanisms to determine when a responder operates according to
  this profile and, as such, when the requirements of this profile
  apply.

I assume from this that every server and every client using this profile must, in fact, be a full-fledged OCSP responder or client, as they will have no way to determine in-band whether this profile is in use or not.  If this not correct, then an applicability statement that describes when a restricted client or server may be deployed is in order.

It's not entirely clear how much this behavior relies on both parties following the profile.  In 1.1.2, the statement that a server MAY ignore a signature indicates, for example, that it may optimize its response processing in this way without regards to the client's wishes--as the client's inclusion of the signature is a moderately strong signal that it is not following the profile.  If there are any cases where the client or server's failure to follow this spec should trigger a failover to default OCSP behavior, then it would probably be better to flag those; as it stands, it appears that each item in the profile is an incremental benefit in lightening the weight of OCSP and will not damage things if deployed alone.  If that is *not* the case, clarifying text is needed.

In section 1.2.4, the documents says:

    For the purposes of this profile, GeneralizedTime values such as
  thisUpdate, nextUpdate and producedAt MUST be expressed Greenwich
  Mean Time (Zulu) and MUST include seconds (i.e.,times are
  YYYYMMDDHHMMSSZ), even where the number of seconds is zero.

The inclusion of the parenthetical time YYYMMDDHHMMSSZ is confusing, as it does not
match either the examples or the HTTP date specified in Section 3.3 of RFC 2616.

In section 4, the document says:

  The OCSP responder MUST support requests and responses over HTTP. 
  When sending requests that are smaller than 255 bytes in total
  (after encoding) including the method (http://)

That's not an HTTP Method, it is a URI scheme (http) and delimiters, used to introduce
an authority section.  "including the scheme and delimiters (http://)" would be appropriate.

The length limit of 255 seems to run contrary to HTTP's design; why is not appropriate
to follow the advice of Section 3.2.1 of RFC 2616:

The HTTP protocol does not place any a priori limit on the length of a
URI. Servers MUST be able to handle the URI of any resource they serve,
and SHOULD be able to handle URIs of unbounded length if they provide
GET-based forms that could generate such URIs. A server SHOULD return
414 (Request-URI Too Long) status if a URI is longer than the server can
handle (see section 10.4.15).

The older client implementations NOTED below in 3.2.1 don't seem to be a likely issue
for anything capable of running this as profile; is the concern proxies?  Is
there any evidence of this as a problem in this environment?  Would allowing
Pragma: No-cache (an HTTP 1.0 directive) but not Cache-Control directives
help eliminate the proxy problem?

Section 2.2 appears to set behavior for when OCSP is invoked, rather than profile
how OCSP is used.  This does not seem to be actionable with the RFC 2119 language
used.  This seems to be more "good practice is to check what you can check locally
before bothering the network/server".  Am I misunderstanding the intent here?

In Section 5.3, the document says:

  This functionality has been specified as an extension to the TLS
  [TLS] protocol in Section 3.6 [TLSEXT], but can be applied to any
  client-server protocol.

It is not clear to me whether this is meant to apply on to aps running over TLS or
any client server application.

[Ballot discuss]
It's very confusing when an IETF working group publishes informational
documents with a lot of normative requirements--particular documents
that are related to existing protocols.  This document clearly can be
published as a proposed standard if there is sufficient consensus: it
has testable requirements and specifies protocol behavior.  I think
this document should be moved to the standards track if there is
sufficient consensus.  If there is not consensus to publish on the
standards track then we should add some text to the draft explaining
its relation to the OCSP protocol spec and explaining what
reservations prevented us from publishing on the standards track.  We
would definitely need a statement saying that while the requirements
of this profile are believed to be compatible with OCSP, the OCSP spec
is definitive in case of conflict.

I'm particularly concerned about two issues which seem to skirt the
boundary of normative changes to OCSP itself.  First, the handling of
nonces seems to be close to normative.  I could not find a direct
conflict with the OCSP spec because it says so little about nonces.
The requirement that servers need not check client signatures
definitely seems like a normative change.  While the validation of
client requests is not covered in great depth, the strong common sense
presumption is that client authentication should be verified when
present.  I have no problem with these if this document is on the
standards track but am uncomfortable especially with the lack of
signature checking as an informational document.

A revised I-D is needed to address the Last Call comments.  The authors have been very responsive, so I expect the revised I-D to be posted soon.