Subject: Re: OSCP BIG BANG

From: Denis Pinkas <[email-masked]>
Date: Tue, 04 May 1999 11:58:32 +0200

> 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.

There has never been such a request, i.e. a *mandated* relocation of AIA
information from
the subject certificate to the CA certificate.

The current text is in fact advocating *against* the adoption of conformant CAs
supporting OCSP. If we keep the current text we will be faced with two
situations:

a) not conformant CAs, supporting OCSP,
b) conformant CAs, not supporting OCSP.

Either situation would not be very good. :-(

Denis

> 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
> >

---

From: Michael Myers <[email-masked]>
Date: Tue, 4 May 1999 08:24:30 -0700

Peter,

The subject certificate in this context is the certificate that is being
validated.

Mike

> From: Peter Sylvester [mailto:[email-masked]]
> Sent: Tuesday, May 04, 1999 8:16 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: OSCP BIG BANG
> 
> 
> Question: 
> 
> What is the 'subject certificate' in the following description. 
> 
> - EE cert to be validated ? 
> - The OCSP cert of a responder? 
> - A CA certificate? 
> 
> 
> 5.4.6  Service Locator
> 
>    An OCSP server may be operated in a mode whereby the 
> server receives
>    a request and routes it to the OCSP server which is known to be
>    authoritative for the identified certificate.  The serviceLocator
>    request extension is defined for this purpose.  This extension is
>    included as one of the singleRequestExtensions in requests.
> 
>    id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { 
> id-pkix-ocsp 7 }
> 
>    ServiceLocator ::= SEQUENCE {
>        issuer    Name,
>        locator   AuthorityInfoAccessSyntax OPTIONAL }
> 
>    Values for these fields are obtained from the 
> corresponding fields in
>    the subject certificate.
>

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 4 May 1999 17:16:07 +0200

Question: 

5.4.6  Service Locator

   An OCSP server may be operated in a mode whereby the server receives

   id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }

   Values for these fields are obtained from the corresponding fields in
   the subject certificate.

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 4 May 1999 18:29:19 +0200

> The subject certificate in this context is the certificate that is being

Do you mean 'As if the corresponding subject cert would
have an AIA with these parameters.'

If the certificate really HAS the extension, then the verifier
could probably go directly to the service. 

If not, I think a good way to publish the location of a
service provider is to have it directly in an extension
with an oid of id-ocsp and the syntax of accessLocation
directly in a CA cert or in an OCSP responder cert. For
the CA this indicates the url of an OCSP responder for
all certificates issued by that CA, for an OCSP
responder cert it indicate the service to verify certs
signed by the CA.

This would resolve in an elgant way Denis concerns,
This can happen either in self signed CA certs or
in any non self signed CA cert. 

This is not just a method for OCSP, but a general technique 
that can be used for *ANY* service where you would have a
pointer in an EE AIA signed by the authority in question
to avoid fat EE certificates.  

In earlier drafts of PKIX there had just been EEInfoaccess
and CAInfoaccess, they are obviously not necessary
as extensions, but the functionality is useful

EE and CA can be distinguished by the nature of the cert.
==> you end with ONE feature. 
Now, whenever someone defines an accessMethod oid to be
usable in an AIA, one can directly define an extension
with that oid and accessLocation as a value telling the
obvious rather obvious thing if it is used in a CA
certificate. 

For a "service" certificate the interpretation
differs slightly. If one doesn't like id-ocsp extension,
in a service certificate, one could also
have an servicelocator extension in such a server cert.

"My issuer tells that I am the service locator
 for Name, and here is the URL." 

I wonder whether some text should be included
in OCSP or in an updated version of 2459, or
in an independant document. 

Peter

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 14 May 1999 16:31:09 +0200

> 
> Denis,
> 
> >>
> >> The change from MAY to MUST was intentional. The notion is that a CA is
> >> considered as OCSP compliant only if it is capable of putting the AIA
> >> extension, with OCSP-specific values, into certs that it generates.
> >
> >What do you mean here ? He is capable to do it, but it does not  ? This is
> >a very
> >odd concept to me.
> 

It seems that what is actually required in case that someone wants
to provide ocsp, is that the software used to provide certification
MUST be able to set AIAs. 

The AIA is an extension especially defined for the Internet, either 
one should be completely silent about whether 'in the Internet context' 
it is required to support an AIA extension in order to be able to support
a multitude of requirements that may come from other protocols, or simply say,
AIA support is mandatory in the Internet. 

Is there a need to clarify rfc2459? If the AIA is mandatory,
then there is no conflict with latest OCSP draft. 
 
Combining a mandatary support for AIAs with a special service definition
like OCSP needs some explication, especially when you can operate
a service without it.

P 

BTW: One might add to the text that the certificate that carries 
'ocsp signing' extended key usage extension,  SHOULD/MAY also carry 
an AIA with ocsp code signing and the url of the service fo example.