Subject: RE: OCSP Service Locator and RFC2459's Authority Information Acce ss

From: Michael Myers <[email-masked]>
Date: Thu, 4 Mar 1999 07:57:59 -0800

Bob,

AIA is multiply-valued, so you can put in other info:

AuthorityInfoAccessSyntax  ::=
        SEQUENCE SIZE (1..MAX) OF AccessDescription

AccessDescription  ::=  SEQUENCE {
        accessMethod          OBJECT IDENTIFIER,
        accessLocation        GeneralName  }

The OCSP OID would simply identify the URI used for that particular method.

Mike

> -----Original Message-----
> From: Bob Jueneman [mailto:[email-masked]]
> Sent: Wednesday, March 03, 1999 5:43 PM
> To: [email-masked]; [email-masked]
> Subject: RE: OCSP Service Locator and RFC2459's Authority Information
> Access
> 
> 
> Michael, is the AIA in that case presumed to apply uniquely 
> to the OCSP provider -- i.e., has OCSP highjacked that field?
> 
> Or can other uses be provided as well, using multiple URIs or 
> whatever?
> 
> Bob
> 
> >>> Michael Myers <[email-masked]> 03/03/99 05:00PM >>>
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] 
> > 
> > This brings up a new question: why is there no OCSP AIA 
> > AccessDescription
> > defined?  :) All we need is an OID and a URIName of type 
> > IA5STRING.  Is it
> > too late to add this to the current draft?  Does it belong 
> > here, or does it
> > more like a cert profile item?  Because of its "dual 
> nature" should it
> > perhaps
> > be written up separately, anyway? (Probably not, since the 
> > OID base will end
> > up
> 
> 
> Rick,
> 
> It's already in there:
> 
> "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)."
> 
> 
> Mike
>

---

From: Michael Myers <[email-masked]>
Date: Thu, 4 Mar 1999 09:42:11 -0800

Bob,

I've seen AIA working as most other OID-based mechanisms work.  One defines
and OID and the semantics associated with it.  The OCSP draft does this for
this one particular method of accessing this one particular type of
authority information using one particular transport--with the underlying
assumption that there is only one value of id-ad-ocsp in the AIA SEQUENCE.

Other AIA accessMethod OIDs can be defined for other purposes and so
disambiguate the cases you cite.  Perhaps this is a subject for an I-D that
identifies and defines additional standard methods and semantics of AIA use.

I can say with certainty that OCSP does not "think" is somehow owns the
entire scope of semantics that AIA establishes.

Mike

> Sent: Thursday, March 04, 1999 8:43 AM
> Michael,
> I understand that AIA is multiply-valued, so I can put in 
> multiple URLs.
> 
> The question, as is the case all too often, is what are the 
> SEMANTICS of those various URLs?
> 
> So I put in one LDAP, one DAP, and one HTTP, or maybe just 
> three LDAPs.
> 
> Is OCSP going to assume that each and every one of those URLs 
> point to an OCSP server, and maybe it should make a random 
> choice?  What if one refers to the originator's directory 
> that contains his certificate, one refers to the CA's 
> directory which can be used to look up certificates by Issuer 
> name and serial and NOT by DN, and one points to a directory 
> of CRLs and/or OCSP providers that do NOT maintain a list of 
> certificate or other potentially useful information?
> 
> I believe that my original thought was correct -- that OCSP 
> thinks it has exclusive ownership of the AIA attribute?
> 
> Bob
> 
> >>> Michael Myers <[email-masked]> 03/04/99 08:57AM >>>
> Bob,
>

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 4 Mar 1999 19:27:24 +0100

> The OCSP OID would simply identify the URI used for that particular method.
Question 
Part 1 (version 11) says

   Each entry in the sequence AuthorityInfoAccessSyntax describes the
   format and location of additional information about the CA who issued
   the certificate in which this extension appears.  The type and format
   of the information is specified by the accessMethod field; the
   accessLocation field specifies the location of the information.  The
   retrieval mechanism may be implied by the accessMethod or specified
   by accessLocation.

The text doesn't say whether you can have DIFFERENT AIAs in certs issued by the
same CA. In fact, the text does not bind the AIA to the cert, it talks
only about the CA. As a result one could imagine that except in rollover
periods, a particular AccessDescription would be always identical in
all certs signed by the CA (if the AIA exists). Or in other words, if
I have ONE cert that has a desired Accessdescription, then I know something
about the CA in general, and not only something about the combination
cert/CA. As a consequence you only need ONE cert with an AccessDescription.

In early drafts there were also SubjectInfoaccess and CAInfoaccess
extensions with a similar syntax. They no longer exist and in fact they
are not necessary.

First both extensions basically mean the same thing, they talk about
informationaccess about the SUBJECT, the distinction of SubjectInfo in
EEs and CAinfo in CAcerts is superfluous. 

Furthermore none of them is actually necessary: If I would want some
AccessDescription pointing to the Subject, I would just put it directly
as an extension. Or, the other way around, the AIA is needed to encapsulate
an extension to tell that it refers to the Issuer and not to the
subject.

If the previous makes sense, then the text in OCSP is slightly misleading.

In fact, I would like to see that in the situation of an OCSP provider
cert signed by ITS authority have an AIA, and maybe the CA cert has
just the ocsp location as a direct extension.
And in case where the CA is directly the server, then the CA cert would
indicate that it is its OWN ocsp server *AND* maybe have an AIA pointing
to another ocsp service (the one of the issuer). 

have fun
Peter Sylvester

---

From: Michael Myers <[email-masked]>
Date: Thu, 4 Mar 1999 15:56:14 -0800

Bob,

There's no requirement that the accessMethod be protocol-specific.  This
level of specificity can be derived from the chosen name form in
GeneralName.  In the case of OCSP, the spec establishes that the URI name
form MAY be used.

Since URIs can be prefixed with a variety of protocol methods (e.g. http://,
ftp://, ldap://), we wrote Appendix A.1 to provide implementation guidance
for OCSP over HTTP and so ensure at least one method of establishing
interoperability.

These are minimum interoperability requirements.  Environments with more
specialized needs are of course free to assert additional requirements in a
forum and manner of their choice, just as they do today with certificate
extensions.  In particular, the spec purposefully has no language
establishing that {URI, HTTP} is the ONLY mechanism for id-ad-ocsp.

Mike

> Sent: Thursday, March 04, 1999 10:31 AM
> Mike,
> Sorry if I misunderstood.
> 
> You said that
> 
> I was interpreting the accessMethod OBJECT IDENTIFIER to 
> refer to say LDAP, DAP, HTTP, or whatever, regardless of 
> what use they might be put to.
> 
> Are you saying that the accessMethod OID is particularized to mean
> "LDAP for OCSP", " LDAP for CRLs", or 
> "LDAP for certificate lookup in a directory", etc?
> 
> Have particular OIDs defined for those semantics, at least 
> in the case of OCSP? 
> 
> (My apologies if all of this is well known to everyone else -- 
> I just don't have the time to and understand read every RFC 
> that comes out in the required amount of detail.)
>