Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Johannes Merkle wrote:
Limitations
- Works only if attacker fraudulently issued a certificate with a serial
that is not associated with a good certificate.
This can be remedied by using an extension in which a server providing
white-list information conveys a hash of the (genuine) certificate
having this serial number. Note, that such an extension does not only
exist but is already used in the context of qualified certificates
in Germany: CertHash (OID 1.3.36.8.3.13), defined in CommonPKI.
Including URLs for publicly availble specsinfos will be appreciated!
(it is my first encounter with CommonPKI)
Peter Rybar seemed to have suggested inclusion of CertHash in July 2012:
http://www.ietf.org/mail-archive/web/pkix/current/msg31385.html
but only had a reference to a powerpoint presentation from 2004
with an experimental tag.
Google led me here:
http://www.t7ev.org/ws/T7-en/Common-PKI-V20-Specification
The v2.0 specification PDF document is a concatenation of several documents,
In Common PKI Part 4: Operational Protocols (page 150 of 361) there
is the definition of a CertHash extension to be used in OCSP response
singleExtension:
3.1.2 Common PKI Private OCSP Extensions
Table 15: CertHash (Positive Statement)
id-commonpki-at-certHash OBJECT IDENTIFIER ::= {1 3 36 8 3 13}
CertHash ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
certificateHashOCTET STRING }
certificateHash -- A hash over the DER-encoding of the entire PKC or
AC (i.e. NOT a hash over tbsCertificate).
[...]
Common PKI Profile: The responder may include this extension in a
response to send the hash of the requested certificate to the responder.
This hash is cryptographically bound to the certificate and serves as
evidence that the certificate is known to the responder (i.e. it has
been issued and is present in the directory). Hence, this extension
is a means to provide a positive statement of availability as described
in T8.[8]. As explained in T13.[1], clients may rely on this information
to be able to validate signatures after the expiry of the corresponding
certificate. Hence, clients MUST support this extension. If a positive
statement of availability is to be delivered, this extension syntax
and OID MUST be used.
CommonPKI seems to be about qualified electronic signatures for the German
Digital Signature Act. Are there any similar standards published
by other (european or otherwise) countries for an private OCSP extension
with a positive statement about certificate issuance?
I think we should have added this to rfc2560bis!
-Martin
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
On Apr 13, 2013, at 4:24 PM, Stefan Santesson ste...@aaa-sec.com wrote: These are the three possible states of a serial number. It must always be in ONE of these states. As long as you assume that a certificate signed by the CA cannot be non-issued i.e. CA knows what certificates it issued. If you break that assumption, you have to deal with the possibility of different certificates with same serial numbers (after all certificates are getting issued without CA's knowledge). This implies that the same serial number can be associated with a good certificate and a non-issued certificate. Let me frame it in a different way. If you get a good response from a responder that issues revoked for non-issued, can you be sure that the certificate you are checking is not a non-issued certificate? No, to take it to that level, you need a new white list extension. You see this from the wrong angle. This change is not intended to provide the client indisputable knowledge about whether a certificate is non-issued or not. It is intended to give the responder a means of causing the client to reject rather than accept something that is known not to be good. Disagree. The protocol is intended to provide information (Status) about an identified cert (or serial number if you prefer) so an RP can make the best decision possible about how to treat it within the scope if its own application. That means that the OCSP responder SHOULD NOT (IMO) conceal the distinction between non-issued and good, nor should it conceal the distinction between non-issued and revoked (for exactly the same reason). Doing either one of those effectively prevents the information from one of the white- or black-lists from contributing to OCSP responses. I don't think it's safe in the first place to assume we know what all the current clients do or want. I likewise don't think it's safe to assume we know what they will do, should do, or want in the future. It may be clear how to handle a white-listed or black-listed cert. However, I can think of several different scenarios for how a non-issued cert ought to be handled. All of that is outside the scope of OCSPs perview. And also the client cannot be sure if the CA delegated responder's certificate is good or non-issued. This renders OCSP completely useless. I did not talk about responder certificates. You did not. But that does not make my statement any less relevant or incorrect and strengthens Henry's point about this spec achieving what it is trying to do. I likewise haven't' addressed responder cert's as a special case. :-/ I need to study the spec more carefully. IIUC Martin seems to imply that you can infer if a cert is white-list/black-list/neither based on new extensions, if enough of them are present. IIUC Stefan seems to imply the opposite, though the extensions should tell you where the ambiguity is. My read supported the latter, but I don't want to stake my reputation on it. Assuming what Stefan implies, would people be happy if we updated the abstract/introduction to say that a new OCSP response, combined with the CRL would allow an RP to infer which of the three status's a cert has? When I opposed this draft, I had not yet thought of this combination of protocols. I see the combination as unnecessarily high-overhead, but a step forward. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Limitations - Works only if attacker fraudulently issued a certificate with a serial that is not associated with a good certificate. This can be remedied by using an extension in which a server providing white-list information conveys a hash of the (genuine) certificate having this serial number. Note, that such an extension does not only exist but is already used in the context of qualified certificates in Germany: CertHash (OID 1.3.36.8.3.13), defined in CommonPKI. Johannes
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
On Apr 11, 2013, at 10:37 PM, Stefan Santesson ste...@aaa-sec.com wrote: To put it simply. Given how OCSP is designed, the only way to allow good to represent a white-list, is if revoked can be returned for everything else. I realize it's unfair of me to take this quote out of context. Apologies, but I want to focus on it. You've just said that there are only two valid responses from an OCSP server which has access to a white list. In other words such a server inherently cannot provide any information about the actual revocation status of a cert, and its responses cannot distinguish between a lost/forged/whatever cert and a known-bad (actually revoked) cert. The actual information which an OCSP responder might (should?) have would include both a white list and a black list. An RP using OCSP to determine the current status of a digital certificate without requiring CRLs (as it says in the abstract) would hope to receive the available information about a subject cert. In other words, after a successful query, it would hope to know if the subject cert was known-good, known-bad, or neither. By combining the known-bad and neither responses, the RP must now use CRLs in order to distinguish those two cases. This situation would appear to contradict the first sentence in the abstract of the document. Doesn't a change which requires a change in the abstract exceed the authorized scope of this revision to 2560? If it doesn't then I think the abstract needs to be updated. I don't understand why we're trying so hard to avoid providing both the white-list and the black-list information at the same time in OCSP responses. (Nit: Since the Introduction repeats the Abstract, the reference to 5912 added to the Abstract should also be added to the Introduction.) -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu
RE: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
An extension may differentiate which serial number that results in a revoked response, that is actually issued and revoked, or if there is any other particular reason for responding revoked. In my universe a syntactically valid serial number can only be good, revoked or non-issued. But expressing this in general terms anyway. [Piyush] From an RP's perspective finding status of serial numbers serves no purpose unless they can associate that serial number with a certificate. When an OCSP client extracts the serial number from a certificate and sends it the responder to determine the status, it is acting under a very important assumption - the CA has issued that certificate and that it has issued only one certificate with that serial. If you say that this assumption is invalid, your trichotomy of serial status is not mutually exclusive any more. Same serial can now be associated with a good, revoked and non-issued status. And also the client cannot be sure if the CA delegated responder's certificate is good or non-issued. This renders OCSP completely useless. So with the help of extensions, a responder can provide both white and black list data. [Piyush] May be you are right. But I doubt that you want a discussion on feasibility/security implications of this, otherwise it would've been a stated goal of 2560bis and would have been captured in the abstract. I tried to think ahead but I cannot figure out a way to communicate the white listed status of a CA delegated responder to the client without avoiding circular logic. I completely fail to see why revoked for non-issued is a pre-requisite for future extensions that can be used to provide white-list data (if it is even possible under CA delegated responder trust model).
RE: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
[Piyush] From an RP's perspective finding status of serial numbers serves no purpose unless they can associate that serial number with a certificate. Absolutely, that is the client's perspective of this. Great. We agree When an OCSP client extracts the serial number from a certificate and sends it the responder to determine the status, it is acting under a very important assumption - the CA has issued that certificate and that it has issued only one certificate with that serial. Absolutely Great. We agree. Let me reiterate -OCSP client extracts the serial number assuming that the CA issued the certificate and issued only one certificate with that serial number. So why do we need the responder to return non-issued for the same certificate? If you say that this assumption is invalid, your trichotomy of serial status is not mutually exclusive any more. Same serial can now be associated with a good, revoked and non-issued status. I didn't say that. I said it can only be good, revoked or non-issued Notice the difference? My sentence contains the word or, yours the word and. I stand by my words :). These are the three possible states of a serial number. It must always be in ONE of these states. As long as you assume that a certificate signed by the CA cannot be non-issued i.e. CA knows what certificates it issued. If you break that assumption, you have to deal with the possibility of different certificates with same serial numbers (after all certificates are getting issued without CA's knowledge). This implies that the same serial number can be associated with a good certificate and a non-issued certificate. Let me frame it in a different way. If you get a good response from a responder that issues revoked for non-issued, can you be sure that the certificate you are checking is not a non-issued certificate? And also the client cannot be sure if the CA delegated responder's certificate is good or non-issued. This renders OCSP completely useless. I did not talk about responder certificates. You did not. But that does not make my statement any less relevant or incorrect and strengthens Henry's point about this spec achieving what it is trying to do.
RE: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Stefan, I don't think that we have any gaps in the technical understanding of this proposal. Based on the discussions over the last few months, I can confidently say that the difference of opinion is around the benefits of adoptions and the costs associated with it. Here are the possible goals that had been discussed 1) Address CA compromise issue 2) Provide certificate white list/black list information to the clients 3) Allow CAs to return revoked for non-issued. Some clients in some situation benefit by not falling back to CRL validation. I understand that according to you, 3 is the only goal for this update. So I am basing the following on that goal Benefits ~~~ - In some situations, It allows clients to reject some (not all) fraudulently issued certificates that are and not detected by the CA. - It allows buggy clients sending incorrect serial number to detect the bug. (This is based on your last post, but I don't think that you seriously consider this a benefit :)) Limitations - Works only if attacker fraudulently issued a certificate with a serial that is not associated with a good certificate. - Works only if attacker did not fraudulently issued a responder certificate. - Works only if client is configured to use OCSP as primary validation option - Works only if responder is not a CRL based responder. - Works only if responder is producing live responses. Cons (this is where we have the disagreement) - Stated goal leaves it to the imagination of readers to figure out the problem that is being tackled. - Provides false sense of security. Readers may believe that it addresses CA compromise issue. - Challenges the fundamental assumption behind x.509 processing that certificate signature and certificate issuance are equivalent. - Leaves the clients to deal with the paradox of responder trust if they choose to interpret the response as meaning non-issued as opposed to revoked - It's a change in the main document, so every implementer will have to go through it even though the benefit is very limited to specific scenarios. - The unintended consequence is that people will incorrectly start believing that CRLs are less secure that OCSP. - The draft exceeds the stated goal in the abstract (protocol useful in determining the current status of a digital certificate without requiring CRLs) I understand that you don't see the cons listed above as major problem. Your position is that it does not affect any other deployments except the CAs who want to support it. That is technically correct, but the side effect of this explicit endorsement from pkix is that the proponents start touting this as the secure solution that needs to be adopted by everyone. They don't have the luxury/motivation to look at pkix discussions to understand the limitations of this approach. As an example, there was a proposal in CAB forum to move away from CRL based responders. Thankfully, a few vendors who have heavily invested in pre-signed OCSP infrastructure voted against it. On a final note, I understand there are facts and there are opinions and this particular instance there are opinions galore (including mine:) ). I suggest we move on, and let the IETF decide. I don't think our opinions will converge with any more discussion. We'll have lot more data in a few years to evaluate the diverse opinions that were presented in this WG. There is always the option of coming out with another update if things don't go as planned :). -Piyush -Original Message- From: Stefan Santesson [mailto:ste...@aaa-sec.com] Sent: Saturday, April 13, 2013 4:24 PM To: Piyush Jain; 'Henry B. Hotz' Cc: p...@ietf.org; ietf@ietf.org Subject: Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard On 4/13/13 8:56 PM, Piyush Jain piy...@ditenity.com wrote: [Piyush] From an RP's perspective finding status of serial numbers serves no purpose unless they can associate that serial number with a certificate. Absolutely, that is the client's perspective of this. Great. We agree When an OCSP client extracts the serial number from a certificate and sends it the responder to determine the status, it is acting under a very important assumption - the CA has issued that certificate and that it has issued only one certificate with that serial. Absolutely Great. We agree. Let me reiterate -OCSP client extracts the serial number assuming that the CA issued the certificate and issued only one certificate with that serial number. So why do we need the responder to return non-issued for the same certificate? Because of your lack of fantasy :) Shift your focus from the client to the server. A client have control over never asking for a non-issued certificate, unless the CA is broken. The server have not. A bad, broken or malicious client may for what ever reason it may have, send
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
On 4/13/13 2:53 AM, Henry B. Hotz h...@jpl.nasa.gov wrote: You've just said that there are only two valid responses from an OCSP server which has access to a white list. In other words such a server inherently cannot provide any information about the actual revocation status of a cert, and its responses cannot distinguish between a lost/forged/whatever cert and a known-bad (actually revoked) cert. I realize it's unfair of me to take this quote out of context. Apologies, but I want to focus on it. (Stole your words :)) No that is NOT what I say. An extension may differentiate which serial number that results in a revoked response, that is actually issued and revoked, or if there is any other particular reason for responding revoked. In my universe a syntactically valid serial number can only be good, revoked or non-issued. But expressing this in general terms anyway. So with the help of extensions, a responder can provide both white and black list data. The legacy client will just look at the status and act accordingly. The extension aware client and a later audit can use the extensions to further determine what happened. /Stefan
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
On 4/13/13 6:51 PM, Piyush Jain piy...@ditenity.com wrote: An extension may differentiate which serial number that results in a revoked response, that is actually issued and revoked, or if there is any other particular reason for responding revoked. In my universe a syntactically valid serial number can only be good, revoked or non-issued. But expressing this in general terms anyway. [Piyush] From an RP's perspective finding status of serial numbers serves no purpose unless they can associate that serial number with a certificate. Absolutely, that is the client's perspective of this. When an OCSP client extracts the serial number from a certificate and sends it the responder to determine the status, it is acting under a very important assumption - the CA has issued that certificate and that it has issued only one certificate with that serial. Absolutely If you say that this assumption is invalid, your trichotomy of serial status is not mutually exclusive any more. Same serial can now be associated with a good, revoked and non-issued status. I didn't say that. I said it can only be good, revoked or non-issued Notice the difference? My sentence contains the word or, yours the word and. These are the three possible states of a serial number. It must always be in ONE of these states. And also the client cannot be sure if the CA delegated responder's certificate is good or non-issued. This renders OCSP completely useless. I did not talk about responder certificates. So with the help of extensions, a responder can provide both white and black list data. [Piyush] May be you are right. But I doubt that you want a discussion on feasibility/security implications of this, otherwise it would've been a stated goal of 2560bis and would have been captured in the abstract. If new extensions are defined, then the RFC defining these extensions will discuss relevant security implications related to those extensions. I tried to think ahead but I cannot figure out a way to communicate the white listed status of a CA delegated responder to the client without avoiding circular logic. I can. The good response provides by default a minimum level of positive confirmation. But it is also make clear that an extensions allows good to say more, as long as it fits within that default statement of good. A white list falls within that basic statement. That is, the serial numbers that will return good in a white-list scenario would also return good if the responder provided default OCSP status information. White listing will simply reduce the number of good status to occasions where it represent a known existing certificate. I completely fail to see why revoked for non-issued is a pre-requisite for future extensions that can be used to provide white-list data (if it is even possible under CA delegated responder trust model). I'll try again. It is only possible to reduce the good status responses to white listed certificates if another suitable status can be return for any other requested serial number. That is, the combined set of revoked and non-issued serial numbers that does not belong in the while list. Responding unknown may not be desirable, as it is likely to cause the client to try another source. With the update of RFC2560bis it is now being made clear (in the definition of revoked), that it is conformant to respond revoked to both revoked and non-issued certificates, while before, that could be questioned as a stretch of semantics. So yes indeed, the updates makes it easy to take the next step into a white-list OCSP responder by adding a suitable extension. Of course, only those understanding the new extension will know that it is a white list response. /Stefan
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
On 4/13/13 8:56 PM, Piyush Jain piy...@ditenity.com wrote: [Piyush] From an RP's perspective finding status of serial numbers serves no purpose unless they can associate that serial number with a certificate. Absolutely, that is the client's perspective of this. Great. We agree When an OCSP client extracts the serial number from a certificate and sends it the responder to determine the status, it is acting under a very important assumption - the CA has issued that certificate and that it has issued only one certificate with that serial. Absolutely Great. We agree. Let me reiterate -OCSP client extracts the serial number assuming that the CA issued the certificate and issued only one certificate with that serial number. So why do we need the responder to return non-issued for the same certificate? Because of your lack of fantasy :) Shift your focus from the client to the server. A client have control over never asking for a non-issued certificate, unless the CA is broken. The server have not. A bad, broken or malicious client may for what ever reason it may have, send a request for a non-issued certificate. If that happens, the protocol should allows ways to handle that. Just imagine a such benign situation of a client with a bug, that sends the wrong serial number if the most significant bit is set. For half of it's requests it sends requests for completely non existent certs. Perhaps not likely, but possible. The chance of discovering this error increase significantly if the non-issued serial number requests returns revoked instead of good. This just on top of the case of a broken CA. If you say that this assumption is invalid, your trichotomy of serial status is not mutually exclusive any more. Same serial can now be associated with a good, revoked and non-issued status. I didn't say that. I said it can only be good, revoked or non-issued Notice the difference? My sentence contains the word or, yours the word and. I stand by my words :). Feel free. But saying a million times that a black stone is white, does not change its colour. These are the three possible states of a serial number. It must always be in ONE of these states. As long as you assume that a certificate signed by the CA cannot be non-issued i.e. CA knows what certificates it issued. If you break that assumption, you have to deal with the possibility of different certificates with same serial numbers (after all certificates are getting issued without CA's knowledge). This implies that the same serial number can be associated with a good certificate and a non-issued certificate. Let me frame it in a different way. If you get a good response from a responder that issues revoked for non-issued, can you be sure that the certificate you are checking is not a non-issued certificate? No, to take it to that level, you need a new white list extension. You see this from the wrong angle. This change is not intended to provide the client indisputable knowledge about whether a certificate is non-issued or not. It is intended to give the responder a means of causing the client to reject rather than accept something that is known not to be good. And also the client cannot be sure if the CA delegated responder's certificate is good or non-issued. This renders OCSP completely useless. I did not talk about responder certificates. You did not. But that does not make my statement any less relevant or incorrect and strengthens Henry's point about this spec achieving what it is trying to do. It makes your statement totally irrelevant until the point where you can demonstrate its relevance. /Stefan
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
On Apr 10, 2013, at 3:02 AM, Stefan Santesson ste...@aaa-sec.com wrote: Nothing has changed in this regard. The good response is pretty clear that it by default provides information that the cert is not on a black-list (is not know to be revoked). However, it is also made clear that extensions may be used to expand this default information about the status. This is how it always have been, and still is in RFC 256bis. So a non-issued cert may be good. The revoked response simply means that the certificate is revoked. Combined with the new extension, it MAY also be used for non-issued certs. So a non-issued cert may be revoked. It's really as simple as that. I would have thought that what was simple was to say a non-issued cert was unknown, since it's neither known-good, nor known-revoked. Is there any collection of extensions which will allow an RP to know, for sure, what value will be returned for a never-issued cert? It is only the discussion on this list that is confusing and that has managed turn something really simple into a complicated debate. What *I* find confusing is the apparent degree of belief that it is possible to improve 2560 and simultaneously to maintain backward compatibility. That should only be possible if there are some previously-ignored extensions which alter the semantics of the information --- effectively creating a version 2 protocol. I don't find the claim that nothing has changed helpful. What I would find helpful, and what I think some people really would like, is for OCSP to be able to provide white-list information in addition to the previous black-list information. When I read through 2560bis, I could not tell if there was an extension which would allow an RP to tell if good actually meant a cert was on the white list (and to know the responder has the white list), or merely not on the black list. (Yes, I'm repeating myself. Am I making more sense, or just wasting everyone's time?) /Stefan On 4/8/13 9:35 PM, Henry B. Hotz h...@jpl.nasa.gov wrote: Actually, what I get from this and all the other discussions is that it's unclear if the updated OCSP satisfies the suitability for the intended purpose test. Or at least it fails the KISS principle w.r.t. that. Rephrasing: an OCSP client should be able to tell from an OCSP response if: a) the subject cert is on the CAs white list, b) the subject cert is on the CAs black list, c) the subject cert is not on either list, or finally d) the OCSP server is obsolete, and doesn't support making those distinctions. It's not trivial to see how to parse 2560bis responses w.r.t. those cases, therefore it's highly likely that computational complexity will prevent us from doing so. Even if that's not actually the case, then implementor misunderstandings will prevent us from doing so in practice. Therefore I vote against moving this draft forward. I just don't see the point. If someone were to write an informational RFC which explained how to determine which of the 4 cases an OCSP response fell into, AND if said RFC also convinced me that the decision process was easy to understand, THEN I would change my vote. Obviously an appendix in 2560bis would serve just as well. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Henry B. Hotz wrote: Stefan Santesson ste...@aaa-sec.com wrote: Nothing has changed in this regard. The good response is pretty clear that it by default provides information that the cert is not on a black-list (is not know to be revoked). However, it is also made clear that extensions may be used to expand this default information about the status. This is how it always have been, and still is in RFC 256bis. So a non-issued cert may be good. An rfc2560 OCSP responder might return good status for a not issued cert. That is listed as a caveat in the rfc2560 description for good. The revoked response simply means that the certificate is revoked. Combined with the new extension, it MAY also be used for non-issued certs. So a non-issued cert may be revoked. Yes. That is already possible and fully conforming with rfc2560. It is just not explicitly standardized how to do it. IMO it is preferable to standardize how to do it consistently, rather than letting a thousand flowers bloom on the significantly underspecified rfc2560. It's really as simple as that. I would have thought that what was simple was to say a non-issued cert was unknown, since it's neither known-good, nor known-revoked. That is another permissible response for an rfc2560 OCSP responder. But there is more to consider than just what is permissible by the spec, and that is client behaviour of an installed base that has grown over more than a decade. If a non-marginal fraction of the installed base will either fallback to CRL checking or do a soft-fail (assume good) upon receiving unknown status, then this choice of response might not be very sensible. Is there any collection of extensions which will allow an RP to know, for sure, what value will be returned for a never-issued cert? The two MUSTs at the end of section 2.2 in rfc2560bis-18 plus the MUST contain the responseExtension from section 4.4.8. To facilitate recognizing the revocationTime from the end of section 2.2 rfc2560bis-18, it really ought to be written as UTCTime! from (-18): - MUST specify the revocationTime January 1, 1970, and; to (example): - MUST specify the revocationTime 70010100Z It is only the discussion on this list that is confusing and that has managed turn something really simple into a complicated debate. What *I* find confusing is the apparent degree of belief that it is possible to improve 2560 and simultaneously to maintain backward compatibility. That should only be possible if there are some previously-ignored extensions which alter the semantics of the information --- effectively creating a version 2 protocol. As far as the spec rfc2560 is concerned, this is trivial from a formal perspective since there is hardly any client behaviour defined in rfc2560. But the absence of definition of client behaviour in rfc2560 also limits what kind of behaviour can be added now. In particular, mandating specific behaviour (MUST rather than SHOULD) or prohibiting specific behaviour (MUST NOR rather than SHOULD NOT) is going to be a backwards incompatible change, and unless there is a really convincing rationale for addition of MUST / MUST NOT behaviour, this will result in a conflict with rfc2119 Section 6! http://tools.ietf.org/html/rfc2119#section-6 I don't find the claim that nothing has changed helpful. The claim that nothing has changed is provably untrue as long as the imperative MUST for using the Extension in section 4.4.8 of rfc2560bis-18 persists. What I would find helpful, and what I think some people really would like, is for OCSP to be able to provide white-list information in addition to the previous black-list information. When I read through 2560bis, I could not tell if there was an extension which would allow an RP to tell if good actually meant a cert was on the white list (and to know the responder has the white list), or merely not on the black list. (Yes, I'm repeating myself. Am I making more sense, or just wasting everyone's time?) You're correct, a white-list confirmation is not in rfc2560bis. There seem to be white-list confirmations in current use as OCSP extensions for some Qualified Electronic Signature (QES) usage scenarios, but the PKIX WG constituency in favour of the rfc2560 defects prevented that any existing solutions would be adopted for rfc2560bis. The technical issue with white-listing is, that the original claim about the OCSP protocol properties is technically wrong. rfc2560 OCSP, just like CRLs, is _not_ about the status of certificates, it is purely about the status of certificate serial numbers. In order to obtain a technically sound white-listing response, the good response will have to include a certificate hash in an OCSP singleResponse extension, not just a mere serial number. And that seems to be the solution adopted by some existing QES usage scenarios. Since such solutions exist, adopting one of those in
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
On 4/12/13 1:31 AM, Henry B. Hotz h...@jpl.nasa.gov wrote: What I would find helpful, and what I think some people really would like, is for OCSP to be able to provide white-list information in addition to the previous black-list information. When I read through 2560bis, I could not tell if there was an extension which would allow an RP to tell if good actually meant a cert was on the white list (and to know the responder has the white list), or merely not on the black list. (Yes, I'm repeating myself. Am I making more sense, or just wasting everyone's time?) What we have done is to roll out the red carpet and made it possible for you to do that. - The only thing you need to do now is to define a white-list extension. To put it simply. Given how OCSP is designed, the only way to allow good to represent a white-list, is if revoked can be returned for everything else. Everything else in this context means every other revoked or non-issued certificate serial number under that CA. With RFC 2560 that is not possible in a clean way. With this new extension in RFC 2560bis, it is now possible.
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Nothing has changed in this regard. The good response is pretty clear that it by default provides information that the cert is not on a black-list (is not know to be revoked). However, it is also made clear that extensions may be used to expand this default information about the status. This is how it always have been, and still is in RFC 256bis. The revoked response simply means that the certificate is revoked. Combined with the new extension, it MAY also be used for non-issued certs. It's really as simple as that. It is only the discussion on this list that is confusing and that has managed turn something really simple into a complicated debate. /Stefan On 4/8/13 9:35 PM, Henry B. Hotz h...@jpl.nasa.gov wrote: Actually, what I get from this and all the other discussions is that it's unclear if the updated OCSP satisfies the suitability for the intended purpose test. Or at least it fails the KISS principle w.r.t. that. Rephrasing: an OCSP client should be able to tell from an OCSP response if: a) the subject cert is on the CAs white list, b) the subject cert is on the CAs black list, c) the subject cert is not on either list, or finally d) the OCSP server is obsolete, and doesn't support making those distinctions. It's not trivial to see how to parse 2560bis responses w.r.t. those cases, therefore it's highly likely that computational complexity will prevent us from doing so. Even if that's not actually the case, then implementor misunderstandings will prevent us from doing so in practice. Therefore I vote against moving this draft forward. I just don't see the point. If someone were to write an informational RFC which explained how to determine which of the 4 cases an OCSP response fell into, AND if said RFC also convinced me that the decision process was easy to understand, THEN I would change my vote. Obviously an appendix in 2560bis would serve just as well. ___ pkix mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/pkix
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Actually, what I get from this and all the other discussions is that it's unclear if the updated OCSP satisfies the suitability for the intended purpose test. Or at least it fails the KISS principle w.r.t. that. Rephrasing: an OCSP client should be able to tell from an OCSP response if: a) the subject cert is on the CAs white list, b) the subject cert is on the CAs black list, c) the subject cert is not on either list, or finally d) the OCSP server is obsolete, and doesn't support making those distinctions. It's not trivial to see how to parse 2560bis responses w.r.t. those cases, therefore it's highly likely that computational complexity will prevent us from doing so. Even if that's not actually the case, then implementor misunderstandings will prevent us from doing so in practice. Therefore I vote against moving this draft forward. I just don't see the point. If someone were to write an informational RFC which explained how to determine which of the 4 cases an OCSP response fell into, AND if said RFC also convinced me that the decision process was easy to understand, THEN I would change my vote. Obviously an appendix in 2560bis would serve just as well.
RE: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
+1. -Original Message- From: pkix-boun...@ietf.org [mailto:pkix-boun...@ietf.org] On Behalf Of Henry B. Hotz Sent: Monday, April 08, 2013 1:35 PM To: Sean Turner Cc: p...@ietf.org; ietf@ietf.org Subject: Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard Actually, what I get from this and all the other discussions is that it's unclear if the updated OCSP satisfies the suitability for the intended purpose test. Or at least it fails the KISS principle w.r.t. that. Rephrasing: an OCSP client should be able to tell from an OCSP response if: a) the subject cert is on the CAs white list, b) the subject cert is on the CAs black list, c) the subject cert is not on either list, or finally d) the OCSP server is obsolete, and doesn't support making those distinctions. It's not trivial to see how to parse 2560bis responses w.r.t. those cases, therefore it's highly likely that computational complexity will prevent us from doing so. Even if that's not actually the case, then implementor misunderstandings will prevent us from doing so in practice. Therefore I vote against moving this draft forward. I just don't see the point. If someone were to write an informational RFC which explained how to determine which of the 4 cases an OCSP response fell into, AND if said RFC also convinced me that the decision process was easy to understand, THEN I would change my vote. Obviously an appendix in 2560bis would serve just as well. ___ pkix mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/pkix
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP to Proposed Standard
On 3/27/13 5:35 PM, Denis wrote: First of all, this is an announcement: I am retiring from Bull at the end of this week, this why I am now using a new email address. Hopefully, you'll still find time in your retirement to keep on PKIXing! The second announcement is that I am taking one full month off (vacations) and will be traveling in Asia. So, I will not be able to respond quickly on the list. I am getting bored of 2560bis which was started more than 3 years ago and everybody in the WG is getting bored too. I agree it's time to get this one done. However, it is the last chance to correct what is still incorrect in the draft. There are some changes warranted by these comments. Some are already addressed in v16. Some I don't see consensus around making. During the PKIX WG last call, Stefan Santesson replied to many of my comments with Not broken, meaning that it considered that the current wording did not have such problems that it merits a change. I said that it would have been a waste of time for both of us to argue again at the WG level and thus that I will resend these comments during the IETF LC. We are now at that stage. The 11 comments were originally numbered 2, 3, 7, 10, 12, 14, 15, 16, 17, 25 and 27. I have kept the same numbering. *Comment 2 Here we're talking about the protocol overview section, which is where authors usually say things like my protocol is great and here's why. The text says: OCSP may be used to satisfy some of the operational requirements of providing more timely revocation information ... I'm not hearing a bunch of implementers saying the overview is confusing and they're being unfairly swayed/tricked in to implementing OCSP over CRLs; All thanks to that goes to the US DoD and their monolithic CRLs. The current text from section 2 states: 2. Protocol Overview In lieu of or as a supplement to checking against a periodic CRL, it may be necessary to obtain*timely information* regarding the revocation status of a certificate (cf. RFC5280], Section 3.3). Examples include high-value funds transfer or large stock trades. The Online Certificate Status Protocol (OCSP) enables applications to determine the (revocation) state of an identified certificate. OCSP may be used to satisfy some of the operational requirements of providing*more timely revocation information* than is possible with CRLs and may also be used to obtain additional status information. This text is misleading because readers may think that OCPS necessarily provides “timely information”. Proposed text replacement: *The Online Certificate Status Protocol (OCSP) is a client-server * *protocol which enables applications to obtain the revocation status * *of one or more certificates either good, revoked, or unknown.* *The revocation status may be provided by the server either using a * *real time access to a database of issued certificates, or using a * *batch access to a database of issued certificates, or using a * *real time access to a database of revocation statuses of issued * *certificates, or using a batch access to a database of revocation * *statuses of issued certificates, or using CRLs, or using a * *combination of base CRLs and delta CRLs.* *In the first case, it is possible to obtain timely revocation status * *information, whereas in the other cases, the freshness of the * *revocation status is not better than the mechanisms it is based on.* Stefan answered “Not broken” and added “may does not mean necessarily. This does not solve the issue since the text is misleading an OCSP server may only use CRLs and then it does not provides timely information since the information it provides is not better that CRLs. How can a normal reader guess this ? *Comment 3* Addressed by in v16. The current text from section 2 states: *An OCSP client issues a status request to an OCSP responder and* *Suspends acceptance of the certificate in question until the* *responder provides a response.* * * *This protocol specifies the data that needs to be exchanged between* *an application checking the status of a certificate and the server* *providing that status.* Thus is insufficient for an overview. More details are needed to know what the document provides, in particular that the request may contain several requests for several certificates issued by different CAs. The possibility of using extensions should also be advertised. Proposed text replacement: *When using OCSP, an OCSP client issues a certificate revocation *** *status request to an OCSP responder for one or more certificates *** *issued by the same CA or for one or more certificates issued by *** *different CAs and then suspends acceptance of the certificate(s) *** *in question until the responder provides a response.*** ** *This document specifies the data that needs to be exchanged between*** *an application checking the status of a
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Martin, I went all the way to Sam's original message about his discuss on the draft that became RFC 5019: https://www.ietf.org/mail-archive/web/pkix/current/msg03627.html and reviewed the 60 or so messages in the thread. Aside: I think when you're referring to updating RFC 5019 you're referring to the updates header. I'd not put a lot of weight in the presence or absence of the updates header. The IESG has waffled including it, authors forgetting about including it, etc. What's clear in the thread was that there was a WGLC issued with the understanding that pre-RFC 5109 was going update the semantics of the error code in RFC 2560. I can't find any objections and the WG consensus was to proceed. Should the header have been added - maybe, but I don't actually find any messages asking for it to be added and push back on it. What the text in 5019 says is that this profile extends the RFC 2560 [OCSP] definition of unauthorized as follows: Your issue, at least to me, seems to be that you'd prefer that new error codes be defined instead of double-upping on unauthorized error. I've been letting this exchange go to see if anybody else rallies to your flag (i.e., joins your cause, gets on your bandwagon, etc). I've not seen that and I think you're in the rough here. But, as one of my fellow ADs constantly reminds everyone, one person can blow up consensus if they're right. So... I think all of this is based on your message to PKIX in late January: The unauthorized response of rfc2560 means this is not a public service, and your OCSP request is outside of our terms-of-service. Go away. I think you're reading a whole lot in to definition from RFC 2560: The response unauthorized is returned in cases where the client is not authorized to make this query to this server. I find it really hard to make the leap to if client sends a request to a non-public server and continues to request status information that it means they've violated the terms of use of the private server and by doing so the client has committed a crime. If we're about interoperability, then I'm waiting for those that think this change breaks things. To date I've not see folks say that it does. Yes, this is all an odd way to use an error code for application specific reasons. However, there really is no point is us moving away from that (again, admittedly odd) behavior if there's no sign that any client will be updated for this. The lack of implementers backing your point seems to put you even deeper in the rough. Unless I've misconstrued something, that's the rough consensus. spt On 3/23/13 2:52 AM, Martin Rex wrote: The IESG wrote: 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. I'm having an issue with a subtle, backwards-incompatible change of the semantics of the exception case with the error code unauthorized, which tries to rewrite history 13 years into the without actually fitting the OCSP spec. It's about the second change from the introduction: o Section 2.3 extends the use of the unauthorized error response, as specified in [RFC5019]. While it is true that the error code abuse originally first appeared in rfc5019, the change was never declared as an update to rfc2560, nor filed as an errata to rfc2560. The original Exception cases in rfc2560 define the following semantics: http://tools.ietf.org/html/rfc2560#section-2.3 2.3 Exception Cases In case of errors, the OCSP Responder may return an error message. These messages are not signed. Errors can be of the following types: -- malformedRequest -- internalError -- tryLater -- sigRequired -- unauthorized [...] The response sigRequired is returned in cases where the server requires the client sign the request in order to construct a response. The response unauthorized is returned in cases where the client is not authorized to make this query to this server. The proposed extended semantics from the rfc2560bis draft: http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-15#page-9 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). The rfc5019 semantics The server can not provide an authoritative response to this specific request is incompatible with the semantics you are not authorized to sumbit OCSP requests to this service. There is another serious conflict with the rfc5019
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
On 3/27/13 10:11 PM, Martin Rex m...@sap.com wrote: It was the Security co-AD Russ Housley who indicated _early_ during the discussion of that draft (2.5 years after it had been adopted as a WG item) that he considered some of the suggested abuses of existing error codes unacceptable For the record. Russ comment was: I find the use of unauthorized to indicate that a client cannot make a multi-certificate request unacceptable. Which is completely different from your raised concern. /Stefan
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Stefan Santesson wrote:
Martin Rex m...@sap.com wrote:
Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7),
single_requests_only(8), unsupported_extension(8) } with well-defined and
conflict-free semantics to the existing enum would be perfectly backwards
compatible.
Of course it is backwards compatible with the standard, but not with the
installed base.
What would happen to the installed base of clients if OCSP responders
would change from current unauthorized to one of your new error codes?
Actually, please look at the I-D text again. Even if the Servers would
change their response to a new error code for the I can not respond
authoritatively, it will be 100% backwards compatible with the clients.
That is at least what proposed change implies!
So lets assign new error codes and have Server change their response!
Backwards compatibility is relevant in the same fashion as interoperability
-- interoperability among independent implementations as well as interop
between new implementations and the installed base.
Since the current change only conveys information, and does that in
an extremely ambiguous fashion, moving to a new error code is provably
NOT going to be any problem to interop, The desired client behaviour
is completely unspecified, so *ANY* client behaviour will be acceptable.
Based on the current text, your claim must be bogus, that assignment of
new error codes for this purpose would be backwards incompatible.
What I can not yet completely rule out, though, is that there are some
currently unstated expectations / desired behaviour that you would
want to retain, and which is currently undocumented. Should that be
the case, then it is paramount that any such expectation about desired
behaviour is ADDED to the document, in order to enable interop with
independent implementations.
It is conceivable that such desired/expected behaviour consists of some
kind of blacklisting that had been previously implemented for the
unauthorized(7) error code, and that the inventors of the rfc5019
profile (VeriSign and Microsoft) wanted to take advantage of.
Should that be the case, then I would really be curious what kind of
blacklisting that is that implementors are thinking of when they
express their concern a move to a newly assigned error code would
be backwards incompatible. Is it about the caching of that responses
on clients? Is there any negative response caching? Are negative
responses cached per server or per (requested) certificate status?
-Martin
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
It is risky to assume that existing clients would work appropriately if
you send them a new never seen before error code.
I'm not willing to assume that unless a big pile of current implementers
assures me that this is the case.
/Stefan
On 3/27/13 3:14 PM, Martin Rex m...@sap.com wrote:
Stefan Santesson wrote:
Martin Rex m...@sap.com wrote:
Adding 3 more OCSPResponseStatus error codes {
no_authoritative_data(7),
single_requests_only(8), unsupported_extension(8) } with well-defined
and
conflict-free semantics to the existing enum would be perfectly
backwards
compatible.
Of course it is backwards compatible with the standard, but not with the
installed base.
What would happen to the installed base of clients if OCSP responders
would change from current unauthorized to one of your new error codes?
Actually, please look at the I-D text again. Even if the Servers would
change their response to a new error code for the I can not respond
authoritatively, it will be 100% backwards compatible with the clients.
That is at least what proposed change implies!
So lets assign new error codes and have Server change their response!
Backwards compatibility is relevant in the same fashion as
interoperability
-- interoperability among independent implementations as well as interop
between new implementations and the installed base.
Since the current change only conveys information, and does that in
an extremely ambiguous fashion, moving to a new error code is provably
NOT going to be any problem to interop, The desired client behaviour
is completely unspecified, so *ANY* client behaviour will be acceptable.
Based on the current text, your claim must be bogus, that assignment of
new error codes for this purpose would be backwards incompatible.
What I can not yet completely rule out, though, is that there are some
currently unstated expectations / desired behaviour that you would
want to retain, and which is currently undocumented. Should that be
the case, then it is paramount that any such expectation about desired
behaviour is ADDED to the document, in order to enable interop with
independent implementations.
It is conceivable that such desired/expected behaviour consists of some
kind of blacklisting that had been previously implemented for the
unauthorized(7) error code, and that the inventors of the rfc5019
profile (VeriSign and Microsoft) wanted to take advantage of.
Should that be the case, then I would really be curious what kind of
blacklisting that is that implementors are thinking of when they
express their concern a move to a newly assigned error code would
be backwards incompatible. Is it about the caching of that responses
on clients? Is there any negative response caching? Are negative
responses cached per server or per (requested) certificate status?
-Martin
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Stefan Santesson wrote: It is risky to assume that existing clients would work appropriately if you send them a new never seen before error code. I'm not willing to assume that unless a big pile of current implementers assures me that this is the case. As I wrote: As long as the spec is _entirely_silent_ about expected/desirable behaviour of the client on receipt of a repurposed unauthorized(7) OCSPResponseStatus, the new error code with be provable backwards compatible within the definition of the specification, because *ANY* client behaviour will formally provable meet the spec and therefore be interoperable. How indiviual OCSP clients behave in particular, and whether all implementors appreciate the behaviour of their own implementation will then be _irrelevant_. ... which is why I believe that leaving client behaviour for the receipt of OCSPResponseStatus error code entirely unspecified is a bad idea, and for the repurposed unauthorized(7) it's a really bad idea. rfc5019 only talks about caching of signed OCSP responses: http://tools.ietf.org/html/rfc5019#section-6.1 -Martin
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Sam Hartman wrote: Martin Rex wrote: Oh, here is a message from the Security AD back then (Sam Hartman), commenting on requirements for rfc2560bis (the I-D under last call right now!): http://www.ietf.org/mail-archive/web/pkix/current/msg03515.html To be clear, I didn't comment on which error codes were overloaded to do what. My point was simply that there needs to be a minimal set of client behavior that is guaranteed to work (if permitted by responder policy) with any responder. That's the level of interoperability we generally require from our specs. It sounds like Martin would like to be able to distinguish three client behaviors: 1) Use less of the spec and send me a simpler request 2) I can't help you with this particular request 3) Please go away and never come back That's a fine desire. In my opinion, it's also fine for us to decide for interoperability, simplicity or other reasons that we're combining all that into one error and clients don't get to make this distinction. True. It was the Security co-AD Russ Housley who indicated _early_ during the discussion of that draft (2.5 years after it had been adopted as a WG item) that he considered some of the suggested abuses of existing error codes unacceptable: http://www.ietf.org/mail-archive/web/pkix/current/msg03570.html So far, I haven't found any arguments that could reasonably invalidate Russ' initial assessment on the unacceptable the error code abuse, i.e. any kind of transparent trade-off and the facts it could be based on. Looking as Russ' comment again, I check the documents again on the exact behaviour required from an rfc5019 server when receiving an OCSP request with a requestList. Myself, I'm surprised and confused by the answer: the rfc5019 server is prohibited from returning an error! rfc2560 neither provides and option nor an error code to refuse a response based on the presence of multiple entries in request list. The limit of a single entry in the requestList ist *CLEARLY* limited to clients conforming to the rfc5019 profile, it is neither limited to the requests sent to rfc5019 servers, nor does it apply to rfc5019 servers themselves - this profile ensures interoperability with a fully conformant OCSP 2560 client: http://tools.ietf.org/html/rfc5019#page-4 End of Section 1: In the case where 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. 2.1.1. OCSPRequest Structure OCSPRequests conformant to this profile MUST include only one Request in the OCSPRequest.RequestList structure. Other than what I had assumed from Russ' message about unacceptable error code abuse, rfc5019 does not define what kind or error code to (ab)use if a request contains more than one entry in requestList, and contains this explicit guidance: http://tools.ietf.org/html/rfc5019#section-2.2.1 2.2.1. OCSPResponse Structure In the case where a responder does not have the ability to respond to an OCSP request containing a option not supported by the server, it SHOULD return the most complete response it can. For example, in the case where a responder only supports pre-produced responses and does not have the ability to respond to an OCSP request containing a nonce, it SHOULD return a response that does not include a nonce. But when there are multiple entries received in a requestList from a fully conformant OCSP 2560 client, to which rfc5019 allegedly ensures interoperability, then the option to return unauthorized to indicate inability to obtain authoritative information, and results in self-contraditory design. I strongly believe this stuff needs some housekeeping applied. The currently proposed minimal change of the description for the unauthorized error code in rfc2560bis is only going to make the mess worse, this is neither a solution, nor an improvement to anything. -Martin
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Unfortunately what you suggest would not be backwards compatible, and can't be done within the present effort. Responders using 5019 need to work in foreseeable time with legacy clients that knows nothing about the update you suggest. This group and the IETF made a decision when publishing 5019, that using unauthorized in the present manner was a reasonable tradeoff. I still think it is. Unless you can convince the community of your course of action, I don't see this happening. /Stefan On 3/26/13 6:28 AM, Martin Rex m...@sap.com wrote: Stefan Santesson wrote: Whether we like it or not. This is the legacy. There is no way for a client to know whether the OCSP responder implements RFC 2560 only or in combination with RFC 5019. So therefore, the update that was introduced in 5019 must be expected by all clients from all responders. Therefore it is included in 2560bis. What in your mind, would be a better solution? Simply listing two mutually exclusive semantics for a single error code looks like a very bad idea. The correct solution would be to assign a new error code for the semantics desirec by rfc5019 and fix rfc5019 and its implementiations. And then mention the rfc5019 semantics for the error code unauthorized in rfc2560bis as defective and deprecated. rfc5019 is hardwired to SHA1 for the cert hashing algorithm, so it will need to get updated at some point already. The second issue is to explain that the errorcode response for can not produce an authoritative response is not applicable to OCSPRequests that contain more than one element in the requestList, because the OCSP client will not know to which elements in the request the error code response applies. Actually, it would be sensible to define two more new error codes, one that indicates that the OCSP server does not support multiple requestList entries, and one that indicates to the client that the server does not support one of the OCSP protocol extensions requested by the client (multiple requests is not a protocol extension). -Martin On 3/23/13 7:52 AM, Martin Rex m...@sap.com wrote: The IESG wrote: 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. I'm having an issue with a subtle, backwards-incompatible change of the semantics of the exception case with the error code unauthorized, which tries to rewrite history 13 years into the without actually fitting the OCSP spec. It's about the second change from the introduction: o Section 2.3 extends the use of the unauthorized error response, as specified in [RFC5019]. While it is true that the error code abuse originally first appeared in rfc5019, the change was never declared as an update to rfc2560, nor filed as an errata to rfc2560. The original Exception cases in rfc2560 define the following semantics: http://tools.ietf.org/html/rfc2560#section-2.3 2.3 Exception Cases In case of errors, the OCSP Responder may return an error message. These messages are not signed. Errors can be of the following types: -- malformedRequest -- internalError -- tryLater -- sigRequired -- unauthorized [...] The response sigRequired is returned in cases where the server requires the client sign the request in order to construct a response. The response unauthorized is returned in cases where the client is not authorized to make this query to this server. The proposed extended semantics from the rfc2560bis draft: http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-15#page-9 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). The rfc5019 semantics The server can not provide an authoritative response to this specific request is incompatible with the semantics you are not authorized to sumbit OCSP requests to this service. There is another serious conflict with the rfc5019 repurposed error code semantics and rfc2560. While rfc5019 is limited to a single status request, rfc2560 and rfc2560bis both allow a list of several Requests to be sent in a single OCSPRequest PDU. An OCSP response, however, is not allowed to contain responseBytes when an error code is returned inthe response status: http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-15#section-4.2.1 4.2.1 ASN.1 Specification of the OCSP Response An OCSP response at a minimum consists of a responseStatus
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Stefan Santesson wrote:
Unfortunately what you suggest would not be backwards compatible,
and can't be done within the present effort.
I'm sorry, I can not follow your arguments.
Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7),
single_requests_only(8), unsupported_extension(8) } with well-defined and
conflict-free semantics to the existing enum would be perfectly backwards
compatible.
Whether and when implementations of rfc5019 or its successor can make
use of additional error codes with well-defined semantics is a seperate
issue.
Sending multiple entries in a requestList is a perfectly valid client
option in rfc2560. rfc5019 has a requirement for single entries.
What response does rfc5019 define in case that it receives an OCSP request
with multiple entries in requestList.
Keep in mind that OCSP responders are typically located through
Authority Identifier Access id-ad-ocsp, and that cert extension is
specified to provide for the conventions of rfc2560 -- *NOT* the subset
of rfc5019:
http://tools.ietf.org/html/rfc5280#page-51
The id-ad-ocsp OID is used when revocation information for the
certificate containing this extension is available using the Online
Certificate Status Protocol (OCSP) [RFC2560].
When id-ad-ocsp appears as accessMethod, the accessLocation field is
the location of the OCSP responder, using the conventions defined in
[RFC2560].
Responders using 5019 need to work in foreseeable time with legacy clients
that knows nothing about the update you suggest.
This group and the IETF made a decision when publishing 5019, that using
unauthorized in the present manner was a reasonable tradeoff.
I still think it is.
Could you point me to any kind of discussion of this tradeoff?
I'm having difficulties finding that information.
The first draft that became rfc5019 seems to have appeared here:
http://www.ietf.org/mail-archive/web/pkix/current/msg17432.html
and it already contained the abuse of the unauthorized(7) error code.
I see a first complaint on the mailing list about the error code abuse here
on 02-Nov-2004:
http://www.ietf.org/mail-archive/web/pkix/current/msg17270.html
but the reponse is -crickets-.
In what way is the client going to treat unauthorized(6) special and
different from other error codes, such as internalError(2) or
malformedRequest(3), and where in rfc5019 is that special behaviour
defined?
-Martin
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
On 3/26/13 12:13 PM, Martin Rex m...@sap.com wrote:
Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7),
single_requests_only(8), unsupported_extension(8) } with well-defined and
conflict-free semantics to the existing enum would be perfectly backwards
compatible.
Of course it is backwards compatible with the standard, but not with the
installed base.
What would happen to the installed base of clients if OCSP responders
would change from current unauthorized to one of your new error codes?
/Stefan
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Following up to myself:
The real discussion seemed to have started in 2006...
Some folks had a pretty reasonable opinion at some point of the discussion,
e.g. Russ Houseley:
http://www.ietf.org/mail-archive/web/pkix/current/msg03570.html
and then there is lots of real dirty horse-trading in the PKIX discussion.
Oh, here is a message from the Security AD back then (Sam Hartman),
commenting on requirements for rfc2560bis (the I-D under last call right now!):
http://www.ietf.org/mail-archive/web/pkix/current/msg03515.html
What I don't understand: during the PKIX discussion there seemed to
be some consensus that a prerequisite to abuse the unauthorized(6)
would an update of rfc2560 would be required.
But rfc5019 *NEVER* updated rfc2560!!
But what puzzles me most is why is there a problem with defining new
error codes in the first place?
In order to NEVER EVER have such a problem again in any future IETF
spec, there should be a requirement for error code partioning upfront
into good, temporary and final, and there should be reserved error code
points that clients will have to handle gracefully and well-behaved
when they receive it.
I find it most difficult to believe that there are OCSP clients out there
that would crash and burn if they received an OCSPResponseStatus (7),(8)
or (9), rather than an unauthorized(6), undefined or a different undefined
return code for the underspecified error situations created by rfc5019
(and rfc2560, as Sam correctly points out).
Should there be such broken clients, then you really do not want to use
them in the first place, because *EVERYONE* can feed those OCSP clients
arbitrary error codes in unsigned OCSPResponses.
-Martin
Martin Rex wrote:
Stefan Santesson wrote:
Unfortunately what you suggest would not be backwards compatible,
and can't be done within the present effort.
I'm sorry, I can not follow your arguments.
Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7),
single_requests_only(8), unsupported_extension(8) } with well-defined and
conflict-free semantics to the existing enum would be perfectly backwards
compatible.
Whether and when implementations of rfc5019 or its successor can make
use of additional error codes with well-defined semantics is a seperate
issue.
Sending multiple entries in a requestList is a perfectly valid client
option in rfc2560. rfc5019 has a requirement for single entries.
What response does rfc5019 define in case that it receives an OCSP request
with multiple entries in requestList.
Keep in mind that OCSP responders are typically located through
Authority Identifier Access id-ad-ocsp, and that cert extension is
specified to provide for the conventions of rfc2560 -- *NOT* the subset
of rfc5019:
http://tools.ietf.org/html/rfc5280#page-51
The id-ad-ocsp OID is used when revocation information for the
certificate containing this extension is available using the Online
Certificate Status Protocol (OCSP) [RFC2560].
When id-ad-ocsp appears as accessMethod, the accessLocation field is
the location of the OCSP responder, using the conventions defined in
[RFC2560].
Responders using 5019 need to work in foreseeable time with legacy clients
that knows nothing about the update you suggest.
This group and the IETF made a decision when publishing 5019, that using
unauthorized in the present manner was a reasonable tradeoff.
I still think it is.
Could you point me to any kind of discussion of this tradeoff?
I'm having difficulties finding that information.
The first draft that became rfc5019 seems to have appeared here:
http://www.ietf.org/mail-archive/web/pkix/current/msg17432.html
and it already contained the abuse of the unauthorized(7) error code.
I see a first complaint on the mailing list about the error code abuse here
on 02-Nov-2004:
http://www.ietf.org/mail-archive/web/pkix/current/msg17270.html
but the reponse is -crickets-.
In what way is the client going to treat unauthorized(6) special and
different from other error codes, such as internalError(2) or
malformedRequest(3), and where in rfc5019 is that special behaviour
defined?
-Martin
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Stefan Santesson wrote:
On 3/26/13 12:13 PM, Martin Rex m...@sap.com wrote:
Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7),
single_requests_only(8), unsupported_extension(8) } with well-defined and
conflict-free semantics to the existing enum would be perfectly backwards
compatible.
Of course it is backwards compatible with the standard, but not with the
installed base.
What would happen to the installed base of clients if OCSP responders
would change from current unauthorized to one of your new error codes?
As it was already mentinoned here:
http://www.ietf.org/mail-archive/web/pkix/current/msg04489.html
I would no longer get a popup from my OCSP client that tells my
that I'm unauthorized to submit OCSPRequests to that server, and that
the server has been moved to a blacklist, and that I will have to
manually enable this server after obtaining proper authorization
before my client will send any further requests that OCSP server.
No longer being interactively bothered about this error seems like a
very valuable improvement!
-Martin
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
What OCSP client are you using that behaves like this? On 3/26/13 1:09 PM, Martin Rex m...@sap.com wrote: I would no longer get a popup from my OCSP client that tells my that I'm unauthorized to submit OCSPRequests to that server, and that the server has been moved to a blacklist
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Stefan Santesson wrote: What OCSP client are you using that behaves like this? On 3/26/13 1:09 PM, Martin Rex m...@sap.com wrote: I would no longer get a popup from my OCSP client that tells my that I'm unauthorized to submit OCSPRequests to that server, and that the server has been moved to a blacklist Every sensible implementation of rfc2560 that does not happen to be based on rfc5019. I knew about rfc2560 for several years, but I only learned about the existence of rfc5019 a few weeks ago -- because of the bogus change to the unauthorized semantics in the rfc2560bis I-D. -Martin
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
I take it that the answer to my question is none. Which is what I suspected. The semantics of unauthorized does not give you the basis for such functionality. And 5019 is very widely deployed. I'm going to sep down from this discussion and see how it goes. It is not me you have to convince. It's the community of implementers. /Stefan On 3/26/13 1:39 PM, Martin Rex m...@sap.com wrote: Stefan Santesson wrote: What OCSP client are you using that behaves like this? On 3/26/13 1:09 PM, Martin Rex m...@sap.com wrote: I would no longer get a popup from my OCSP client that tells my that I'm unauthorized to submit OCSPRequests to that server, and that the server has been moved to a blacklist Every sensible implementation of rfc2560 that does not happen to be based on rfc5019. I knew about rfc2560 for several years, but I only learned about the existence of rfc5019 a few weeks ago -- because of the bogus change to the unauthorized semantics in the rfc2560bis I-D. -Martin
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Stefan Santesson wrote: I take it that the answer to my question is none. Why would an rfc5019 client have a problem with a (7) instead of (6) OCSPResponseStatus? And what about an error code for only a single request that rfc5019 fails to specify. Which is what I suspected. The semantics of unauthorized does not give you the basis for such functionality. And 5019 is very widely deployed. The way I read this message from the security AD back then: http://www.ietf.org/mail-archive/web/pkix/current/msg03515.html rfc5019 was only passed on the promise from PKIX that it would clean up rfc2560bis -- the I-D under last call here. So the IESG should return this I-D to PKIX and have them provide the updates that they agreed to do. -Martin
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Martin == Martin Rex m...@sap.com writes: Martin Oh, here is a message from the Security AD back then (Sam Martin Hartman), commenting on requirements for rfc2560bis (the I-D Martin under last call right now!): Martin http://www.ietf.org/mail-archive/web/pkix/current/msg03515.html To be clear, I didn't comment on which error codes were overloaded to do what. My point was simply that there needs to be a minimal set of client behavior that is guaranteed to work (if permitted by responder policy) with any responder. That's the level of interoperability we generally require from our specs. It sounds like Martin would like to be able to distinguish three client behaviors: 1) Use less of the spec and send me a simpler request 2) I can't help you with this particular request 3) Please go away and never come back That's a fine desire. In my opinion, it's also fine for us to decide for interoperability, simplicity or other reasons that we're combining all that into one error and clients don't get to make this distinction.
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Sam Hartman wrote: Martin Rex m...@sap.com writes: Martin http://www.ietf.org/mail-archive/web/pkix/current/msg03515.html To be clear, I didn't comment on which error codes were overloaded to do what. My point was simply that there needs to be a minimal set of client behavior that is guaranteed to work (if permitted by responder policy) with any responder. That's the level of interoperability we generally require from our specs. It sounds like Martin would like to be able to distinguish three client behaviors: 1) Use less of the spec and send me a simpler request 2) I can't help you with this particular request 3) Please go away and never come back That's a fine desire. In my opinion, it's also fine for us to decide for interoperability, simplicity or other reasons that we're combining all that into one error and clients don't get to make this distinction. When the rfc2560 semantics of unauthorized(6) and the rfc5019 semantics of unauthorized(6) are merged into one, then this error code ought to be renamed to whatever(6), because it will be impossible for a client to know what a server really meant! Whether an OCSP responder is rfc2560 compliant or whether it adheres to rfc5019 subset can neither be determined from the id-ad-ocsp AIA information of an X.509v3 certificate nor from an OCSPResponse that conveys a responseStatus (6). Why don't we add sensible, well-defined OCSPResponseStatus error code now during rfc2560bis, and see how and when we can make appropriate use of those in clients. -Martin
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Martin,
Whether we like it or not. This is the legacy.
There is no way for a client to know whether the OCSP responder implements
RFC 2560 only or in combination with RFC 5019.
So therefore, the update that was introduced in 5019 must be expected by
all clients from all responders. Therefore it is included in 2560bis.
What in your mind, would be a better solution?
/Stefan
On 3/23/13 7:52 AM, Martin Rex m...@sap.com wrote:
The IESG wrote:
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.
I'm having an issue with a subtle, backwards-incompatible change
of the semantics of the exception case with the error code
unauthorized, which tries to rewrite history 13 years into the
without actually fitting the OCSP spec.
It's about the second change from the introduction:
o Section 2.3 extends the use of the unauthorized error
response, as specified in [RFC5019].
While it is true that the error code abuse originally first appeared
in rfc5019, the change was never declared as an update to rfc2560,
nor filed as an errata to rfc2560.
The original Exception cases in rfc2560 define the following semantics:
http://tools.ietf.org/html/rfc2560#section-2.3
2.3 Exception Cases
In case of errors, the OCSP Responder may return an error message.
These messages are not signed. Errors can be of the following types:
-- malformedRequest
-- internalError
-- tryLater
-- sigRequired
-- unauthorized
[...]
The response sigRequired is returned in cases where the server
requires the client sign the request in order to construct a
response.
The response unauthorized is returned in cases where the client is
not authorized to make this query to this server.
The proposed extended semantics from the rfc2560bis draft:
http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-15#page-9
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).
The rfc5019 semantics The server can not provide an authoritative
response
to this specific request is incompatible with the semantics you are not
authorized to sumbit OCSP requests to this service.
There is another serious conflict with the rfc5019 repurposed error code
semantics and rfc2560. While rfc5019 is limited to a single status
request,
rfc2560 and rfc2560bis both allow a list of several Requests to
be sent in a single OCSPRequest PDU. An OCSP response, however, is
not allowed to contain responseBytes when an error code is returned
inthe response status:
http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-15#section-4.2.1
4.2.1 ASN.1 Specification of the OCSP Response
An OCSP response at a minimum consists of a responseStatus field
indicating the processing status of the prior request. If the value
of responseStatus is one of the error conditions, responseBytes are
not set.
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
So it is impossible to convey OCSP responder is not capable of
responding authoritatively for a subset of Requests in the requestList
and regular status for the remaining Requests in the List by using
a repurposed unauthorized error code.
The current draft neither mention this contradiction, nor does it
provide any guidance how an implementation should behave in this
situation.
I would appreciate if this problem of draft-*-rfc2560bis could be fixed
prior to making it a successor for rfc2560.
-Martin
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
Stefan Santesson wrote:
Whether we like it or not. This is the legacy.
There is no way for a client to know whether the OCSP responder implements
RFC 2560 only or in combination with RFC 5019.
So therefore, the update that was introduced in 5019 must be expected by
all clients from all responders. Therefore it is included in 2560bis.
What in your mind, would be a better solution?
Simply listing two mutually exclusive semantics for a single error code
looks like a very bad idea. The correct solution would be to assign
a new error code for the semantics desirec by rfc5019 and fix rfc5019
and its implementiations. And then mention the rfc5019 semantics for
the error code unauthorized in rfc2560bis as defective and deprecated.
rfc5019 is hardwired to SHA1 for the cert hashing algorithm, so
it will need to get updated at some point already.
The second issue is to explain that the errorcode response for can not
produce an authoritative response is not applicable to OCSPRequests
that contain more than one element in the requestList, because the
OCSP client will not know to which elements in the request the error
code response applies.
Actually, it would be sensible to define two more new error codes,
one that indicates that the OCSP server does not support multiple
requestList entries, and one that indicates to the client that the
server does not support one of the OCSP protocol extensions requested
by the client (multiple requests is not a protocol extension).
-Martin
On 3/23/13 7:52 AM, Martin Rex m...@sap.com wrote:
The IESG wrote:
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.
I'm having an issue with a subtle, backwards-incompatible change
of the semantics of the exception case with the error code
unauthorized, which tries to rewrite history 13 years into the
without actually fitting the OCSP spec.
It's about the second change from the introduction:
o Section 2.3 extends the use of the unauthorized error
response, as specified in [RFC5019].
While it is true that the error code abuse originally first appeared
in rfc5019, the change was never declared as an update to rfc2560,
nor filed as an errata to rfc2560.
The original Exception cases in rfc2560 define the following semantics:
http://tools.ietf.org/html/rfc2560#section-2.3
2.3 Exception Cases
In case of errors, the OCSP Responder may return an error message.
These messages are not signed. Errors can be of the following types:
-- malformedRequest
-- internalError
-- tryLater
-- sigRequired
-- unauthorized
[...]
The response sigRequired is returned in cases where the server
requires the client sign the request in order to construct a
response.
The response unauthorized is returned in cases where the client is
not authorized to make this query to this server.
The proposed extended semantics from the rfc2560bis draft:
http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-15#page-9
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).
The rfc5019 semantics The server can not provide an authoritative
response
to this specific request is incompatible with the semantics you are not
authorized to sumbit OCSP requests to this service.
There is another serious conflict with the rfc5019 repurposed error code
semantics and rfc2560. While rfc5019 is limited to a single status
request,
rfc2560 and rfc2560bis both allow a list of several Requests to
be sent in a single OCSPRequest PDU. An OCSP response, however, is
not allowed to contain responseBytes when an error code is returned
inthe response status:
http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-15#section-4.2.1
4.2.1 ASN.1 Specification of the OCSP Response
An OCSP response at a minimum consists of a responseStatus field
indicating the processing status of the prior request. If the value
of responseStatus is one of the error conditions, responseBytes are
not set.
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
So it is impossible to convey OCSP responder is not capable of
responding authoritatively for a subset of Requests in the requestList
and regular status for the remaining Requests in the List by using
a repurposed
Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
The IESG wrote:
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.
I'm having an issue with a subtle, backwards-incompatible change
of the semantics of the exception case with the error code
unauthorized, which tries to rewrite history 13 years into the
without actually fitting the OCSP spec.
It's about the second change from the introduction:
o Section 2.3 extends the use of the unauthorized error
response, as specified in [RFC5019].
While it is true that the error code abuse originally first appeared
in rfc5019, the change was never declared as an update to rfc2560,
nor filed as an errata to rfc2560.
The original Exception cases in rfc2560 define the following semantics:
http://tools.ietf.org/html/rfc2560#section-2.3
2.3 Exception Cases
In case of errors, the OCSP Responder may return an error message.
These messages are not signed. Errors can be of the following types:
-- malformedRequest
-- internalError
-- tryLater
-- sigRequired
-- unauthorized
[...]
The response sigRequired is returned in cases where the server
requires the client sign the request in order to construct a
response.
The response unauthorized is returned in cases where the client is
not authorized to make this query to this server.
The proposed extended semantics from the rfc2560bis draft:
http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-15#page-9
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).
The rfc5019 semantics The server can not provide an authoritative response
to this specific request is incompatible with the semantics you are not
authorized to sumbit OCSP requests to this service.
There is another serious conflict with the rfc5019 repurposed error code
semantics and rfc2560. While rfc5019 is limited to a single status request,
rfc2560 and rfc2560bis both allow a list of several Requests to
be sent in a single OCSPRequest PDU. An OCSP response, however, is
not allowed to contain responseBytes when an error code is returned
inthe response status:
http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-15#section-4.2.1
4.2.1 ASN.1 Specification of the OCSP Response
An OCSP response at a minimum consists of a responseStatus field
indicating the processing status of the prior request. If the value
of responseStatus is one of the error conditions, responseBytes are
not set.
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
So it is impossible to convey OCSP responder is not capable of
responding authoritatively for a subset of Requests in the requestList
and regular status for the remaining Requests in the List by using
a repurposed unauthorized error code.
The current draft neither mention this contradiction, nor does it
provide any guidance how an implementation should behave in this
situation.
I would appreciate if this problem of draft-*-rfc2560bis could be fixed
prior to making it a successor for rfc2560.
-Martin
