Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

From: Stefan Santesson <[email-masked]>
Date: Wed, 09 Jan 2013 05:39:47 +0100

Peter;

On 1/8/13 5:18 PM, "Peter Rybar" <[email-masked]> wrote:

>Stefan,
>The terminology is not clear for someone who will see:
>The revocation is of "non-issued certificate".
>Because by reading the text it is expected that the certificate was
>issued, but fraudulently.

What part of the text supports that?

>
>The revocation with a new extension is only about fraudulently issued
>certificate. It means this new extension and revocation is not used when
>the certificate is not issued and only fake random certificate serial
>number was created in OCSP request.

What?
How in this physical universe would the OCSP responder tell the
difference???
Crystal ball?

>
>While it is intended only for fraudulently issued certificate where
>fraudulently issued certificate can potentially reuse any already used
>certificate-serial-number the extension must contain e.g. a positive
>confirmation of existence in the form of hash value of fraudulently
>issued certificate.

No that is a task for another possible effort.
It's not part of this update.

But this update paves the way for such extension. Which I'm not against.
It's just not part of this update effort.

>
>Only according to the hash value of fraudulently issued certificate
>relaying party and OCSP responder is able to identify fraudulently issued
>certificate because CA was compromised and serial numbers of certificates
>are not any longer unique for compromised CA.
>
>Conclusion:
>Positive statement extension as a hash value of the certificate whose
>status OCSP response is providing can be used in this case:
>  when the certificate is revoked,
>  when the certificate is good and also
>  when the certificate is fraudulently issued.
>
>For that reason it can be more helpful to define in RFC one positive
>statement extension as a hash value of the certificate whose status the
>OCSP response is providing and define in RFC that it will support
>situations when status is:
>   -- good
>   -- revoked
>And for randomly created certificate serial numbers without records in
>OCSP database will be use:
>   -- unknown

No, we have been through this and determined WG consensus.
Unknown is not the choice, since it may not have the desired effect (to
indicate that a certificate with this serial number should not be trusted).

It's important that this works with legacy clients. They will be around
for a while.

/Stefan

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

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 9 Jan 2013 09:17:17 -0800

> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Tuesday, January 08, 2013 8:40 PM
> To: Peter Rybar; 'Piyush Jain'; 'pkix'
> Subject: Re: [pkix] Question about extended Revoked Extension defined in
> section 4.4.8 of ocsp draft 8
> Importance: High
> 
> Peter;
> 
[Piyush] None explicitly, but many would infer it that way. The certificate
space that is covered by your interpretation of "non-issued" includes
certificates which are not signed using the CA key and those that are signed
fraudulently. RPs won't make queries for certificate for which they cannot
verify the signature. So the only genuine requests for "non-issued
certificates" coming to a responder would be those for fraudulently issued
certificates unless you are saying that this specification will allow for
RPs to skip signature checking.
> >certificate. It means this new extension and revocation is not used
> >when the certificate is not issued and only fake random certificate
> >serial number was created in OCSP request.
> 
> What?

[Piyush] Can you clarify what is the goal for this update? I think it is one
of the following
- Allow for extending definition of revoked so other specifications can
extend the protocol
- Address handling of fraudulently issued certificate.
- Address handling of any certificate not issued by the CA.

But based on different threads on this topic I get confused about what it
is. Having the goal clear would help us keep the review of draft focused. 

> >relaying party and OCSP responder is able to identify fraudulently
> >issued certificate because CA was compromised and serial numbers of
> >certificates are not any longer unique for compromised CA.
> >
> >Conclusion:
for a
> while.
[Piyush] That's an interesting usage of the word "legacy". I don't think
that any of the previous versions of OCSP recommended interpreting "unknown"
or UNAUTHORIZED(unsigned) responses to imply that certificate can be
trusted. The right word would be to "incorrectly implemented clients".

---

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

>is. Having the goal clear would help us keep the review of draft focused.

The purpose of this update is to correct errors, fix problems, merge
previous updates into one document and clarify ambiguities.
It is not to add new features to OCSP.

The reason why the non-issed thing is handled is because it was not
perfectly clear how an OCSP responder could respond to a certificate with
a serial number that was known to never have been issued during the
lifetime of the CA.

So the answer is your first bullet.

The update is limited to allowing the revoked response for non-issued
certs, which required an extension.
The playing field is then open for user community profiles or other
extensions to the OCSP protocol to address the area of fraudulent issued
certs or positive confirmations.

/Stefan

---

From: "Peter Rybar" <[email-masked]>
Date: Thu, 10 Jan 2013 12:13:08 +0100

Stefan,

For me is unclear how this extension of revoked with reason code certificateHold is useful.

It define that now is possible to revoke what does not exist and it open never ending cycle of trying to fixing or correcting the first incorrect status that "fake" cert serial number is revoked but cert serial number is not revoked because "fake" cert does not exist.

I agree that extension of revoked can be helpful like:

   The "revoked" state indicates that the certificate has been revoked
   (either permanently or temporarily (on hold)). Response extensions
   may be used to convey additional information on assertions made by
   the responder regarding the status of the certificate such as
   positive statement about issuance, validity, etc.

When the certificate serial number is not in the OCSP database/CRL then according to rfc2560bis there are defined following possible responses:

1. signed -  good (e.g. certificate serial number is not listed in CRL)

2. signed -  unknown (e.g. certificate serial number is not listed in CRL)

3. unsigned – unauthorized as an error message

4. signed -  revoked where according to rfc2560bis are defined values for:

Extensions: id-pkix-ocsp-extended-revoke

Revocation Reasons: certificateHold

Revocation Time: 1.1.1970 00:00:00 UTC

What is missing? The rfc2560bis must also specify values for:

This Update:  ?? ?? ??     10.1.2013 9:51:15 UTC

Next Update:  ?? ?? ??     10.1.2013 9:51:15 UTC

X.509 defines the reason code certificateHold as 1) it may remain on the CRL; 2) it may be replaced by a (final) revocation; 3) it may be explicitly released;

and 

4) as a consequence of rfc2560bis the status of certificate serial number indicated as revoked with reason code certificateHold can be replaced with real status of a new real certificate which was issued with the same certificate serial number as was asked in the incorrect OCSP request created by insufficiently implemented applications where the signature of the certificate was not checked with CA public key.

It is based on the following definitions:

According to rfc2560bis the certificate status value is:
http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/ 
 
   -  good … is not revoked, (does not necessarily mean that the certificate was ever issued)…
   -  revoked … has been revoked (This state MAY also be returned if the responder knows that the requested certificate has never been issued during the history of the associated CA using any current or previous issuing key.)
   -  unknown …

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

According to ITU-T Rec. X.509 (11/2008), clause 8.5.2.2 Reason code extension:

http://www.itu.int/rec/T-REC-X.509 

A certificate may be placed on hold by issuing a CRL entry with a reason code of certificateHold. The certificate hold notice may include an optional hold instruction code to convey additional information to certificate users (see 8.5.2.3). 

Once a hold has been issued, it may be handled in one of three ways: 

a) it may remain on the CRL with no further action, causing users to reject transactions issued during the hold period; or, 

b) it may be replaced by a (final) revocation for the same certificate, in which case the reason shall be one of the standard reasons for revocation, the revocation date shall be the date the certificate was placed on hold, and the optional instruction code extension field shall not appear; or, 

c) it may be explicitly released and the entry removed from the CRL.

-----Original Message-----
From: Piyush Jain [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2013 6:17 PM
To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix'
Subject: RE: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

of the following

extend the protocol

> indicate that a certificate with this serial number should not be

trusted).

for a

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 10 Jan 2013 14:18:40 +0100

Peter, i think the reason for this has been thoroughly debated.

It is correct that a cert serial number that was on hold, may be released.
The requested cert serial number may actually be used in a future
representing a real certificate.
So this is intentional and the whole purpose behind using the on hold
reason.

/Stefan

From:  Peter Rybar <[email-masked]>
Date:  Thursday, January 10, 2013 12:13 PM
To:  'Piyush Jain' <[email-masked]>, Stefan Santesson
<[email-masked]>, 'pkix' <[email-masked]>
Subject:  Re: [pkix] Question about extended Revoked Extension defined in
section 4.4.8 of ocsp draft 8

> It define that now is possible to revoke what does not exist and it open never
> ending cycle of trying to fixing or correcting the first incorrect status that
> "fake" cert serial number is revoked but cert serial number is not revoked
> because "fake" cert does not exist.
>  
> When the certificate serial number is not in the OCSP database/CRL then
> according to rfc2560bis there are defined following possible responses:
> 3. unsigned  unauthorized as an error message
> X.509 defines the reason code certificateHold as 1) it may remain on the CRL;
> 2) it may be replaced by a (final) revocation; 3) it may be explicitly
> released;
> and 
> 4) as a consequence of rfc2560bis the status of certificate serial number
> indicated as revoked with reason code certificateHold can be replaced with
> real status of a new real certificate which was issued with the same
> certificate serial number as was asked in the incorrect OCSP request created
> by insufficiently implemented applications where the signature of the
> certificate was not checked with CA public key.
>  
>    -  good Š is not revoked, (does not necessarily mean that the certificate
> was ever issued)Š
>    -  revoked Š has been revoked (This state MAY also be returned if the
> responder knows that the requested certificate has never been issued during
> the history of the associated CA using any current or previous issuing key.)
>    -  unknown Š
>  
> A certificate may be placed on hold by issuing a CRL entry with a reason code
> of certificateHold. The certificate hold notice may include an optional hold
> instruction code to convey additional information to certificate users (see
> 8.5.2.3). 
> a) it may remain on the CRL with no further action, causing users to reject
> transactions issued during the hold period; or,
> b) it may be replaced by a (final) revocation for the same certificate, in
> which case the reason shall be one of the standard reasons for revocation, the
> revocation date shall be the date the certificate was placed on hold, and the
> optional instruction code extension field shall not appear; or,
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: [email-masked] (Martin Rex)
Date: Thu, 10 Jan 2013 19:32:17 +0100 (CET)

> Peter, i think the reason for this has been thoroughly debated.

+1

More importantly: it is entirely irrelevant for the operation of the
OCSP responder what motivates the RP doing what it does, and what
weird things the RP might infer that are *NOT* specified.

For completeness, the behaviour of the OCSP responder should be well-defined
even for requests that some think would be spec-incompliant for an RP to
send, because there are going to be RPs that will do spec-incompliant things.

> Peter Rybar wrote:
> >   2) it may be replaced by a (final) revocation;
> >   3) it may be explicitly released;
> 

Peter's list is misleading to the point that I would call it incorrect.

While there exists a ReasonCode "removeFromCRL(8)", this reason code
is strictly limited to "delta CRLs", and therefore MUST NOT appear
on base CRLs and consequently MUST NOT appear in OCSP responses.

An (issued!) certificate that was listed onHold on a base CRL or on a
delta CRL will simple be missing on the next base CRL if the
CA clears the onHold status.

> So this is intentional and the whole purpose behind using the on hold

Correct.

-Martin

---

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

> From: Martin Rex [mailto:[email-masked]]
> Sent: Thursday, January 10, 2013 10:32 AM
> To: Stefan Santesson
> Cc: Peter Rybar; 'Piyush Jain'; 'pkix'
[Piyush]  Debated but there was no consensus. 
> 
> More importantly: it is entirely irrelevant for the operation of the OCSP
> responder what motivates the RP doing what it does, and what weird things
> the RP might infer that are *NOT* specified.
[Piyush] I think we are in agreement. If RPs decides to treat signed unknown
or UNAUTHORIZED as good, the standards body should not change the spec to
accommodate such behavior.
> 
> For completeness, the behaviour of the OCSP responder should be well-
> defined even for requests that some think would be spec-incompliant for an
> RP to send, because there are going to be RPs that will do
spec-incompliant
> things.
[Piyush] I agree again. The question is what is that well-defined behavior?
Unsigned UNAUTHORIZED or MALFORMED_REQUST is quick and effective.

> While there exists a ReasonCode "removeFromCRL(8)", this reason code is
> strictly limited to "delta CRLs", and therefore MUST NOT appear on base
CRLs
> and consequently MUST NOT appear in OCSP responses.
[Piyush] While I see no value of including removefromcrl in OCSP responses
I'm surprised at how you arrive to that conclusion in the above sentence.
How is content of OCSP response related to that of CRL or delta CRL?
> An (issued!) certificate that was listed onHold on a base CRL or on a
delta CRL
> will simple be missing on the next base CRL if the CA clears the onHold
status.
> > representing a real certificate.

[Piyush] It is as likely as I growing wings and start flying in future. 

> > So this is intentional and the whole purpose behind using the on hold
[Piyush] The purpose is to support the hack of unissued certificates.
Genuine RPs won't send request for such certificates.
And it does not matter what you return to malicious clients.

---

From: [email-masked] (Martin Rex)
Date: Thu, 10 Jan 2013 22:21:25 +0100 (CET)

Piyush Jain wrote:
> > spec-incompliant things.

At the pure fomal level, you're correct that just having defined
_any_ behaviour would suffice to describe it as "well defined".

But when just slightly beyond, OCSP does not exist for its own merit,
it has a specific purpose, and we *know* that RPs are going to infer
(and then act on) the OCSP response.

We know that RPs / OCSP clients will either skip revocation checking
or fallback to using CRLs when they receive MALFORMED_REQUEST or
UNAUTHORIZED as the response, and in both cases, will end up
considering the certificate status for the certificate serial in question
as "good".  Which means that both of these answers are useless for
the intended purpose, discouraging the RP from considering a certificiate
status of a certificate with the serial in question as "good".

> > CRLs and consequently MUST NOT appear in OCSP responses.
>

It was and still is perfectly OK for OCSP responders to draw their
knowledge about certificate (serial) status from CRLs.

  http://tools.ietf.org/html/rfc2560#section-4.4.2

The rfc2560 update is not going to change that.

However, an OCSP responder which would copy a status "removeFromCRL(8)"
from a delta CRL into an OCSP response would be defective.

> [Piyush] It is as likely as I growing wings and start flying in future. 

This is about avoiding the abusive potential.

"certificateOnHold(8)" is an un-ambiguously temporary status assertion,
whereas a generic "revoked" is a final status assertion.

> And it does not matter what you return to malicious clients. 

You're not looking at the complete picture.

If you set up a local OCSP responder, it will be perfectly OK for such
a responder not only to source from CRLs, but alternatively to essentially
forward/proxy the OCSP request, and either cache and forward the response
cache and recreate an OCSP response with the local signature.

In the latter case, when the original OCSP client only sent the
issuer&serial in the OCSP request, the local OCSP responder is a
perfectly correct an honest client, still it might be forwarding
a request for a certificate serial without having seen (let alone
verified) the certificate carrying that serial.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Thu, 10 Jan 2013 14:51:01 -0800

> Sent: Thursday, January 10, 2013 1:21 PM
> To: Piyush Jain
> Cc: [email-masked]; 'Stefan Santesson'; 'Peter Rybar'; 'pkix'
> > > For completeness, the behaviour of the OCSP responder should be
> > > well- defined even for requests that some think would be
> > > spec-incompliant for an RP to send, because there are going to be
> > > RPs that will do spec-incompliant things.
> >
> At the pure fomal level, you're correct that just having defined _any_
> behaviour would suffice to describe it as "well defined".
> 
> But when just slightly beyond, OCSP does not exist for its own merit, it
has a
> specific purpose, and we *know* that RPs are going to infer (and then act
> on) the OCSP response.
[Piyush]  You said before - "it is entirely irrelevant for the operation of
the OCSP responder what motivates the RP doing what it does".
So what is it - Is it relevant or not?
> 
> We know that RPs / OCSP clients will either skip revocation checking or
> fallback to using CRLs when they receive MALFORMED_REQUEST or
> UNAUTHORIZED as the response, and in both cases, will end up considering
> the certificate status for the certificate serial in question as "good".
Which
> means that both of these answers are useless for the intended purpose,
> discouraging the RP from considering a certificiate status of a
certificate with
> the serial in question as "good".
[Piyush] We also know that OCSP clients will check certificate issuance by
verifying the signature. So they will never send a request for a certificate
that was not issued.
And making the universal claim that RPs treat all non-revoked responses as
good is incorrect.  There are RPs who implement 5280 correctly and reject
the certificates whose status cannot be determined.
> > [Piyush] While I see no value of including removefromcrl in OCSP
> > responses I'm surprised at how you arrive to that conclusion in the
above
> sentence.
knowledge
> about certificate (serial) status from CRLs.
> 
> > > > So this is intentional and the whole purpose behind using the on
> > > > hold reason.
> > >
> If you set up a local OCSP responder, it will be perfectly OK for such a
> responder not only to source from CRLs, but alternatively to essentially
> forward/proxy the OCSP request, and either cache and forward the
> response cache and recreate an OCSP response with the local signature.

[Piyush] It could but it would be incorrect. And none of the OCSP responder
products that exist today work in the way you describe.
You are talking about proxy responder re-signing response from another
responder without establishing trust. Do we even need to discuss the
security implications of this approach?

> In the latter case, when the original OCSP client only sent the
issuer&serial in
> the OCSP request, the local OCSP responder is a perfectly correct an
honest
> client, still it might be forwarding a request for a certificate serial
without
> having seen (let alone

[Piyush] I think it will suffice to say that you should not circumvent the
trust model by putting a proxy in the middle.

---

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

> So what is it - Is it relevant or not?

This is getting boring.

At the protocol level, it is important that the protocol is well-defined
for every possible situation, not just the situations that the inventors
had in mind.  In that respect, rfc2560 is defective.

When fixing a protocol that can be formally proven to be defective,
fixing it in a fashion that results in *DESIRED* behaviour is even
more important than just making the spec formally provable correct.

Formal logic is indifferent to whether the formally provable correct
behaviour (with respect the a given specification) is sensible and
desirable or stupid and not desirable.

Consumers of a protocol and implementations thereof, on the other hand,
typically do care about this difference.

> > Which means that both of these answers are useless for the intended
> > purpose, discouraging the RP from considering a certificiate status of a
> > certificate with the serial in question as "good".
>
> verifying the signature.

That statment is a proven logical fallacy. (colloquial "nonsense").

We all know that were some 200 certs created by hackers that would
verify under the public DigiNotar CA which were never issued.

And there was a CA certificate created by some researchers as a
proof-of-concept which also was never issued, but the signature on
that cert would verify under a public CA:

  http://www.win.tue.nl/hashclash/rogue-ca/

Btw. *NONE* of the RP software I know (MS-CryptoAPI, Firefox, OpenSSL,
and ours) checks certificate issuance, for the simple reason that none of
the existing protocols actually supports conveying proof-of-issuance.

Chrome might be one of the first to check certificate issuance through
the "Certificate Transparency" protocol, but that is currently
outside of X.509/PKIX.  So with respect to a PKIX concept of an RP,
we would need to augment OCSP to convey the certificate hash from
the CA issue log in an OCSP "good" SingleResponseExtension in order
to enable updated PKIX-RPs to check certificate issuance.

>
> So they will never send a request for a certificate that was not issued.

You seem to know very little about what RPs in the installed base are doing.

What I know from discussions on IETF Mailing lists, there are RPs, which

 - given an untrusted leaf cert with an incomplete path,
   will silently perform forward AIA-caIssuers chasing during
   certificate path validation

 - will attempt to parallelile AIA-based OCSP lookups with
   certificate path validation

And I'm pretty sure there is more dangerous behaviour out there in
the installed base that I wouldn't think of in my wildest dreams.

> the certificates whose status cannot be determined.

"Implements 5280 correctly"?

While I can see "must reject the certificate" in a few places in
the certificate path validation algorithm in Section 6.1 of rfc5280,
I am still searching for where in Section 6.3 of rfc5280 it says
"an RP MUST reject the certificate when the revocation check returns
with the cert_status UNDETERMINED".

Btw. I'm also still searching for a requirement in rfc5280 that
says "a compliant RP MUST perform certificate revocation checking".

I was under the impression that both, whether to perform revocation
checking at all, and what to do when the check returns cert_status
UNDETERMINED is subject to local policy of the RP, and that soft-failing
on OCSP lookup failures is actually the norm common RPs such as
Web-Browsers, rather than the exception.

> [Piyush] It could but it would be incorrect.

Huh??

Could you please enlighten me which part of rfc2560 you believe
would prohibit this?

>
> And none of the OCSP responder

While I do not have any experience with OCSP responders myself,
the Microsoft Online Responder Web proxy described here:

  http://technet.microsoft.com/en-us/library/cc731001.aspx

appears to do just that. It is to be configured as local OCSP responder,
will forward the RPs request to the real responder (local or public,
I assume, depending on the request), and cache the response.

While this particular implementation from Microsoft is conceptionally
split into two components, the OCSP proxy itself does not need to (re-)sign
the OCSP responses.  But rfc2560 Section 4.2.2.2 (1) clearly makes it
a valid implementation option that the OCSP proxy could re-sign instead
of forwarding the OCSP response, e.g. to achive a coherent maximum
caching of forwarded OCSP responses by local RPs, configurable centrally
on the OCSP proxy.

> 
> You are talking about proxy responder re-signing response from
> another responder without establishing trust.

Huh??

   public CA responder (identified through AIA)
        ^
        |
        v
   trusted local/organizational OCSP responder
        ^
        |
        v
   local RP
 
What do you mean by "without establishing trust",
-- that does not exist in this picture, the basic
usage scenario that involves a local OCSP responder.

Besides "official" OCSP responders, there are _existing_
protocol extensions for OCSP request proxying.

-Martin

---

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

> That statment is a proven logical fallacy. (colloquial "nonsense").
Proven how?

> We all know that were some 200 certs created by hackers that would verify
> under the public DigiNotar CA which were never issued.

There is a difference between fraudulently issued and non-issued. 
This is what 5280 says about such a scenario
"On a larger scale, compromise of a CA's private signing   key may have a
catastrophic effect.  If an attacker obtains the   private key unnoticed,
the attacker may issue bogus certificates and   CRLs.  Existence of bogus
certificates and CRLs will undermine   confidence in the system.  If such a
compromise is detected, all   certificates issued to the compromised CA MUST
be revoked, preventing   services between its users and users of other CAs."
 
> And there was a CA certificate created by some researchers as a proof-of-
> concept which also was never issued, but the signature on that cert would
> verify under a public CA:
> 
It is addressed by adopting strong hash algorithms.

But at least you have presented two cases where you think it is useful. So
how does the 2560 update help address these issues? 
The fallacy in your approach is that one hand you are unwilling to put your
trust in the signature created by a CA and on the other hand you are willing
to put your trust in a responder that is signed by the same CA.

> and ours) checks certificate issuance, for the simple reason that none of
the
> existing protocols actually supports conveying proof-of-issuance."

[Piyush] Once again, issuance is checked by verifying the signature on the
certificate. If you disagree then let us know how you would verify that the
cert that signed the response was "issued" by the CA

>    certificate path validation

[Piyush] And you have a proposal which would make these RPs secure?

> And I'm pretty sure there is more dangerous behaviour out there in the
> installed base that I wouldn't think of in my wildest dreams.
> 
[Piyush] Sure. So you have a magic bullet to make these RPs secure?

> While I can see "must reject the certificate" in a few places in the
certificate
> path validation algorithm in Section 6.1 of rfc5280, I am still searching
for
> where in Section 6.3 of rfc5280 it says "an RP MUST reject the certificate
> when the revocation check returns with the cert_status UNDETERMINED".
> 
> Btw. I'm also still searching for a requirement in rfc5280 that says "a
compliant
> RP MUST perform certificate revocation checking".
> 
[Piyush]
 5280 section 6.1:
This text describes an algorithm for X.509 path processing.  A conforming
implementation MUST include an X.509 path processing  procedure that is
functionally equivalent to the external behavior of  this algorithm."
5280 section 6.1.3
The basic path processing actions to be performed for certificate i   (for
all i in [1..n]) are listed below.
      (a)  Verify the basic certificate information.  The certificate MUST
satisfy each of the following:
         (1)  ....
         (2)  ...
         (3)  At the current time, the certificate is not revoked.  This may
be determined by obtaining the appropriate CRL (Section 6.3), by status
information, or by out-of-band mechanisms.
I think it is easy to deduce from above that if you cannot determine that
certificate is "not revoked" you should reject the certificate.

> UNDETERMINED is subject to local policy of the RP, and that soft-failing
on
> OCSP lookup failures is actually the norm common RPs such as Web-
> Browsers, rather than the exception.
> 
[Piyush] Unfortunately, that's a myopic view. Browser's soft fail because
they don't want to offend the user and unsuspecting users just hit continue
on warning displayed on their browser window because they do not understand
the warning.  Browser vendors can afford to do so because of complete lack
of accountability.
PKI has presence outside the CAB community. In enterprise deployments,
depending on the application, such behavior would be completely
unacceptable.

> Could you please enlighten me which part of rfc2560 you believe would
> prohibit this?
> 
[Piyush] Common sense I would guess. If the proxy is re-signing the response
it should ensure that it can trust the response first. Otherwise I can route
you AIA to my rogue responder and have your proxy responder attest my rogue
response.
> While I do not have any experience with OCSP responders myself, the
> Microsoft Online Responder Web proxy described here:
> 
will
> forward the RPs request to the real responder (local or public, I assume,
> depending on the request), and cache the response.
> 
split
> into two components, the OCSP proxy itself does not need to (re-)sign the
> OCSP responses.  
[Piyush] Sane behavior. Microsoft got this right :)

But rfc2560 Section 4.2.2.2 (1) clearly makes it a valid
> implementation option that the OCSP proxy could re-sign instead of
> forwarding the OCSP response, e.g. to achive a coherent maximum caching
> of forwarded OCSP responses by local RPs, configurable centrally on the
> OCSP proxy.
>
[Piyush] Sure it could sign. After making sure that the response is signed
by a responder that is authorized to provide response for the payload
certificate.
 
> > responder without establishing trust.
> 
> Huh??
> 
[Piyush] Identified through AIA is fine but it does not obviate the need to
ensure that it is authorized to provide response for the certificate in
question

> -- that does not exist in this picture, the basic usage scenario that
involves a
> local OCSP responder.
[Piyush] Simple local ocsp responder needs to make sure that public CA
responder is authorized to issue response for the payload certificate.
The fact that it was reached through the AIA does not make it trustworthy.

-Piyush

---

From: [email-masked] (Martin Rex)
Date: Fri, 11 Jan 2013 07:36:20 +0100 (CET)

I don't really see any convergence of this discussion,
and I'm lacking time and endurance to continue.

Piyush Jain wrote:
> > certificate path validation algorithm in Section 6.1 of rfc5280,
> > Btw. I'm also still searching for a requirement in rfc5280 that says
> > "a compliant RP MUST perform certificate revocation checking".
>
> [Piyush]
>  5280 section 6.1:

You seem to have missed the important parts in the text you quoted.

All that "the certificate is not revoked" means, is that your RP does
not have positive proof of the revocation.

The "This may be determined ... or by out-of-band mechanisms.",
means, that an RP, who does neither support CRLs nor OCSP (or has them
disabled), and only an implementation-defined "out-of-band mechanism",
that consists of "Revocation by manual out-of-band means on the granularity
of trust anchors" will actually be _compliant_ with RFC5280.

While this might not be what *YOU* want, but it definitely is what
rfc5280 explicitly permits.

> by a responder that is authorized to provide response for the payload

This is bordering on silliness.

Honestly, why wouldn't it?

Who would be so stupid to write **TWO** seperate OCSP clients,
one that implements rfc2560 correctly (including section 4.2.2.2 1/2/3)
and a goofed one that lacks section 4.2.2.2 1/2/3, and then use the
goofed one in the proxy, rather than using the same rfc2560-client
everywhere?

An other than CRLs, where it is undefined (explicitly declared
out-of-scope by rfc5280) how to obtain the CRL signer cert if the
CRL is not signed with the same CA key than the cert under investigation,
OCSP has a standardized carry-on for the OCSP signer cert (chain),
in case that the OCSP response is not signed by the cert signer key
itself.

-Martin

---

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

> Unsigned UNAUTHORIZED or MALFORMED_REQUST is quick and effective.

Are you aware of rfc-2560 Section 2.7?

   2.7 CA Key Compromise

   If an OCSP responder knows that a particular CA's private key has
   been compromised, it MAY return the revoked state for all
   certificates issued by that CA.

As you can see, even rfc2560 has been suggesting all the time,
that when the OCSP responder is aware of a CA key compromise,
it MAY return a revoked response as a safety precaution for cert
serials that are suspect to (or even positively known to)
not be validly issued certs.

This MAY implies "at the discretion of the responder", and includes
selectively returning "revoked", e.g. if it wasn't a complete CA
compromise, but only a fraudulent cert creation for which CA issue
records may have been destroyed -- so the existence of fraudulent
certs could be invisible to any audits.  Du to the lack of issue
records, it is also not possible to revoke such certs in the X.509
sense, since it is unknown how many there are, what serials they
carry, and whether they share the serials of "innocent" certs that
exist on the CA cert issue record.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Thu, 10 Jan 2013 23:04:27 -0800

>Who would be so stupid to write **TWO** seperate OCSP clients, one that
implements rfc2560 correctly (including section 4.2.2.2 1/2/3) and a goofed
one that lacks section 4.2.2.2 1/2/3, and then use the goofed >one in the
proxy, rather than using the same rfc2560-client everywhere?
[Piyush] Glad we are on same page now.

This what you quoted before:
" You're not looking at the complete picture.
If you set up a local OCSP responder, it will be perfectly OK for such a
responder not only to source from CRLs, but alternatively to essentially
forward/proxy the OCSP request, and either cache and forward the response
cache and recreate an OCSP response with the local signature. In the latter
case, when the original OCSP client only sent the issuer&serial in the OCSP
request, the local OCSP responder is a perfectly correct an honest client,
still it might be forwarding a request for a certificate serial without
having seen (let alone verified) the certificate carrying that serial."

Which seemed to indicate that local OCSP responder re-signs the response
without having all the information (since it does not have access to the
cert) to verify the response from the public CA responder.
You came up with the scenario to refute my assertion that genuine OCSP
clients need to verify signature (issuance) before sending an OCSP response.

> I don't really see any convergence of this discussion, and I'm lacking
time and
> endurance to continue.
[Piyush] I agree - too much flip flop. I'll let others chime in.

---

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

> cert) to verify the response from the public CA responder.

The cert for which the status is requested would actually be pretty useless
for verifying the signature on the OCSP response.  It will require
the _CA_cert_ that signed the cert for which the status is requested
in order to verify the OCSP response.

While both, proxying and re-signing OCSP responses aren't possible
in a "fully dynamic" fashion, both should be possible for explicitly
configured issuers, where the proxy already knows the URL to the CA's
OCSP responder and has the necessary CA cert, and therefore can recognize
the issuerNameHash and issuerKeyHash in the CertID of the OCSP request,
as well as verify the OCSP response.

Under these conditions, the actual cert for whose serial the
status is requested, seems entirely unnecessary.  Are any common
OCSP clients actually including the cert for which they're requesting
the status?  My Firefox doesn't seem to send it (says wireshark),
although I don't have a local OCSP responder to see whether this
makes a difference.

For reference, the relevant OCSP request contents from rfc2560:

   Request         ::=     SEQUENCE {
       reqCert                     CertID,
       singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
       serialNumber        CertificateSerialNumber }

-Martin

---

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

>[Piyush] It is as likely as I growing wings and start flying in future.

It feels like you are not reading the posts here.

As said numerous times before, If the CA is using sequential serial number
assignments, I can make it 100% sure that this WILL happen.

If I just got a cert with serial number 1000 from that CA, and immediately
sends an OCSP request for cert 1001, then I would get a revoked response
if the proposed update was implemented.

Next time that CA issues a cert, it will have serial number 1001.

Random serial number assignment with high entropy avoids this, but that is
not mandated.

/Stefan

---

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

>verifying the signature. So they will never send a request for a

No, the OCSP responder has no way to know this.

Attackers can do this at will at any time if they find any reason to do
so. The client may even have a bug, using a flawed mechanism to extract
the serial number form cert after signature validation, causing it to ask
status for the wrong cert serial number.

Yes, that is hypothetical and our task is not to fix that, but the point
is, there might be any reason unknown to the OCSP responder that could
cause an OCSP request for a non-existing cert serial number.

We are simply dealing with this on a protocol level, allowing the OCSP
responder to respond to such request in a reasonable way, without even
wandering about the reason that caused the client to do such request.

/Stefan

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 11 Jan 2013 13:55:48 +0100

To the list

The purpose of this email is to provide replacement text and its 
rational related to the topic currently
called "non-issued certificates".

First of all, speaking of non-issued certificate is misleading. The certificate may also have been issued

by the CA, but irregularly because the RA was attacked and thus the certificate was indeed issued by the CA.

So either the certificate has not been issued or has been irregularly issued (either by the CA or someone else).

Secondly, RFC 5280 states:

CRL issuers are strongly encouraged to include meaningful reason codes 
in CRL entries.

The re-use of onhold reason code is not meaningful, because it does not correspond to the meaning of onhold

as it is used today. Some applications dealing with electronic signatures are already applying a specific treatment

on that reason code. Depending of the content of the signature policy, these applications may "wait and

come back later" to see if there is a change in the revocation status. That change will never happen

if the certificate has not been regularly issued.

It would be more appropriate to use a specific reason code that will only appear in OCSP Responses, and never in CRLs.

The authors of RFC 5280 were very wise, because that have reserved bit 7 for a purpose that is not supported in CRLs.

:-)

The current definition of CRLReason within RFC 5280 is:

CRLReason ::= ENUMERATED {

unspecified(0),

keyCompromise(1),

cACompromise(2),

affiliationChanged(3),

superseded(4),

cessationOfOperation(5),

certificateHold(6),

-- value 7 is not used

removeFromCRL(8),

privilegeWithdrawn(9),

aACompromise(10) }

Rather than importing CRLReason from RFC 5280, we can define RevocationReason locally, consistent with CRLReason with one more bit

which will be specific to OCSP. Anyway, we need to redefine the ASN.1 module, since the syntax of nonce had been omitted and must be added.

This changes the meaning of the revoked reason in the following way:

temporary revocation will apply for two reason code rather than one:

certificateHold(6),

notIssuedOrIrregularlyIssued(7),

Note that the proposed new "extended revoked definition response extension" is not necessary anymore.

Why do not make things simpler, when they can be simpler ?  :-)

This leads to the following replacement:

OLD:

    (either permanently or temporarily (on hold)). This state MAY also be

    returned if the responder knows that the requested certificate has

    never been issued during the history of the associated CA using any

    current or previous issuing key.

NEW:

    The "revoked" state indicates that the certificate has been revoked,

    either permanently or temporarily (i.e. certificateHold or

    notIssuedOrIrregularlyIssued).   In particular, this state MAY be

    returned if the responder knows that currently the serial number

    from the requested certificate has not been used by the CA to issue

    a certificate or has been used irregularly to issue a certificate.

NOTE: The "revoked" state is used rather than the "unknown" state, to

       make sure that relying parties that were conformant to RFC 2560

       will not use CRLs as a fall back mechanism.

The Note above will allow people that do not have followed the discussion on the PKIX mailing list

to understand why we have chosen "revoked" rather than "unknown", which would have been more natural.

This leads to another change, since the following sentence is not English, it uses the word "never"

which is inappropriate and omits to take into consideration certificates that have been irregularly issued:

OLD:

       o Section 2.2 extends the use of the "revoked" response to allow

          this response status certificates that has never been issued.

NEW:

       o Section 2.2 extends the use of the "revoked" response to also

         allow  this response status either for certificates that have

         notbeen issued or that have been irregularly issued.

The above arguments lead to other changes. The text copied below, does not follow the order of the ASN.1 syntax

and should be aligned with the above proposed text.

OLD:

       certificates,

NEW:

    When a responder responds revoked to a status request for a serial

    number which has not been used by the CA or used irregularly to issue

    a certificate, the responder MUST also:

     - specify the revocation date January 1, 1970,

     - provide the RevocationReason : notIssuedOrIrregularlyIssued (7).

and also:

OLD:

       o Section 4.4.8 specifies a new extension that indicates that the

          responder supports the extended use of the "revoked" response

          for non-issued certificates defined in section 2.2.

NEW:

This section should be deleted.

Denis

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 11 Jan 2013 15:00:19 +0100

2013/1/11 Denis Pinkas <[email-masked]>

>
> The re-use of onhold reason code is not meaningful, because it does not correspond to the meaning of onhold ****
>
> as it is used today. Some applications dealing with electronic signatures are already applying a specific treatment ****
>
> on that reason code. Depending of the content of the signature policy, these applications may “wait and ****
>
> come back later” to see if there is a change in the revocation status. That change will never happen ****
>
> if the certificate has not been regularly issued.********
>
> ** ******
>
> It would be more appropriate to use a specific reason code that will only appear in OCSP Responses, and never in CRLs.********
>
> ** ******
>
If you're talking about bit instead of enumerated value, then you're
talking about the "ReasonFlags" definition that is used in
cRLDistributionPoints extension instead of the "CRLReason" definition used
to indicate the revocation reason. And this "ReasonFlags" bit string
already uses bit 7 ;)

-- 
Erwann.

---

From: "Peter Rybar" <[email-masked]>
Date: Fri, 11 Jan 2013 15:38:41 +0100

Stefan,
As you can see in my previous mail, when OCSP request contains incorrect (malformed) serial number, because the certificate does not exist, the OCSP Responder may return an error message malformedRequest or all other types of responses except for revoked!!!
According to rfc2560bis is situation worse because the status revoked which was about the real certificate status (in CRL or in previous OCSP RFC) is now with extension of revoked with reason code certificateHold defined as equivocal result when is not correctly implemented. 
It means according to rfc2560bis all serial numbers are initially revoked with reason code certificateHold… Is it useful?
(The revoked with reason code certificateHold is based on CA database and in some next steps database can also include the hash values of certificates for positive statement!)
 
For that reason some systems and legislations where non-repudiation services are required (e.g. QES) dictate that status value good or revoked in OCSP response MUST contain a positive statement a hash value of certificate in singleExtensions.
 
When hash of the certificate as a positive statement MUST be used, the situations with OCSP responses for RP are clear and unique because:
1) good or revoked is only about know and issued certificates,
2) any other situations are moved into one group which is unclear and not analyzed – no evidence, no responsibility.
 
It is a radical simplification!
 
Instead of trying to solve presently not practical and theoretical situations from the responsibility/liability point of view (like preparing us for situations: what we will offer for intergalactic green man, are vegetarian? ;) we can define steps which can be implemented by CAs and OCSP systems like usage of positive statement cert hash.
 
E.g. define new or reuse already defined in private OID space.
PositiveStatement ::= SEQUENCE {
   hashAlgorithm    AlgorithmIdentifier,
   certHash         OCTET STRING, -- Hash of Subjects certificate
}
 
And according it we cam move.
 
Peter Rybar

  _____  

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Thursday, January 10, 2013 2:19 PM
To: Peter Rybar; 'Piyush Jain'; 'pkix'
Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

The requested cert serial number may actually be used in a future representing a real certificate.

So this is intentional and the whole purpose behind using the on hold reason.

/Stefan

From: Peter Rybar <[email-masked]>
Date: Thursday, January 10, 2013 12:13 PM
To: 'Piyush Jain' <[email-masked]>, Stefan Santesson <[email-masked]>, 'pkix' <[email-masked]>
Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

Stefan,

 

and 

 

 

 

-----Original Message-----
From: Piyush Jain [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2013 6:17 PM
To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix'
Subject: RE: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

of the following

extend the protocol

trusted).

for a

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

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 11 Jan 2013 15:59:34 +0100

Erwann,

Yes indeed, it is not a bit, since CRLReason ::= ENUMERATED

Case 7 is unused.

Denis

>
> 2013/1/11 Denis Pinkas <[email-masked] 
> <mailto:[email-masked]>>
>
>
>     on that reason code. Depending of the content of the signature policy, these applications may “wait and
>
>     come back later” to see if there is a change in the revocation status. That change will never happen
>
> cRLDistributionPoints extension instead of the "CRLReason" definition 
> used to indicate the revocation reason. And this "ReasonFlags" bit 
> string already uses bit 7 ;)
>
> -- 
> Erwann.

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 11 Jan 2013 16:04:35 +0100

From:  Peter Rybar <[email-masked]>
Date:  Friday, January 11, 2013 3:38 PM
To:  Stefan Santesson <[email-masked]>, 'Piyush Jain'
<[email-masked]>, 'pkix' <[email-masked]>
Subject:  Re: [pkix] Question about extended Revoked Extension defined in
section 4.4.8 of ocsp draft 8

> Stefan,
> As you can see in my previous mail, when OCSP request contains incorrect
> (malformed) serial number, because the certificate does not exist, the OCSP
> Responder may return an error message malformedRequest or all other types of
> responses except for revoked!!!

How does a serial number become malformed just because it doesn't exists.
Its just an integer.
Its syntactically a well formed integer.

> According to rfc2560bis is situation worse because the status revoked which
> was about the real certificate status (in CRL or in previous OCSP RFC) is now
> with extension of revoked with reason code certificateHold defined as
> equivocal result when is not correctly implemented.
> It means according to rfc2560bis all serial numbers are initially revoked with
> reason code certificateHoldŠ Is it useful?

Yes.

> (The revoked with reason code certificateHold is based on CA database and in
> some next steps database can also include the hash values of certificates for
> positive statement!)
>  
> For that reason some systems and legislations where non-repudiation services
> are required (e.g. QES) dictate that status value good or revoked in OCSP
> response MUST contain a positive statement a hash value of certificate in
> singleExtensions.
>  

Then that can be achieved by defining a new single response extension that
does not interfere with what is being done in 2560bis.

> When hash of the certificate as a positive statement MUST be used, the
> situations with OCSP responses for RP are clear and unique because:

Great, so how then do you respond to a request for a serial number that has
never been issued?

> 2) any other situations are moved into one group which is unclear and not
> analyzed  no evidence, no responsibility.

But the responder still need to respond.

> It is a radical simplification!

Of what?

>  
> Instead of trying to solve presently not practical and theoretical situations
> from the responsibility/liability point of view (like preparing us for
> situations: what we will offer for intergalactic green man, are vegetarian? ;)
> we can define steps which can be implemented by CAs and OCSP systems like
> usage of positive statement cert hash.
>  

Asking for status of a never issued serial number is not impossible. It is
not even hard.
A good protocol should provide a reasonable response to every possible
request.

> And according it we cam move.

I have nothing against such extension being defined.
But it still does not remove the need for the current discussed mechanism.

The current discussed mechanism address how to respond to legacy clients to
requests for non-issued serial numbers.
Your extension does not help, because it is not understood by legacy
clients.

So its not either or.

/Stefan

>> It define that now is possible to revoke what does not exist and it open
>> never ending cycle of trying to fixing or correcting the first incorrect
>> status that "fake" cert serial number is revoked but cert serial number is
>> not revoked because "fake" cert does not exist.
>>  
>> which case the reason shall be one of the standard reasons for revocation,
>> the revocation date shall be the date the certificate was placed on hold, and
>> the optional instruction code extension field shall not appear; or,

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 11 Jan 2013 16:32:03 +0100

The purpose is to signal that the serial number is CURRENTLY regarded as
revoked, but this may change in the future, i.e. a legitimate certificate
may be issued with this serial number.
Thus the certificateHold is a good match.

/Stefan

From:  Denis Pinkas <[email-masked]>
Date:  Friday, January 11, 2013 3:59 PM
To:  Erwann Abalea <[email-masked]>
Cc:  <[email-masked]>
Subject:  Re: [pkix] About extended Revoked Extension defined in section
4.4.8 of ocsp draft 8

>>> as it is used today. Some applications dealing with electronic signatures
>>> are already applying a specific treatment
>>>  
>>> on that reason code. Depending of the content of the signature policy, these
>>> applications may ³wait and
>>>  
>>> come back later² to see if there is a change in the revocation status. That
>>> change will never happen
>>>  
>>> It would be more appropriate to use a specific reason code that will only
>>> appear in OCSP Responses, and never in CRLs.
>>>  
>>>  
>>>  
>> If you're talking about bit instead of enumerated value, then you're talking
>> about the "ReasonFlags" definition that is used in cRLDistributionPoints
>> extension instead of the "CRLReason" definition used to indicate the
>> revocation reason. And this "ReasonFlags" bit string already uses bit 7 ;)
>>  
>>  
>> 
>>  
>>  -- 
>>  Erwann. 
>  
>

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 11 Jan 2013 07:55:44 -0800

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Denis Pinkas
Sent: Friday, January 11, 2013 4:56 AM
To: [email-masked]
Subject: [pkix] About extended Revoked Extension defined in section 4.4.8 of
ocsp draft 8

To the list

The purpose of this email is to provide replacement text and its rational
related to the topic currently 
called "non-issued certificates".

First of all, speaking of non-issued certificate is misleading. The
certificate may also have been issued 
by the CA, but irregularly because the RA was attacked and thus the
certificate was indeed issued by the CA. 
So either the certificate has not been issued or has been irregularly issued
(either by the CA or someone else).
 
[Piyush] +1. 
I think it is important to distinguish between these two situations
conceptually even though a compromised CA may have no means to do so.
Secondly, RFC 5280 states:

   CRL issuers are strongly encouraged to include meaningful reason codes in
CRL entries.

The re-use of onhold reason code is not meaningful, because it does not
correspond to the meaning of onhold 
as it is used today. Some applications dealing with electronic signatures
are already applying a specific treatment 
on that reason code. Depending of the content of the signature policy, these
applications may "wait and 
come back later" to see if there is a change in the revocation status. That
change will never happen 
if the certificate has not been regularly issued.
 
[Piyush] +1.
The reason cited for onHold code is that the certificate with that serial
may be issued in future. However, this is not true if the certificate was
irregularly issued.

The authors of RFC 5280 were very wise, because that have reserved bit 7 for
a purpose that is not supported in CRLs. 
 
:-)
 
[Piyush] J Lucky us. I hope in future we do not encounter a bunch of
incorrectly implemented RPs who want the responder to return revoked for
some other reason.

        unspecified             (0),

        keyCompromise           (1),

        cACompromise            (2),

        affiliationChanged      (3),

        superseded              (4),

        cessationOfOperation    (5),

        certificateHold         (6),

             -- value 7 is not used

        removeFromCRL           (8),

        privilegeWithdrawn      (9),

        aACompromise           (10) }

Rather than importing CRLReason from RFC 5280, we can define
RevocationReason locally, consistent with CRLReason with one more bit 
which will be specific to OCSP. Anyway, we need to redefine the ASN.1
module, since the syntax of nonce had been omitted and must be added.

        certificateHold               (6),

        notIssuedOrIrregularlyIssued  (7),

Note that the proposed new "extended revoked definition response extension"
is not necessary anymore.

OLD:

NEW:

   The "revoked" state indicates that the certificate has been revoked,
   either permanently or temporarily (i.e. certificateHold or 
   notIssuedOrIrregularlyIssued).  In particular, this state MAY be 
   returned if the responder knows that currently the serial number 
   from the requested certificate has not been used by the CA to issue 
   a certificate or has been used irregularly to issue a certificate.
 [Piyush] +1 again. 
I think it is important to capture the fact that this response may imply
that CA may have been compromised. Use of "non-issued" hides that
implication.

[Piyush] The note is a good idea. Do you think it makes sense to clarify why
CRLs cannot be used in such cases? Folks not privy to the discussions on
this list may get confused because 5280 implies that CRLs and OCSP are
interchangeable.

The Note above will allow people that do not have followed the discussion on
the PKIX mailing list 
to understand why we have chosen "revoked" rather than "unknown", which
would have been more natural.
 
This leads to another change, since the following sentence is not English,
it uses the word "never"
which is inappropriate and omits to take into consideration certificates
that have been irregularly issued:

OLD: 

NEW:
 
      o Section 2.2 extends the use of the "revoked" response to also 
        allow this response status either for certificates that have 
        not been issued or that have been irregularly issued.
 
[Piyush] +1 . Distinction between not-issued and irregularly issued is
important to have any meaningful discussion.
The above arguments lead to other changes. The text copied below, does not
follow the order of the ASN.1 syntax 
and should be aligned with the above proposed text.

OLD:

 

NEW:

 
 
and also:

OLD:

NEW:

+1

Denis

---

From: [email-masked] (Martin Rex)
Date: Fri, 11 Jan 2013 17:20:01 +0100 (CET)

Denis,

It's fascinating to see the whole scope of conceivable positions
in this discussion.

Piyush argues that the situation this change/update addresses is
so rare that it is not worth bothering, and in particular that no
reasonable RP would ever be sending OCSP requests for "non-issued"
certs anyway.

You seem to argue that there is an installed base which has covertly
made the bold move to abuse the certificateHold ReasonCode in a fashion
that it is *not* guaranteed to be used, and seem to lack back-off
and reasonable recursion limits on the one hand, and that those
OCSP clients could be coerced into making requests for non-issued
certs that you have serious concerns about creating operational
problem with the proposed update using certificateHold ReasonCode.

I'm not in favour of breaking an installed base lightheartedly,
although it sounds to me that like a somewhat unreasonable abuse
if it really is so brittle that it makes you worry that much.

When creatatively going beyond the official scope of a spec,
one MUST ensure that the behaviour remains _safe_and_robust_
so that there can not occur any disastrous interference if
someone else "bends" an interpretation into the opposite
direction.  Looping on certificateHold status to the level of
operational risk status to me looks dangerously unsafe and
significantly overstepping the boundaries of robustness for
creatively re-interpreting protocol features.

How real is the problem you outlined?  Is there an official
specification what exactly should be done (including limits
that have to be observed) for certificateHold by the OCSP
clients you have in mind?

Should the suggestion to use/assign a new ReasonCode be adopted,
then it would be important to describe it as being a TEMPORARY status,
much like certificateHold and unlike all the other ReasonCodes.
(I didn't see anything to that effect in your proposed text).

Further, I stronlgy dislike the term "irregularly issued".
This status is about certificate serials(!!) that are not found
on the CA cert issue record.  There is exactly ZERO point in trying
to speculate why this is the case.  It could have been something
as beningn as a desaster recovery after some physical damage
(fire, storm, flooding, earthquake), which resulted in
recovery from backup and loss of records of issuance on that day.
It could have been the result of a non-yet public progress on hash
collisions.  It could have been a simple software bug.

For me, the a certificate earns the status "issued" only when it
is created following the issuance procedures, gets recorded on
the CAs cert issue log, becomes visible to auditing and can
therefore be revoked upon request (not just through OCSP,
but also through CRLs), and the CA can produce a proof-of-issuance
on request.

Calling a certificate "issued", for which there is no issue record
visible to audits, no proof-of-issuance can be created and no
revocation can be posted on a CRL, is a logical fallacy based on
a design flaw in X.509.

A humans existence is not proof of his birth.  While most, if not all
currently living humans might have been "born" (given birth by
a human mother), alternative means are already technically
conceivable, if not feasible today.  I'm afraid they might become
"commercially available" within my remaining lifetime (which to me
is a pretty uncomfortable thought).

-Martin

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 11 Jan 2013 17:24:31 +0100

Stefan,

We both agree that the serial number is CURRENTLY regarded as revoked, 
but this may change in the future,
i.e. a legitimate certificate may be issued with this serial number".

However, the use of certificateHold  is not a good match, as it is 
explained below.
The use of the extended Revoked Extension defined in section 4.4.8 is an 
overcomplication that is not necessary in my proposal.

You have provided no argument about the proposal for using case 7 in the 
enumeration of CRL revocation reasons.

Denis

> The purpose is to signal that the serial number is CURRENTLY regarded 
> as revoked, but this may change in the future, i.e. a legitimate 
> certificate may be issued with this serial number.
> From: Denis Pinkas <[email-masked] <mailto:[email-masked]>>
> To: Erwann Abalea <[email-masked] <mailto:[email-masked]>>
> Cc: <[email-masked] <mailto:[email-masked]>>
> Subject: Re: [pkix] About extended Revoked Extension defined in 
>>     If you're talking about bit instead of enumerated value, then
>>     you're talking about the "ReasonFlags" definition that is used in
>>     cRLDistributionPoints extension instead of the "CRLReason"
>>     definition used to indicate the revocation reason. And this
>>     "ReasonFlags" bit string already uses bit 7 ;)
>>
>>     -- 
>>     Erwann. 
>
>     [email-masked] <mailto:[email-masked]>

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 11 Jan 2013 17:49:44 +0100

Two things,

1) The purpose of this exercise is to provide a solution that works with
legacy clients. That is, the output provided by the responder have to work
and provide the desired effect when sent to a client using a current
implementation of OCSP.
2) The extension was evidently required after discussions at the last IETF
meeting to reach WG rough consensus on this mechanism. The reason being
mainly to support audit when going back and examining what happened, it must
be evident that the responder operated using this extended definition of
revoked.

Therefore, the on hold bit is the only one that is known to represent a
temporary revocation in current clients.
And therefore the extension is needed.

The rationale you give for not using certificateHold, is provide no
problems.
I see no obligation to help your client understand that this serial number
will never be released from certificateHold.
Because your client must always consider that as a possibility when seeing
certificateHold, so it should not fail badly in any case.

/Stefan

From:  Denis Pinkas <[email-masked]>
Date:  Friday, January 11, 2013 5:24 PM
To:  Stefan Santesson <[email-masked]>
Cc:  <[email-masked]>
Subject:  Re: [pkix] About extended Revoked Extension defined in section
4.4.8 of ocsp draft 8

>     
>  
> Stefan,
>  
>  We both agree that the serial number is CURRENTLY regarded as revoked, but
> this may change in the future,
>  However, the use of certificateHold  is not a good match, as it is explained
> below.
>> revoked, but this may change in the future, i.e. a legitimate certificate may
>> be issued with this serial number.
>>  
>>>>> on that reason code. Depending of the content of the signature policy,
>>>>> these applications may ³wait and
>>>>>  
>>>>> come back later² to see if there is a change in the revocation status.
>>>>> That change will never happen
>>>>>  
>>>>> The authors of RFC 5280 were very wise, because that have reserved bit 7
>>>>> for a purpose that is not supported in CRLs.
>>>>>  
>>>>>  
>>>>  
>>>>  
>>>>  
>>>>

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 11 Jan 2013 09:49:04 -0800

> Piyush argues that the situation this change/update addresses is so rare
that it is not worth bothering, and in particular that no reasonable RP
would ever be sending OCSP requests for "non-issued" certs anyway.

[Piyush] I would love for someone to clear my misconception. And I think it
is because my interpretation of "non-issued" is that the certificate does
not exist and your definition includes both certificates that exist and
certificates that do not exist.
And yes, compliant RPs gain no knowledge by sending requests for
certificates that do not exist to CA responders because they have no means
to verify such a response in absence of payload certificate.

> This status is about certificate serials(!!) that are not found on the CA
cert
> issue record.  There is exactly ZERO point in trying to speculate why this
is the
> case.  It could have been something as beningn as a desaster recovery
after
> some physical damage (fire, storm, flooding, earthquake), which resulted
in
> It could have been the result of a non-yet public progress on hash
collisions.
> It could have been a simple software bug.
 
[Piyush] Do you think it is important for relying party to know what the
reason was?  A distinction between revoked because of RA/CA  compromise and
revoked because of Disaster recovery is pretty important, at least from
relying party's perspective. It does not matter if you call it
irregularlyIssued or notYetIssued or certificateOnHold as long as the
relying party clearly understands that such a response may imply that RA/CA
was compromised.  In case of former, depending on its risk tolerance, an RP
might decide to consider all certificates issued by the CA as revoked, at
least temporarily. 
BTW, the only practical use case that prompted this update was to provide
CAB community to deal with DigiNotor like scenarios.

---

From: "Piyush Jain" <[email-masked]>
Date: Mon, 14 Jan 2013 08:19:57 -0800

> for verifying the signature on the OCSP response.  It will require the
> _CA_cert_ that signed the cert for which the status is requested in order
to
> verify the OCSP response.
[Piyush] True. It is not required for verifying signature on the resppnse.
But it is required to ensure that the responder is authorized to sign
responses for the certificate for which status is requested.
> 
> While both, proxying and re-signing OCSP responses aren't possible in a
"fully
> dynamic" fashion, both should be possible for explicitly configured
issuers,
> where the proxy already knows the URL to the CA's OCSP responder and has
> the necessary CA cert, and therefore can recognize the issuerNameHash and
> issuerKeyHash in the CertID of the OCSP request, as well as verify the
OCSP
> response.
[Piyush]  "Verifying" in this context means more that signature checking.
Yes, the proxy can establish that the signature on the response is correct,
but it cannot establish that the response is applicable to the cert in
question.
> 
> Under these conditions, the actual cert for whose serial the status is
> requested, seems entirely unnecessary.  Are any common OCSP clients
> actually including the cert for which they're requesting the status?  My
> Firefox doesn't seem to send it (says wireshark), although I don't have a
local
> OCSP responder to see whether this makes a difference.
> 
[Piyush] You are correct. Clients do not send the certificates. But they
establish trust in the responder by ensuring that the responder certificate
is issued by the same entity as the one who issued the payload certificate.
The more interesting fact is that directly trusted responders do not re-sign
the response that they proxy to the CA responder. They only sign the
response that they create locally.

What's important is to understand the subtle difference between trusting
that the response is signed by a particular entity, and that such a response
is applicable to the cert being verified.
The proxy should re-sign the response only if it knows that the response is
applicable to the cert that its client is trying to validate, otherwise is
should pass on the response without re-signing.

BTW,  Many folks fail to understand this subtle difference. But it becomes
clear if just think of proxy as an OCSP client. Which model in section
4.2.2.2 can it use to establish trust in the CA responder? You'll see that
the answer is none. So in such case, it ''ll be irresponsible for it to
re-sign the response using it own key.

-Piyush

---

From: [email-masked] (Martin Rex)
Date: Mon, 14 Jan 2013 23:17:34 +0100 (CET)

Piyush Jain wrote:
>
> > The cert for which the status is requested would actually be pretty
> > useless for verifying the signature on the OCSP response.
> > It will require the_CA_cert_ that signed the cert for which the
> > status is requested in order to verify the OCSP response.
>

Plain wrong conclusion.  You failed to account for "public CA OCSP responder
needs to be preconfigured on local OCSP responder".  The local responder
doesn't need and doesn't care about the certificate for which the
status is requested.  Verification of the OCSP response is possible
with the admin-preconfigured information -- and both, proxying and
re-signing OCSP responses is impossible without the preconfigured info.

> > "fully dynamic" fashion, both should be possible for explicitly
> > configured issuers, where the proxy already knows the URL to the
> > CA's OCSP responder and has the necessary CA cert, and therefore
> > can recognize the issuerNameHash and issuerKeyHash in the CertID
> > of the OCSP request, as well as verify the OCSP response.
>

With respect to the OCSP protocol (rfc2560), it clearly does not!

> but it cannot establish that the response is applicable to the cert in

An perfectly valid and reasonable rfc2560 will not and need not care.

Which does not preclude that you build an implementation that does
it anyway, but that is not a prerequsite from a spec, and your
proxy would probably return errors to all common OCSP clients because
of their lack to include the certificate in their request to the
local responder.  Arguably, your implementation of an rfc2560 local
OCSP responder could be described as not being a correct implementation
of rfc2560.

> > local OCSP responder to see whether this makes a difference.
>

Funny.  Now you're agreeing that an OCSP proxy doesn't need to care, and
that it is the expected duty of (only) the RP doing the revocation check
to ensure that the OCSP response properly matches the certificate under
investigation.

> response that they create locally.

But a local OCSP responder could perfectly well proxy OCSP requests and
re-sign responses rather than just operating exclusively on CRLs.

> is applicable to the cert being verified.

That subtle difference is only relevant to the RP.  It is irrelevant
to a local OCSP responder who decides to proxy OCSP requests and
re-sign the responses rather than feeding exclusively only on CRLs.

> should pass on the response without re-signing.

This is definitely no something suggested or implied by the OCSP protocol
specified in rfc2560.  It might be something that you may want from your
own implementation, but it is extremely important for discussions about
standardization that you realize the difference here.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Mon, 14 Jan 2013 16:06:40 -0800

> doesn't need and doesn't care about the certificate for which the status
is
> requested.  Verification of the OCSP response is possible with the admin-
> preconfigured information -- and both, proxying and re-signing OCSP
> responses is impossible without the preconfigured info.

[Piyush] Fair enough. What you are saying that client directly trusts the
local responder and local responder trusts the CA responders based on local
configuration. 
I agree that certificate is not required to accept a response if you trust
the responder directly.

However, This whole discussion was about CA delegated responder/CA responder
and whether the payload certificate is required to verify a response from
such responders.
You provide an example in which you use direct trust model in both the
client and the proxy. And on the basis of that you claim that payload
certificate is not required to establish trust in a response issued by CA/CA
delegated responders.

---

From: "Piyush Jain" <[email-masked]>
Date: Mon, 14 Jan 2013 16:38:42 -0800

> Sent: Thursday, January 10, 2013 11:01 PM
> To: Piyush Jain
[Piyush] Yup.  A responder product that I worked on long time ago has
support for it since last 10 years.

> As you can see, even rfc2560 has been suggesting all the time, that when
the
> OCSP responder is aware of a CA key compromise, it MAY return a revoked
> response as a safety precaution for cert serials that are suspect to (or
even
> positively known to) not be validly issued certs.
> 
compromise,
> but only a fraudulent cert creation for which CA issue records may have
been
> destroyed -- so the existence of fraudulent certs could be invisible to
any
> audits.  Du to the lack of issue records, it is also not possible to
revoke such
> certs in the X.509 sense, since it is unknown how many there are, what
> serials they carry, and whether they share the serials of "innocent" certs
that
> exist on the CA cert issue record.

 [Piyush] Not sure if I agree that "MAY return the revoked state for all
certificates issued by that CA" implies "MAY return the revoked state for
some certificates issued by that CA" but I'll bite.
 So what's the need for the update? 2560 already allows what you want to do.
Return revoked with CA compromised as the reason code for such certificate.

-Piyush

---

From: [email-masked] (Martin Rex)
Date: Tue, 15 Jan 2013 02:18:02 +0100 (CET)

> Return revoked with CA compromised as the reason code for such certificate.

I'm perfectly OK for an OCSP responder to return the reason code
cACompromise(2) for those cert serials which do appear on a current CRL with
that very ReasonCode or are scheduled to appear with that very ReasonCode
on the next base CRL.

But for certs where the CA can not make any assessment about its status,
and where in particular, it is possible that a valid cert with that serial
might still get created in the future, the OCSP responder ought to abstain
from asserting any ReasonCode with the semantics of a permanent/final
revocation and probably also abstain from currently unknown reason codes,
if the desire of this update is to make it comprehensible to the installed
base of rfc2560.

CertificateHold asserts that the status for this cert serial is
currently undecided.   the certificatHold status _might_ simply disappear
at some indeterminate point the future, or _might_ be replaced with a
permanent/final revocation.  Since neither X.509 nor PKIX specify
any time limit specified for how long a certificateHold status may last,
RPs MUST assume that it may last essentially forever
(=beyond the lifetime of the CA cert).

If CAs or RPs would want to establish special semantics for batched
processing of signed request and queuing&re-processing of requests
for which the OCSP-based revocation check returned the status
certificateHold, then these CAs and RPs ought to use OCSP extensions
to convey either a GeneralizedTime at which point in the future
retrying the OCSP status request should be attempted (=polling),
or whether and at which time the OCSP responder (or CA) will have
determined a final/permant status for this cert serial.

Trying to infer anything beyond "do not trust this cert NOW" from a
plain certificateHold status would be silly, and can be characterized
as an implementation bug.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Tue, 15 Jan 2013 02:51:33 +0100 (CET)

Piyush Jain wrote:
>
> > Plain wrong conclusion.  You failed to account for "public CA OCSP
> > responder needs to be preconfigured on local OCSP responder".
> > The local responder doesn't need and doesn't care about the
> > certificate for which the status is requested.  Verification
> > of the OCSP response is possible with the admin-preconfigured
> > information -- and both, proxying and re-signing OCSP

The concept of a local OCSP responder is undoubtedly based on the notion
that the local OCSP responder puts a local signature on an assertion
(=OCSP response) about certificate serial status which itself has determined
based on revocation status information from a pre-configured issuing CA.

Whether an OCSP responder obtains the revocation status information
from a pre-configured issuing CA by CRLs, delta-CRLs, OCSP or direct
access to the CA cert database is irrelevant for the OCSP protocol
between this OCSP responder and an RP that trusts this OCSP responder
(independent of whether that trust is due to rfc2560 4.2.2.2 (1), (2) or (3)).

> certificate is not required to establish trust in a response issued by CA/CA
 
This really isn't about some specific example.  This applies to the whole
concept of local OCSP responders and applies _each_and_every_time_
when an OCSP client determines rfc2560 section 4.2.2.2 (1) to apply.

   4.2.2.2 Authorized Responders

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question

A local OCSP responder that itself obtained the certificate serial
status in form of a CRL or delta CRL is effectively re-signing that
certificate serial status information when creating an OCSP response
from CRLs.  Probably most, if not all existing OCSP responders,
i.e. including regular OCSP responders (direct and designated),
are operating in such a fashion that they obtain cert serial status in
some local trusted fashion, and then create from that trusted information
an OCSP response and (re-)sign this response with their OCSP responder key.

-Martin

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 15 Jan 2013 10:17:04 +0100

Stefan,

You said: "The purpose of this exercise is to provide a solution that 
works with legacy clients". True, but not only.

As proposed, new clients have no way to know that the OCSP responder is 
using the database of issued certificates from the CA.
A non-critical extension to an individual response should be added to 
advertise it.

You said: "the on hold bit is the only one that is known to represent a 
temporary revocation in current clients".

This is not what RFC 5280 says, nor what X.509 states. I have made a 
search in X.509:

*Text from X.509 using "temporarily" or "on hold"*

*8.5 Basic CRL extensions*

*8.5.1 Requirements*

The following requirements relate to CRLs:

a) Certificate users need to be able to track all CRLs issued from a CRL 
issuer or CRL distribution point (see 8.6)
and be able to detect a missing CRL in the sequence. CRL sequence 
numbers are therefore required.

b) Some CRL users may wish to respond differently to a revocation, 
depending upon the reason for the revocation.
There is therefore a requirement for a CRL entry to indicate the reason 
for revocation.

c) There is a requirement for an authority to be able to temporarily 
suspend validity of a certificate and subsequently
either revoke or reinstate it. Possible reasons for such an action include:

-- desire to reduce liability for erroneous revocation when a revocation 
request is unauthenticated and there is inadequate
information to determine whether it is valid;

-- other business needs, such as temporarily disabling the certificate 
of an entity pending an audit or Investigation.

*8.5.2.2 Reason code extension*

A certificate may be placed on hold by issuing a CRL entry with a reason 
code of *certificateHold*. The certificate hold notice
may include an optional hold instruction code to convey additional 
information to certificate users (see 8.5.2.3).

a) it may remain on the CRL with no further action, causing users to 
reject transactions issued during the hold period; or,

b) it may be replaced by a (final) revocation for the same certificate, 
in which case the reason shall be one of the standard reasons
for revocation, the revocation date shall be the date the certificate 
was placed on hold, and the optional instruction code extension
field shall not appear; or,

c) it may be explicitly released and the entry removed from the CRL**

*9 Delta CRL relationship to base*

(...)

A certificate's revocation notice, with revocation reason 
*certificateHold, *may appear on either a dCRL or a CRL that is complete
for a given scope. This reason code is intended to indicate a temporary 
revocation of the certificate pending a further decision on
whether to permanently revoke the certificate or reinstate it as one 
that is not revoked.

You will also notice that all this appies to CRLs, since neither X.509, 
nor RFC 5280 say how to handle revocation in the context of OCSP.

There is not even a path processing procedure, which is a fundamental 
defect of RFC 2560.

RFC 2560 states:

(either permanantly or temporarily (on hold)).

It does not say "(i.e. on hold)", nor "(e.g. on hold)". Notice also that 
the sentence "(either permanantly or temporarily)" is in parenthesis.

Anyway, we may clarify this and this was my original change proposal, 
which I copy again below
(see may email from 11/01/2013 13:55):

OLD:

NEW:

Using certificateHold creates problems as already mentioned (see may 
email from 11/01/2013 13:55),
whereas using case 7 in the enumeration does not.

Note that there is yet another reason of not importing CRLReason from 
RFC 5280:
removeFromCRL cannot be used in OCSP responses.

*CRLReason ::= ENUMERATED {***

*unspecified(0),***

*keyCompromise(1),***

*cACompromise(2),***

*affiliationChanged(3),***

*superseded(4),***

*cessationOfOperation(5),***

*certificateHold(6),***

*-- value 7 is not used***

*removeFromCRL(8),***

*privilegeWithdrawn(9),***

*aACompromise(10) }***

**

Denis

> Two things,
>
> 1) The purpose of this exercise is to provide a solution that works 
> with legacy clients. That is, the output provided by the responder 
> have to work and provide the desired effect when sent to a client 
> using a current implementation of OCSP.
> 2) The extension was evidently required after discussions at the last 
> IETF meeting to reach WG rough consensus on this mechanism. The reason 
> being mainly to support audit when going back and examining what 
> happened, it must be evident that the responder operated using this 
> extended definition of revoked.
>
> Therefore, the on hold bit is the only one that is known to represent 
> a temporary revocation in current clients.
> I see no obligation to help your client understand that this serial 
> number will never be released from certificateHold.
> Because your client must always consider that as a possibility when 
> seeing certificateHold, so it should not fail badly in any case.
>
> /Stefan
>
>
> To: Stefan Santesson <[email-masked] <mailto:[email-masked]>>
>     We both agree that the serial number is CURRENTLY regarded as
>     revoked, but this may change in the future,
>     The use of the extended Revoked Extension defined in section 4.4.8
>     is an overcomplication that is not necessary in my proposal.
>
>     You have provided no argument about the proposal for using case 7
>     in the enumeration of CRL revocation reasons.
>
>     Denis
>
>
>>     The purpose is to signal that the serial number is CURRENTLY
>>     regarded as revoked, but this may change in the future, i.e. a
>>     legitimate certificate may be issued with this serial number.
>>>         If you're talking about bit instead of enumerated value,
>>>         then you're talking about the "ReasonFlags" definition that
>>>         is used in cRLDistributionPoints extension instead of the
>>>         "CRLReason" definition used to indicate the revocation
>>>         reason. And this "ReasonFlags" bit string already uses bit 7 ;)
>>>
>>>         -- 
>>>         Erwann. 
>>
>>         _______________________________________________ pkix mailing
>>         list [email-masked] <mailto:[email-masked]>

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 15 Jan 2013 10:37:43 +0100

Denis,

The term irregularly is totally ambiguous.

The CA either has, or has not issued a certificate with the serial number in
question.
That is all the responder need to know.

If it has been issued and still is bad, then it should be revoked. In this
case the protocol works as usual.

Hence, I can't support your proposal.

Also, old clients have no need to know what is going on, They will just see
"revoked" and act accordingly, which is intended.
In case of an audit, the extension is there and thus, parties can conclude
what happened.
That is the reason for the extension.

/Stefan

From:  Denis Pinkas <[email-masked]>
Date:  Tuesday, January 15, 2013 10:17 AM
To:  Stefan Santesson <[email-masked]>
Cc:  <[email-masked]>
Subject:  Re: [pkix] About extended Revoked Extension defined in section
4.4.8 of ocsp draft 8

>     
>  
> Stefan,
>  
>  You said: "The purpose of this exercise is to provide a solution that works
> with legacy clients". True, but not only.
>  
>  As proposed, new clients have no way to know that the OCSP responder is using
> the database of issued certificates from the CA.
>  This is not what RFC 5280 says, nor what X.509 states. I have made a search
> in X.509:
>  
>  
> 
> Text from X.509 using ³temporarily² or ³on hold²
>  
> 8.5 Basic CRL extensions
>  
> 8.5.1 Requirements
>  
>  and be able to detect a missing CRL in the sequence. CRL sequence numbers are
> therefore required.
>  
> b) Some CRL users may wish to respond differently to a revocation, depending
> upon the reason for the revocation.
>  There is therefore a requirement for a CRL entry to indicate the reason for
> revocation.
>  
> c) There is a requirement for an authority to be able to temporarily suspend
> validity of a certificate and subsequently
>  desire to reduce liability for erroneous revocation when a revocation
>  other business needs, such as temporarily disabling the certificate of an
> entity pending an audit or Investigation.
>  
>  
>  
> 8.5.2.2 Reason code extension
>  
> of certificateHold. The certificate hold notice
> which case the reason shall be one of the standard reasons
>  for revocation, the revocation date shall be the date the certificate was
> placed on hold, and the optional instruction code extension
> c) it may be explicitly released and the entry removed from the CRL
>  
>  
>  
> 9 Delta CRL relationship to base
>  
> (Š)
>  
> A certificate's revocation notice, with revocation reason certificateHold, may
> appear on either a dCRL or a CRL that is complete
>  whether to permanently revoke the certificate or reinstate it as one that is
> not revoked.
>  
> 
>  You will also notice that all this appies to CRLs, since neither X.509, nor
> RFC 5280 say how to handle revocation in the context of OCSP.
>  
>  There is not even a path processing procedure, which is a fundamental defect
> of RFC 2560.
>  
>  RFC 2560 states:
>  
>  
>    
>        It does not say "(i.e. on hold)", nor "(e.g. on hold)". Notice also
> that the sentence "(either permanantly or temporarily)" is in parenthesis.
>  
>  Anyway, we may clarify this and this was my original change proposal, which I
> copy again below 
> NOTE: The "revoked" state is used rather than the ³unknown² state, to
>  Using certificateHold creates problems as already mentioned (see may email
> from 11/01/2013 13:55),
>  Note that there is yet another reason of not importing CRLReason from RFC
> 5280: 
>> The rationale you give for not using certificateHold, is provide no problems.
>>  
>>>>>>> as it is used today. Some applications dealing with electronic
>>>>>>> signatures are already applying a specific treatment
>>>>>>>  
>>>>>>> It would be more appropriate to use a specific reason code that will
>>>>>>> only appear in OCSP Responses, and never in CRLs.
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>> used to indicate the revocation reason. And this "ReasonFlags" bit string
>>>>>> already uses bit 7 ;)
>>>>>>  
>>>>>>  
>>>>>> 
>>>>>>  
>>>>>>  -- 
>>>>>>  Erwann. 
>>>>>  
>>>>>  
>>>>>

---

From: [email-masked] (Martin Rex)
Date: Tue, 15 Jan 2013 11:46:26 +0100 (CET)

> the sentence "(either permanantly or temporarily)" is in parenthesis.

The stuff in the parenthesis is a further explanation to the stuff just
preceding the parenthesis.

Based on this explanation in rfc2560, a revocation will come in one
of two forms: (1) permanent revocation and (2) temporary revocation.
Temporary revocation is further explained to consist of the
certificateHold status.  As you note yourself, it does *NOT* say
"e.g. on hold", so it can *not* be expected from OCSP clients to
recognize any other ReasonCode besides "certificateHold" as a temporary
revocation status.

> This is not what RFC 5280 says, nor what X.509 states. I have made a 

What needs to be done is looking at the semantics defined for the
certificateHold ReasonCode, the only revocation reason code that
could be expected to be properly recognized as a temporary status
indication by an rfc2560 client.

> The following requirements relate to CRLs:

Requirements for CRLs are mostly irrelevant for OCSP, since
OCSP is not a CRL.  What is relevant is the semantics of the
ReasonCode(s), which can be conveyed through OCSP, and which
_may_ originate from a real CRL.  Howver, there is *NO* requirement
that this ReasonCode originates from a real CRL.  Anyhow, the only thing
that can be reasonably expected to be understood by an OCSP client
is the X.509 semantics defined for the certificateHold ReasonCode,
since that is the only definition that existed when the installed
base was created.

> reject transactions issued during the hold period; or,

Up to here is all what we need from X.509 ReasonCode semantics.
We have our OCSP responder convey certificateHold with no further action,
causing OCSP clients to reject transactions issued during the hold period.

This is exactly the semantics we want to re-use for OCSP to convey
the "not issued" status in a fashion that has a high likelyhood to
be understood as a temporary revocation.

> nor RFC 5280 say how to handle revocation in the context of OCSP.

This statement is somewhat silly.  By making the ReasonCode extension
an optional element of an OCSP singleResponse, the part of the semantics
of the ReasonCodes that isn't wedlocked to CRLs, but has a generic meaning
with respect to the revocation cause and revocation status has become
part of the (optional) OCSP semantics.  removeFromCRL is a ReasonCode
with a semantics that is clearly wedlocked to CRLs, and an OCSP responder
that would an OCSP response with the revoked(ReasonCode=removeFromCRL)
must be considered defective.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 15 Jan 2013 05:29:08 -0800

Stefan,

notIssuedOrIrregularlyIssued is less ambiguous than non-issued, given that
this draft is deviating from the normally accepted definition of issued i.e.
signed.

The fact that responder cannot differentiate between certs not signed by the
CA and those signed by a compromised CA does not make the distinction any
less important for the client. In latter case, a security conscious client
should not accept any certificate issued by the CA until the extent of CA
compromised is determined.

Moreover you have not provided a single example where a genuine client
benefits from sending a request for non-existent certificate. In absence of
such examples, you can only interpret that from client's point of view
irregularly issued certificates are going to be more prevalent than
non-existent certificates. Therefore using the term non-issued would be
misleading to clients who do encounter a situation where they receive a
revoked response for such class of certificate serial numbers.

For audit purpose, the extension and notIssuedOrIrregularlyIssued are
semantically equivalent.

Auditors can look for either the presence of this new extension or the
presence of reason code 'notIssuedOrIrregularlyIssued.

-Piyush

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Santesson
Sent: Tuesday, January 15, 2013 1:38 AM
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: [pkix] About extended Revoked Extension defined in section
4.4.8 of ocsp draft 8

Denis,

/Stefan

Stefan,

Text from X.509 using "temporarily" or "on hold"

8.5 Basic CRL extensions

8.5.1 Requirements

a) Certificate users need to be able to track all CRLs issued from a CRL
issuer or CRL distribution point (see 8.6) 
and be able to detect a missing CRL in the sequence. CRL sequence numbers
are therefore required.

- desire to reduce liability for erroneous revocation when a revocation
request is unauthenticated and there is inadequate 
information to determine whether it is valid;

- other business needs, such as temporarily disabling the certificate of an
entity pending an audit or Investigation.

A certificate may be placed on hold by issuing a CRL entry with a reason
code of certificateHold. The certificate hold notice 
may include an optional hold instruction code to convey additional
information to certificate users (see 8.5.2.3).

(.)

A certificate's revocation notice, with revocation reason certificateHold,
may appear on either a dCRL or a CRL that is complete 
for a given scope. This reason code is intended to indicate a temporary
revocation of the certificate pending a further decision on 
whether to permanently revoke the certificate or reinstate it as one that is
not revoked.

RFC 2560 states:

It does not say "(i.e. on hold)", nor "(e.g. on hold)". Notice also that the
sentence "(either permanantly or temporarily)" is in parenthesis.

Anyway, we may clarify this and this was my original change proposal, which
I copy again below 
(see may email from 11/01/2013 13:55):

OLD:

NEW:

        unspecified             (0),

        keyCompromise           (1),

        cACompromise            (2),

        affiliationChanged      (3),

        superseded              (4),

        certificateHold         (6),

             -- value 7 is not used

        removeFromCRL           (8),

        privilegeWithdrawn      (9),

        aACompromise           (10) }

Denis

Two things,

/Stefan

Stefan,

Denis

/Stefan

Erwann,

Case 7 is unused.

Denis

 

-- 
Erwann.

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 15 Jan 2013 14:58:05 +0100

Piyush,

We both agree.

However, what is important first is to use the enumeration case 7 rather 
than the enumeration case 6 : "CertificateHold".

Then, we can argument about the name of the enumeration case 7.

However, the proposed term is well chosen:

- "notIssued" may correspond to the case where the certificate serial 
number that was sent was erroneous
    and has never been used by the CA at the time of the query,

- "irregularlyIssued" may correspond to the case where the certificate 
serial number that was sent really exists
    in a certificate that is correctly signed but the CA has not issued 
(to its knowledge) a certificate with such a serial number.
    However, it may indeed have been issued by the CA itself because the 
RA was compromised. This is why "irregularly issued"
    makes sense.

The OCSP responder cannot distinguish between notIssued and 
IrregularlyIssued.

Stefan, the single argument you raised is not a valid argument to refuse 
the whole text replacement proposal.

In addition, new clients need to know what is going on. Your proposal 
does not allow for it.

Stefan, it is time to move on now, since there will be other topics to 
be debated.

Denis

> Stefan,
>
> notIssuedOrIrregularlyIssued is less ambiguous than non-issued, given 
> that this draft is deviating from the normally accepted definition of 
> issued i.e. signed.
>
> The fact that responder cannot differentiate between certs not signed 
> by the CA and those signed by a compromised CA does not make the 
> distinction any less important for the client. In latter case, a 
> security conscious client should not accept any certificate issued by 
> the CA until the extent of CA compromised is determined.
>
> benefits from sending a request for non-existent certificate. In 
> absence of such examples, you can only interpret that from client's 
> point of view irregularly issued certificates are going to be more 
> prevalent than non-existent certificates. Therefore using the term 
> non-issued would be misleading to clients who do encounter a situation 
> where they receive a revoked response for such class of certificate 
> serial numbers.
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Stefan Santesson
> *Sent:* Tuesday, January 15, 2013 1:38 AM
> *To:* Denis Pinkas
> *Cc:* [email-masked]
> *Subject:* Re: [pkix] About extended Revoked Extension defined in 
> The CA either has, or has not issued a certificate with the serial 
> number in question.
>
> If it has been issued and still is bad, then it should be revoked. In 
> this case the protocol works as usual.
>
> Also, old clients have no need to know what is going on, They will 
> just see "revoked" and act accordingly, which is intended.
>
> In case of an audit, the extension is there and thus, parties can 
> conclude what happened.
>
> *From: *Denis Pinkas <[email-masked] 
> *Date: *Tuesday, January 15, 2013 10:17 AM
> *To: *Stefan Santesson <[email-masked] <mailto:[email-masked]>>
> *Cc: *<[email-masked] <mailto:[email-masked]>>
> *Subject: *Re: [pkix] About extended Revoked Extension defined in 
>     You said: "The purpose of this exercise is to provide a solution
>     that works with legacy clients". True, but not only.
>
>     As proposed, new clients have no way to know that the OCSP
>     responder is using the database of issued certificates from the CA.
>     A non-critical extension to an individual response should be added
>     to advertise it.
>
>     You said: "the on hold bit is the only one that is known to
>     represent a temporary revocation in current clients".
>
>     This is not what RFC 5280 says, nor what X.509 states. I have made
>     a search in X.509:
>
>     a) Certificate users need to be able to track all CRLs issued from
>     a CRL issuer or CRL distribution point (see 8.6)
>     There is therefore a requirement for a CRL entry to indicate the
>     reason for revocation.
>
>     c) There is a requirement for an authority to be able to
>     temporarily suspend validity of a certificate and subsequently
>     -- desire to reduce liability for erroneous revocation when a
>     revocation request is unauthenticated and there is inadequate
>     -- other business needs, such as temporarily disabling the
>     certificate of an entity pending an audit or Investigation.
>
>     A certificate may be placed on hold by issuing a CRL entry with a
>     reason code of *certificateHold*. The certificate hold notice
>     a) it may remain on the CRL with no further action, causing users
>     to reject transactions issued during the hold period; or,
>
>     b) it may be replaced by a (final) revocation for the same
>     certificate, in which case the reason shall be one of the standard
>     reasons
>     for revocation, the revocation date shall be the date the
>     certificate was placed on hold, and the optional instruction code
>     extension
>     for a given scope. This reason code is intended to indicate a
>     temporary revocation of the certificate pending a further decision on
>     whether to permanently revoke the certificate or reinstate it as
>     one that is not revoked.
>
>
>     You will also notice that all this appies to CRLs, since neither
>     X.509, nor RFC 5280 say how to handle revocation in the context of
>     OCSP.
>
>     There is not even a path processing procedure, which is a
>     fundamental defect of RFC 2560.
>
>     RFC 2560 states:
>
>
>
>     It does not say "(i.e. on hold)", nor "(e.g. on hold)". Notice
>     also that the sentence "(either permanantly or temporarily)" is in
>     parenthesis.
>
>     Anyway, we may clarify this and this was my original change
>     proposal, which I copy again below
>     Using certificateHold creates problems as already mentioned (see
>     may email from 11/01/2013 13:55),
>     Note that there is yet another reason of not importing CRLReason
>     from RFC 5280:
>     *CRLReason ::= ENUMERATED {*
>
>     *        unspecified (0),*
>
>     *        keyCompromise (1),*
>
>     *        cACompromise (2),*
>
>     *        affiliationChanged (3),*
>
>     *        superseded (4),*
>
>     *        cessationOfOperation (5),*
>
>     *        certificateHold (6),*
>
>     *             -- value 7 is not used*
>
>     *        removeFromCRL (8),*
>
>     *        privilegeWithdrawn (9),*
>
>     *        aACompromise           (10) }*
>
>     **
>
>
>     Denis
>
>         Two things,
>
>         1) The purpose of this exercise is to provide a solution that
>         works with legacy clients. That is, the output provided by the
>         responder have to work and provide the desired effect when
>         sent to a client using a current implementation of OCSP.
>
>         2) The extension was evidently required after discussions at
>         the last IETF meeting to reach WG rough consensus on this
>         mechanism. The reason being mainly to support audit when going
>         back and examining what happened, it must be evident that the
>         responder operated using this extended definition of revoked.
>
>         Therefore, the on hold bit is the only one that is known to
>         represent a temporary revocation in current clients.
>
>         I see no obligation to help your client understand that this
>         serial number will never be released from certificateHold.
>
>         Because your client must always consider that as a possibility
>         when seeing certificateHold, so it should not fail badly in
>         any case.
>
>         /Stefan
>
>         *From: *Denis Pinkas <[email-masked]
>         *Date: *Friday, January 11, 2013 5:24 PM
>         *To: *Stefan Santesson <[email-masked]
>         <mailto:[email-masked]>>
>         *Cc: *<[email-masked] <mailto:[email-masked]>>
>         *Subject: *Re: [pkix] About extended Revoked Extension defined
>         in section 4.4.8 of ocsp draft 8
>
>             Stefan,
>
>             We both agree that the serial number is CURRENTLY regarded
>             as revoked, but this may change in the future,
>             However, the use of certificateHold  is not a good match,
>             as it is explained below.
>             The use of the extended Revoked Extension defined in
>             section 4.4.8 is an overcomplication that is not necessary
>             in my proposal.
>
>             You have provided no argument about the proposal for using
>             case 7 in the enumeration of CRL revocation reasons.
>
>             Denis
>
>                 The purpose is to signal that the serial number is
>                 CURRENTLY regarded as revoked, but this may change in
>                 the future, i.e. a legitimate certificate may be
>                 issued with this serial number.
>
>                 *From: *Denis Pinkas <[email-masked]
>                 *Date: *Friday, January 11, 2013 3:59 PM
>                 *To: *Erwann Abalea <[email-masked]
>                 <mailto:[email-masked]>>
>                 *Cc: *<[email-masked] <mailto:[email-masked]>>
>                 *Subject: *Re: [pkix] About extended Revoked Extension
>                 defined in section 4.4.8 of ocsp draft 8
>
>                     Erwann,
>
>                         If you're talking about bit instead of
>                         enumerated value, then you're talking about
>                         the "ReasonFlags" definition that is used in
>                         cRLDistributionPoints extension instead of the
>                         "CRLReason" definition used to indicate the
>                     pkix mailing list [email-masked]
>                     <mailto:[email-masked]>
>             _______________________________________________ pkix
>             mailing list [email-masked] <mailto:[email-masked]>

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 18 Jan 2013 06:28:39 +0100

On some of the latest proposals where new reason codes etc are proposed.

I will not administer introduction of new reason codes or alike features to
the OCSP protocol without a major part of the implementing community showing
up on this list and approving it.
You may have noticed that there has been a whole lot of messages sent to
this list on this subject by a few people.

So as an example, having the same person saying things loudly many times,
does not count as WG consensus. In particular not when we are dealing with a
widely deployed protocol.

The direction of the current draft is the result of a WG consensus process
where many people on this list voiced their opinion.
If you want a material, change of that direction, you need to attract
support from enough people on this list to demonstrate wide support of the
direction change.
Unless that happens, I will not incorporate it in the draft.

Scott Rea just sent me test results from real implementation of the current
draft. This shows that implementers care about this even if they don't
engage in this discussion.
When we are dealing with a magnitude of platforms and clients, any change to
the protocol is a potential disaster, so we need to be very careful.

I do encourage as may implementers as possible to do tests and publish your
findings, before we ship this.

/Stefan