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

From: [email-masked]
Date: Thu, 08 Nov 2012 10:27:49 +0100

Hi all,

In the recent Straw poll after saying that this is not a way to fix it and choose option 1 as the lesser evil, I´d like to clarify my "proposal" and let you know that from a point of view of a PKI software company that wants to implement this solution, it´s not easy and in fact will not fix anything. So here it goes

This "fix" tries to avoid that someone can issue a bogus certificate and after that delete the log/registry of the issuance (This is the Diginotar case). But this "fix" wouldn´t help/fix much:

- if a bogus certificate has been issued, it means that the CA key has been compromised so that CA has to be removed/deleted/destroyed.
But
- as I´m an evil hacker that get access to the CA, I can create the bogus certificate without AIA
- as I´m en evil hacket that get access to the CA, I can create the bogus certificate without AIA and with CDP pointing to legitimate CRLs
- as I´m en evil hacket that get access to the CA, I can create the bogus certificate with an AIA that points to an OCSP responder that I control/manage
- as I´m en evil hacket that get access to the CA, I can create the bogus certificate with a serial number of a valid certificate

So, all third parties systems that use CRLs instead of OCSP to validate certs, will consider this bogus cert as valid

In summary, the VA has to manage, somehow, a kind of a white list that can grow to the infinite. This VA has to "ask this list" every time an OCSP responder is generated and has to update practically at the same time than the issuance of the certificate.
But the key question is that once this evil hacker has done "his job", the only fix is to revoke the complete CA. It´s useless that the OCSP responder gives a "revoked" for unknown certificates because the browsers for example could be asking the bogus OCSP (the one controlled by the hacker) or asking for a serial number of the bogus certificate which is identical to a legitimate one.

I know that we all know this situation so maybe this is useless, not easy to implement for sure and with very limited good results.

Regards

Iñigo Barreira
Responsable del Área técnica
[email-masked]
945067705

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Stefan Santesson
Enviado el: miércoles, 07 de noviembre de 2012 14:39
Para: [email-masked]
Asunto: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP

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

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

---

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

Hi,

On 11/8/12 5:27 AM, "[email-masked]" <[email-masked]> wrote:

>This "fix" tries to avoid that someone can issue a bogus certificate and
>after that delete the log/registry of the issuance (This is the Diginotar
>case). But this "fix" wouldn´t help/fix much:

You go wrong already here, and thus the rest goes wrong as well.

This is NOT what the fix attempts to do.

This is what CAB Forum attempts to do. If you think the CAB Forum deals
with this the wrong way, you should really take this up on their mailing
list.

This fix (The OCSP update in PKIX) simply allows CAB forum to do what they
feel they need to do in one particular area.

/Stefan

---

From: [email-masked]
Date: Thu, 08 Nov 2012 16:14:25 +0100

Stefan,

I think this is what the recent poll tries to do, say revoked for a non issued certificate, and this is what will happen. As said i voted option 1 but that does not mean that I´m agree with this situation because at the end, the CA has to be revoked and for the OCSP responder knows what certs have been issued or not, then you´ll need to manage a kind of a big white list and this is not easy to implement. That´s it, I´m not wrong whatsoever you want to call it

Iñigo Barreira

-----Mensaje original-----
De: Stefan Santesson [mailto:[email-masked]] 
Enviado el: jueves, 08 de noviembre de 2012 13:51
Para: Barreira Iglesias, Iñigo; [email-masked]
Asunto: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP

Hi,

On 11/8/12 5:27 AM, "[email-masked]" <[email-masked]> wrote:

>This "fix" tries to avoid that someone can issue a bogus certificate 
>and after that delete the log/registry of the issuance (This is the 
>Diginotar case). But this "fix" wouldn´t help/fix much:

This is what CAB Forum attempts to do. If you think the CAB Forum deals with this the wrong way, you should really take this up on their mailing list.

This fix (The OCSP update in PKIX) simply allows CAB forum to do what they feel they need to do in one particular area.

/Stefan

---

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

list.

[Piyush] If you are updating a PKIX document solely based on CAB forum's
requirements, the merits of those requirements should be discussed here, not
in CAB forum. Otherwise CAB forum is free to create profile of OCSP that
suits their needs. The current text in OCSP merely says that revoked is an
indication that certificate was revoked. It does not say the responders MUST
return revoked only if certificate is revoked by the CA.

> feel they need to do in one particular area.
[Piyush] 
Not a reason to update a pkix document which has applications outside the
CAB community.
Just because I feel that my responder should return revoked for certificate
of people who wear red shirts does not mean that PKIX should have text in
OCSP endorsing this.

---

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

Piyush,

We had a straw-poll and it clearly favoured to allow "revoked" to be
returned for non-issued certs.
Unless you can come up with a real issue where this creates real problems,
I'm considering this issue closed.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 08 Nov 2012 12:58:04 -0400

Inigo,

You are not wrong.

But you don't have to manage any white list to conform with the updated
OCSP spec.
CAB Forum will require responders in their infrastructure to do it, so
this also seems to be an issue for the CAB Forum.

/Stefan

On 11/8/12 11:14 AM, "[email-masked]" <[email-masked]> wrote:

>Stefan,
>
>I think this is what the recent poll tries to do, say revoked for a non
>issued certificate, and this is what will happen. As said i voted option
>1 but that does not mean that I´m agree with this situation because at
>the end, the CA has to be revoked and for the OCSP responder knows what
>certs have been issued or not, then you´ll need to manage a kind of a big
>white list and this is not easy to implement. That´s it, I´m not wrong
>whatsoever you want to call it
>
>
>Iñigo Barreira
>ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
>egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada
>(helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari,
>korreo honi erantzuna. KONTUZ!
>ATENCION! Este mensaje contiene informacion privilegiada o confidencial a
>la que solo tiene derecho a acceder el destinatario. Si usted lo recibe
>por error le agradeceriamos que no hiciera uso de la informacion y que se
>pusiese en contacto con el remitente.
>
>
>This fix (The OCSP update in PKIX) simply allows CAB forum to do what
>they feel they need to do in one particular area.
>
>/Stefan
>
>
>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 08 Nov 2012 19:58:17 -0400

I think this is a very valid post for the CAB forum.

In their context this is only a piece of the puzzle. I'm sure they will be
able to respond to how this is a legitimate part of their strategy where
they have other things in place that provides a more complete picture.

The current update has never been proposed as a complete solution.

/Stefan

On 11/8/12 5:27 AM, "[email-masked]" <[email-masked]> wrote:

>Hi all,
>
>In the recent Straw poll after saying that this is not a way to fix it
>and choose option 1 as the lesser evil, I´d like to clarify my "proposal"
>and let you know that from a point of view of a PKI software company that
>wants to implement this solution, it´s not easy and in fact will not fix
>anything. So here it goes
>
>- if a bogus certificate has been issued, it means that the CA key has
>been compromised so that CA has to be removed/deleted/destroyed.
>But
>- as I´m en evil hacket that get access to the CA, I can create the bogus
>certificate without AIA and with CDP pointing to legitimate CRLs
>- as I´m en evil hacket that get access to the CA, I can create the bogus
>certificate with an AIA that points to an OCSP responder that I
>control/manage
>- as I´m en evil hacket that get access to the CA, I can create the bogus
>certificate with a serial number of a valid certificate
>
>So, all third parties systems that use CRLs instead of OCSP to validate
>certs, will consider this bogus cert as valid
>
>In summary, the VA has to manage, somehow, a kind of a white list that
>can grow to the infinite. This VA has to "ask this list" every time an
>OCSP responder is generated and has to update practically at the same
>time than the issuance of the certificate.
>But the key question is that once this evil hacker has done "his job",
>the only fix is to revoke the complete CA. It´s useless that the OCSP
>responder gives a "revoked" for unknown certificates because the browsers
>for example could be asking the bogus OCSP (the one controlled by the
>hacker) or asking for a serial number of the bogus certificate which is
>identical to a legitimate one.
>
>I know that we all know this situation so maybe this is useless, not easy
>to implement for sure and with very limited good results.
>
>Regards
>
>Iñigo Barreira
>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.
>

---

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

Iñigo,

There are two goals:

The first goal is to allow an OCSP client to *detect* an abnormal 
situation and to alert
the OCSP server. This is only a *detection* mechanism which may be 
followed by a
*recovery* mechanism. This is not a *prevention* mechanism.

draft-pinkas-2560bis-certinfo-00.txt includes a text about security 
considerations which
provides more details. For convenience, it is copied below:

    " When an OCSP server receives an alert from an OCSP client, it should
    use the information provided by the OCSP client to investigate the
    case.

    If the target certificate is unknown to the OCSP server, but has
    been regularly issued, it is necessary to discriminate between a
    denial of service attack or an accident and to correct the problem
    so that the situation does not persist.

    If the target certificate has not been regularly issued, its serial
    number should be immediately added by the CA to the list of revoked
    certificates.

    Then after, the OCSP server should continue to investigate the case:

      - either the extend of the damage can be evaluated by the CA and
        only those certificates which have been fraudulently issued
        shall be revoked by the CA, or

      - the extend of damage cannot be evaluated and in that case the CA
        should ask to its superior CA to revoke its CA certificate.

    It is up to the CA and to the OCSP server to cooperate together in
    order to attempt to recover from these situations.  OCSP servers and
    CAs should include in their recovery plans, the above situations".

The second goal is to avoid to return the "good" revocation status when the
OCSP responder has access to a database of issued (and currently valid)
certificates and when it knows that the serial number is not in the 
database.

Denis

> De:[email-masked]  [mailto:[email-masked]] En nombre de Stefan Santesson
> Para:[email-masked]

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 9 Nov 2012 07:44:47 -0800

Stefan,

It seems the goal of you proposal is to just make the status flexible
enough, so CAB forum responders stay compliant when they return revoked for
fraudulently issued certificates. You've dismissed any discussions about
usefulness or security implications of their proposed method by saying that
it is CAB forum's problem to solve.

Here is a modified version of your proposal. It provides flexibility to
return revoked for any 'bad' certificates as opposed to only fraudulently
issued ones. It also makes the discussions on certificate hold, revocation
time moot (these discussions don't make sense anyway for so called
non-issued certificates)

"The "revoked" state indicates that the certificate has been revoked (either
permanently or temporarily (on hold)). This state MAY also be returned to
indicate that the certificate should not be trusted by the relying party,
even if it is not revoked by the CA". How the responder makes this
determination is beyond the scope of this document."

Thoughts?

-Piyush

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stefan Santesson
> Sent: Thursday, November 08, 2012 3:58 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [pkix] What's the need to introduce fraudulently issued
> certificates in OCSP
> 
able to
> respond to how this is a legitimate part of their strategy where they have
> other things in place that provides a more complete picture.
> 
> >and let you know that from a point of view of a PKI software company
> >that wants to implement this solution, it´s not easy and in fact will
> >not fix anything. So here it goes
> >
> >- as I´m en evil hacket that get access to the CA, I can create the
> >bogus certificate without AIA and with CDP pointing to legitimate CRLs
> >- as I´m en evil hacket that get access to the CA, I can create the
> >bogus certificate with an AIA that points to an OCSP responder that I
> >control/manage
> >- as I´m en evil hacket that get access to the CA, I can create the
> >bogus certificate with a serial number of a valid certificate
> >
> >responder gives a "revoked" for unknown certificates because the
> >browsers for example could be asking the bogus OCSP (the one controlled
> >by the
> >I know that we all know this situation so maybe this is useless, not
> >easy to implement for sure and with very limited good results.
> >
> >Regards
> >
> >Iñigo Barreira
> >ATENCION! Este mensaje contiene informacion privilegiada o confidencial
> >a la que solo tiene derecho a acceder el destinatario. Si usted lo
> >recibe por error le agradeceriamos que no hiciera uso de la informacion
> >y que se pusiese en contacto con el remitente.
> >
> >De: [email-masked] [mailto:[email-masked]] En nombre de
> >Stefan Santesson Enviado el: miércoles, 07 de noviembre de 2012 14:39
> >Para: [email-masked]
> >I would suggest that what we are trying to do with OCSP in this update
> >is NOT to fix problems with compromised CAs.
> >

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 9 Nov 2012 16:01:41 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Piyush Jain

>  "The "revoked" state indicates that the certificate has
>   been revoked (either permanently or temporarily (on hold)).
>   This state MAY also be returned to indicate that the certificate
>   should not be trusted by the relying party, even if it is not
>   revoked by the CA". How the responder makes this determination
>   is beyond the scope of this document."

+1

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 09 Nov 2012 11:06:06 -0400

Hi,

I con't possibly come up with more than 3 states of a randomly selected
cert serial number:
It is either:
1) Never issued (never included in any issued certificates by this CA).
2) Has been issued and is revoked.
3) Has been issued but is not revoked

The other dimension of this is whether the cert is within its validity
period or not.
I reaaly want to stay out of that aspect due to all variants of dealing
with historic validation.

My fear is that responders that adopts your text may want to include cert
expiration into the determination of "bad".
And then we have really created confusion as to what "revoked" really
means.

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 9 Nov 2012 08:31:07 -0800

The first state that you refer to has no practical value. Clients don't send
OCSP requests for randomly selected certificates. I think the cause of
confusion is the misnomer "non-issued-certificates". The reasoning offered
for this proposal was that it helps CAs to deal with digiNotor like
scenarios. If I've missed any discussion on usefulness of providing status
for random serial numbers which are not tied to a certificate, please let me
know.

> The other dimension of this is whether the cert is within its validity
period or
> not.> I reaaly want to stay out of that aspect due to all variants of
dealing with
> historic validation.
The changed text actually helps us stay out of those discussions
> expiration into the determination of "bad". And then we have really
created confusion as to what "revoked" really
> means.

I don't see any practical problem even if the responders decide to do so.
The arguments that are made for returning revoked for non-issued are
applicable even for expired certificates or for that matter any bad
certificate. Its more secure for clients who do not deal with expired
certificates correctly - same as revoked for 'non-issued', which is more
secure for clients who do not deal with 'unknown' correctly.
BTW - I think that above text is actually clearer in conveying the changed
meaning, from just 'revocation status' to negative proof.

> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Friday, November 09, 2012 7:06 AM
> To: Piyush Jain; [email-masked]; [email-masked]
cert
> serial number:
period or
> not.
with
> historic validation.
> >enough, so CAB forum responders stay compliant when they return
> revoked
> >for fraudulently issued certificates. You've dismissed any discussions
> >about usefulness or security implications of their proposed method by
> >saying that it is CAB forum's problem to solve.
> >
> >return revoked for any 'bad' certificates as opposed to only
> >fraudulently issued ones. It also makes the discussions on certificate
> >hold, revocation time moot (these discussions don't make sense anyway
> >for so called non-issued certificates)
> >
> >"The "revoked" state indicates that the certificate has been revoked
> >(either permanently or temporarily (on hold)). This state MAY also be
> >returned to indicate that the certificate should not be trusted by the
> >relying party, even if it is not revoked by the CA". How the responder
> >makes this determination is beyond the scope of this document."
> >
> >Thoughts?
> >
> >-Piyush
> >
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Stefan Santesson
> >> respond to how this is a legitimate part of their strategy where they
> >>have  other things in place that provides a more complete picture.
> >>
> >> >In the recent Straw poll after saying that this is not a way to fix
> >> >it and choose option 1 as the lesser evil, I´d like to clarify my
> >>"proposal"
> >> >that wants to implement this solution, it´s not easy and in fact
> >> >will not fix anything. So here it goes
> >> >
> >> >- if a bogus certificate has been issued, it means that the CA key
> >> >has been compromised so that CA has to be
> removed/deleted/destroyed.
> >> >But
> >> >bogus certificate with an AIA that points to an OCSP responder that
> >> >I control/manage
> >> >So, all third parties systems that use CRLs instead of OCSP to
> >> >validate certs, will consider this bogus cert as valid
> >> >
> >> >In summary, the VA has to manage, somehow, a kind of a white list
> >> >that can grow to the infinite. This VA has to "ask this list" every
> >> >time an OCSP responder is generated and has to update practically at
> >> >the same time than the issuance of the certificate.
> >> >But the key question is that once this evil hacker has done "his
> >> >job", the only fix is to revoke the complete CA. It´s useless that
> >> >the OCSP responder gives a "revoked" for unknown certificates
> >> >because the browsers for example could be asking the bogus OCSP (the
> >> >one controlled by the
> >> >hacker) or asking for a serial number of the bogus certificate which
> >> >is identical to a legitimate one.
> >> >
> >> >(helbidea gaizki idatzi, transmisioak huts egin) eman abisu
> >> >igorleari, korreo honi erantzuna. KONTUZ!
> >> >ATENCION! Este mensaje contiene informacion privilegiada o
> >> >confidencial a la que solo tiene derecho a acceder el destinatario.
> >> >Si usted lo recibe por error le agradeceriamos que no hiciera uso de
> >> >la informacion y que se pusiese en contacto con el remitente.
> >> >
> >> >De: [email-masked] [mailto:[email-masked]] En nombre
> >> >de Stefan Santesson Enviado el: miércoles, 07 de noviembre de 2012
> >> >14:39
> >> >Para: [email-masked]
> >> >I would suggest that what we are trying to do with OCSP in this
> >> >update is NOT to fix problems with compromised CAs.
> >> >

---

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

On 11/9/12 12:31 PM, "Piyush Jain" <[email-masked]> wrote:

>Clients don't send
>OCSP requests for randomly selected certificates.

An attacker may, e.g. in order to harvest information/data that may be
useful to form attacks.

A responder must be prepared to deal with all possible requests.

I'm reluctant to take this discussion any further unless something really
new comes up.
We have already established our level of disagreement.

/Stefan

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 9 Nov 2012 18:09:44 +0100

2012/11/9 Piyush Jain <[email-masked]>

> OCSP requests for randomly selected certificates. I think the cause of

They do. Everyday. Some are purely bogus requests, some are crafted ones.
The OCSP responder has to respond to those.

-- 
Erwann.

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 9 Nov 2012 09:14:45 -0800

Erwaan,

What do you think is the right response in such cases?

One large public CA vendor returns unsigned ‘try later’ for such requests. The reasoning is to not waste CPU cycles and bandwidth on such requests because they have no practical value.

-Piyush

From: Erwann Abalea [mailto:[email-masked]] 
Sent: Friday, November 09, 2012 9:10 AM
To: Piyush Jain
Cc: Stefan Santesson; [email-masked]; [email-masked]
Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP

-- 
Erwann.

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 9 Nov 2012 18:35:37 +0100

I'd reply an unsigned response. "unauthorized" seems better than "tryLater"
(the later is obviously an invitation to retry, which is undesired).
It's easier to define in the CABForum context because of the 'B'rowsers
participation.

That's why I responded #3 to the stray poll, with the hope that some
constraints or guidelines could be set on RP.

> Erwaan,****
>
> ** **
>
> What do you think is the right response in such cases?****
>
> One large public CA vendor returns unsigned ‘try later’ for such requests.
> The reasoning is to not waste CPU cycles and bandwidth on such requests
> because they have no practical value.****
>
> ** **
>
> -Piyush****
>
> ** **
>
> *From:* Erwann Abalea [mailto:[email-masked]]
> *Sent:* Friday, November 09, 2012 9:10 AM
> *To:* Piyush Jain
> *Cc:* Stefan Santesson; [email-masked]; [email-masked]
>
> *Subject:* Re: [pkix] What's the need to introduce fraudulently issued
> certificates in OCSP****
>
> ** **
>
> ** **
>
> 2012/11/9 Piyush Jain <[email-masked]>****
>
> OCSP requests for randomly selected certificates. I think the cause of****
>
> ** **
>
> They do. Everyday. Some are purely bogus requests, some are crafted ones.*
> ***
>
> The OCSP responder has to respond to those.****
>
> ** **
>
> --
> Erwann.****
>

-- 
Erwann.

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 9 Nov 2012 09:51:33 -0800

Thanks Erwann,

Unsigned Unauthorized indeed seems to be a better choice.

-Piyush

From: Erwann Abalea [mailto:[email-masked]] 
Sent: Friday, November 09, 2012 9:36 AM
To: Piyush Jain
Cc: Stefan Santesson; [email-masked]; [email-masked]
Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP

I'd reply an unsigned response. "unauthorized" seems better than "tryLater" (the later is obviously an invitation to retry, which is undesired).

It's easier to define in the CABForum context because of the 'B'rowsers participation.

That's why I responded #3 to the stray poll, with the hope that some constraints or guidelines could be set on RP.

Erwaan,

-Piyush

 

-- 
Erwann.

-- 
Erwann.

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 09 Nov 2012 13:22:40 -0400

Just for clarity,

The current proposal does not preclude you from responding "unauthorized".
It just allows you to respond "revoked".

/Stefan

From:  Erwann Abalea <[email-masked]>
Date:  Friday, November 9, 2012 1:35 PM
To:  Piyush Jain <[email-masked]>
Cc:  Stefan Santesson <[email-masked]>, <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject:  Re: [pkix] What's the need to introduce fraudulently issued
certificates in OCSP

>> One large public CA vendor returns unsigned Œtry later¹ for such requests.
>> because they have no practical value.
>>  
>> -Piyush
>>  
>>

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 9 Nov 2012 10:38:49 -0800

Stefan,

Could you also respond to second part of my post, which I think was your
primary reason for shooting down the alternative text that I proposed?
 I'm interested in knowing why revoked makes sense only for some cases of
'bad', but not for all cases of 'bad'.  Don't you think it will be little
presumptuous of this WG to pre-determine what those 'bad' certificates could
be. We've been bitten once by assuming that signatures are enough to
establish issuance.

For your reference, here is the text that did not make it in your last
response.

>> My fear is that responders that adopts your text may want to include 
>> cert expiration into the determination of "bad". And then we have 
>> really

I> don't see any practical problem even if the responders decide to do so.

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 9 Nov 2012 10:46:16 -0800

My apologies Stefan.  I was not trying to question if changing the meaning
of revoked makes sense. That issue has been put to rest. I think that most
folks believe that changing the meaning of revoked to imply a negative
assertion (beyond revocation status) about the certificate makes sense. 

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Friday, November 09, 2012 9:23 AM
To: Erwann Abalea; Piyush Jain
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] What's the need to introduce fraudulently issued
certificates in OCSP

Just for clarity,

/Stefan

Erwaan,

One large public CA vendor returns unsigned 'try later' for such requests.
The reasoning is to not waste CPU cycles and bandwidth on such requests
because they have no practical value.

-Piyush

 

-- 
Erwann.

-- 
Erwann.

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 09 Nov 2012 15:47:02 -0400

Piyush,

We are walking on a mine field because we have to respect a huge deployed
base that needs to work and be in compliance also after the update.

I get scared of using a such broad term such as "bad" as reason for
responding revoked of reasons in my previous mail.
If it leads to responders responding revoked because the certificate has
expired, then we could create some serious problems.
At, least I'm not sure that it is safe.

That is why I don't like your generic approach.
To go down that path would require us to take a huge step back in the
process and explore the consequences thoroughly.
I'm reluctant to do that at this stage.

You may have noticed how every new detail stirs up huge discussions :)

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 9 Nov 2012 14:34:46 -0800

> base that needs to work and be in compliance also after the update.
[Piyush] Agree with that assessment. Every change that is proposed here
should be evaluated based on its impact of the whole base, not just on a
single requirement
> expired, then we could create some serious problems.
[Piyush] Stefan - we are still discussing the impact of introducing
non-issued on how other deployments which use revocation reason, revocation
date, CRLs as backup revocation check mechanism are affected. 
My proposed change just moves those discussions out of this WG puts the onus
on implementers who decide to deploy their responder this way.

> At, least I'm not sure that it is safe.
[Piyush] I think you are pretty comfortable with the notion that only
responders who decided to respond this way are affected and that none of the
clients are affected by this. This was your reasoning all along and that
reasoning still applies to the alternative text.
> I'm reluctant to do that at this stage.
[Piyush] Again - what consequences? It only affects the responders who want
to use revoked this way and it does not require changes in any of the
clients. 
The new text also communicates the change precisely and concisely. Revoked,
now implies any negative assertion about the certificate, not just a revoked
status.

The benefit is obvious. Allows CAB forum responders to be compliant and
allows OCSP to abstain from making judgments on their choice. With your
proposal, at the minimum we'll need to update OCSP text to provide guidance
on how this affects other fields and also on the security implications.
Plus, it would be restrictive if tomorrow we find that there is another use
case where it makes sense for the responder to make a negative assertion
about the certificate.

BTW, I bet if you do a straw poll asking what the responder should return
for a certificate that cannot be trusted, you will still find that majority
will vote for revoked.

> You may have noticed how every new detail stirs up huge discussions :)
[Piyush] I think only the ones where opinions are divided lead to huge
discussions. Discussions die if everyone is in agreement :).

---

From: [email-masked]
Date: Tue, 13 Nov 2012 09:44:08 +0100

Stefan,

I know is something CABF is worried about, what I´m trying to say is that this "solution" is not easy to implement, at least from my point of view (a CA), and it wouldn´t help to prevent the CA to be attacked and compromised, which is the main issue here. It´s a way forward solution that does not prevent an attack and maybe not issuing fraudulent certificates, but at least it´s better than doing nothing.

Iñigo Barreira

-----Mensaje original-----
De: Stefan Santesson [mailto:[email-masked]] 
Enviado el: jueves, 08 de noviembre de 2012 17:58
Para: Barreira Iglesias, Iñigo; [email-masked]
Asunto: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP

Inigo,

You are not wrong.

But you don't have to manage any white list to conform with the updated OCSP spec.
CAB Forum will require responders in their infrastructure to do it, so this also seems to be an issue for the CAB Forum.

/Stefan

On 11/8/12 11:14 AM, "[email-masked]" <[email-masked]> wrote:

>certs have been issued or not, then you´ll need to manage a kind of a 
>big white list and this is not easy to implement. That´s it, I´m not 
>wrong whatsoever you want to call it
>
>
>Iñigo Barreira
>De: Stefan Santesson [mailto:[email-masked]] Enviado el: jueves, 08 
>de noviembre de 2012 13:51
>with this the wrong way, you should really take this up on their 
>mailing list.
>

---

From: "Peter Rybar" <[email-masked]>
Date: Tue, 13 Nov 2012 09:53:40 +0100

Only when CA is/was compromised then "non-issued" certificates can/could be created by such CA and only that case is the important one which must be detected. 
Randomly created serial numbers in OCSP request must be ignored as unauthorized (quick unsigned response when all issued certificates are known for OCSP responder) or unknown (general signed response).

When the serial number of a "non-issued" certificate is a serial number reused from correctly issued certificate (one of the cases described by Stefan in points 2) or 3)) then only positive statement single extension as a hash value of certificate whose status OCSP response provides is a solution for detection of such attacks/problems.
Relying parties can provide such detection to accreditation organization or to the issuer of compromised CA certificate to make corrections.

It is a wrong expectation that compromised CA will be able to provide the correct data for the OCSP responder and OCSP responder will be able to revoke such certificate as the "non-issued" certificate. 

Once CA is compromised then it is unclear what else was also compromised under CA key.

[Stefan]
I can't possibly come up with more than 3 states of a randomly selected cert serial number:
It is either:
1) Never issued (never included in any issued certificates by this CA).
2) Has been issued and is revoked.
3) Has been issued but is not revoked

Peter Rybar

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 13 Nov 2012 07:56:42 -0800

Peter- I'm in complete agreement with you.

I think that the reason to propose returning revoked for fraudulently issued certificates is that many in CAB forum believe that this is the right way and current text in OCSP does not allow them to do so. If that flexibility needs to be provided, the simplest way to do it is to allow them to return revoked for any certificate that they think cannot be trusted, without endorsing any method that they use to make that determination.

As you said, non-issued is ambiguous because it can refer to any of the following
1)  Not present in CA database (this may include expired certs, random serials not signed by CA cert, fraudulently issued certificates)
2)  Never signed using the CA certificate
3) Signed using CA certificate fraudulently

If people interpret it to be 1), it actually affects most of the responders operated by public CAs because it essentially precludes pre-signing. Two biggest public CAs in the U.S. use pre-signed OCSP responses to meet the operational requirements of their infrastructure.

For 2) , the best response is unsigned UNAUTHORIZED. At least one large public CA vendor returns unsigned TRY_LATER for these cases.

If CAs can differentiate between 2) and 3), they can simply mark fraudulently issued certificates as revoked (even though that is not a secure way to deal with the problem).

> From: Peter Rybar [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2012 12:54 AM
> To: 'Piyush Jain'; 'Stefan Santesson'; [email-masked]; [email-masked]
> Subject: RE: [pkix] What's the need to introduce fraudulently
> issuedcertificates in OCSP
> 
> Only when CA is/was compromised then "non-issued" certificates can/could
> be created by such CA and only that case is the important one which must be
> detected.
> Randomly created serial numbers in OCSP request must be ignored as
> unauthorized (quick unsigned response when all issued certificates are
> known for OCSP responder) or unknown (general signed response).
> 
> When the serial number of a "non-issued" certificate is a serial number
> reused from correctly issued certificate (one of the cases described by Stefan
> in points 2) or 3)) then only positive statement single extension as a hash
> value of certificate whose status OCSP response provides is a solution for
> detection of such attacks/problems.
> Relying parties can provide such detection to accreditation organization or to
> the issuer of compromised CA certificate to make corrections.
> 
> It is a wrong expectation that compromised CA will be able to provide the
> correct data for the OCSP responder and OCSP responder will be able to
> revoke such certificate as the "non-issued" certificate.
> 
> Piyush Jain
> > We are walking on a mine field because we have to respect a huge
> > deployed base that needs to work and be in compliance also after the
> update.
> > If it leads to responders responding revoked because the certificate
> > has expired, then we could create some serious problems.
> [Piyush] Stefan - we are still discussing the impact of introducing non-issued
> on how other deployments which use revocation reason, revocation date,
> CRLs as backup revocation check mechanism are affected.
> My proposed change just moves those discussions out of this WG puts the
> onus on implementers who decide to deploy their responder this way.
> 
> 
> responders who decided to respond this way are affected and that none of
> the clients are affected by this. This was your reasoning all along and that
> [Piyush] Again - what consequences? It only affects the responders who
> want to use revoked this way and it does not require changes in any of the
> clients.
> The new text also communicates the change precisely and concisely.
> Revoked, now implies any negative assertion about the certificate, not just a
> revoked status.
> 
> proposal, at the minimum we'll need to update OCSP text to provide
> guidance on how this affects other fields and also on the security
> implications.
> BTW, I bet if you do a straw poll asking what the responder should return for
> a certificate that cannot be trusted, you will still find that majority will vote
> for revoked.
> 
> >