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

[Michael Myers <MMyers@xxxxxxxxxxxx>]

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




> -----Original Message-----
> From: Bob Jueneman [mailto:BJUENEMAN@novell.com]
> Sent: Thursday, March 04, 1999 10:31 AM
> To: ietf-pkix@imc.org; MMyers@verisign.com
> Subject: RE: OCSP Service Locator and RFC2459's Authority Information
> Access
> 
> 
> Mike,
> 
> Sorry if I misunderstood.
> 
> You said that
> 
> >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.
> 
> 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.)
>