Subject: [pkix] What's the need to introduce fraudulently issued certificates in OCSP

From: "Piyush Jain" <[email-masked]>
Date: Sat, 3 Nov 2012 09:09:00 -0700

Here are a few points about the current proposal
- Most folks agree that it adds very little or no incremental security,
given current OCSP trust models. The benefits that are mentioned only apply
if CA is compromised, but any smart attacker who has compromised the CA can
easily circumvent the 'supposed' additional security provided by returning
revoked for fraudulent certs.
- It adds confusion because users are asked to put different level of trust
in two signatures, both generated by the same authority (end entity cert and
responder cert)
- It introduces functional differences between OCSP and CRLs which are
traditionally considered interchangeable from functional point of view by
most deployments, thus making revocation checking non-deterministic based on
source of revocation information.
- Its impact on other features of OCSP (revocation reason, revocation time,
crl references, may be others) extends the scope of change to sections
beyond the one which re-defines the meaning of revoked.
- It can be perceived as an alternative to signature checking if OCSP
responder claims to check issuance.

The biggest point is that it does not change the protocol specification
(bits on wire) at all. Implementations can still decide to return revoked
for fraudulently issued certificates without breaking the protocol.
So what's the need to introduce this concept in OCSP which can lead many to
believe that OCSP can successfully deal with the case of CA compromise?

-Piyush

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sat, 03 Nov 2012 20:47:06 +0100

Hi,

For reference, my point of view on this topic is that of a browser vendor  
that have to provide security and trust information to the users of our  
browser; that is, WebPKI.

Our users expect their browser to indicate whether they are on a safe site  
or not; while that may be a bit above what can be reasonably done, we do  
use fraud and malware information, as well as certificate revocation  
checking (for site certificates this is primarily OCSP, not CRLs) to  
provide the best possible advice to our users.  In relation to revocation  
information we rely on the information provided, in particular by OCSP, to  
give an accurate and truthful indication of the status of the certificate  
at the time the response was generated. Personally, I do not consider a  
"Good" response for a non-issued certificate to be accurate, because the  
responder cannot truthfully say that the certificate is "Good", as the  
issuer does not know the certificate was issued, or who uses the  
certificate.

Based on what was revealed about last year's breach of DigiNotar, I  
proposed to the CABForum, and the CABForum earlier this year accepted,  
that OCSP responders MUST NOT reply "Good" for a certificate that it does  
not know has been issued (Effective August 2013). My original proposal was  
that the response should be "Revoked", but this was rejected as to the  
language of RFC 2560 seemed to forbid it. Using "Revoked" would have meant  
that clients would not have had to be updated to handle different  
responses (as is the case with the final resolution), and would also  
immediately protect older clients that have not been updated. Please note  
that my proposal only concerned certificates that have never been issued,  
it does not define anything about certificates that have been issued, but  
have expired.

The relevant background for my proposal was, as should be known by members  
of this WG, that the DigiNotar attacker was able to issue certificates  
that was not tracked by the CA systems, and was thus unknown to the  
issuer. The certificates were then used to perform MITM attacks on at  
least Google Mail users living in Iran. Because DigiNotar's OCSP system  
returned "Good" for serial numbers it did not know, no client seeing these  
certificates would be able to warn their users about the fake certificate.

If the OCSP responder had been required to return something else for these  
certificates, and which the clients would have treated as Fatal errors,  
then the attacker would not have been able to use the methods he was  
using. (For reference, in Opera 12.02 functionality was introduced that  
treat "Unknown" and "unauthorized" as indications of non-issued  
certificates, and display a Fatal Error about the certificate being  
unknown to the issuer, and in the worst case scenario is a fraudulent  
certificate.)

He could have mitigated the effect by blocking access to the OCSP  
responder, since most clients does not, currently, indicate such failures  
to the user. However, the browser I develop, Opera, do remove any  
indication that the site is secure when revocation checks fails to  
complete successfully, and we have had frequent experience with users  
reporting the incidents when a site have lost its padlock, most recently  
involving a bug in our revocation caching system, and host-files overrides  
that prevent access to the revocation servers (possibly self-inflicted to  
bypass application licensing requirements). See also  
<http://my.opera.com/yngve/blog/2008/06/27/nobody-checks-the-padlock-debunked-by-opera-users>.

Making it impossible for the attacker to give his certificates a "good"  
OCSP response means that he will either have to leave the certificate in  
the database, or have to achieve far deeper and wider penetration of the  
CA than he would otherwise have needed, in order to compromise other parts  
of the CA system necessary to successfully obtain fraudulent certificates  
that can be used. Based on my information, I would guess that the reason  
the DigiNotar attacker started destroying the logs was that DigiNotar was  
repeatedly revoking his fraudulent certificates as they were discovered.  
If so, that means that the revocation system worked, at least in part, and  
the attacker was forced to find a way around it.

As the attacker would need more control, or leave more obvious tracks,  
that means that there is far better chance of an attack being discovered  
and stopped.

The no-"good"/"revoked" OCSP response suggestions are not a panacea for  
detecting fraudulent certificates or CA compromise, but it provides an  
extra layer of security for users, and makes sure the attacker have to  
jump through a lot more hoops, which make detection more likely (remember,  
DigiNotar did detect the attacker's activity). Combined with other  
counter-measures, such as the browser removing secure indications if the  
revocation check fails (if not going for hard fail), and perhaps other  
protocols being developed/suggested (pinning, certificate transparency,  
etc.) it may be possible to make a CA compromise much less profitable or  
likely to succeed.

Personally, I would have preferred that the "does not necessarily mean the  
certificate was ever issued" text in the definition of "Good" was removed.  
In my opinion it is dangerous, and should never have been in the text  
originally, since it requires that CA issuance systems cannot be  
compromised. Even if it ever made sense to have "Good" as a response for  
non-issued certificates, in my opinion any reasonable rationale for  
allowing it went out the window in September 2011, as it was proven that  
CA issuance systems could be compromised. Given that, as I understand it,  
one reason for allowing this kind of response in such a case, was that  
OCSP responders could be based entirely on CRL data, perhaps it is now an  
idea to retire that entire concept, since it has, at least, proven to be  
based on one unwarranted assumption: that CAs cannot be compromised.

OCSP can, and should, provide more and better information about a  
certificate's status than CRLs, which after all only provide information  
about revoked certificates.

As for CRLs, maybe they need to be replaced by a Certificate Status List,  
listing all issued and currently unexpired certificate, and whether they  
are revoked or not, but that is a different discussion.

For further reference, the final report in the DigiNotar incident can be  
found here:  
<http://www.rijksoverheid.nl/ministeries/bzk/documenten-en-publicaties/rapporten/2012/08/13/black-tulip-update.html>

On Sat, 03 Nov 2012 17:09:00 +0100, Piyush Jain <[email-masked]>  
wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 96 90 41 51              Fax:    +47 23 69 24 01
********************************************************************

---

From: Santosh Chokhani <[email-masked]>
Date: Sat, 3 Nov 2012 16:17:02 -0400

I am ok with OCSP returning "revoked" for certificate that it knows has not been issued.  It can also inform the CA of the certificate if it has a copy so that the CA can determine if there was a fraudulent certificate or simply a mischief.

I am also ok with disparity in CRL and OCSP results.

What I am not ok with is the CAB Forum and the post below's false sense of security "but it provides an extra layer of security".  The attacker can mint a delegated OCSP Responder certificate and browsers will not know of it.  The post below and CAB Forum do not seem to recognize this and seem to give a false sense of security.  This is only effective if the CA had some genuine controls that would prevent from generating OCSP certificates while it has been compromised.  This all depends on the CA design and the nature of compromise.  Some designs and compromises I have seen, what you write below will be useless since the browser will be going to the rogue OCSP Responder created by the attacker.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yngve N. Pettersen (Developer Opera Software ASA)
Sent: Saturday, November 03, 2012 3:47 PM
To: [email-masked]
Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP

Hi,

For reference, my point of view on this topic is that of a browser vendor that have to provide security and trust information to the users of our browser; that is, WebPKI.

Our users expect their browser to indicate whether they are on a safe site or not; while that may be a bit above what can be reasonably done, we do use fraud and malware information, as well as certificate revocation checking (for site certificates this is primarily OCSP, not CRLs) to provide the best possible advice to our users.  In relation to revocation information we rely on the information provided, in particular by OCSP, to give an accurate and truthful indication of the status of the certificate at the time the response was generated. Personally, I do not consider a "Good" response for a non-issued certificate to be accurate, because the responder cannot truthfully say that the certificate is "Good", as the issuer does not know the certificate was issued, or who uses the certificate.

Based on what was revealed about last year's breach of DigiNotar, I proposed to the CABForum, and the CABForum earlier this year accepted, that OCSP responders MUST NOT reply "Good" for a certificate that it does not know has been issued (Effective August 2013). My original proposal was that the response should be "Revoked", but this was rejected as to the language of RFC 2560 seemed to forbid it. Using "Revoked" would have meant that clients would not have had to be updated to handle different responses (as is the case with the final resolution), and would also immediately protect older clients that have not been updated. Please note that my proposal only concerned certificates that have never been issued, it does not define anything about certificates that have been issued, but have expired.

The relevant background for my proposal was, as should be known by members of this WG, that the DigiNotar attacker was able to issue certificates that was not tracked by the CA systems, and was thus unknown to the issuer. The certificates were then used to perform MITM attacks on at least Google Mail users living in Iran. Because DigiNotar's OCSP system returned "Good" for serial numbers it did not know, no client seeing these certificates would be able to warn their users about the fake certificate.

If the OCSP responder had been required to return something else for these certificates, and which the clients would have treated as Fatal errors, then the attacker would not have been able to use the methods he was using. (For reference, in Opera 12.02 functionality was introduced that treat "Unknown" and "unauthorized" as indications of non-issued certificates, and display a Fatal Error about the certificate being unknown to the issuer, and in the worst case scenario is a fraudulent
certificate.)

He could have mitigated the effect by blocking access to the OCSP responder, since most clients does not, currently, indicate such failures to the user. However, the browser I develop, Opera, do remove any indication that the site is secure when revocation checks fails to complete successfully, and we have had frequent experience with users reporting the incidents when a site have lost its padlock, most recently involving a bug in our revocation caching system, and host-files overrides that prevent access to the revocation servers (possibly self-inflicted to bypass application licensing requirements). See also <http://my.opera.com/yngve/blog/2008/06/27/nobody-checks-the-padlock-debunked-by-opera-users>.

Making it impossible for the attacker to give his certificates a "good"  
OCSP response means that he will either have to leave the certificate in the database, or have to achieve far deeper and wider penetration of the CA than he would otherwise have needed, in order to compromise other parts of the CA system necessary to successfully obtain fraudulent certificates that can be used. Based on my information, I would guess that the reason the DigiNotar attacker started destroying the logs was that DigiNotar was repeatedly revoking his fraudulent certificates as they were discovered.  
If so, that means that the revocation system worked, at least in part, and the attacker was forced to find a way around it.

As the attacker would need more control, or leave more obvious tracks, that means that there is far better chance of an attack being discovered and stopped.

The no-"good"/"revoked" OCSP response suggestions are not a panacea for detecting fraudulent certificates or CA compromise, but it provides an extra layer of security for users, and makes sure the attacker have to jump through a lot more hoops, which make detection more likely (remember, DigiNotar did detect the attacker's activity). Combined with other counter-measures, such as the browser removing secure indications if the revocation check fails (if not going for hard fail), and perhaps other protocols being developed/suggested (pinning, certificate transparency,
etc.) it may be possible to make a CA compromise much less profitable or likely to succeed.

Personally, I would have preferred that the "does not necessarily mean the certificate was ever issued" text in the definition of "Good" was removed.  
In my opinion it is dangerous, and should never have been in the text originally, since it requires that CA issuance systems cannot be compromised. Even if it ever made sense to have "Good" as a response for non-issued certificates, in my opinion any reasonable rationale for allowing it went out the window in September 2011, as it was proven that CA issuance systems could be compromised. Given that, as I understand it, one reason for allowing this kind of response in such a case, was that OCSP responders could be based entirely on CRL data, perhaps it is now an idea to retire that entire concept, since it has, at least, proven to be based on one unwarranted assumption: that CAs cannot be compromised.

OCSP can, and should, provide more and better information about a certificate's status than CRLs, which after all only provide information about revoked certificates.

As for CRLs, maybe they need to be replaced by a Certificate Status List, listing all issued and currently unexpired certificate, and whether they are revoked or not, but that is a different discussion.

For further reference, the final report in the DigiNotar incident can be found here:  
<http://www.rijksoverheid.nl/ministeries/bzk/documenten-en-publicaties/rapporten/2012/08/13/black-tulip-update.html>

On Sat, 03 Nov 2012 17:09:00 +0100, Piyush Jain <[email-masked]>
wrote:

> - Most folks agree that it adds very little or no incremental 
> security, given current OCSP trust models. The benefits that are 
> mentioned only apply if CA is compromised, but any smart attacker who 
> has compromised the CA can easily circumvent the 'supposed' additional 
> security provided by returning revoked for fraudulent certs.
> - It adds confusion because users are asked to put different level of 
> trust in two signatures, both generated by the same authority (end 
> entity cert and responder cert)
> traditionally considered interchangeable from functional point of view 
> by most deployments, thus making revocation checking non-deterministic 
> based on source of revocation information.
> - Its impact on other features of OCSP (revocation reason, revocation 
> time, crl references, may be others) extends the scope of change to 
> sections beyond the one which re-defines the meaning of revoked.
> The biggest point is that it does not change the protocol 
> specification (bits on wire) at all. Implementations can still decide 
> to return revoked for fraudulently issued certificates without breaking the protocol.
> So what's the need to introduce this concept in OCSP which can lead 
> many to believe that OCSP can successfully deal with the case of CA 
> compromise?
>
> -Piyush
>

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sat, 03 Nov 2012 22:08:41 +0100

On Sat, 03 Nov 2012 21:17:02 +0100, Santosh Chokhani  
<[email-masked]> wrote:

> The attacker can mint a delegated OCSP Responder certificate and  
> browsers will not know of it.

AFAIK delegated OCSP certificates require special attributes, meaning that  
the attacker would need to be able to access a system that could issue  
such a certificate.

If the CA system allows any extension to be set, or the CA system issuing  
OCSP responder certs can be compromised then, yes, an OCSP minting cert  
could be created and arbitrary responses created, as would be possible if  
the attacker managed to take control over the OCSP system itself. If an  
OCSP minting cert is created, then the only way to repair the problem is  
to revoke the issuing subCA. The same would be the case if the certificate  
issuance system allowed arbitrary byte sequences, e.g.  an OCSP response,  
to be signed.

That is, however, part of what I mention about the attacker requiring  
deeper penetration than just what is needed to issue certs, increasing the  
risk of detection. It is up to the CA to design their system so that such  
special certificates cannot be created without the CA intending to do so.

In my opinion, an issuing system should not be able to set arbitrary  
extensions, they should be part of what the CA have hardcoded for that  
particular product.

In part, these changes are made to eliminate a direct security problem  
(and I do say they are not a panacea) and, like many security measures, in  
part to increase the hassle and risks for the attacker by making an "easy"  
attack less feasible. In other ongoing work, other aspects of the attack  
is being countered, also seeking to block an attack, or increase the risks  
for the attacker.

---

From: Liaquat Khan <[email-masked]>
Date: Sat, 03 Nov 2012 22:47:48 +0000

IMO an attacker that has the capability to bypass the normal CA security
controls and access the CA's private signing key to issue fake
certificates will be capable of also generating fake OCSP responder
certificates.  

The fact that OCSP responder certificates contain special extension (I
assume you were referring to EKU extension) is hardly going to raise the
bar in terms of complexity for the attacker.  Security should not hinge on
the fact that the attacker cannot add an extension in the to-be-signed
certificate, since this is just manipulating the input to the certificate
signing process, but rather that they cannot use the CA's private signing
key. So IMO if they can issue one fake certificate without detection, it's
safer to assume they can issue multiple certificates and also of different
types. 

In some cases you may be right, but to make a general statement that it's
much harder to issue an OCSP certificate compared to an end-entity
certificate is indeed a "false sense of security".

---

From: "Piyush Jain" <[email-masked]>
Date: Sun, 4 Nov 2012 09:37:16 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yngve N. Pettersen (Developer Opera Software ASA)
> Sent: Saturday, November 03, 2012 12:47 PM
> To: [email-masked]
that
> have to provide security and trust information to the users of our
browser;
> that is, WebPKI.
or
> not; while that may be a bit above what can be reasonably done, we do use
> fraud and malware information, as well as certificate revocation checking
(for
> site certificates this is primarily OCSP, not CRLs) to provide the best
possible
> advice to our users.  In relation to revocation information we rely on the
> information provided, in particular by OCSP, to give an accurate and
truthful
> indication of the status of the certificate at the time the response was
> generated. Personally, I do not consider a "Good" response for a
non-issued
> certificate to be accurate, because the responder cannot truthfully say
that
> the certificate is "Good", as the issuer does not know the certificate was
> issued, or who uses the certificate.
[Piyush] OCSP is clear about what 'good' means. It explicitly states that
'good' does not imply that certificate is issued or valid. Issuance is
checked by signature on the certificate,  validity for a purpose is checked
by building path to trusted root and performing additional checks on the
path.
People should understand that OCSP status 'good' does not imply that
certificate is valid for their purpose. On a side note, I have seen products
that just perform an OCSP check on the certificate and accept the
certificate if responder returns 'good'. 
> Based on what was revealed about last year's breach of DigiNotar, I
proposed
> to the CABForum, and the CABForum earlier this year accepted, that OCSP
> responders MUST NOT reply "Good" for a certificate that it does not know
> has been issued (Effective August 2013). My original proposal was that the
> response should be "Revoked", but this was rejected as to the language of
> RFC 2560 seemed to forbid it. Using "Revoked" would have meant that
> clients would not have had to be updated to handle different responses (as
> is the case with the final resolution), and would also immediately protect
> older clients that have not been updated. 
> Please note that my proposal only
> concerned certificates that have never been issued, it does not define
> anything about certificates that have been issued, but have expired.
> 
> The relevant background for my proposal was, as should be known by
> members of this WG, that the DigiNotar attacker was able to issue
> certificates that was not tracked by the CA systems, and was thus unknown
> to the issuer. The certificates were then used to perform MITM attacks on
at
> certificates, and which the clients would have treated as Fatal errors,
then
> the attacker would not have been able to use the methods he was using.
> (For reference, in Opera 12.02 functionality was introduced that treat
> "Unknown" and "unauthorized" as indications of non-issued certificates,
and
> display a Fatal Error about the certificate being unknown to the issuer,
and in
> the worst case scenario is a fraudulent
> certificate.)
[Piyush] The right approach IMO. Handle 'unknown' correctly and the world is
a happy place.
> responder, since most clients does not, currently, indicate such failures
to
> the user. However, the browser I develop, Opera, do remove any indication
> that the site is secure when revocation checks fails to complete
successfully,
> and we have had frequent experience with users reporting the incidents
> when a site have lost its padlock, most recently involving a bug in our
> revocation caching system, and host-files overrides that prevent access to
> the revocation servers (possibly self-inflicted to bypass application
licensing
> requirements). See also
the
> database, or have to achieve far deeper and wider penetration of the CA
> than he would otherwise have needed, in order to compromise other parts
that
> can be used. Based on my information, I would guess that the reason the
> DigiNotar attacker started destroying the logs was that DigiNotar was
the
> attacker was forced to find a way around it.
> 
that
> means that there is far better chance of an attack being discovered and
> stopped.
> 
extra
> layer of security for users, and makes sure the attacker have to jump
through
> a lot more hoops, which make detection more likely (remember, DigiNotar
> did detect the attacker's activity). Combined with other counter-measures,
> such as the browser removing secure indications if the revocation check
fails
> (if not going for hard fail), and perhaps other protocols being
> developed/suggested (pinning, certificate transparency,
[Piyush] I can understand a no-"good" response for such scenario, but it
does not have to be 'revoked'. Based on what you are describing a signed
'unknown' or an error response from the responder would be equally
effective. I know of at least one CA (among the biggest ones) which returns
TRY later for certificates that are not present in its database.

> certificate was ever issued" text in the definition of "Good" was removed.

[Piyush] 
[Piyush] That could make sense only if you assume that OCSP responders are
tied to the CA. Unfortunately, some of the biggest deployments of OCSP
depend on CRL to provide revocation status.  And in public key certificates
issuance is determined by checking the signature on the certificate. 

> originally, since it requires that CA issuance systems cannot be
compromised.
[Piyush] That's one way to look it. The other way is to assume that CA would
detect the compromise and revoke the certificate that are fraudulently
issued or mark itself as compromised if it cannot figure out what
certificates are fraudulently issued. Assuming that relying parties will
only use OCSP to check revocation status is dangerous.
Given that at least one browser vendor has stated that it won't use OCSP for
revocation checks proves that this assumption is invalid.

> Even if it ever made sense to have "Good" as a response for non-issued
> certificates, in my opinion any reasonable rationale for allowing it went
out
> the window in September 2011, as it was proven that CA issuance systems
> could be compromised. Given that, as I understand it, one reason for
> allowing this kind of response in such a case, was that OCSP responders
could
> be based entirely on CRL data, perhaps it is now an idea to retire that
entire
> concept, since it has, at least, proven to be based on one unwarranted
> assumption: that CAs cannot be compromised.

[Piyush] I don't think that CAs cannot be compromised was ever an
assumption. However, assumption that CA's can continue operations normally
after being compromised is dangerous.
> certificate's status than CRLs, which after all only provide information
about
> revoked certificates.
[Piyush] Based on current OCSP trust models the above statement is
incorrect. If your goal is to provide validity of certificate for a purpose,
instead of revocation status, deploy SCVP.
> listing all issued and currently unexpired certificate, and whether they
are
> revoked or not, but that is a different discussion.
> 
[Piyush] The system that you are proposing does not need public key
certificates. What you are proposing is that CA stops makes an assertion
about the user and his associated public key through PKC and instead use an
online request/response mechanism or signed white list to make such an
assertion.
There is nothing wrong with the approach or proposal but Imo it's outside
the charter of PKIX.

> For further reference, the final report in the DigiNotar incident can be
found
> here:
> <http://www.rijksoverheid.nl/ministeries/bzk/documenten-en-
> publicaties/rapporten/2012/08/13/black-tulip-update.html>
> 
> 
> > to return revoked for fraudulently issued certificates without breaking
the
> protocol.

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sun, 04 Nov 2012 20:07:05 +0100

> certificate if responder returns 'good'.

Those who are experts of PKIX systems may know, and believe that.

That kind of interpretation of "Good" may even make sense if the RP/client  
can only check a limited number of pre-configured serial numbers for a  
specific CA. For an RP (browser) that can access random sites chosen from  
millions of sites that kind of interpretation does not make sense.

Unfortunately, many, or most, normal users tend to have a "either it is  
good, or it isn't", black and white interpretation of any signal to them,  
they do not want to know about gray areas.

Opera had, for many years, a graduated padlock system going from 0 to 3,  
zero being unencrypted, 1 for user has been warned about certificates a  
very weak encryption, 2 for downgraded due to sightly weak encryption  
including revocation failure, and 3 for passed all certificate,  
encryption, revocation checks, including "good" for OCSP.

We no longer have that, we now have an indication for what was level 3  
(Same meaning), Extended Validation certificates (level 5), and one for  
everything else, including unencrypted content.

The reason for that change was that the graduated display was too  
confusing for the users. Opera is also the only browser ever to have such  
a graduated system.

If an OCSP "Good" response is a PKIX version of Schroedinger's Cat, the  
certificate either exists and is valid (in revocation terms), or it does  
not exists and is not valid, and there is no way to tell the difference  
unless we open the box (phones the CA and demand access to their  
database), then OCSP cannot be used as part of a security system that  
reports to the user. We will have to discard the protocol, and use  
something else, or "fix" the protocol for the purposes where users are  
involved, which is what the CABForum decided to do in BR 1.1, by making  
sure the responder can only reply "Good" when the certificate is known to  
be issued and not revoked.

> issuance is determined by checking the signature on the certificate.

As I said further down, I think that kind of deployment can no longer be  
defended (if it ever could), since it makes what I think are unwarranted  
assumptions.

> certificates are fraudulently issued.

You are assuming that a CA could in all cases detect incorrectly issued  
certificates that have been hidden. DigiNotar proved that that is not  
always the case, and while the CABforum have been working on procedures to  
avoid a repetition, I would not want to assume that something similar  
(untracked certificates) could not happen again. That means that the  
"Good" response cannot be used when the certificate serial number is  
unknown.

> Assuming that relying parties will

I assume that you are referring to Google and their CRLSets.

As a matter of fact, I do not approve of Google's experiment (and that is  
what they are calling it themselves: an experiment). And one reason I do  
not approve is that they would not be protected against the kind of attack  
that the non-issued response is aimed at.

Their reason for doing this is, as I understand it, in part due to what  
they consider unreliability of revocation checking (not revocation  
itself), particularly network stability, and speed considerations due to  
the delays loading OCSP and/or CRLs introduce (browsers are in a race to  
load and display the page as quickly as possible, opening multiple  
connections to load revocation information can delay that by hundreds of  
milliseconds, if not seconds).

According to my information, Google Chrome will use OCSP when received via  
OCSP Stapling in the TLS protocol.

> after being compromised is dangerous.

It may not have been a stated assumption, but whether or not it was, the  
effect is the same; it was a builtin assumption.

One of the points that have cause a lot of my concern about DigiNotar's  
handling *is* that they continued operations as normal, particularly since  
another CA was reporting itself under attack at the same time the attack  
on them started. They did not inform any of the browsers or the CABforum  
about what was going on, only after the Google cert was discovered and  
reported did they confirm that they had been compromised.

However, there will usually be a delay between attack and detection, and  
assuming the attacker manages to hide a certificate in that period, the  
only defense is that the OCSP responder does not reply "Good" for that  
serial number.

> incorrect.

The name is "Status Protocol", not "Revocation Status Protocol". I think  
it can be argued either way, but names matter, and my opinion is that OCSP  
should only reply Good for certificates that the issuer knows have been  
issued and have not been revoked. If "not revoked" is the desired  
indication, then the name should say that, not "Good".

> If your goal is to provide validity of certificate for a purpose,

SCVP is not AFAIK deployed by any CA or browser, at present, and there was  
no interest expressed from PKIX WG participants, or anyone else, to add it  
as a method for the TLS Multi Stapling extension document I am editing,  
and I therefore removed the text in the most recent draft. It is, also,  
AFAIK not implemented in OpenSSL, which indicates that the protocol is  
minimum 12-24 months from deployment, assuming interest is expressed for  
deploying it.

---

From: "Ben Wilson" <[email-masked]>
Date: Sun, 4 Nov 2012 14:09:14 -0700

Yngve,
Putting aside the technical interpretation of "good" defense for the moment,
there still may be legal liability for responding "good" to a non-issued
certificate.   This brings to mind the paper written by Tom Smedinghoff in
1998 on CA Liability.  http://64.78.35.30/article/ca-liability-analysis.pdf.
The provider of certificate status information might be held liable for
saying that a certificate is "good" when it isn't - either under a theory of
negligent misrepresentation, or making a representation about the status of
a certificate with reckless disregard for the truth, or some other legal
liability theory (you know lawyers, they can create new claims where none
existed before).
Ben

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yngve N. Pettersen (Developer Opera Software ASA)
Sent: Sunday, November 04, 2012 12:07 PM
To: [email-masked]; Piyush Jain
Subject: Re: [pkix] What's the need to introduce fraudulently issued
certificates in OCSP

---

From: "Piyush Jain" <[email-masked]>
Date: Mon, 5 Nov 2012 08:57:34 -0800

Yngve,

The question is if the responder can authoritatively provide the information
you are seeking or not.  I appreciate your point about returning good for
fraudulently-issued certificates. My question is, can the responder figure
out if the certificate is fraudulently issued if the CA is compromised. In
most cases this untrue, unless you standup a responder independent of the
CA. 

I'm sorry to say, but you proposal to CAB forum was just a feel good measure
without providing any additional security. It is actually a disservice
because now people believe that their deployments are more secure without
that being the case.
Here are a few scenarios, some of which have been discussed in this forum
before:
- Attacker issued a new OCSP certificate and issued site certificate with
AIA that point to a bogus responder with a OCSP certificate issued by the
CA. To counter this you need to have OCSP certificates that are not issued
by the CA.
-Attacker issued site certificate with same serial number as an existing
valid certificate. To counter this you would require that the OCSP request
should contain a unique representation of the certificate as opposed to just
the serial number. Given that CAs issue millions of certificates other than
site certificates, think of the impact it would've on the size of OCSP
request and response and on the latency of an OCSP response.
- CRLs are still used to validate all kind of certificates. There are big
enterprises that have directly trusted OCSP responders feeding of CRLs.
These responders provide revocation information for all kind of
certificates, even public website certificates (somewhat similar to google
model). 

The only benefit of your proposal, as I see it could be to detect a CA
compromise scenario that too not in a fool proof way.
To continue operating the CA by claiming that OCSP has effectively dealt
with CA compromise would be incorrect and deceptive.

Your point about 'good' status is a valid one. The name 'good' is a misnomer
and almost everyone one this WG believes that it should be 'not revoked'.
Simple reason is that, given the guidance on certificate validation and OCSP
trust model , OCSP responder does not have and cannot have enough
information to respond with an authoritative 'good'. Folks realized the
benefit of a service that can return authoritative 'good' and that is why we
have SCVP. BTW, All these proposed changes in OCSP (different trust model,
including certificate identifier in request and returning authoritative
goods) turn it into a protocol that could very well be a light weight
profile of SCVP.

-Piyush
- 
> From: Yngve N. Pettersen (Developer Opera Software ASA)
> [mailto:[email-masked]]
> Sent: Sunday, November 04, 2012 11:07 AM

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 07 Nov 2012 09:39:12 -0400

I would suggest that what we are trying to do with OCSP in this update is
NOT to fix problems with compromised CAs.

We are simply allowing responders to provide a more
accurate/functional/safer response in case of a status request for a
non-issued cert.

As said before, the current proposal:
- Breaks on-one
- Does not add ambiguity for responses to issued certs from good CAs
- Does not add ambiguity in any case for those understanding the new
extension.
- Allows CAB Forum responders to be compliant with OCSP.

Problems raised are purely philosophical. Not ONE practical real
issue/problem has been presented.
If I missed one, please let me know.

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 7 Nov 2012 10:08:29 -0800

> Stefan Santesson
> Sent: Wednesday, November 07, 2012 5:39 AM
> To: [email-masked]
NOT
> to fix problems with compromised CAs.

[Piyush] 
[Piyush] This is a change. Until now, the only reason cited for proposing
this was to deal with fraudulently issued certificates. 
> accurate/functional/safer response in case of a status request for a non-
> issued cert.
> 
[Piyush] Certificate is not marked as revoked, so returning revoked for such
certificates is not more accurate. 
Given existing OCSP trust models, there is no additional safety/security.

> As said before, the current proposal:
[Piyush] Not a reason to propose a change.

> - Does not add ambiguity in any case for those understanding the new
[Piyush] Nothing is ambiguous if you view it in a silo. Unfortunately, CAB
forum's desire to make OCSP the granddaddy of all certification validation
mechanisms without worrying about security, does not imply that other
deployments share the same desire. 
The protocol specification does not say that it should only be used between
CAs and browsers. Here are the ambiguities/confusion that you introduce for
an implementer who needs to add x.509 support in his application
- Is it safe to fallback from OCSP to CRL if OCSP is not available?
Traditionally it has been.
- What is the need for signature checking if responders can make claim about
issuance? It has a performance impact on the client.
- what is the meaning of non-issuance? Doesn't a valid signature imply that
the certificate was issued?
- If I cannot trust a signature on EE certificate, why should I trust the
signature on OCSP responder issued by the same CA?

> - Allows CAB Forum responders to be compliant with OCSP.
[Piyush] What I fail to understand is why current text make such responders
non-compliant.
If a responder chooses to indicate revoked for fraudulently issued
certificates, it can do so under the current guidelines. It is up to the
operator of such responder to explain why a certificate is being reported
revoked by OCSP and not by CRL.
If you put this guideline in the standard, you are tacitly endorsing that it
is okay for CAs to continue operations after they've been compromised.

As I said before, It may make sense for CAs to do so, depending on the level
of compromise. But if they make this business decision, they should be doing
the explaining, instead of pointing to a PKIX document that endorses this
behavior.

> If I missed one, please let me know.
[Piyush] See above.
And BTW, there is not a single practical use case that has been presented
(other than CA compromise) where this proposal has any benefit.
And in case of CA compromise, the only apparent benefit is that it allows
CAs to detect a compromise.

Don't get me wrong - I do not care what a compromised responder returns in a
response (revoked, unknown, good, beautiful,ugly).
 The problems are:
- presenting it as a minor change that does not affect interpretation of
other sections in OCSP and that of other pkix documents. 
- Lack of accompanying security guidance which is fairly important given the
range of claims/counter-claims that has been made about the benefits of this
change.

---

From: Simon Tardell <[email-masked]>
Date: Wed, 7 Nov 2012 19:55:30 +0100

> the explaining, instead of pointing to a PKIX document that endorses this
To me, this is not so much about endorsing CAs to respond on whether a
certificate was issued or not. And certainly not promote the idea that CAs
can continue operations beyond compromise. I mostly agree with the you
about the futility of these ideas. However. I believe that cause is lost
already. There are CAs out there that already check issuance.  I want to
prevent CAs from using "unknown" to indicate non-issuance, since I believe
it breaks the protocol, and an important aspect of the protocol at that
(besides from being highly illogical). Also, I want to stop this perennial
beating of a horse with limited vital signs. The issuance issue and whether
it should be reported and how has been discussed on this list on-and-off
for well over ten years (at least twelve).

I think all the caveats that you and others have pointed out should be
summarized in the RFC. E.g. there should be a caution that if you implement
some kind of white list functionality, you can't reliably fall back to CRLs
etc.

Once this issue is off the table I think it could be useful to discuss if
there are real solutions to the problems that web PKI and national PKIs are
facing (I believe there are), and if they warrant changes or extensions to
formats and or protocols.

/Simon

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 08 Nov 2012 09:31:56 +0100

Stefan,

There are two problems with the current proposal:

1) In France, currently, the technical specifications which are mandated 
by the French legislation forbid the use of the suspension state:

IV.9.13. Causes possibles d’une suspension
La suspension de certificats n'est pas autorisée dans la présente PC Type.

Sources:

a) Annexe A8 au RGSv1.0 : PC Type - Signature. Identification du 
document (OID) 1.2.250.1.137.2.2.1.2.2.2 2.3
date 11/02/2010 Page 41/82

b) Annexe A7 au RGSv1.0 : PC Type - Authentification. Identification du 
document (OID) 1.2.250.1.137.2.2.1.2.2.1 2.3
Date 11/02/2010 Page 42/82

So requiring the support of the suspension state would either :

a - prevent the CAs and OCSP responders which comply with that 
legislation to take advantage of the indication
of a certificate that is not in the database of issued certificates and 
currently within their validity period, or

b - mandate a change in the specification which will only be applicable 
in the future.
.
2° For CAS which do not comply with that French legislation, and for 
certificates used for non repudiation purposes,
when an electronic signature is verified, if a certificate is suspended, 
then the current logic is to consider that
the status of the electronic signature is unknown but if it is possible 
to make a final decision later on, another test
will be done later on, since the suspension state (in the usual case) is 
not going to last for ever.

Since the proposal is deviating from the original meaning of the 
suspension state, we would be in a case where
the suspension state would last for ever. So the verifying applications 
will keep continue to wait for the end of the
suspended state and that end will never happen. I do not believe that 
this is nice.

Returning the unknown status is still the better choice in the case 
where a certificate that is not in the database
of issued certificates and currently within their validity period.

Remember that is is a major difference between an unknown status 
returned by an authoritative OCSP responder and
an unknown status returned by an OCSP responder that is not 
authoritative. In the former case, the relying party
has no reason to switch to a CRL issuer (if it ever exist) , since the 
OCSP responder is authoritative and did said "unknown".

IMO, changing the semantics of "suspended" is not acceptable.

Denis

PS. A reply to Simon who said: " I want to prevent CAs from using 
"unknown" to indicate non-issuance";
This sentence is not appropriate. CAs do not return certificate statuses 
unless they act as CRL issuers
or OCSP responders. Your main argument against the use of the unknown 
status is the use of CRLs as a
fall back mechanism. At this time, nobody said on the list under which 
exact circumstances that fall back
mechanism is being used in some code. Is it when there is no response 
from the OCSP responder
(in such a case, all solutions are equivalent) or under other 
circumstances (which would need to be detailed) ?

---

From: Simon Tardell <[email-masked]>
Date: Thu, 8 Nov 2012 11:10:27 +0100

> La suspension de certificats n'est pas autorisée dans la présente PC Type.

Well, that is ok. We are not proposing suspending any certificates, only
non-certificates. (Note that it does *not* say that an OCSP responder must
not respond with reason code certificate hold, it says *certificates* must
not be put on hold, or equivalently that the validity period of the
certificate must be continuous.)

> the status of the electronic signature is unknown but if it is possible to
> make a final decision later on, another test
> suspended state and that end will never happen. I do not believe that this
> is nice.
>
>  […]

> IMO, changing the semantics of "suspended" is not acceptable
>

Well, that is exactly what you did in the text above! You more or less
reversed the meaning of revoked (certificateHold) and unknown.

If a certificate is revoked at the time of use, the use is not approved by
the CA. Period. The only thing special with reason code certificateHold is
that it may become approved for use at a later point in time, but it can
not change status at the current point in time.

CertificateHold is useful when you have lost control of your token but may
be able to recover it without it having been compromised (as in your wallet
is missing, and you probably left it at home this morning, but you are not
100% sure). If you recover your token, you can unsuspend it again. But in
the off chance that the cleaning lady used her keys to get into your
apartment and found your wallet, used your card and put it back into place
without you noticing anything, any signature created during the suspension
period must be rejected. (And certificateHold makes sense only when
replacing a token is expensive compared to the extra complexity of handling
the suspension state, of course).

Returning the unknown status is still the better choice in the case where a
> certificate that is not in the database
> Remember that is is a major difference between an unknown status returned
> by an authoritative OCSP responder and
> an unknown status returned by an OCSP responder that is not authoritative.
> In the former case, the relying party

Responding "unknown" means "I am not authoritative for this issuer, at
least not right now.". The only difference in your authoritative and
non-authoritative case is whether there is any one else to ask. An
authoritative responder is probably less likely to respond "unknown", but
could have outages too.

PS. A reply to Simon who said: " I want to prevent CAs from using "unknown"
> to indicate non-issuance";
> mechanism is being used in some code. Is it when there is no response from
> the OCSP responder

"Unknown" is part of what makes it possible to provide timely revocation
information in a distributed and redundant fashion. This is a useful
feature which I would like you not to break for me. Falling back to CRLs is
the least useful option, but what many clients (including Windows) will do.
That is a security problem, if you let "unknown" be an assertion of
non-issuance.

/Simon

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 08 Nov 2012 08:56:54 -0400

So you can't use this option for French CAs that needs to conform to this
legislation.

If the OCSP update says SHOULD set certificateHold, then you can set
something else for those CAs (if that is what you want).
Would that help?

/Stefan

On 11/8/12 4:31 AM, "Denis Pinkas" <[email-masked]> wrote:

>IV.9.13. Causes possibles d¹une suspension

---

From: "Piyush Jain" <[email-masked]>
Date: Thu, 8 Nov 2012 08:02:16 -0800

"Unknown" is part of what makes it possible to provide timely revocation
information in a distributed and redundant fashion. This is a useful feature
which I would like you not to break for me. Falling back to CRLs is the
least useful option, but what many clients (including Windows) will do. That
is a security problem, if you let "unknown" be an assertion of non-issuance.

[Piyush] signature mismatch on the certificate is an assertion of
non-issuance. Unknown is an assertion that revocation status is unknown. The
notion that revoked/unknown is an assertion of non-issuance is a security
problem.

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 09 Nov 2012 09:24:58 +0100

Stefan,

> So you can't use this option for French CAs that needs to conform to this

Correct. :-(

In the PKIX minutes I also read:

"Scott expressed concern about the certificateHold status since CAB
Forum may hare requirements to never use certificateHold status
when revoking certificates".

> something else for those CAs (if that is what you want).

Not really. None of the currently defined secondary statuses seems to be 
appropriate
unless using "unspecified" (0). So why not using unspecified ?

Denis

> /Stefan
>
>
> On 11/8/12 4:31 AM, "Denis Pinkas"<[email-masked]>  wrote:
>
>> Stefan,
>>

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 09 Nov 2012 09:30:46 +0100

Stefan,

As responded to Iñigo, what we are trying to do with OCSP in this update 
is *not only* "to provide
a more accurate/functional/safer response in case of a status request 
for a non-issued cert".

BTW, using the terminology "non-issued cert" is restrictive, since two 
cases may happen:

       - either the target certificate has indeed not been issued and 
thus is a forged certificate,

       - or the target certificate which was indeed regularly issued has 
been removed from the database
          by an attacker (as the result of a denial of service attack) 
or by accident.

So the primary revocation status would need to reflect both cases as 
detailed above.

The second aspect, which is equally important, is to allow an OCSP 
client to *detect* an abnormal situation
and to alert the OCSP server to fix it. This is only a *detection* 
mechanism, which needs to be followed by
a *recovery* mechanism.

> As said before, the current proposal:
   1) Not really:  it would prevent CAs which need to comply with the 
French legislation from taking advantage of the new feature.

   2) it seems to be a problem for the CAB forum as well:

   2) It breaks the logic of some relying parties which verify 
electronic signatures: they will wait for end of the suspension state,
or a time out which does not exist today would need to be added. So, why 
not using "unspecified" ?

> - Does not add ambiguity for responses to issued certs from good CAs

This is not a matter of "good" or "bad" CA, until an abnormal situation 
is detected by the OCSP client

> - Does not add ambiguity in any case for those understanding the new extension.

This is not a new extension, but a change in the semantics of the 
"revoked" status and that may have further implications
on its processing.

> - Allows CAB Forum responders to be compliant with OCSP.

Well, could someone post the requirements terms of the CAB forum, so we 
can know what they really are  ?
> If I missed one, please let me know.

See above.

Denis

---

From: Simon Tardell <[email-masked]>
Date: Fri, 9 Nov 2012 10:17:51 +0100

> French legislation from taking advantage of the new feature.

As I noted earlier I don't read it that way. The text is about what you can
do to a *certificate*. You can't *suspend a certificate*. But the proposed
text is about responding certificateHold for *anything but a certificate*.

> when revoking certificates".

Well, that's easier to solve. It is not a practical problem, for the very
same reason (actual certificates will never be on hold, so they will only
have one continuous validity period, which is the simplification I believe
they are after). And CAB Forum is perhaps easier to reason with than a
French ministry (given my prejudice about the napoleonic system of
government ;)-.

  2) It breaks the logic of some relying parties which verify electronic
> signatures: they will wait for end of the suspension state,
> or a time out which does not exist today would need to be added.
>

That logic is clearly against the specification, so why should we
accommodate it? Perhaps we need some clarifying language somewhere else to
prevent this practice from proliferating.

> So, why not using "unspecified" ?
>

Because it is still definite. A serial number which is not issued today may
be issued tomorrow. So you have to use a reason code that carries with it
that it is valid _now_ but may change the next time you ask.

> "revoked" status and that may have further implications

I don't agree here. It does not change anything for clients that are
already complying with relevant PKIX standards. The only parties that *may*
need to change something are OCSP responders, and that's only if they want
to take advantage of this functionality.

/Simon

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 09 Nov 2012 12:22:08 +0100

Simon,

Thank you for your detailed response.

[Denis] So, why not using "unspecified" ?

[Simon] Because it is still definite. A serial number which is not 
*issued* today may be issued tomorrow.
So you have to use a reason code that carries with it that it is valid 
_now_ but may change the next time you ask.

Reading again your sentence twice, I know understand. You mean that a 
serial number which is not yet *used* today, m
ight be used tomorrow for a newly issued certificate and since 
"unspecified" is a definite response, its status cannot
be changed later on to "good".

(...)

[Simon] We are not proposing suspending any certificates, only 
non-certificates. (Note that it does /not/ say
that an OCSP responder must not respond with reason code certificate 
hold, it says /certificates/ must not be
put on hold, or equivalently that the validity period of the certificate 
must be continuous.)

Well, I don't know your skills in French, but mine are rather good. :-)

When you have the sentence: "La suspension de certificats n'est pas 
autorisée dans la présente PC Type ",
an auditor verifying the compliance of the CA would not expect when 
asking for tests to receive a response
which says that the certificate is revoked with one of the 
ReasonFlagsset to "certificateHold".

The advantage of using "unknown" is that there is no need to give any 
revocation reason and any revocation date
(however a new non-critical extension may be added to provide more 
details for those able to understand it).

The current definition from RFC 2560 is:
The "unknown" state indicates that the responder doesn't know about the 
certificate being requested.

You said: "Responding "unknown" means " I am not authoritative for this 
issuer, at least not right now." This is not what
the sentence states above. This is your interpretation.

You also said: "The only difference in your authoritative and 
non-authoritative case is whether there is any one else to ask".

No. The difference is that you know that the responder is authoritative 
only if response for that serial number is signed
either by the right CA and the right key or by an OCSP Responder which 
received an OCSP certificate from the right CA
and the right key.

You said: An authoritative responder is probably less likely to respond 
"unknown", but could have outages too.
So this demonstrates that your interpretation above of the unknown 
status is too restrictive.

An "unknown" response from an authoritative authority is a response at 
the time of the request: it might be that there is temporarily
no access to the data base or that there is temporarily no access to the 
CRLs. So it is not a definitive response.

If there is another OCSP server, it may be tried, but switching to CRLs 
as a backup mechanism is a matter of local policy,
since there may be an associated risk. Which local policy should be used 
is outside the definition of the protocol and may only be
discussed in the security considerations section.

If some implementations use as a local policy to switch to CRLs when an 
authoritative OCSP responder responds "unknown",
it is not a problem that we should attempt to solve. The solution is to 
change the local policy in these implementations.

Nota: If a non-authoritative OCSP responder responds "unknown", this 
simply means that the request was addressed to the
wrong OCSP server.

Denis

:
>
> On Fri, Nov 9, 2012 at 9:30 AM, Denis Pinkas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>       1) Not really:  it would prevent CAs which need to comply with
>     the French legislation from taking advantage of the new feature.
>
>
> As I noted earlier I don't read it that way. The text is about what 
> you can do to a /certificate/. You can't /suspend a certificate/. But 
> the proposed text is about responding certificateHold for /anything 
> but a certificate/.
>
> Well, that's easier to solve. It is not a practical problem, for the 
> very same reason (actual certificates will never be on hold, so they 
> will only have one continuous validity period, which is the 
> simplification I believe they are after). And CAB Forum is perhaps 
> easier to reason with than a French ministry (given my prejudice about 
> the napoleonic system of government ;)-.
>
> accommodate it? Perhaps we need some clarifying language somewhere 
> else to prevent this practice from proliferating.
>
> Because it is still definite. A serial number which is not issued 
> today may be issued tomorrow. So you have to use a reason code that 
> carries with it that it is valid _now_ but may change the next time 
> you ask.
>
> already complying with relevant PKIX standards. The only parties that 
> *may* need to change something are OCSP responders, and that's only if 
> they want to take advantage of this functionality.
> /Simon

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 09 Nov 2012 14:05:46 +0100

hI,

"Suspension of a real certificate means certificateHold ni a CRL entry"
     is equivalent to
"having certficateHold cannot mean Suspension of a real certificate"
(and not more).

Since we are talking about non existing certs, this is out of scope of 
the RGS IMO.

In  other words: An RP that talks to an RGS conformant RGS
seeing certificateHold MAY interprete this as (left as an execise).

The reason of the text in the RGS is the difficulty to assume
that a relying party can handle resumption of a real existing
suspended cert.

I do not make a comment on the usefulness of certificateHold
as a reasonCode for non existing certs

/p

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 09 Nov 2012 10:00:21 -0400

+1 to what Simon says here. Well put.

/Stefan

From:  Simon Tardell <[email-masked]>
Date:  Friday, November 9, 2012 5:17 AM
To:  Denis Pinkas <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [pkix] What's the need to introduce fraudulently issued
certificates in OCSP

>>    1) Not really:  it would prevent CAs which need to comply with the French
>> legislation from taking advantage of the new feature.
> 
> As I noted earlier I don't read it that way. The text is about what you can do
> to a certificate. You can't suspend a certificate. But the proposed text is
> about responding certificateHold for anything but a certificate.
>  
> Well, that's easier to solve. It is not a practical problem, for the very same
> reason (actual certificates will never be on hold, so they will only have one
> continuous validity period, which is the simplification I believe they are
> after). And CAB Forum is perhaps easier to reason with than a French ministry
> (given my prejudice about the napoleonic system of government ;)-.
> 
> That logic is clearly against the specification, so why should we accommodate
> it? Perhaps we need some clarifying language somewhere else to prevent this
> practice from proliferating.
>  
> Because it is still definite. A serial number which is not issued today may be
> issued tomorrow. So you have to use a reason code that carries with it that it
> is valid _now_ but may change the next time you ask.
>  
>> This is not a new extension, but a change in the semantics of the "revoked"
>> status and that may have further implications
>>  on its processing.
> 
> I don't agree here. It does not change anything for clients that are already
> complying with relevant PKIX standards. The only parties that *may* need to
> change something are OCSP responders, and that's only if they want to take
> advantage of this functionality.
>  
> /Simon
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix