Subject: OCSP Service Locator and RFC2459's Authority Information Access

From: Rich Salz <[email-masked]>
Date: Sun, 28 Feb 1999 12:57:44 -0500 (EST)

Is there any reason to use the OCSP "Service Locator", (Draft 7,
Section 5.4.6) instead of defining an Authority Information Access
AccessDescription for the OCSP service (RFC2459, Section 4.2.2.1)?
Is it just a case of parallel efforts duplicating work, or is there
a subtlety I'm missing?

Replies to me will be summarized for the list.
	/r$

---

From: "Peter Williams" <[email-masked]>
Date: Mon, 1 Mar 1999 10:39:52 -0600

What *are* the critical "usage semantics" of an OCSP/CRLDP
service locator, in the various kinds of signalling fields,
AKI, CRLDP distributionPoint URI, etc.?

What are the non-critical usage semantics of the same?

For example, if the locator is an http URI or URL, may I
use my UA's or local proxies http cache, or must I positively
identify and use the values from the URI/URL in an
end-end online exchange, authenticated by http's basic auth,
MSIE's challenege/response auth,  or other mechanism such as
TLS or  IPSEC?

If a Internet OCSP/CRLDP UA is ever forced to use a online
exchange as a result of standard conformance
language, we will be undermining the assurance
of 2459, which states (informally, speaking) that PKIX does
not assume the average Internet UA worldwide
has other than minimal connectivity to the Net. Also,
confidentiality of acts of reliance would be potentially
compromised by traffic-pattern analysis threats.

One could imagine mandatory locator semantics
being usefully specified, but being either recommended
or required operationally only in policy documents such
as PKIX-QC, where the UA-desired legal respectability
of the online revocation/validation attestation might benefit
 from the CA/VA's online confirmation. Similarly, one could
imagine PKIX-QC profiling OCSP to use the available
nonces, to ensure replay threats are countered in such
enviornments and applications, whereas
normal-internet OCSP UA's may use/enforce nonces only
at the option of the UA , responder's private
commercial/liability policy permitting.

Peter.

Notes:

"In order to relieve some of the obstacles to using X.509
   certificates, this document defines a profile to promote the
   development of certificate management systems; development of
   application tools; and interoperability determined by policy." [RFC 2459]

"This profile supports users without
   high bandwidth, real-time IP connectivity, or high connection
   availability.  In addition, the profile allows for the presence of
   firewall or other filtered communication." [RFC 2459]

---

From: [email-masked]
Date: Wed, 3 Mar 1999 18:08:29 -0500

> > Is it just a case of parallel efforts duplicating work, or is there

Thanks to Rich Ankney for reminding me that since the whole cert isn't
sent in the OCSP request you can't use an OCSP AIA AccessDescription.
However, if one were defined, you could cut&paste it into the Service
Locator.

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
"directing" the user/reader/implementor to OCSP specs anyway.)
	/r$

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 03 Mar 1999 18:42:34 -0700

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

> From: [email-masked] [mailto:[email-masked]] 
> 

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: "Bob Jueneman" <[email-masked]>
Date: Thu, 04 Mar 1999 09:43:08 -0700

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,

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

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

---

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 04 Mar 1999 11:31:18 -0700

Mike,

Sorry if I misunderstood.

You said that

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

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

Bob

>>> Michael Myers <[email-masked]> 03/04/99 10:42AM >>>
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
> 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
>