X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
RFC 6960
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2020-01-21
|
20 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
|
2019-05-24
|
20 | (System) | Received changes through RFC Editor sync (added Errata tag) |
|
2015-10-14
|
20 | (System) | Notify list changed from pkix-chairs@ietf.org, draft-ietf-pkix-rfc2560bis@ietf.org to (None) |
|
2013-06-06
|
20 | (System) | RFC published |
|
2013-06-03
|
20 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc6960">AUTH48-DONE</a> from AUTH48 |
|
2013-05-20
|
20 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc6960">AUTH48</a> from RFC-EDITOR |
|
2013-05-09
|
20 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
|
2013-04-30
|
20 | (System) | RFC Editor state changed to AUTH from EDIT |
|
2013-04-16
|
20 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2013-04-15
|
20 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
|
2013-04-15
|
20 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
|
2013-04-15
|
20 | (System) | RFC Editor state changed to EDIT |
|
2013-04-15
|
20 | (System) | Announcement was received by RFC Editor |
|
2013-04-15
|
20 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2013-04-15
|
20 | (System) | IANA Action state changed to In Progress |
|
2013-04-15
|
20 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
|
2013-04-15
|
20 | Amy Vezza | IESG has approved the document |
|
2013-04-15
|
20 | Amy Vezza | Closed "Approve" ballot |
|
2013-04-15
|
20 | Amy Vezza | Ballot approval text was generated |
|
2013-04-15
|
20 | Amy Vezza | Ballot writeup was changed |
|
2013-04-15
|
20 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
|
2013-04-15
|
20 | Stefan Santesson | New version available: draft-ietf-pkix-rfc2560bis-20.txt |
|
2013-04-13
|
19 | Barry Leiba | [Ballot comment] In a conversation about my former discuss position, Stefan said this: > Current clients are stateless functions of a certificate validation > process … [Ballot comment] 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? |
|
2013-04-13
|
19 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
|
2013-04-13
|
19 | Stefan Santesson | New version available: draft-ietf-pkix-rfc2560bis-19.txt |
|
2013-04-11
|
18 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2013-04-11
|
18 | Stefan Santesson | New version available: draft-ietf-pkix-rfc2560bis-18.txt |
|
2013-04-11
|
17 | Cindy Morgan | State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
|
2013-04-11
|
17 | Ted Lemon | [Ballot Position Update] Position for Ted Lemon has been changed to Yes from Discuss |
|
2013-04-11
|
17 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
|
2013-04-11
|
17 | Ted Lemon | [Ballot discuss] Section 5.1.2 contradicts section 5.1.1, in the sense that following the line of reasoning in 5.1.1 might lead to opening a window for … [Ballot discuss] Section 5.1.2 contradicts section 5.1.1, in the sense that following the line of reasoning in 5.1.1 might lead to opening a window for a downgrade attack. I don't think there's an easy fix for this, but it argues to me that the advice in 5.1.1 about insufficiently secure algorithms ought to be removed. |
|
2013-04-11
|
17 | Ted Lemon | [Ballot comment] Stefan has proposed the following change in 4.4.8, which addresses the point raised about that section in my earlier DISCUSS: "If this … [Ballot comment] 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." |
|
2013-04-11
|
17 | Ted Lemon | Ballot comment and discuss text updated for Ted Lemon |
|
2013-04-11
|
17 | Benoît Claise | [Ballot comment] 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 … [Ballot comment] 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. |
|
2013-04-11
|
17 | Benoît Claise | Ballot comment text updated for Benoit Claise |
|
2013-04-11
|
17 | Benoît Claise | [Ballot comment] 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 … [Ballot comment] 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. |
|
2013-04-11
|
17 | Benoît Claise | Ballot comment text updated for Benoit Claise |
|
2013-04-11
|
17 | Benoît Claise | [Ballot comment] 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 … [Ballot comment] 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. |
|
2013-04-11
|
17 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
|
2013-04-11
|
17 | Ted Lemon | [Ballot comment] Toward the end of section 2.2, I suggest the following change for clarity: OLD: When a responder responds revoked to a status … [Ballot comment] Toward the end of section 2.2, I suggest the following change for clarity: OLD: When a responder responds revoked to a status request for a non- NEW: When a responder responds 'revoked' to a status request for a non- |
|
2013-04-11
|
17 | Ted Lemon | Ballot comment text updated for Ted Lemon |
|
2013-04-11
|
17 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
|
2013-04-10
|
17 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
|
2013-04-10
|
17 | Ted Lemon | [Ballot comment] Toward the end of section 2.2, I suggest the following change for clarity: OLD: When a responder responds revoked to a status … [Ballot comment] Toward the end of section 2.2, I suggest the following change for clarity: OLD: When a responder responds revoked to a status request for a non- issued certificate, the responder MUST include the extended revoked definition response extension (section 4.4.8) in the response, indicating that the OCSP responder supports the extended definition of revoked state to also cover non-issued certificates. In addition, the SingleResponse related to this non-issued certificate; NEW: When a responder responds 'revoked' to a status request for a non- issued certificate, the responder MUST include the extended revoked definition response extension (section 4.4.8) in the response, indicating that the OCSP responder supports the extended definition of revoked state to also cover non-issued certificates. In addition, the SingleResponse related to this non-issued certificate: Note the trailing colon rather than semicolon. At the end of 2.3: The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server or the server is not capable of responding authoritatively (cf. [RFC5019], Section 2.2.3). Really? What's the motivation for overloading the error code in this way? In 2.3: OLD: thisUpdate The most recent time at which the status being indicated, is known by the responder to be correct. NEW: thisUpdate The most recent time at which the status being indicated is known by the responder to have been correct. In 4.4.7.2.1, the terms "signing algorithm" and "signature algorithm" are used. I think they mean the same thing, and using two different terms in such close proximity leads me to wonder if I am missing something; for the sake of future readers' insecurities, it might be better to pick either "signing" or "signature" and stick with it. Also, in the first paragraph you use "method" to mean the same thing (I think) as "selection mechanism" in the last paragraph; to avoid misunderstandings, you should use "selection mechanism" or "selection method" in both cases (I don't think it makes sense to use just "method" in the last paragraph). In section 4.4.8, the responder can send an indication that it supports returning the "revoked" status for non-issued certificates; is there some reason why the client isn't expected to indicate that it accepts this type of response? I am just curious—I'm not proposing that you make a change in response to this question. In section 5.1, the singular of criteria is criterion. |
|
2013-04-10
|
17 | Ted Lemon | Ballot comment text updated for Ted Lemon |
|
2013-04-10
|
17 | Ted Lemon | [Ballot discuss] In 4.4.8: This extension indicates that the responder supports the extended definition of the "revoked" status to also include non-issued … [Ballot discuss] In 4.4.8: This extension indicates that the responder supports the extended definition of the "revoked" status to also include non-issued certificates according to section 2.2. Presence of this extension indicates that this responder MAY respond with a "revoked" status value to a status request for non-issued certificates. When present, this extension MUST be included as one of the responseExtensions in a response. This text doesn't make sense: the responder is sending the indication that it supports the "revoked" status for non-issued certificates; there's no negotiation going on here, and the MAY just doesn't make sense. Did you really intend to use normative language here? I think you probably should have just said "this responder will respond with..." Presumably "for non-issued certificates" takes care of the variability that this sentence is trying to document. Section 5.1.2 contradicts section 5.1.1, in the sense that following the line of reasoning in 5.1.1 might lead to opening a window for a downgrade attack. I don't think there's an easy fix for this, but it argues to me that the advice in 5.1.1 about insufficiently secure algorithms ought to be removed. |
|
2013-04-10
|
17 | Ted Lemon | Ballot discuss text updated for Ted Lemon |
|
2013-04-10
|
17 | Ted Lemon | [Ballot comment] Toward the end of section 2.2, I suggest the following change for clarity: OLD: When a responder responds revoked to a status … [Ballot comment] Toward the end of section 2.2, I suggest the following change for clarity: OLD: When a responder responds revoked to a status request for a non- issued certificate, the responder MUST include the extended revoked definition response extension (section 4.4.8) in the response, indicating that the OCSP responder supports the extended definition of revoked state to also cover non-issued certificates. In addition, the SingleResponse related to this non-issued certificate; NEW: When a responder responds 'revoked' to a status request for a non- issued certificate, the responder MUST include the extended revoked definition response extension (section 4.4.8) in the response, indicating that the OCSP responder supports the extended definition of revoked state to also cover non-issued certificates. In addition, the SingleResponse related to this non-issued certificate: Note the trailing colon rather than semicolon. At the end of 2.3: The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server or the server is not capable of responding authoritatively (cf. [RFC5019], Section 2.2.3). Really? What's the motivation for overloading the error code in this way? In 2.3: OLD: thisUpdate The most recent time at which the status being indicated, is known by the responder to be correct. NEW: thisUpdate The most recent time at which the status being indicated is known by the responder to have been correct. In 4.4.7.2.1, the terms "signing algorithm" and "signature algorithm" are used. I think they mean the same thing, and using two different terms in such close proximity leads me to wonder if I am missing something; for the sake of future readers' insecurities, it might be better to pick either "signing" or "signature" and stick with it. Also, in the first paragraph you use "method" to mean the same thing (I think) as "selection mechanism" in the last paragraph; to avoid misunderstandings, you should use "selection mechanism" or "selection method" in both cases (I don't think it makes sense to use just "method" in the last paragraph). In section 4.4.8, the responder can send an indication that it supports returning the "revoked" status for non-issued certificates; is there some reason why the client isn't expected to indicate that it accepts this type of response? I am just curious—I'm not proposing that you make a change in response to this question. In section 5.1, the singular of criteria is criterion. |
|
2013-04-10
|
17 | Ted Lemon | Ballot comment text updated for Ted Lemon |
|
2013-04-10
|
17 | Ted Lemon | [Ballot discuss] In 4.4.8: This extension indicates that the responder supports the extended definition of the "revoked" status to also include non-issued … [Ballot discuss] In 4.4.8: This extension indicates that the responder supports the extended definition of the "revoked" status to also include non-issued certificates according to section 2.2. Presence of this extension indicates that this responder MAY respond with a "revoked" status value to a status request for non-issued certificates. When present, this extension MUST be included as one of the responseExtensions in a response. This text doesn't make sense: the responder is sending the indication that it supports the "revoked" status for non-issued certificates; there's no negotiation going on here, and the MAY just doesn't make sense. Did you really intend to use normative language here? I think you probably should have just said "this responder will respond with..." Presumably "for non-issued certificates" takes care of the variability that this sentence is trying to document. Section 5.1.2 contradicts section 5.1.1, in the sense that following the line of reasoning in 5.1.1 might lead to opening a window for a downgrade attack. I don't think there's an easy fix for this, but it argues to me that the advice in 5.1.1 about insufficiently secure algorithms ought to be removed. |
|
2013-04-10
|
17 | Ted Lemon | [Ballot comment] Toward the end of section 2.2, I suggest the following change for clarity: OLD: When a responder responds revoked to a status … [Ballot comment] Toward the end of section 2.2, I suggest the following change for clarity: OLD: When a responder responds revoked to a status request for a non- issued certificate, the responder MUST include the extended revoked definition response extension (section 4.4.8) in the response, indicating that the OCSP responder supports the extended definition of revoked state to also cover non-issued certificates. In addition, the SingleResponse related to this non-issued certificate; NEW: When a responder responds 'revoked' to a status request for a non- issued certificate, the responder MUST include the extended revoked definition response extension (section 4.4.8) in the response, indicating that the OCSP responder supports the extended definition of revoked state to also cover non-issued certificates. In addition, the SingleResponse related to this non-issued certificate: Note the trailing colon rather than semicolon. At the end of 2.3: The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server or the server is not capable of responding authoritatively (cf. [RFC5019], Section 2.2.3). Really? What's the motivation for overloading the error code in this way? In 2.3: OLD: thisUpdate The most recent time at which the status being indicated, is known by the responder to be correct. NEW: thisUpdate The most recent time at which the status being indicated is known by the responder to have been correct. In 4.4.7.2.1, the terms "signing algorithm" and "signature algorithm" are used. I think they mean the same thing, and using two different terms in such close proximity leads me to wonder if I am missing something; for the sake of future readers' insecurities, it might be better to pick either "signing" or "signature" and stick with it. Also, in the first paragraph you use "method" to mean the same thing (I think) as "selection mechanism" in the last paragraph; to avoid misunderstandings, you should use "selection mechanism" or "selection method" in both cases (I don't think it makes sense to use just "method" in the last paragraph). In section 4.4.8, the responder can send an indication that it supports returning the "revoked" status for non-issued certificates; is there some reason why the client isn't expected to indicate that it accepts this type of response? I am just curious—I'm not proposing that you make a change in response to this question. In section 5.1, the singular of criteria is criterion. |
|
2013-04-10
|
17 | Ted Lemon | [Ballot Position Update] New position, Discuss, has been recorded for Ted Lemon |
|
2013-04-10
|
17 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
|
2013-04-10
|
17 | Stefan Santesson | New version available: draft-ietf-pkix-rfc2560bis-17.txt |
|
2013-04-10
|
16 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
|
2013-04-09
|
16 | Richard Barnes | [Ballot comment] Thanks for making the document easy to diff against RFC 2560 :) These changes look reasonable, and the explanation in the introduction makes … [Ballot comment] 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. |
|
2013-04-09
|
16 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
|
2013-04-09
|
16 | Barry Leiba | [Ballot discuss] I have a few points I want to talk about before we're done with this. Thanks in advance for addressing these with me. … [Ballot discuss] I have a few points I want to talk about before we're done with this. Thanks in advance for addressing these with me. -- Section 2.2 -- The "revoked" state indicates that the certificate has been revoked either permanently or temporarily (i.e. the revocation reason is certificateHold). 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, using any current or previous issuing key (referred to as a "non-issued" certificate in this document). The "unknown" state indicates that the responder doesn't know about the certificate being requested. A few things here: 1. I was confused for a while about the "i.e." parenthetical, but now I think I understand that its scope is only the "temporarily" part, not both "permanently or temporarily". In other words, I first read it to mean that the only time "revoked" would be returned would be when the revocation reason was certificateHold. But now I think I understand that it means to say either {permanently} or {temporarily (i.e., certificateHold)}. I think re-wording is critical here. Moving "temporarily" first might be the easiest answer. So, also eliminating the unnecessary Latin abbreviation: NEW The "revoked" state indicates that the certificate has been revoked, either temporarily (the revocation reason is certificateHold) or permanently. END 2. I do not understand how "the associated CA has no record of ever having issued a certificate with the certificate serial number in the request, using any current or previous issuing key" is substantively distinct from "doesn't know about the certificate being requested." Please explain that. 3. I'm not really following the explanatory note that comes after this. What sort of "fall back mechanism"? Are you suggesting that we want to avoid having requestors use OCSP as a way of checking validity of certs and revocation at the same time (good == valid, revoked == revoked, unknown == invalid)? If so, I think you need to be clearer about that. If not, I think you need to be clearer about what you are trying cover. 4. The subsequent text, which prescribes a particular contrived "revoked" response (reason == certificateHold, revocationTime == 1 Jan 1970) seems to make this particular type of "revoked" response distinct from others anyway. Doesn't that defeat the mechanism you're trying to create, by allowing requesters to distinguish them? 5. If they are *not* distinguishable, are we quite certain that there will be no undesirable client effects that result? Is it really OK to have a possibility that a completely unrecognized cert can get any response, "good", "revoked", or "unknown"? -- Section 2.7 -- If an OCSP responder knows that a particular CA's private key has been compromised, it MAY return the revoked state for all certificates issued by that CA. 6. I know this hasn't changed since 2560, but... is "MAY" really all we want here? Not "SHOULD"? Shouldn't we be strongly encouraging dissemination of information about CA compromises, and isn't there a way to make this a RECOMMENDable thing? |
|
2013-04-09
|
16 | Barry Leiba | Ballot discuss text updated for Barry Leiba |
|
2013-04-09
|
16 | Barry Leiba | [Ballot comment] -- Section 4.2.2.3 -- The response MUST include a SingleResponse for each certificate in the request and SHOULD NOT include any … [Ballot comment] -- Section 4.2.2.3 -- The response MUST include a SingleResponse for each certificate in the request and SHOULD NOT include any additional SingleResponse elements. OCSP responders that pre-generate status responses MAY return responses that include additional SingleResponse elements if necessary to improve response pre-generation performance or cache efficiency. (According to Section 2.2.1 of [RFC5019]). This doesn't seem to be a correct use of "SHOULD NOT" and "MAY" together. Remember that "MAY" specifies that something is entirely optional. I suggest not using 2119 key words in the second sentence, and making it clear that it's giving a reason for the previous "SHOULD NOT". Maybe this?: NEW The response MUST include a SingleResponse for each certificate in the request. The response SHOULD NOT include any additional SingleResponse elements, but, for example, OCSP responders that pre-generate status responses might include additional SingleResponse elements [...] END Nit: The parenthetical at the end is a sentence fragment; attach it to the end of the previous sentence: "efficiency (according to [RFC5019], Section 2.2.1)." (By the way: the HTML generator will generate a link fragment in the RFC to the specific section, if you use "[RFC5019], Section 2.2.1", but not if you use "Section 2.2.1 of [RFC5019]".) |
|
2013-04-09
|
16 | Barry Leiba | Ballot comment text updated for Barry Leiba |
|
2013-04-09
|
16 | Barry Leiba | [Ballot discuss] [I am composing this in pieces, putting my notes in as I make them. I'll send the email out when it's complete.] -- … [Ballot discuss] [I am composing this in pieces, putting my notes in as I make them. I'll send the email out when it's complete.] -- Section 2.2 -- The "revoked" state indicates that the certificate has been revoked either permanently or temporarily (i.e. the revocation reason is certificateHold). 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, using any current or previous issuing key (referred to as a "non-issued" certificate in this document). The "unknown" state indicates that the responder doesn't know about the certificate being requested. A few things here: 1. I was confused for a while about the "i.e." parenthetical, but now I think I understand that its scope is only the "temporarily" part, not both "permanently or temporarily". In other words, I first read it to mean that the only time "revoked" would be returned would be when the revocation reason was certificateHold. But now I think I understand that it means to say either {permanently} or {temporarily (i.e., certificateHold)}. I think re-wording is critical here. Moving "temporarily" first might be the easiest answer. So, also eliminating the unnecessary Latin abbreviation: NEW The "revoked" state indicates that the certificate has been revoked, either temporarily (the revocation reason is certificateHold) or permanently. END 2. I do not understand how "the associated CA has no record of ever having issued a certificate with the certificate serial number in the request, using any current or previous issuing key" is substantively distinct from "doesn't know about the certificate being requested." Please explain that. 3. I'm not really following the explanatory note that comes after this. What sort of "fall back mechanism"? Are you suggesting that we want to avoid having requestors use OCSP as a way of checking validity of certs and revocation at the same time (good == valid, revoked == revoked, unknown == invalid)? If so, I think you need to be clearer about that. If not, I think you need to be clearer about what you are trying cover. 4. The subsequent text, which prescribes a particular contrived "revoked" response (reason == certificateHold, revocationTime == 1 Jan 1970) seems to make this particular type of "revoked" response distinct from others anyway. Doesn't that defeat the mechanism you're trying to create, by allowing requesters to distinguish them? 5. If they are *not* distinguishable, are we quite certain that there will be no undesirable client effects that result? Is it really OK to have a possibility that a completely unrecognized cert can get any response, "good", "revoked", or "unknown"? -- Section 2.7 -- If an OCSP responder knows that a particular CA's private key has been compromised, it MAY return the revoked state for all certificates issued by that CA. 6. I know this hasn't changed since 2560, but... is "MAY" really all we want here? Not "SHOULD"? Shouldn't we be strongly encouraging dissemination of information about CA compromises, and isn't there a way to make this a RECOMMENDable thing? |
|
2013-04-09
|
16 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
|
2013-04-08
|
16 | Stephen Farrell | [Ballot comment] - 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 … [Ballot comment] - 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? |
|
2013-04-08
|
16 | Stephen Farrell | Ballot comment text updated for Stephen Farrell |
|
2013-04-08
|
16 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
|
2013-04-08
|
16 | Stephen Farrell | [Ballot comment] - Do we or the RFC editor have a policy on deceased authors? I can see why folks might leave a name on, … [Ballot comment] - 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? |
|
2013-04-08
|
16 | Stephen Farrell | [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell |
|
2013-04-08
|
16 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
|
2013-04-05
|
16 | David Black | Request for Telechat review by GENART Completed: Ready. Reviewer: David Black. |
|
2013-04-04
|
16 | Jean Mahoney | Request for Telechat review by GENART is assigned to David Black |
|
2013-04-04
|
16 | Jean Mahoney | Request for Telechat review by GENART is assigned to David Black |
|
2013-04-04
|
16 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Sandra Murphy. |
|
2013-04-04
|
16 | Adrian Farrel | [Ballot comment] I have no objeciton to the publication of this document, and only two minor points which you can take or leave as you … [Ballot comment] 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. |
|
2013-04-04
|
16 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
|
2013-03-28
|
16 | Stefan Santesson | New version available: draft-ietf-pkix-rfc2560bis-16.txt |
|
2013-03-27
|
15 | Sean Turner | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
|
2013-03-27
|
15 | Sean Turner | Ballot has been issued |
|
2013-03-27
|
15 | Sean Turner | [Ballot Position Update] New position, Yes, has been recorded for Sean Turner |
|
2013-03-27
|
15 | Sean Turner | Created "Approve" ballot |
|
2013-03-27
|
15 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
|
2013-03-26
|
15 | David Black | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: David Black. |
|
2013-03-25
|
15 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-pkix-rfc2560bis-15.txt. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-pkix-rfc2560bis-15.txt. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA has a question about the IANA Considerations section of this document. IANA question --> Do the authors intend that, upon approval of this document, that the MIME media types documented in Appendix C of this document have their reference changed from RFC2560 to this document? Note: Although the datatracker lists this document's state, as of now, as "IANA review needed," Standards Tree media types registered through IETF documents do NOT require expert review, per section 3.1 of RFC 6838. Also Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
|
2013-03-21
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sandra Murphy |
|
2013-03-21
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sandra Murphy |
|
2013-03-14
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Black |
|
2013-03-14
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Black |
|
2013-03-13
|
15 | Sean Turner | Placed on agenda for telechat - 2013-04-11 |
|
2013-03-13
|
15 | Cindy Morgan | IANA Review state changed to IANA Review Needed |
|
2013-03-13
|
15 | Cindy Morgan | The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <pkix@ietf.org> Reply-To: ietf@ietf.org Subject: … The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <pkix@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-pkix-rfc2560bis-15.txt> (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP' <draft-ietf-pkix-rfc2560bis-15.txt> as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-03-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFC 2560 and RFC 6277, and updates RFC 5912. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis/ballot/ No IPR declarations have been submitted directly on this I-D. |
|
2013-03-13
|
15 | Cindy Morgan | State changed to In Last Call from Last Call Requested |
|
2013-03-13
|
15 | Sean Turner | During WGLC one WG participant continued to object to progression of this draft because "the major problems are not solved to my satisfaction." I did … During WGLC one WG participant continued to object to progression of this draft because "the major problems are not solved to my satisfaction." I did not judge the issues to be problems; however, the participant is aware that bringing their points back up on the IETF list is the next step in trying to get others to agree with his position. In fact, I fully expect that they will. There is also now a possibility that the participant will submit an appeal. |
|
2013-03-13
|
15 | Sean Turner | Last call was requested |
|
2013-03-13
|
15 | Sean Turner | Ballot approval text was generated |
|
2013-03-13
|
15 | Sean Turner | State changed to Last Call Requested from AD Evaluation |
|
2013-03-13
|
15 | Sean Turner | Last call announcement was generated |
|
2013-03-13
|
15 | Sean Turner | Ballot writeup was changed |
|
2013-03-13
|
15 | Sean Turner | Ballot writeup was generated |
|
2013-03-13
|
15 | Stefan Santesson | New version available: draft-ietf-pkix-rfc2560bis-15.txt |
|
2013-02-28
|
14 | Cindy Morgan | New version available: draft-ietf-pkix-rfc2560bis-14.txt |
|
2013-02-20
|
13 | Sean Turner | State changed to AD Evaluation from Publication Requested |
|
2013-02-11
|
13 | Amy Vezza | Document Writeup for: draft-ietf-pkix-rfc2560bis-13 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … Document Writeup for: draft-ietf-pkix-rfc2560bis-13 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document specifies a protocol used by a relying party to determine the current status of a digital certificate without requiring the RP to acquire a CRL. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFC 2560 and RFC 6277, and updates RFC 5912. Working Group Summary: This draft represents a long WG process that was initiated through publication of "draft-cooper-pkix-rfc2560bis-00.txt" in June 2010. This document represents a complete re-write of the OCSP document, while remaining bits-on-the-wire compatability with RFC 2560. It is very hard to demonstrate that all requirements of a complete re-write are backwards compatible with the original RFC, so the WG agreed to adopt a new approach: only errors and ambiguities with the original draft would be addressed, and the structure of the original document would be preserved as much as possible. Since the change of direction and authorship in 2012, the document has progressed in it's current form. A major question for this document was posed by the CA Browser Forum (CABF) as a result of the compromised CA DigiNotar. In that compromise, the designated OCSP responder continued to respond "good" to certificates, that DigiNotar had no record of issuing. This caused the CABF to issue requirements on the behavior of OCSP responders that were not fully supported by RFC 2560. This was thoroughly debated in the WG. A straw-poll demonstrated a strong majority for the following way of dealing with this problem: If an OCSP receives a query for a certificate that was not issued by the CA in question, and if the responder is aware of this, the responder should reply to the a request as though the cert in question has been revoked. The conclusion of this WG decision has dominated the process of concluding this document. Document Quality: This document is of good quality and suitable for publication. This document has deliberately retained text and the outline of RFC 2560 whenever possible, e.g., when text has not been determined to be wrong or ambiguous. The document could have a better structure, but the WG decided to retain the outline of the original RFC as much as possible, to make it easier to review the changes in this update. Personnel: Document Shepherd: Steve Kent (PKIX cochair), Cognizant AD: Sean Turner (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed this document and feel that it is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The document is an update of an existing and widely-deployed protocol. It has been reviewed and tested by at least one current implementer. No further review is required. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The latter phases of the development of this doc has been contentious, but the current version represents WG (rough) consensus. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? RFC 2560 predates BCP 78 & 79. This version retains the authors of the original version. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. I am aware of no IRP disclosures relevant to this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document represent WG rough consensus, as noted above. A few individuals in the WG have objected to some aspects of the draft. However, in each area that has been debated, the draft represents the sentiment of a clear majority of the WG. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) Martin Rex has stated that he may raise additional; objections during IETF last call, but he has not cited any procedural issues that would form a basis for an appeal. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. IDnits generates no errors, a a few minor warnings that can be addressed later. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. This draft specifies a protocol that is bits on the wire compatible with the RFC that it updates, with the exception of one new extension. The document has been reviewed by Alexey Melnikov with regard to URIs. (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? N/A (15) Are there downward normative down references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No, but, this (stanfdards track) document updates (informative) RFC 5912. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document obsoletes RFCs 2560 and 6277 and updates RFC 5912. This is listed in the document header and mentioned in the Abstract. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). I have reviewed the IANA considerations section and find it consistent with the document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. This draft include MIME type registrations (in Appendix C) that currently reside in RFC 2560, which is obsoleted by publication of this draft as RFC. So, there are no new MIME types to be registered. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Appendix B contains ASN.1 modules for the defined OCSP protocol. These modules has been compiled and tested by Jim Schaad. Jim is the editor of RFC 5912, which contains ASN.1 modules that are updated by this document. |
|
2013-02-11
|
13 | Amy Vezza | Note added 'Document Shepherd: Steve Kent (kent@bbn.com)' |
|
2013-02-11
|
13 | Amy Vezza | Intended Status changed to Proposed Standard |
|
2013-02-11
|
13 | Amy Vezza | IESG process started in state Publication Requested |
|
2013-01-31
|
13 | Stephanie McCammon | New version available: draft-ietf-pkix-rfc2560bis-13.txt |
|
2013-01-29
|
12 | Stefan Santesson | New version available: draft-ietf-pkix-rfc2560bis-12.txt |
|
2013-01-27
|
11 | Stefan Santesson | New version available: draft-ietf-pkix-rfc2560bis-11.txt |
|
2013-01-27
|
10 | Stefan Santesson | New version available: draft-ietf-pkix-rfc2560bis-10.txt |
|
2013-01-27
|
09 | Stefan Santesson | New version available: draft-ietf-pkix-rfc2560bis-09.txt |
|
2013-01-03
|
08 | Stefan Santesson | New version available: draft-ietf-pkix-rfc2560bis-08.txt |
|
2013-01-01
|
07 | Stefan Santesson | New version available: draft-ietf-pkix-rfc2560bis-07.txt |
|
2012-10-14
|
06 | Stefan Santesson | New version available: draft-ietf-pkix-rfc2560bis-06.txt |
|
2012-07-30
|
05 | Stefan Santesson | New version available: draft-ietf-pkix-rfc2560bis-05.txt |
|
2011-10-03
|
04 | (System) | New version available: draft-ietf-pkix-rfc2560bis-04.txt |
|
2011-04-05
|
03 | (System) | New version available: draft-ietf-pkix-rfc2560bis-03.txt |
|
2010-10-14
|
02 | (System) | New version available: draft-ietf-pkix-rfc2560bis-02.txt |
|
2002-10-10
|
04 | (System) | Document has expired |
|
2002-02-12
|
01 | (System) | New version available: draft-ietf-pkix-rfc2560bis-01.txt |
|
2002-02-04
|
00 | (System) | New version available: draft-ietf-pkix-rfc2560bis-00.txt |