Subject: Re: [pkix] Revising OCSP

From: koichi sugimoto <[email-masked]>
Date: Sat, 10 Jul 2010 00:01:31 +0900

Hello Cooper,

>Could you be specific about what from this document you believe needs
>to be included in the update to RFC 2560.  I have only skimmed through
>the Microsoft document, but it says that it is based on RFC 5019,
>which is a profile of RFC 2560, and it is not our intention to
>incorporate RFC 5019 into the update to RFC 2560.  RFC 5019 will
>continue to be a useful document for implementors to read after the
>update to RFC 2560 is published.

Please refer "Independent OCSP Signing Certificate" part, on page 9.
They do not restrict the issuer of OCSP signing certificate to the CA
that revokes the issued certifcates.

Sugi

---

From: koichi sugimoto <[email-masked]>
Date: Mon, 12 Jul 2010 20:47:57 +0900

Hello Dave,

I think that Microsoft's specification is one of the concrete examples
that Nelson ever posted on 17 Apr 2010.
I believe that their implementation is not against RFC 2560.
The following is the reference that Nelson posted:

> Every year, Mozilla receives numerous requests for inclusion of root CA
> certificates into its products.  Over the last 5+ years, Mozilla has found
> it necessary to reject or indefinitely postpone at least one such request
> per year, because NONE of the OCSP responses for the EE certificates issued
> by the root CA's subordinate issuers bore a signature that could be
> determined to have come from an "Authorized Responder" as defined in RFC
> 2560 section 4.2.2.2 (as Mozilla's developers have interpreted it), unless
> the browser was individually configured to trust that OCSP response
> signer's certificate as its OCSP signing authority.
>
> In each and every case, the CA organization had already invested a large
> amount in its OCSP infrastructure, and its designers believed that they
> were compliant with RFC 2560.  They disagreed with Mozilla over the
> interpretation of RFC 2560.
>
> Mozilla's understanding of RFC 2560 section 4.2.2.2 is that the OCSP
> response must have a signature that is verifiable by one of the following:
> 1) the same CA certificate with which the signature on the "certificate in
> question" is verified, or
> 2) a certificate bearing the id-ad-ocspSigning EKU, which was issued by,
> and whose signature is verifiable by, the same CA certificate with which
> the signature on the "certificate in question" is verified, or
> 3) a certificate chosen by the relying party and configured in the relying
> party's software as the relying party's OCSP signing authority.
>
> Each of the contesting CAs has disagreed with Mozilla over that
> interpretation in one of the following areas:
>
> a) They understand "CA" or "issuer" to mean the CA organization, not a
> particular CA private key and its corresponding certified public key.  So
>
> a1) They ALL interpret section 2.6 as saying that the certificate's issuer
> (organization) delegates OCSP signing authority by issuing (from some
> issuing CA key under the control of that organization) a certificate
> containing the special id-ad-ocspSigning EKU in the OCSP signer's
> certificate. Where the RFC says "This certificate MUST be issued directly
> to the responder by the cognizant CA" they understand "congnizant CA" to
> mean "organization" or "legal entity", not "private key" or even "Issuer Name".
>
> a2) Most believe the requirement in section 4.2.2.2 that "the certificate
> required to validate the signature on the response ... 2. Is the
> certificate of the CA that issued the certificate in question;" is
> satisfied if the OCSP response signer's cert is the certificate of any
> issuer directly in the certification path of the cert in question.
>
> a3) Likewise, most believe that the alternative requirement that "the
> certificate required to validate the signature on the response ... 3.
> Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage extension and
> is issued by the CA that issued the certificate in question" is satisfied
> if the OCSP response signer's cert with that EKU is issued by any issuer
> directly in the certification path of the cert in question.
>
> b) Alternatively, some CA's understand "local configuration" to be the
> CA's configuration, not the relying party's configuration.
>
> So, in all (or nearly all) cases, they have set up a single central OCSP
> responder with a single response signing cert, typically issued directly
> from the root issuer, and have carefully given that cert the special EKU
> extension, and expect that the OCSP responses it signs will be fully
> acceptable for OCSP inquiries regarding certs issued by other subordinate
> Issuers whose CA certs were issued by that same root issuer.
>
> I wish I could say that the text of RFC 2560 was so unambiguously clear
> that there was no room for any other interpretation than mine, but in fact
> it IS ambiguous, and the best I can say is that there are (at least) two
> interpretations, neither of which seems entirely unreasonable.
>
>> The single VA for [many] CAs, where the VA is represented by a single
>> certificate, is allowed but requires all clients to manually configure
>> trust in this VA for each and every CA they rely on. While this may work
>> in a closed environment, it is not very practical in an open
>> environment.
>
> You and I read RFC 2560 and come to that conclusion, but I believe
> reasonable people can read it and come to other conclusions and many have
> done just that, with very unfortunate and costly results.  A clearer
> document would help us all.

To clarify their implementation, I'll send e-mail to Microsoft's
well-informed persons and invite them to this discussion.

Regards,
Koichi Sugimoto.

> From: "David A. Cooper" <[email-masked]>
> To: koichi sugimoto <[email-masked]>
> Date: Fri, 09 Jul 2010 11:32:46 -0400
> Subject: Re: [pkix] Revising OCSP
> I read through the section in the document on Page 9 entitled "Independent OCSP Signing Certificate", but I can't understand what it is saying.  If I had to guess, however, I would guess that it is describing something related to "Locally Trusted OCSP Responders", not "Designated OCSP Responders".  Perhaps someone at Microsoft who is familiar with this OCSP implementation can clarify the meaning of this section in that document.
>
> However, the scope of the current effort to update RFC 2560 is very limited, and any changes to the protocol would be considered out of scope (except changes that have already been approved in RFC 5019 or that are part of draft-ietf-pkix-ocspagility).  So, if the Microsoft document is describing something that is not permitted by RFC 2560 or RFC 5019, then it cannot be included in the update to RFC 2560.
>
> Dave