Subject: RE: OSCP BIG BANG

From: Michael Myers <[email-masked]>
Date: Thu, 29 Apr 1999 09:41:04 -0700

Denis,

I understand Steve is on vacation this week.  But I do wish to clarify -08
against your request.

You are restating a request for a requirement that we discussed during the
original last call.  Namely, a mandated relocation of AIA information from
the subject certificate to the CA certificate.  We debated this issue on the
list during the original last call with the resolution that the text remains
as written.  In constrast, Steve asked for additional clarity and precision
regarding an existing requirement; this we responded to.

We are not in the mode at this very late stage of introducing new
requirements or reopening issues which were previously resolved.  That work
has been done.  My thanks to all who provided their time and energy to the
effort.

Mike

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, April 28, 1999 6:45 AM
> To: Stephen Kent
> Cc: [email-masked]
> Subject: OSCP BIG BANG
> 
> 
> The original title was "Re: WG Last call, redux".
> 
> Steve,
> 
> Thanks for giving the hint for the change. :-)
> 
> In the previous text, as it will be explained in detail, we 
> were somewhat
> inconsistent having a SHALL followed by a MAY.
> 
> The new text is proposing to keep the SHALL and change the 
> MAY into a MUST.
> I am basically proposing to change the SHALL into a SHOULD 
> and keep the MAY.
> 
> Both solutions are consistent. :-)
> 
> It seems now the Pandora box is re-opened  :-) and we have a 
> chance to fix the
> issue.
> 
> First, let me duplicate the section from the version 08 so 
> that people may save
> time, if they wish to follow this thread.
> 
> In version -08
> 
> 4.  Functional Requirements
> 
> 4.1  Certificate Content
> 
> In order to convey to OCSP clients a well-known point of 
> information access,
> CAs SHALL provide the capability to include the 
> AuthorityInfoAccess extension
> (defined in [RFC 2459], section 4.2.2.1) in certificates that 
> can be checked
> using OCSP.  Alternatively, the accessLocation for the OCSP 
> provider may be
> configured locally at the OCSP client.
> 
> CAs that support an OCSP service, either hosted locally or 
> provided by an
> Authorized Responder, MUST provide for the inclusion of a value for a
> uniformResourceIndicator (URI) accessLocation and the OID 
> value id-ad-ocsp for
> the accessMethod in the AccessDescription SEQUENCE.
> 
> The value of the accessLocation field in the subject 
> certificate defines the
> transport (e.g. HTTP) used to access the OCSP responder and 
> may contain other
> transport dependent information (e.g. a URL).
> 
> 
> In version 07 we had:
> 
> 
> 4.  Functional Requirements
> 
> 4.1  Certificate Content
> 
> In order to convey to OCSP clients a well-known point of 
> information access,
> CAs SHALL provide the capability to include the 
> AuthorityInfoAccess extension
> (defined in [PKIX1], section 4.2.2.1) in certificates that 
> can be checked using
> OCSP.  Alternatively, the accessLocation for the OCSP provider may be
> configured locally at the OCSP client.
> 
> CAs that support an OCSP service, either hosted locally or 
> provided by an
> Authorized Responder, MAY provide a value for a
> uniformResourceIndicator (URI) accessLocation and the OID 
> value id-ad-ocsp for
> the accessMethod in the AccessDescription SEQUENCE.
> 
> The value of the accessLocation field in the subject 
> certificate defines the
> transport (e.g. HTTP) used to access the OCSP responder and 
> may contain other
> transport dependent information (e.g. a URL).
> 
> (...)
> 
> The « MAY » in the second paragraph has been changed into a « MUST ».
> 
> Leaving the text out for a moment, let us consider the 
> following scenario:
> 
> A CA is started up with a CRL scheme. After one year of 
> operation, the CA
> wishes to offer an *additional* service available for *all* 
> the certificates,
> i.e. an On-line Certificate Status (OCS) Service.
> 
> For doing so, there is one single option: to revoke all the current
> certificates and re-issue new certificates with the 
> appropriate extension.
> 
> This is a BIG BANG situation. :-(
> 
> The consequences are quite important, among them, the size of 
> the CRLs is going
> to increase dramatically (there is no reason to stop that service).
> 
> The concern is that a smooth transition cannot occur. What 
> can we do ? Is there
> a panacea to this problem ?
> 
> Let us now take a closer look at the text. The last sentence 
> of the fist
> paragraph from 4.1 says: « Alternatively, the accessLocation 
> for the OCSP
> provider *may* be configured locally at the OCSP client. ». 
> If this is the
> case, then the extension is not used. If someone wanted to 
> deploy a system by
> configuring locally the system, CAs would nevertheless be 
> mandated to support
> the extension.  :-(
> 
> This is one argument for having SHALL changed into SHOULD, 
> i.e. « In order to
> convey to OCSP clients a well-known point of information 
> access, CAs SHOULD
> provide the capability to include the AuthorityInfoAccess extension »
> 
> When the local configuration is NOT used, let us now attempt 
> to solve the BIG
> BANG issue, and let us take a look at the text from RFC 2459.
> 
> « 4.2.2.1  Authority Information Access
> 
> The authority information access extension indicates how to access CA
> information and services for the issuer of the certificate in 
> which the
> extension appears. Information and services may include 
> on-line validation
> services and CA policy data.  (The location of CRLs is not 
> specified in this
> extension; that information is provided by the cRLDistributionPoints
> extension.)  This extension may be included in subject or CA 
> certificates, and
> it MUST be non-critical. »
> 
> The text allows the extension to be placed in CA certificate. 
> To my knowledge,
> a self-signed certificate is also a CA certificate. So it is 
> possible to have
> that extension is a self-signed certificate. The advantage is 
> two folds:
> 
> 1) the content of a self-signed certificate may change 
> without affecting the
> content of the leaf certificates or of the cross-certificates.
> 
> 2) since the extension is not in a leaf certificate, then it 
> makes leaf
> certificates smaller (remember low-fat leaf certificates ?)
> 
> We have defined in CMP a protocol to allow a certificate 
> rollover for trust
> points, so we know how to handle the renewal of a self-signed 
> certificate.
> 
> Now, I still guess that some people would like the current 
> text when a CA is
> started from the very beginning with an OCS service or when 
> that service is
> gradually offered to renewed certificates. So I would now 
> propose some text
> that handles all the three cases. Here is the new proposal 
> for a text to fit
> under 4.1.
> 
> 
> « 4.1  Certificate Content
> 
>  In order to convey to OCSP clients a well-known point of 
> information access,
> CAs SHOULD provide the capability to include the 
> AuthorityInfoAccess extension
> (defined in [RFC2459], section 4.2.2.1) either in every 
> certificate that can be
> checked using OCSP or in a self-signed certificate.  
> Alternatively, the
> accessLocation for the OCSP provider may be configured 
> locally at the OCSP
> client.
> 
> CAs that support an OCSP service, either hosted locally or 
> provided by an
> Authorized Responder, MAY provide for the inclusion of a value for a
> uniformResourceIndicator (URI) accessLocation and the OID 
> value id-ad-ocsp for
> the accessMethod in the AccessDescription SEQUENCE.
> 
> The value of the accessLocation field in the subject 
> certificate defines the
> transport (e.g. HTTP) used to access the OCSP responder and 
> may contain other
> transport dependent information (e.g. a URL). »
> 
> 
> Note: the other major change around this topic is in section 5.2.2.2
> Authorized Responders:
> 
> 
> In version 08 we have:
> 
>  (...)
> 
> 5.2.2.2  Authorized Responders
> 
>    The key that signs a certificate's status information need 
> not be the
>    same key that signed the certificate. It is necessary however to
>    ensure that the entity signing this information is authorized to do
>    so.  Therefore, a certificate's issuer MUST either sign the OCSP
>    responses itself or it MUST explicitly designate this authority to
>    another entity.  OCSP signing delegation SHALL be designated by the
>    inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
>    extension included in the OCSP response signer's certificate.  This
>    certificate MUST be issued directly by the CA that issued the
>    certificate in question.
> 
> 
>    id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
> 
>    Systems or applications that rely on OCSP responses MUST be capable
>    of detecting and enforcing use of the id-ad-ocspSigning value as
>    described above. They MAY provide a means of locally 
> configuring one
>    or more OCSP signing authorities, and specifying the set of CAs for
>    which each signing authority is trusted. They 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-ad-ocspSigning in an ExtendedKeyUsage
>     extension and is issued by the CA that issued the certificate in
>     question."
> 
>    Additional acceptance or rejection criteria may apply to either the
>    response itself or to the certificate used to validate the 
> signature
>    on the response.
> 
> 
> While in version -07 we have:
> 
> 5.2.2.2  Authorized Responders
> 
>    The key that signs a certificate's status information need 
> not be the
>    same key that signed the certificate. A certificate's issuer MAY
>    explicitly delegate OCSP signing authority by issuing a certificate
>    including an extendedKeyUsage extension in the OCSP signer's
>    certificate containing the value id-kp-OCSPSigning.
> 
>    id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
> 
> 
> Denis
> 
> 
> > Several folks pointed out that I made the re-opening of 
> last call into a
> > treasure hunt!  Sorry 'bout that.  I am away from the 
> office and not easily
> > able to provide a diff, but I can describe the goal for the 
> changes, which
> > resulted in both editorial and sunstantive modifications to 
> the text.
> >
> > The concern I raised with the OCSP authors was that it was 
> not clear what
> > the hard and fast requirements were for CAs and clients 
> with regard to
> > supporting three different ways that OCSP can be "enabled." 
> I felt it
> > important to ensure that CAs and clients that claim 
> comformance would
> > provide a set of confuguration controls that would allow 
> interoperability,
> > if properly configured. So, the resvied text tries to make 
> this perfectly
> > clear. The final form of the requirements, with some abstraction, is
> > sumarized below:
> >
> >         - an OCSP-compliant CA SHALL be capable of issuing 
> OCSP responses
> > that are signed ditrectly by the CA, and MUST be able to 
> designate an OCSP
> > responder by issuing an appropriately marked certificate 
> directly to the
> > responder.  the choice or direct vs. delegated OCSP 
> responses is a local,
> > administrative option. the CA also SHALL be capable of 
> putting the AIA
> > extension into certs when it is the intent that these certs 
> will be checked
> > via OCSP, and MUST be capable of populating this extension 
> with the OID
> > specifying OCSP access method and a URI for such access.  
> (This last part
> > was changed from a MAy to a MUST, which seems reasonable to 
> ensure the goal
> > cited above.)
> >
> >         - an OCSP-compliant client MUST be able to accept 
> OCSP responses
> > via three different means: responses signed by the CA that 
> issued the cert
> > in question, responses signed by a responder directly 
> designated by that
> > CA, or via a locally designated responder.  It is a local 
> administrative
> > choice as to which of these options if enabled. If local 
> designation is
> > enabled, vendors have choices as to how fancy it gets, 
> e.g., how many OCSP
> > responders are specified, how one knows which ones are authorized to
> > provide status for which sets of certs, etc.
> >
> > Steve
>