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 IESG member
Yes
Yes
(for -15)
Unknown
Stephen Farrell Former IESG member
Yes
Yes
(2013-04-08 for -16)
Unknown
- 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 IESG member
(was Discuss)
Yes
Yes
(2013-04-11 for -17)
Unknown
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 IESG member
No Objection
No Objection
(2013-04-04 for -16)
Unknown
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 IESG member
(was Discuss)
No Objection
No Objection
(2013-04-13 for -19)
Unknown
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 IESG member
No Objection
No Objection
(2013-04-11 for -17)
Unknown
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 IESG member
No Objection
No Objection
(for -16)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -17)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -16)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -17)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -16)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -17)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(2013-04-09 for -16)
Unknown
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 IESG member
No Objection
No Objection
(for -17)
Unknown