Subject: [pkix] Review of 2560-bis draft 8

From: "Piyush Jain" <[email-masked]>
Date: Wed, 9 Jan 2013 08:49:27 -0800

Hi list,

I just finished reviewing the latest draft. Here is the summary.

1) Text from Section 1 
"Section 4.4.8 specifies a new extension that indicates that the responder
supports the extended use of the "revoked" response for non-issued
certificates defined in section 2.2."
However, section 2.2 does not have a corresponding definition for
"non-issued certificates"

2a)  Text from  Section 2.2
"The "revoked" state indicates that the certificate has been revoked (either
permanently or temporarily (on hold)). This state MAY also be returned if
the responder knows that the requested certificate has never been issued
during the history of the associated CA using any current or previous
issuing key."

Switching the subject (state) in the second sentence makes the text
confusing. Also "never been issued" is ambiguous. Please see the comments in
Authorized responder section
Here is an alternative proposal.
"The "revoked" state indicates that either the certificate has been revoked
(either permanently or temporarily (on hold)) or the associated CA has no
record of issuance of the requested certificate." 

An even better alternative would be to allow for revoked to be extended for
any bad certificate and have the extended revoked extension specify the
actual meaning by including a OID. This document can define a OID for one of
the meanings (fraudulently issued as revoked). This leave room for
extensibility without the need to change the main document should someone
come up with another requirement to return revoked as a negative proof.

2b) Text from section 2.2
"When a responder responds revoked to a status request for a non-issued
certificate, the responder MUST also;
    - include the extended revoked definition response extension (section
4.8), indicating that the OCSP responder supports the extended definition of
revoked state to also cover non-issued  certificates,
    - provide the revocation reason certificateHold (6), and;
    - specify the revocation date January 1, 1970.
"

- IMO the above text belongs in the extension specification for extended
revoked.
- I repeat that use of non-issued is ambiguous. It will help to define what
non-issued is and to explicitly mention that a certificate signed using the
CA key can be non-issued as per this specification.
- Why force the responder to include optional revocation reason field.
Change MUST to MAY and change the text to say that if revocation reason is
included it must be set to 6.
-Reference to "revocation date" in above text is dangling. It should be
changed to "revocationTime in RevokedInfo"

3) Text from section 2.5
"nextUpdate: The time at or before which newer information will be available
about the status of the certificate"

4.2.2.1 states  - " The thisUpdate and nextUpdate fields define a
recommended validity  interval. This interval corresponds to the
{thisUpdate, nextUpdate}  interval in CRLs"
SO guidance needs to be provided for setting nextUpdate in case where
extended revoked for "non-issued" is used because the response does not
correspond to a CRL.

4) Texts from Section 4.2.2.2
"OCSP signing delegation SHALL be designated by the inclusion of
id-kp-OCSPSigning in an extendedKeyUsage certificate  extension included in
the OCSP response signer's certificate.  This   certificate MUST be issued
directly by the CA that issued the certificate in question."

The above text introduces a paradox if a response contains revoked for
non-issued certificates.
Any response that implies that certificate was not issued by the CA makes
that response non authoritative because the response is not issued by a
responder that is issued by the same CA as the one who issued the paylod
certificate.
One way to address this could be change all references to "issued" to
"signed". We should also explicitly call out that "signed" and "issued" are
not synonymous as per this draft.
Please note that "issued" is used extensively in section 4.2.2.2

5) Section 4.4.2 - CRL references
This section needs to be updated with a note that this extension is
incompatible with extended revoked and should not be included if extended
revoked is included in the response.

6) Section 4.4.5 - CRL Entry extensions
This section needs to include a note that "invalidityDate" extension should
not be included as single response extension if extended revoked is being
returned.

7) 4.4.8 - Extended revoked definition
If this extension is used to indicate responder capability, it should be
included with all responses, not just revoked.
If it is used to indicate changed meaning of revoked, it should be a single
response extension.

Also, IMO it is a misnomer to call it extended revoked. It might be more
meaningful to call it "Fraudulently Issued as revoked". Other option is to
keep the name extended revoked but allow for adding a list of OIDs that
represent the changed meaning of revoked. In current case it would be a new
id - "id-pkix-ocsp-fraudulently-issued-as-revoked". In future someone could
add id-pkix-ocsp-revoked-expired-as-revoked or
id-pkix-ocsp-ugly-moustache-as-revoked through an add-on RFC.

8) Section 2.5 - Response pre-production.
I think it will be useful to indicate that if responder choses to issue
revoked for fraudulently issued response pre-production becomes
computationally infeasible.
The note could be added here or in the section defining extended revoked.

Thoughts/comments are welcome.

-Piyush
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stefan Santesson
> Sent: Friday, January 04, 2013 1:58 AM
> To: [email-masked]
> Subject: [pkix] 2560bis WGLC
> 
> Forwarding Steve's WGLC on RFC 2560bis.
> (It was misaddressed)
> 
> 
> On 1/2/13 4:43 PM, "Stephen Kent" <[email-masked]> wrote:
> 
> >Folks,
> >
> >Stefan has just published the long-awaited 2560bis update, and has
> >requested WGLC.
> >
> >Let's begin a slightly longer WGLC, to accommodate those who may be on
> >a post-New year vacation.
> >
> >the WGLC will end on 1/20/13.
> >
> >Steve
> 
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 10 Jan 2013 09:42:13 +0100

Thanks for the review.

I will get back with comments on them.

One questions though.

Taking any random certificate serial number in the context of a CA. How
can that serial number have any status other than.

1) issued and not revoked.
2) issued and revoked (or currently on hold).
3) never issued by this CA.

This seem to be a fundamental unambiguous factual basic division of the
possible state of a serial number that is beyond question.

Then of course you can sub-divide each category into further divisions,
but every possible serial number will always fall into exactly one of
these categories.
The Responder may not know which category a serial number belongs to (may
just know whether it belongs to 2) or not), and in such case, the
discussed update is of no relevance to them.

To introduce "Bad" as a reason for responding revoked, or to be more
granular than this basic division, scares me, because there is no end to
its potential complexity and ambiguity.
I'm not against the community going further in giving more granular
information, but I'm reluctant to do it within this update.

I further can't see why a CA would treat a certificate as "bad" without
having it revoked or on hold.

What I feel less sure about is wether the extension should go into
responseExtensions or into singleExtensions. There are pros and cons with
both.

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Thu, 10 Jan 2013 05:18:19 -0800

Stefan,

Thanks for getting back. Please see inline.

> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Thursday, January 10, 2013 12:42 AM
> To: Piyush Jain; [email-masked]
> Subject: Re: Review of 2560-bis draft 8
> 
> Thanks for the review.
> 
can
> that serial number have any status other than.
> 
[Piyush] Relying parties trust certificates. They do not trust certificate
serial numbers. The question to ask is - what is the status of the
certificate, not what is the status of a certificate serial number.
"Never issued" is not a status of the certificate and RPs do not need
responders to determine issuance. (at least in OCSP context).
I have not seen an OCSP client which determines the trustworthiness of a
certificate by sending an OCSP request without verifying that the
certificate is issued by the CA. According to the spec, you cannot trust the
responder if it is not issued by the same CA as the responder.

The notion of extending revoked to imply a negative proof beyond revoked
status (through use of extensions) is fine but to allow it for only one
other kind of negative proof is limiting IMO.

> possible state of a serial number that is beyond question.
[Piyush] Think of a RP which sends a status request a certificate and
includes a request extension to check if the bank account associated with
the cert has at least 100 dollars.
Failing this check the responder could return revoked (which implies bad
according to this new update)

My personal preference is to limit OCSP for just revocation status checks
and communicate additional state information through extensions, as
originally envisioned.
However, if you are extending the meaning of revoked, allow it for any
negative proof and require that meaning of revoked (if overridden) is
communicated through a new OID in the extended revoked extension.
This spec does not need to go into the details of what those overridden
negative proofs could be. 

> Then of course you can sub-divide each category into further divisions,
but
> every possible serial number will always fall into exactly one of these
> categories.
> The Responder may not know which category a serial number belongs to
> (may just know whether it belongs to 2) or not), and in such case, the
its
> potential complexity and ambiguity.

[Piyush] That is why this update should just allow for changing the meaning
of revoked through single response extensions and let other communities
define and use those extensions.
The topic of "not issued" should not even feature in the main OCSP
specification.  

> I further can't see why a CA would treat a certificate as "bad" without
having
> it revoked or on hold.
[Piyush] On hold is just a reason code associated with revoked.
A responder can determine if the certificate is 'bad' or untrustworthy if it
is asked to perform validation under some context specified in the request
extension. 
Responders are not needed to determine issuance and people have repeatedly
asserted that fraudulently issued certs cannot be addressed by OCSP in a
secure way.
> responseExtensions or into singleExtensions. There are pros and cons with
[Piyush] Depends on what it indicates. If it is responder capability it
should be a response extension that should be sent with every response. If
it is about overloading the meaning of revoked it should be a single
response extension sent only with revoked status where the meaning has been
changed.

---

From: [email-masked] (Martin Rex)
Date: Thu, 10 Jan 2013 20:18:06 +0100 (CET)

Piyush Jain wrote:
>
> Stefan Santesson wrote:
> > 
> > Taking any random certificate serial number in the context of a CA.
> > How can that serial number have any status other than:
> > 

Exactly.

> 
> [Piyush] Relying parties trust certificates.
> They do not trust certificate serial numbers.

That is actually entirely irrelevant.  We're discussing the
OCSP protocol here (and to some extent CRLs), and these protocols are
factually about status of certificate serial numbers, NOT certificates.

(which is exactly one of the security problems of CRLs and OCSP,
 for which this change is a partial remedy...).

>
> The question to ask is - what is the status of the certificate,

That is a question/decision inside the RP.  Irrelevant to OCSP.

> 
> not what is the status of a certificate serial number.

CRLs and OCSP (the latter in its basic form), are not about certs,
they're only about certificate serial numbers.

PKIX unfortunately has the bad habit of drawing bold conclusions
from the status of certificate serial numbers.

>
> "Never issued" is not a status of the certificate

It is the status of a certificate serial number.
OCSP is about the status of certificate serial numbers.

>
> and RPs do not need responders to determine issuance.

The OCSP responder, as well as the OCSP protocol, do not care at all,
about motivations of RPs.

> responder if it is not issued by the same CA as the responder.

You might want to update your Web Browser if yours really so old that
it does not allow you to configure a local trusted OCSP responder ... ;-)

> > possible state of a serial number that is beyond question.

+1

> according to this new update)

That OCSP responder can do that today.  And even if we add a
MUST NOT for this particular example into the spec, that OCSP responder
can continue operating in this fashion, and there will be nothing
that we can do about it.  There is not IETF protocol SWAT team that
will take down a service for an IETF protocol violation (if it existed,
it would probably have to take down 99% of the internet...).

> and communicate additional state information through extensions, as

You can continue doing that in _your_ RPs and _your_ OCSP responders.
This update is not going to interfere with what you're doing in any way.

> negative proofs could be. 

It's my impression that you're misunderstanding the OCSP protocol.
Although the expanded name is "Online Certificate Status Protocol",
it really is, and always was, about the status of certificate serial
numbers, not about the status of certs.

Any other "negatives" would have to be new ReasonCode-s to be added
to X.509.

> > discussed update is of no relevance to them.

+1

> > its potential complexity and ambiguity.

+1

> > information, but I'm reluctant to do it within this update.

+1

> The topic of "not issued" should not even feature in the main OCSP

You're ~13 years late.  "not issued" is *already* part of rfc2560:

quoting from rfc2560:

   The "good" state indicates a positive response to the status inquiry.
   At a minimum, this positive response indicates that the certificate
   is not revoked, but does not necessarily mean that the certificate
   was ever issued 

This update is about fixing an inconsistency in rfc2560.

> Responders are not needed to determine issuance

(OCSP) Responders are need to convey certificate serial number status.
Conveying "good" for a certificate serial number that is positively
known to have never been issued would be stupid and wrong.

>
> and people have repeatedly asserted that fraudulently issued certs
> cannot be addressed by OCSP in a secure way.

This is the first step in standardizing how to report "non-issued"
for a certificate serial number.

You're misinterpreting the situation.  For OCSP, this approach *IS*
completely secure.

There is the problem that some of the bold/flawed assumptions of PKI(X)
evaporate for certain kind of CA security breaches.  But that could
be addressed by updating OCSP even further, eliminating the single
point of failure CA cert that is implied by OCSP AIA in the leaf cert.

> response extension sent only with revoked status where the meaning has been

I agree with that determination.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Thu, 10 Jan 2013 13:37:59 -0800

> From: Martin Rex [mailto:[email-masked]]
> Sent: Thursday, January 10, 2013 11:18 AM
> To: Piyush Jain
> Cc: 'Stefan Santesson'; [email-masked]
> Subject: Re: [pkix] Review of 2560-bis draft 8
> 
> Piyush Jain wrote:
> >
> > Stefan Santesson wrote:
> > >
> That is actually entirely irrelevant.  We're discussing the OCSP protocol
here
> (and to some extent CRLs), and these protocols are factually about status
of
> certificate serial numbers, NOT certificates.
> 
[Piyush] I'm surprised by your interpretation of these specs. My simple
advice - don't trust the certificate if OCSP responder says it is good. Make
sure it chains to a trust anchor.
CA hash and serial combined is representation of the certificate. 

> (which is exactly one of the security problems of CRLs and OCSP,  for
which
> this change is a partial remedy...).
> 
>
[Piyush] You allude to this problem again and again. Please lay out a use
case that captures the problem and tell us how this update addresses the
problem. 
 
> That is a question/decision inside the RP.  Irrelevant to OCSP.
[Piyush] I don't get it. RP uses OCSP to determine the status of a
certificate and it is irrelevant to OCSP?
> CRLs and OCSP (the latter in its basic form), are not about certs, they're
only
> about certificate serial numbers.
> 
> PKIX unfortunately has the bad habit of drawing bold conclusions from the
> status of certificate serial numbers.
> 
> 
> >
about
> motivations of RPs.

[Piyush] Really. I thought that the protocol and responders exist primarily
to address one motivation of RPs - to get correct revocation status of a
certificate.
> 
> >
> > I have not seen an OCSP client which determines the trustworthiness of
> > a certificate by sending an OCSP request without verifying that the
> > certificate is issued by the CA. According to the spec, you cannot
> > trust the responder if it is not issued by the same CA as the responder.
> 
> You might want to update your Web Browser if yours really so old that it
does
> not allow you to configure a local trusted OCSP responder ... ;-)
> 
> 
[Piyush] Silly me - So I can assume that you support addition of text that
says that CA delegated responders should not issue extended revoked
responses.;)
 
> >
> > > This seem to be a fundamental unambiguous factual basic division of
> > > the possible state of a serial number that is beyond question.
> 
> +1
> 
> 
> >
> > includes a request extension to check if the bank account associated
> > with the cert has at least 100 dollars.
> > Failing this check the responder could return revoked (which implies
> > bad according to this new update)
> 
> That OCSP responder can do that today.  And even if we add a MUST NOT for
> this particular example into the spec, that OCSP responder can continue
> operating in this fashion, and there will be nothing that we can do about
it.
> There is not IETF protocol SWAT team that will take down a service for an
IETF
> protocol violation (if it existed, it would probably have to take down 99%
of
> the internet...).

[Piyush] We are agreeing on quite a few things here.  So what is the need
for this update. OCSP responders can respond with revoked for non-issued or
fraudulently issued certificates today. There is not IETF protocol SWAT team
that will take down a service for an IETF protocol violation (if it existed,
it would probably have to take down 99% of the internet...).
> 
> 
> >
> > My personal preference is to limit OCSP for just revocation status
> > checks and communicate additional state information through
> > extensions, as originally envisioned.
> 
[Piyush] Or we can get rid of this update. Lack of this update won't
interfere with responders who return revoked for non-issued.
> > This spec does not need to go into the details of what those
> > overridden negative proofs could be.
> 
> 
[Piyush] What can I say - I'm speechless.  I think the misnomer got me.

>it really
> is, and always was, about the status of certificate serial numbers, not
about
> the status of certs.
[Piyush] I think you sincerely believe this. You should petition to change
the text in all those published specs that call for checking certificate
status using CRLs and OCSP.
Here are some examples:
5280 Section 3: " CAs are responsible for indicating the revocation status
of the  certificates that they issue.  Revocation status information may be
provided using the Online Certificate Status Protocol (OCSP)"
5280 Section 5: " A delta CRL only lists  those certificates, within its
scope, whose revocation status has  changed since the issuance of a
referenced complete CRL."
5280 Section 6.3 : " The algorithm output is the revocation status of the
certificate"
5280 Section 6.3.1 : " certificate:  The algorithm requires the certificate
serial  number and issuer name to determine whether a certificate is on a
particular CRL."

And so on.
I guess we globally replace "certificate status" with "certificate serial
status". 
> Any other "negatives" would have to be new ReasonCode-s to be added to
> X.509.
[Piyush] 
> 
> 
> 
> 
> >
> > > Then of course you can sub-divide each category into further
> > > divisions, but every possible serial number will always fall into
> > > exactly one of these categories.
> > > (may just know whether it belongs to 2) or not), and in such case,
> > > the discussed update is of no relevance to them.
> 
> +1
> 
> > >
> > > granular than this basic division, scares me, because there is no
> > > end to its potential complexity and ambiguity.
> 
> +1
> 
> > [Piyush] That is why this update should just allow for changing the
> > meaning of revoked through single response extensions and let other
> > communities define and use those extensions.
> > A responder can determine if the certificate is 'bad' or untrustworthy
> > if it is asked to perform validation under some context specified in
> > the request extension.
> Conveying "good" for a certificate serial number that is positively known
to
> have never been issued would be stupid and wrong.

[Piyush] Sure. How about UNAUTHORIZED or MALFORMED_REQUEST
> for a certificate serial number.
[Piyush] A step that does not address any practical use cases.

> You're misinterpreting the situation.  For OCSP, this approach *IS*
[Piyush] That's another bold claim without any associated facts. Just lay
out one use case and we can analyze it to see if the claim holds up
[Piyush] 
> evaporate for certain kind of CA security breaches. 
[Piyush] What flawed assumptions. There are security breaches and there are
procedures to address them. And some of the procedures require that CA be
revoked.
What's wrong with that.

 But that could be
> addressed by updating OCSP even further, eliminating the single point of
> failure CA cert that is implied by OCSP AIA in the leaf cert.
> 
[Piyush] May be. But the trust models are what they are today.
> > > responseExtensions or into singleExtensions. There are pros and cons
> > > with both.
> >
> > [Piyush] Depends on what it indicates. If it is responder capability
> > it should be a response extension that should be sent with every
> > response. If it is about overloading the meaning of revoked it should
> > be a single response extension sent only with revoked status where the
> > meaning has been changed.
>

---

From: [email-masked] (Martin Rex)
Date: Fri, 11 Jan 2013 00:52:55 +0100 (CET)

Piyush Jain wrote:
> > here (and to some extent CRLs), and these protocols are factually
> > about status of certificate serial numbers, NOT certificates.
>
> advice - don't trust the certificate if OCSP responder says it is good.
> Make sure it chains to a trust anchor.

Huh?  You're just saying that certificate revocation checking is not worth
bothering.

I believe there are some folks on this list that do not agree and would
like to improve certificate revocation checking so that less certs that
are not supposed to be considered good will be reported as good to
RPs that perform certificate revocation checking through OCSP.

> CA hash and serial combined is representation of the certificate. 

That is actually wrong.

The octet string that _is_ the certificate is the only valid representation
of the certificate.

X.509/PKIX uses a (cryptgraphic) hash (plus a digital signature transform)
(which isn't quite perfect, as we all know) to perform data integrity
protection and data integrity authentication.

When deciding whether to trust a certificate, that was received from a
communication peer, we're already using a certificate (or ToBeSigned)
hash to check data integrity and data origin, so it is OK when we use
a certificate hash of at least the same strength for protocols like
OCSP to identify the certificate, rather then conveying the certificate
itself in full.  Keeping in mind that OCSP itself also uses
a cryptographic hash for data integrity protection and data origin
authentication...

> >  which this change is a partial remedy...).
>

CRLs are based on the absence of a negative status, so are pretty much
a lost cause.

OCSP, on the other hand, is at least about positive assertions.
However, it currently fails to securely identify the certificate
in the positive assertions, because the "good" response does not
include a certificate hash from the CAs database of issued certs.

> certificate and it is irrelevant to OCSP?

That is incorrect.

The RP uses OCSP to determine the status of a certificate serial number,
and infers from the absence of a negative status of the certificate
serial number the status of the certificate.

When the OCSP responder returns bad (certificateOnHold) for a "not issued"
certificate, then it will not matter if the RP does not understand the
subtle difference here.

> > does not allow you to configure a local trusted OCSP responder ... ;-)
> 

Huh?  Definite NO.

Currently, the CA key(!!) is the single point of failure, so
the fix to the single-point-of-failure problem will consequently
have to look like a delegated responder for backwards compatibility
with the installed base of OCSP clients, but the OCSP signer cert
will additionaly need a property that can not be faked by compromising
the CA key (something that only updated OCSP clients will understand
 and check, of course -- that is regularly inevitable when fixing
 protocol shortcomings).

> > it.  There is not IETF protocol SWAT team that will take down a service
> > for an IETF protocol violation (if it existed, it would probably have
> > to take down 99% of the internet...).
> 

The IETF is a so-called "Standardization Organization", and rather that
leaving it undefined and up to implementors how to convey the "not issued"
status which some OCSP responders may be positively aware of, it is
expected from the IETF, the maintainer of the OCSP protocol (rfc2560),
to standardize how to convey this information.

You do not have to donate your time to the effort, but I would like
to ask you not to stop others from doing that work.

> 
> > it really is, and always was, about the status of certificate
> > serial numbers, not about the status of certs.
>
> [Piyush] I think you sincerely believe this.

That is formally provable for the protocol specified in rfc2560.

> I guess we globally replace "certificate status" with "certificate serial

OR we could just improve OCSP to better live up to the expectations.
Like adding the certificate hash from the CA cert issue log into the
OCSP "good" responses.

> > to have never been issued would be stupid and wrong.
> 

As explained in a previous reply, it would be entirely useless to
standardize either of these for "not issued", because for most RPs
in the installed base, it would have just the same bottom line
effect as returning "good".

> revoked. What's wrong with that.

X.509/PKIX does *NOT* have a procedure for dealing with a CA key compromise.

The PKIX assumption is that it can not possibly happen.
And if it happens anyway, the reaction is to "Nuke the PKI",
a stereotype of the US military in hollywood movies
(we don't know how to deal with it, so nuke it).

What I'm calling for is reasonable plans for disaster recovery
that will work in the real work.  We reliably know that immediately
nuking a large PKI did not work a single time in the real world,
besides being a stupid idea in the first place.

It is the same underlying idea as for the "Certificate Transparency"
project.  Accept as valid only certs that can be positively proven
to exist (=have been issued), based on information that can be
audited to be correct.

Infering from the absence of a negative assertion (i.e. the concept
of black-listing) has always been a pretty dumb idea security-wise.

If online shops would be verifying credit cards by looking at paper-based
CC-Number blacklist only, fraud would be skyrocketing.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Thu, 10 Jan 2013 17:50:12 -0800

> Huh?  You're just saying that certificate revocation checking is not worth
Nop. I'm saying is that revocation checking is not worth bothering if you
have not done signature verification.

> CRLs are based on the absence of a negative status, so are pretty much a
lost
> cause.
OCSP, at least as envisioned by original authors is functionally equivalent
to CRLs. It was an oversight to have a 'good' status in the specification.
It should've been 'not revoked'.

---

From: [email-masked] (Martin Rex)
Date: Fri, 11 Jan 2013 03:39:52 +0100 (CET)

Piyush Jain wrote:
> >
> > CRLs are based on the absence of a negative status, so are pretty
> > much a lost cause.
> > 
> OCSP, at least as envisioned by original authors is functionally
> equivalent to CRLs. It was an oversight to have a 'good' status
> in the specification. It should've been 'not revoked'.

What may have been envisioned by the original authors
is entirely irrelevant today.

What has been standardized by thet IETF ~13 years ago, evidently
as you can see from the published specification, and from a lack
of an update or errata of the kind you seem to desire,
is a positive assertion "good", decorated with the caveat
that when lacking information about issuance (such as when
feeding the OCSP responder on CRLs only), a "good" response
might be erroneously returned for a certificate that, in fact,
was never issued.

The update currently under disussion is about enabling OCSP to actually
and sensibly convey within the OCSP protocol, whether a certificate
serial number refers to a certificate that is present on the
CA cert issue log.  And the choice is to convey the information
in such a fashion, that it will cause the desired behaviour with
very close to all of the installed base of RPs (rfc2560 OCSP clients).

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 11 Jan 2013 11:59:50 +0100

+1 To Martin's post here. Well put.

Piyush.

This discussion seems to go nowhere.
It seems to have gotten to the point where you can't even acknowledge
facts, because they don't support your view of the world.

/Stefan

On 1/10/13 8:18 PM, "Martin Rex" <[email-masked]> wrote:

>>trust the
>>the
>>checks
>>divisions,
>>meaning
>>if it
>>with

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 18 Jan 2013 08:08:36 +0100

I have just submitted a new draft 09 to accommodate some nits and comments.

Great thanks to Piyish Jain for your review, which digged up some things.

I'll respond to how I dealt with your comments below;

>"non-issued certificates"

It now is more clear on the use of this term.

>record of issuance of the requested certificate."

I have to a major extent adopted your wording.

>- IMO the above text belongs in the extension specification for extended

I disagree. The extension text is helpful for understanding the extension
and its syntax. Section 2.2. Gives you the context for using it and other
similar guidance related to responding revoked to non-issued certs.

>extended revoked for "non-issued" is used because the response does not

No, the text is correct. These parameters still corresponds to the meaning
they have in CRL:s.

>directly by the CA that issued the certificate in question."

Updated the text

>revoked is included in the response.

This is being made clear in 2.2

>not be included as single response extension if extended revoked is being

Good, added in 2.2

>id-pkix-ocsp-ugly-moustache-as-revoked through an add-on RFC.

Made no changes on this at this point.

>The note could be added here or in the section defining extended revoked.

Yes, issuing pre-produced responses for any possible serial number is
impossible.
I had a discussion with Scott Rea where he showed that this could still be
used in pre-production environment as response to a non-issued
serial-number that is asked for repeatedly in the network.
Then a reproduced response for this serial number could be produced as
some kind of mitigation strategy.

Some words of this kind would be good in the draft but is currently no
included.

/Stefan