Skip to main content

X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
draft-ietf-pkix-rfc2560bis-20

Yes

(Sean Turner)

No Objection

(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Stewart Bryant)

Note: This ballot was opened for revision 15 and is now closed.

(Sean Turner; former steering group member) Yes

Yes (for -15)

                            

(Stephen Farrell; former steering group member) Yes

Yes (2013-04-08 for -16)
- Forgot to say: please consider the nits identified in the 
secdir review. [1]

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03874.html

- Do we or the RFC editor have a policy on deceased authors? I
can see why folks might leave a name on, but it doesn't really
seem correct to me. Adding an ack that does or doesn't make it
clear that that person is no longer with us would be better.

- 3.1, it'd be good if more guideance could be given about the
forms of URI the need to be supported, presumably http at
least? The same could be said for other fields, where we have
information about what implementations currently do. However,
since the wpkops WG are planning to document that, I can buy
the argument that its better to not delay this for that
additional detail.

- 4.2.2.1, why did the producedAt sentence here from 2560 get
deleted? I think this is to be fixed in a -17, right?

- 4.3, I'm surprised DSA/SHA-1 is still a SHOULD. Does anyone
actually use it?

(Ted Lemon; former steering group member) (was Discuss) Yes

Yes (2013-04-11 for -17)
Stefan has proposed the following change in 4.4.8, which addresses the point raised about that section in my earlier DISCUSS:

  "If this extension is absent, the responder MUST NOT respond "revoked" to 
   a status request for a non-issued certificate."

(Adrian Farrel; former steering group member) No Objection

No Objection (2013-04-04 for -16)
I have no objeciton to the publication of this document, and only two
minor points which you can take or leave as you see fit.

---

In Section 1... 
   Additional
   mechanisms addressing PKIX operational requirements are specified in
   separate documents.
When RFC 2560 was written, you could probably get away with this. Now
those document probably exist so it would be good to include citations.

---

I should have liked to see a summary of the configuration/management 
aspects of the protocol. There are a number of configurable values that
could be called out into one section for convenience, but more important
is to discuss how OCSP is managed and operated.

(Barry Leiba; former steering group member) (was Discuss) No Objection

No Objection (2013-04-13 for -19)
In a conversation about my former discuss position, Stefan said this:

> Current clients are stateless functions of a certificate validation
> process that typically are supposed to return one of three states to the
> upper application, and the forget about the request.
> The typical states returned to the validation application is:
>
> 1) This is a bad cert. Reject it.
> 2) This cert is not revoked. Continue to process this cert.
> 3) Revocation status could not be determined. Find some other means to
> verify revocation status or reject the certificate.
>
> I just simply do not understand what interest the client has in whether
> the cert was indicated as revoked becuse it indeed was revoked, or because
> it was never issued.

Ha!  This has now made a lot of things clearer to me, and thanks for that.  So, two things coming from this:

First, on the explanatory note:

   NOTE: The "revoked" state for known non-issued certificate serial
         numbers is allowed in order to reduce the risk of relying
         parties using CRLs as a fall back mechanism, which would be
         considerably higher if an "unknown" response was returned.

I get, here, that it's not so much "reduce the risk" (which I took to be based on some sort of attack, or malfeasant client), but "reduce the necessity".  Maybe a change such as this would say it better?:

NEW
   NOTE: The "revoked" state for known non-issued certificate serial
         numbers is allowed in order to reduce the number of situations
         when relying parties are likely to use CRLs as a fall back
         mechanism, which would be considerably higher if an
         "unknown" response was returned.
END

(Or perhaps "will need to use" instead of "are likely to use"?)

Second, the explanation quoted above was helpful to me to put the whole purpose of OCSP in perspective.  Would it make sense to capture that briefly in Section 2?

(Benoît Claise; former steering group member) No Objection

No Objection (2013-04-11 for -17)
I won't comment on the security-related aspects: I'll trust the security experts.
Let me, however, copy here Adrian's feedback, which makes a lot of sense:

  I should have liked to see a summary of the configuration/management
  aspects of the protocol. There are a number of configurable values 
  that could be called out into one section for convenience, but 
  more important is to discuss how OCSP is managed
  and operated.

Maybe it's addressed already in one of the numerous pkix RFCs. I browsed throuhg http://datatracker.ietf.org/wg/pkix/, but it was not obvious to me.

(Brian Haberman; former steering group member) No Objection

No Objection (for -16)

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection (for -17)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -16)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -17)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -16)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (for -17)

                            

(Richard Barnes; former steering group member) No Objection

No Objection (2013-04-09 for -16)
Thanks for making the document easy to diff against RFC 2560 :)

These changes look reasonable, and the explanation in the introduction makes it clear why they were needed.

(Stewart Bryant; former steering group member) No Objection

No Objection (for -17)