Subject: Re: [Gen-art] [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

From: [email-masked] (Martin Rex)
Date: Wed, 3 Apr 2013 10:37:22 +0200 (CEST)

Piyush Jain wrote:
> 
> The sole reason cited for overloading the meaning of revoked status with
> non-issued was that it allows new servers to interoperate with legacy
> clients.

There is *NO* overloading of a revoked status.  The change is making use
of an existing temporary revocation status (certificateHold) **EXACTLY**
with the original semantics for a temporary revocation,
originating from X.509 08/2005 8.5.2.2 (a):

   A certificate may be placed on hold 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 hold with no further action, causing users to reject
      transactions issued during the hold period; or,

>
>     The WG agreed that there are many better alternatives but they all
> break compatibility with older clients.

If you want to describe "an OCSP responder no longer responding 'good'
for certificate serial numbers for which no records of issuance exist"
as "breaking compatibility with older clients", then yes, this is what
we want to do.

But in reality, this is change is about fixing a security problem that
was documented as such in rfc2560 for the "good" status.

>
> In fact, a more secure and complete
> proposal by Denis was not adopted because of the same reason.

I don't understand this statement, but there can not possibly be a more
secure solution that reporting revoked for not-issued certs.

> 
> I believe that Stefan is trying to convey that requiring servers to return
> revoked in this context will make them non-compliant with 2560 and 5019 as
> opposed to breaking interoperability with legacy clients.

The proposed change primarily intends to _standardize_ how to report
revoked/certificateHold for "not-issued" certificate serial numbers,
something that has been found useful (and already been used) in dealing
with certain kinds of security breaches of CAs/RAs.

Returning revoked/certificateHold for not-issued certs is perfectly
compliant with rfc2560 and rfc5019.  Returning "unknown" is also
perfectly compliant with rfc2560 and rfc5019.  Returning an error code
response status would be just dumb for an authoritative OCSP responder.

Should rfc5019 be interpreted to suggest for authoritative OCSP responders
to returning an error code for "not-issued" certs does not make such
behaviour any less dumb.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 3 Apr 2013 07:27:20 -0700

> There is *NO* overloading of a revoked status.  The change is making use
of
> an existing temporary revocation status (certificateHold) **EXACTLY** with
> the original semantics for a temporary revocation, originating from X.509
> 08/2005 8.5.2.2 (a):
> 
[Piyush] Revokes status is being used to communicate non-existent
certificates. 

> as "breaking compatibility with older clients", then yes, this is what we
want
> to do.

[Piyush] That is not what I implied.  There were alternatives proposed to
address fraudulently-issued certificates in OCSP (none of them solved the
problem completely BTW). 
The reason cited by you along with a few others was that any other proposal
would require clients to be updated. This is what breaking backward
compatibility means.
> 
> But in reality, this is change is about fixing a security problem that was
> documented as such in rfc2560 for the "good" status.
> 
[Piyush] What security problem? I don't see any security problem documented
in RFC 2560 bis and repeated refusal to discuss how 2560bis solves any
security problems. The only vague goal stated is - "it allows responders to
return revoked for non-issued so clients do not fall back to CRL"
I also see a creative way to circumvent responder trust issue by saying that
servers indicate "non-issued" by setting the revocation date to 1970 but
clients should not interpret the response as non-issued.
> 
> > 
> >
> > I believe that Stefan is trying to convey that requiring servers to
> > return revoked in this context will make them non-compliant with 2560
> > and 5019 as opposed to breaking interoperability with legacy clients.

[Piyush] This part I agree with as I stated in my original post. Backward
compatibility is wrong choice of words. Compliance with other standards is
the right choice.
Standards are not backward compatible. Implementations of standards are.
> with certain kinds of security breaches of CAs/RAs.
[Piyush] May be so. But that is not the goal cited for this update. Yes a
few CA vendors may have adopted it but that no way indicates consensus among
CA vendors.
If you refer to CAB forum thread, most reputable CA vendors are reluctant to
adopt it.
> 
> Returning an error code response status would be
> just dumb for an authoritative OCSP responder.
> 
[Piyush] Really. And why is that. It actually makes a lot of sense and that
is why CAs "who are not compromised" continue to return an error code for
such responses.
The only requirement for them is to be confident of the certificates they
have issued. The only reason a CA would return a revoked for non-issued is
that it is not sure if certificates are fraudulently issued using its key.

> to returning an error code for "not-issued" certs does not make such
[Piyush] The behavior that you are calling dumb has enabled the CAs to scale
their OCSP infrastructure.
What is dumb IMO is to continue to run the CA after being compromised and
demanding that standards be updated to support such behavior.

---

From: [email-masked] (Martin Rex)
Date: Wed, 3 Apr 2013 18:05:32 +0200 (CEST)

I have strong doubts that regurgitating the entire previous
discussion is going to help.

> address fraudulently-issued certificates in OCSP (none of them solved the

OCSP is *NOT* about certificates and therefore the use of the term
"fraudulently-issued" certificate does not make any sense.

OCSP is about certificate serial status.  Everything else is
inferences by RPs, some of them bold, some of them flawed.

> would require clients to be updated. This is what breaking backward

If you have an installed base with with a ratio of > 1000:1 for Cli:Srv,
and the choice for a protocol feature update between "having to update
all clients and server" and "having to update only servers", then
the latter has a significant deployment advantage.

> [Piyush] What security problem?

   The "good" state indicates a positive response to the status inquiry.
   At a minimum, this positive response indicates that the certificate
   is not revoked, but does not necessarily mean that the certificate
   was ever issued or that the time at which the response was produced
   is within the certificate's validity interval. 

This text is pretty explicit that "good" is potentially lame, equally lame
as infering "good" from the absence of a revocation on published CRLs.

> security problems.

rfc2560bis itself does not solve security problems.  We're in the IETF
not in the roman catholic church.

rfc2560bis describes a minimal mitigation that OCSP responder
implementations can adopt to discontinue reporting "good" for "not issued"
certs in a corherent and standardized fashion.

> clients should not interpret the response as non-issued.

That is a lame argument.

If you look at the ASN.1 in rfc2560:

   RevokedInfo ::= SEQUENCE {
       revocationTime              GeneralizedTime,
       revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

the "revocationTime" element in RevokedInfo is a mandatory element.
Since our "synthesized" certificateHold revocation status does not
originate from a CRL, we will have to define what value to convey
in revocationTime -- and choose a value that will not interfere with
any future "traditional" status information in case a certificate
with that serial gets issued.

Defining a simple fixed value for this field that can not possibly
cause any such confusion is an obvious, simple and straightforward
engineering solution.

> Standards are not backward compatible. Implementations of standards are.

The issue of backwards compatibility also applies to changes of a standard.
If you either newly require different behaviour or prohibit previously
allowed or previously required behaviour, then a standards change is
backwards-incompabible.

Some Qualified Electronic Signature (QES) consumers (including legislation)
require OCSP responders to include a certificateHash as proof-of-issuance
in an OCSP response and require OCSP clients to verify that the
certificateHash is present in a "good" OCSP response and matches the
hash of the certificate under investigation -- as a means to work
around the shortcoming (security problems) inherent in CRLs and
rfc2560 OCSP.  However, such additional requirements are backwards
incompatible and require updating of the entire installed base,
so this approach is typically embraced only where there is not
installed base yet, or when updating the installed base is not
seen as a deterrent to adoption/deployment.

> If you refer to CAB forum thread, most reputable CA vendors are reluctant to

What is so difficult about the concept of standardizing/documenting:
"if you want to do this (e.g in case of emergency response), this is how:"

> [Piyush] Really. And why is that. It actually makes a lot of sense

No, it does not make any sense at all.  An error code is unsigned and
can be easily inserted into the communication by an attacker.  Which is
why there exists the fallback to CRL checking -- except that it is
impossible to discourage an RP from trusting a non-issued cert
through CRL checking, because the whole concept of revocation through
CRLs is fundamentally flawed and is unable to convey proof-of-issuance.

>
> and that is why CAs "who are not compromised" continue to return
> an error code for such responses.

These kinds of argument are based on two very flawed premises:

 (1) the premise that there exist only two possible states for a CA:
      (a) safe and pristine
      (b) full and thorough compromise of each and everything

 (2) that a huge PKI (100k+ entities) can be nuked and
     re-personalized after a CA compromise at close to zero cost and
     within the blink of an eye

and both premises exhibit a throrough cluelessness about security,
risk management and the real world.

> demanding that standards be updated to support such behavior.

"scale their OCSP infrastructure"?  *cough*

The TLS multiple OCSP response stapling extension is a design that scales.

On demand CRL downloading and on demand OCSP checking scales between
poorly and hardly.  AFAIK, Verisign put rfc5019 OCSP responder
behaviour into production in early 2004, but Windows XP and Windows 2003
will be end-of-lifed in 2014, never having had revocation checking
enabled by default in their entire lifetime.  And many RPs which do have
revocation checking enabled still soft-fail on OCSP lookup erros.
Non-negligible amounts of programmatic RPs (curl/wget?) probably still
have revocation checking unconfigured or disabled today.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 3 Apr 2013 10:38:20 -0700

> No, it does not make any sense at all.  An error code is unsigned and can
be
> easily inserted into the communication by an attacker. 

[Piyush] Funny that you make this argument. How does returning a signed
revoked address this? Attacker can still replace signed revoked with an
UNSIGNED TRY_LATER.

>       (b) full and thorough compromise of each and everything
[Piyush] NIST has addressed RA compromise and CA key compromise separately
so this is not true.
And you have not listed what other breaches you are trying to address
offering revoked for non-issued as the silver bullet for all those unknown
security breaches.
 You tendency to allude to vague problems to justify a particular solution,
couple with a reluctance to engage in a discussion regarding the security
implications continues to amuse me. List the other states and have a
discussion around how this solution solves those problems.> 
>      within the blink of an eye

and both premises exhibit a throrough cluelessness about security, risk
> management and the real world.
 
Let's get this right.
Only possible benefit of revoked for non-issued exists when there are CA
SIGNED certificates floating in the wild and CA has no clue that it has
issued it and therefore cannot revoke it.

Now, to say that clients are secure and CA can continue to operate if it
issues revoked OCSP response for such certificate indicates cluelessness
about security. 

Customers pay a lot of money for certificates for which the marginal cost of
issuance is almost 0. CAs obligation is to make sure that they are secure
and to address any breach securely.
To say that customers will tolerate a CA security breach just because it
issues revoked for non-issued and continues to publish CRLs that imply
fraudulent certificates as good indicates cluelessness about risk management
and real world.

---

From: Sean Turner <[email-masked]>
Date: Mon, 08 Apr 2013 16:22:36 -0400

Piyush,

(David's on the "to:" line because the text in question showed up as a 
result of the gen-art review and it's now in -16)

I've been following this thread trying to figure out what if anything 
needs to be changed to address your concerns in -17.  (Note the thread 
forked later, but I'm addressing the "times" issue in another thread.)

The sentence in questions was added to address the gen-art review is the 
following (it's in a "note" paragraph and there's actually more to it):

   The "revoked" status is still optional in this context in
   order to maintain backwards compatibility with deployments
   of RFC 2560.

1) The first bit I'd like to discuss is this part of your concern:

   And it gives the impression that best course of action
   for 2560bis responders is to start issuing revoked for
   "not-issued", which is far from the originally stated
   goal to provide a way for CAs to be able to return
   revoked for such serial numbers.

and:

   I believe that Stefan is trying to convey that requiring
   servers to return revoked in this context will make them
   non-compliant with 2560 and 5019 as opposed to breaking
   interoperability with legacy clients.

I honestly don't see how you get to your impression, because the 2119 
language about when a responder might used revoked for not-issued is:

  This state MAY also be returned if the associated
  CA has no record of ever having issued a certificate with the
  certificate serial number in the request, using any current or
  previous issuing key (referred to as a "non-issued" certificate in
  this document).

MAY being the operable word here.  That's clear to implementers because 
if you read 2119 for MAY it says:  This word, or the adjective 
"OPTIONAL", mean that an item is truly optional.  One vendor may choose 
to include the item because a particular marketplace requires it or 
because the vendor feels that it enhances the product while another 
vendor may omit the same item. ...

For me this seems clear because the 2119 language trumps any note.

Even Stefan's response to David a couple of days earlier than when you 
posted this concerns includes:

   In theory we could possibly say that responding revoked
   is optional, but if you choose between revoked and unknown
   then you SHOULD favour revoked over unknown. But such nested
   requirements just feels bad and impossible to test compliance
   against. I'd much rather just leave it optional.

I'm not sure what else could be added to alliveate your concern on this 
point.  Maybe this one got over taken by events?

2) The second bit of your concern is that this is not an accurate 
characterization of the WG's rationale for the choices made.  This 
concern is easier to evaluate and I agree that it is important to 
capture the actual rationale.  I think you've suggested that the following:

   "maintain backwards compatibility with deployments of RFC 2560"

be replaced with:

   "maintain compliance with RFC 2560 and RFC 5019"

Using the word "compliance" might set of an entirely new debate. 
Servers/clients can claim compliance if they want to but I'm not sure 
that the primary goal was for a document to claim compliance with 
another set of RFCs.  These drafts for interoperability and that would 
lead me to compatibility and not conformance.

spt

On 4/3/13 1:38 PM, Piyush Jain wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: "Piyush Jain" <[email-masked]>
Date: Mon, 8 Apr 2013 14:59:27 -0700

Sean,

Thanks for your comments.
There are two points that I would like to cover separately. The first point
is a response to your comments below. The second point is a broader
objection to revoked for issued.

1) The text says - The "revoked" status is still optional in this context in
order to maintain backwards compatibility with deployments of RFC 2560.
This implies that making "revoked" status REQUIRED will break
interoperability between newer and older implementations. This is INCORRECT.

> Servers/clients can claim compliance if they want to but I'm not sure that
the
> primary goal was for a document to claim compliance with another set of
> RFCs.  
>These drafts for interoperability and that would lead me to
> compatibility and not conformance.
That is fair. I was just pointing at the intent of the author. If you make
"revoked" status REQUIRED it does not break compatibility of newer
implementations with older implementations, however it does break
conformance of older implementations with RFC 5019 and 2560.

2) Returning revoked for non-issued adds confusion without addressing any
real problem. "Allowing CAs to return revoked for non-issued" is a goal that
is vague and meaningless, given that CAs indicate issuance by signing the
certificate in question with their private key. If you question this basic
premise of x.509 that issuance is determined by signature, you should
question the signature on signed response as well. Who is to say that the
responder certificate that was used to sign a good response was issued by
the CA?

Henry nicely articulated the whole issue with this draft in his post
(attached). I second his view on not moving this draft forward.

-Piyush
> -----Original Message-----
> From: Sean Turner [mailto:[email-masked]]
> Sent: Monday, April 08, 2013 1:23 PM
> To: Piyush Jain
> Cc: [email-masked]; [email-masked];
> [email-masked]; 'Stefan Santesson'; 'Black, David'; sts@aaa-
> sec.com; [email-masked]; [email-masked]
> Subject: Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
> 
> Piyush,
> 
result
> of the gen-art review and it's now in -16)
> 
needs to
> be changed to address your concerns in -17.  (Note the thread forked
later,
> but I'm addressing the "times" issue in another thread.)
> 
> MAY being the operable word here.  That's clear to implementers because if
> you read 2119 for MAY it says:  This word, or the adjective "OPTIONAL",
> mean that an item is truly optional.  One vendor may choose to include the
> item because a particular marketplace requires it or because the vendor
feels
> that it enhances the product while another vendor may omit the same item.
> ...
> 
point.
> Maybe this one got over taken by events?
> 
> characterization of the WG's rationale for the choices made.  This concern
is
> easier to evaluate and I agree that it is important to capture the actual
> rationale.  I think you've suggested that the following:
> 
> Servers/clients can claim compliance if they want to but I'm not sure that
the
> primary goal was for a document to claim compliance with another set of
> RFCs.  These drafts for interoperability and that would lead me to
> compatibility and not conformance.
> 
> spt
> 
> >> can
> > [Piyush] Funny that you make this argument. How does returning a
> > signed revoked address this? Attacker can still replace signed revoked
> > with an UNSIGNED TRY_LATER.
> >
> > [Piyush] NIST has addressed RA compromise and CA key compromise
> > separately so this is not true.
> > offering revoked for non-issued as the silver bullet for all those
> > unknown security breaches.
> >   You tendency to allude to vague problems to justify a particular
> > solution, couple with a reluctance to engage in a discussion regarding
> > the security implications continues to amuse me. List the other states
> > and have a discussion around how this solution solves those problems.>
> > Only possible benefit of revoked for non-issued exists when there are
> > CA SIGNED certificates floating in the wild and CA has no clue that it
> > has issued it and therefore cannot revoke it.
> >
> > Now, to say that clients are secure and CA can continue to operate if
> > it issues revoked OCSP response for such certificate indicates
> > cluelessness about security.
> >
> > Customers pay a lot of money for certificates for which the marginal
> > cost of issuance is almost 0. CAs obligation is to make sure that they
> > are secure and to address any breach securely.
> > To say that customers will tolerate a CA security breach just because
> > it issues revoked for non-issued and continues to publish CRLs that
> > imply fraudulent certificates as good indicates cluelessness about
> > risk management and real world.
> >
> >

Subject: Re: [pkix] Last Call: <draft-ietf-pkix-rfc2560bis-15.txt> (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard
From: "Henry B. Hotz" <[email-masked]>
To: "Sean Turner" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Mon, 8 Apr 2013 13:35:00 -0700

Actually, what I get from this and all the other discussions is that it's
unclear if the updated OCSP satisfies the "suitability for the intended
purpose" test.  Or at least it fails the KISS principle w.r.t. that.

Rephrasing:  an OCSP client should be able to tell from an OCSP response if:
a) the subject cert is on the CAs white list, b) the subject cert is on the
CAs black list, c) the subject cert is not on either list, or finally d) the
OCSP server is obsolete, and doesn't support making those distinctions.
It's not trivial to see how to parse 2560bis responses w.r.t. those cases,
therefore it's highly likely that computational complexity will prevent us
from doing so.  Even if that's not actually the case, then implementor
misunderstandings will prevent us from doing so in practice.

Therefore I vote against moving this draft forward.  I just don't see the
point.

If someone were to write an informational RFC which explained how to
determine which of the 4 cases an OCSP response fell into, AND if said RFC
also convinced me that the decision process was easy to understand, THEN I
would change my vote.  Obviously an appendix in 2560bis would serve just as
well.
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Sean Turner <[email-masked]>
Date: Mon, 08 Apr 2013 22:59:27 -0400

> (attached). I second his view on not moving this draft forward.

I went back and looked at the WG poll about this issue that you and lot 
of other people participated in 
(https://www.ietf.org/mail-archive/web/pkix/current/msg31906.html).  The 
WG's rough consensus was to allow "revoked" to be used for non-issued 
certificates with the caveat thrown in by Paul Hoffman that the meaning 
of "revoked" be clear about what it now means.  I've not seen anything 
that would make me want to throw this draft back to the WG to revisit 
that consensus.

spt

---

From: "Piyush Jain" <[email-masked]>
Date: Mon, 8 Apr 2013 23:02:57 -0700

> I went back and looked at the WG poll about this issue that you and lot of
> other people participated in (https://www.ietf.org/mail-
> archive/web/pkix/current/msg31906.html).  The WG's rough consensus was
> to allow "revoked" to be used for non-issued certificates with the caveat
> thrown in by Paul Hoffman that the meaning of "revoked" be clear about
> what it now means.  I've not seen anything that would make me want to
> throw this draft back to the WG to revisit that consensus.
> 

I believe that the straw poll consensus was that revoked will be overloaded
to convey non-issued status to the clients.
The deviation from that consensus is that in such cases, the current draft
prohibits clients to interpret the certificate as non-issued, and requires
them to interpret it as issued and revoked by the CA. And this is necessary
to circumvent the responder trust issue for CA delegated responders if they
return extended revoked indicating non-issuance.
Please see http://www.ietf.org/mail-archive/web/pkix/current/msg32336.html.

This is an important distinction because from client's point of view
non-issued response for a CA signed certificate is much more severe than a
revoked response and is indicative of a CA/RA compromise.
The reason I'm raising this at LC is because there were a few WG members who
acknowledged this issue and there was no consensus (other than Stefan's
response in the post linked above) on how this should be handled.

I guess it would be okay if you and David make the determination that this
issue is not worth debating anymore but I would surely have appreciated
hearing the opinions of a few others. 

Best
Piyush

---

From: "Black, David" <[email-masked]>
Date: Tue, 9 Apr 2013 09:35:24 -0400

> hearing the opinions of a few others.

I'm not sure how much of a say I have in that determination - Sean (as AD)
is absolutely free to acknowledge my input and ignore it ;-).

> Please see http://www.ietf.org/mail-archive/web/pkix/current/msg32336.html.

I do not see that prohibition in the new text in -16.  In the cited email
message, I do see a disagreement between you and Stefan about what implementations
are likely to do, but I don't see any text in the draft that dictates that
implementations must or must not make that interpretation.

Speaking for myself, I would have no problem w/client code that inferred that
any "revoked" response with revocation reason certificateHold (6) and
revocationTime January 1, 1970 most likely indicates a non-issued certificate.
OTOH, such a client *cannot* rely on always receiving that form of response
for a known non-issued certificate for the reasons discussed in the new text
(e.g., responder not updated to use that response, responder uses only pre
produced responses).

Again speaking for myself, I think the current text in -16 is ok, in that I
don't see the prohibition that Piyush is concerned about there.  OTOH, I'd also
be ok with a couple of sentences added to say that (new) clients could use
that response format to infer that the certificate is a known non-issued
certificate, but that clients cannot rely on getting that form of response
for all known non-issued certificate (i.e., may get an "unknown" response).

Thanks,
--David

> From: Piyush Jain [mailto:[email-masked]]
> Sent: Tuesday, April 09, 2013 2:03 AM
> To: 'Sean Turner'
> Cc: [email-masked]; [email-masked]; [email-masked];
> 'Stefan Santesson'; Black, David; [email-masked]; [email-masked]; gen-
> [email-masked]; 'Henry B. Hotz'
> Subject: RE: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
>

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 09 Apr 2013 16:57:05 +0100

>for all known non-issued certificate (i.e., may get an "unknown"

I'd rather not try to describe what clients should do or expect in terms
of non-issued certificates.
Clients are really not meant to know anything beyond "revoked" = this cert
should not be trusted.

This is a server choice to prevent the requested cert (if it exist at all)
from being accepted.
For requests for real certs, issued by a trusted CA, this case will never
even occur unless the CA is compromised.
And, if I put something in, given the discussion so far, the chance that
there will be some major disagreements with it, is really high.

The current text works.

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 9 Apr 2013 08:14:03 -0700

> message, I do see a disagreement between you and Stefan about what
> implementations are likely to do, but I don't see any text in the draft
that
> dictates that implementations must or must not make that interpretation.

I think I failed to clarify this in my last message. Let me try again. I
based my interpretation on the following response from Stefan :

BEGIN QUOTE
~~~~~~~~~~~
" The draft does NOT define a "not-issued" response. It allows the "revoked"
response if a certificate serial number has never been issued. That is two
entirely different things. If you ask how to deal with the response, then
the client will not get a non- issued response. It will get a "revoked"
status."
END QUOTE
~~~~~~~~

The above explanation at the minimum indicates the author's intent that
clients should treat such certificates as "revoked" and not "non-issued".
However, if readers of the draft do not think that the draft explicitly
mandates it, we have a bigger problem w.r.t. to establishing trust in such
responses. Please see the text from section 4.2.2.2 bullet 2 and 3(page 15)

Begin TEXT
~~~~~~~~~
Clients MUST reject the   response if the certificate required to validate
the signature on the response fails to meet at least one of the following
criteria:
   1. Matches a local configuration of OCSP signing authority for the
certificate in question; or
   2. Is the certificate of the CA that issued the certificate in
question; or
   3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage extension
and is issued by the CA that issued the certificate in question as stated
above."
End Text
~~~~~~~

Based on above the responder trust models referred to by "2." and "3."
cannot be used to communicate "non-issued". 

-Piyush

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 9 Apr 2013 08:41:57 -0700

of
> non-issued certificates.
[Piyush] 
Thanks for clarifying your position on this Stefan.
This is the position I disagree with. I think several people in the WG
expressed that the meaning should be clearly conveyed if "revoked" is
extended to communicate "non-issued".  Expectation that clients should treat
these responses as normal revoked is not aligned with WG consensus IMO.
> This is a server choice to prevent the requested cert (if it exist at all)
from
> being accepted.
even
> occur unless the CA is compromised.
[Piyush]
 And I think this is the only case that is interesting to the clients. I
combed through the WG discussion and did not find a single case being
discussed where clients benefit from sending OCSP requests for serial
numbers for non-existent certificates.

> And, if I put something in, given the discussion so far, the chance that
there
> will be some major disagreements with it, is really high.
[Piyush]
These are the issues that implementers will have to deal with. If there are
going to be disagreement, they should be dealt with before the document is
published IMO, unless 2560bis is considered a stop gap measure and OCSP v2
is on the radar.
I understand the desire to wrap up the pending documents so pkix can be
disbanded on schedule. However, I'll leave that to the AD to decide that the
benefits of meeting that schedule outweighs the cons of publishing a
document that can potentially lead to confusion among implementers.

---

From: "Black, David" <[email-masked]>
Date: Tue, 9 Apr 2013 11:57:02 -0400

Piyush,

> based my interpretation on the following response from Stefan :

[ ... snip ...]

> clients should treat such certificates as "revoked" and not "non-issued".

This may be where we're talking past each other, because what matters is
the text in the draft.  I understand Stefan's intent, and believe that the
use of lower case "should" in the text quoted above is a fair summary of
what's in the current draft.  That's not an absolute prohibition on or
requirement for client behavior, although it's certainly the client behavior
that responders should expect (again, lower case "should").

> cannot be used to communicate "non-issued".

I think the mechanics of the response validation checks are fine - is the
concern that use of "that issued" for items 2 and 3 may be incorrect wrt
known non-issued certificates?  

It may be useful to keep in mind that the CA may have issued the
"non-issued" certificate, but no longer has any record of having done so,
so I disagree with the statement that the later two models cannot be used
to communicate "non-issued", as the CA's signature on such a certificate
may be valid.

Thanks,
--David

> Sent: Tuesday, April 09, 2013 11:14 AM
> To: Black, David; 'Sean Turner'
> 'Stefan Santesson'; [email-masked]; [email-masked]; [email-masked]; 'Henry
> B. Hotz'

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 9 Apr 2013 09:34:39 -0700

> It may be useful to keep in mind that the CA may have issued the
"non-issued" certificate
[Piyush] 
This is what I think will be confusing to many implementers :), who did not
participate in the WG discussions.
But then, it is an assumption on my part and you for one have proved that
the assumption is not universally true.

I guess we can move on if no one else has an input on this and deal with it
later (if needed) when we get more feedback from implementers who sign up
for adopting this feature.

-Piyush

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 10 Apr 2013 06:30:57 +0100

It is impossible to write a text that cannot deliberately be misunderstood.

This debate is so full of constructed, non-existent problems.

Nothing has changed for the clients. The client can receive an error, or
they can receive (good, revoked or unknown).
The meaning of those responses are pretty clearly explained.

The only thing we talk about here is an extremely unlikely and rare
exception case where the responder is allowed to respond revoked even if a
cert was never issued.

I'm sorry to say, but this is getting ridiculous.

/Stefan