Subject: OCSP & Authority Information Access

From: Denis Pinkas <[email-masked]>
Date: Tue, 19 Jan 1999 12:19:02 +0100

I have a major problem with OCSP related to the AuthorityInfoAccess extension
which is said to be mandatory in OSCP. OCSP-07 contains the following text:

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.

PKIX1, section 4.2.2.1 contains the following:

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 is always non-critical.

We should limit the size of the certificates to a minimum, in particular when
they are stored in a smart card. It is therefore not acceptable to mandate the
inclusion of that information in every subject certificate.

On the contrary it can make sense to include it in a self-signed certificate
from a CA.

To this respect, I propose to amend the text in the following way:

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 their self-signed certificates (CA certificate) so that it can be
known that some or all the subjects certificates from that CA can be
checked using OCSP. Alternatively, the accessLocation for the OCSP
provider may be configured locally at the OCSP client.

Regards,

Denis

---

From: Sarbari Gupta <[email-masked]>
Date: Wed, 27 Jan 1999 12:38:07 -0500

A self-signed certificate offers some level of integrity protection to
the root public key. It also binds the key to a name (although there is
little trust in this binding since it is self-signed) - this name is
useful for displaying to the human user. The self-signed certs (root
keys and names) can be stored on unprotected media (if necessary)
without any additional integrity protection mechanisms. 

- Sarbari
=================================
Sarbari Gupta
CygnaCom Solutions
(703)848-0883 (voice)
(703)848-0960(FAX)
[email-masked]
=================================

-----Original Message-----
From: Phillip M Hallam-Baker [mailto:[email-masked]]
Sent: Wednesday, January 27, 1999 12:21 PM
To: [email-masked]; Michael Myers; ietf-pkix
Subject: RE: OCSP & Authority Information Access

> 
> I have a problem to understand why we consider self-signed
certificates
> instead of root keys as primary trusted data objects. More specific
> comments in lines below. 

This is something I thought a lot about when I was at W3C, we were
looking
at a system in which root keys were expressed as URLs.

The distinction pointed out is that if the KEY is trusted then the means
of revocation needs to refer to the KEY (which in our case it did, a 
revocation statement referred to the URL of the revoked key).

In the case of PKIX however it is the Serial Number of the self signed
cert which is used for revocation. Thus it is the binding of the key to
the serial number which is trusted in this respect. A similar argument
may then be made wrt the subject name.

Although this may appear to be a debate in semantics, this is of course
what a standards effort (court proceeding, academic paper) is.

I do not however think that it is necessary to over-analyse the point.
SDSI is fine if one wishes to construct an algebra of trust in which
to analyse a PKI such as PKIX. I now believe that the value of approach
is limited to being an analytical tool and that reifying it in an
implementation is a mistake. It is too low level, it is necessary to
make simplifying assumptions to make the system tractible. 'Structured
trust' is necessary for the same reason as 'structured programming'.

Although one can make a distinction between reliance on the key and 
reliance on the self signed certificate, trusting the key if the
certificate is lost it is IMHO not wise to do so.

		Phill

---

From: Andrew Probert <[email-masked]>
Date: Thu, 28 Jan 1999 09:37:08 +1100

... and if a key is bound to a name, then it is possible to renew keys and
certificates reusing the same name, where each is differentiated by its
serial number, thus a level of indirection / one-many relationship is
possible allowing date/time overlaps and other real world renewal issues.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> From:	Sarbari Gupta [SMTP:[email-masked]]
> Sent:	Thursday, January 28, 1999 4:38 AM
> To:	'Phillip M Hallam-Baker'; [email-masked]
> Cc:	ietf-pkix