Subject: RE: OCSP & Authority Information Access

From: Michael Myers <[email-masked]>
Date: Tue, 26 Jan 1999 18:28:57 -0800

Denis,

Responses inline, with some trimming.

> You wrote:
> From: Denis Pinkas [mailto:[email-masked]]
> . . .
>
> > It means the capability shall be there, but its use in any 
> particular
> > circumstance is a matter of choice.  I would have preferred 
> the simplicity
> > of a single way of doing things, but legacy effect 
> considerations alone
> > warranted the wording of the requirement.
> 
> Well, let me see ...
> 
> Suppose I propose a PKIX Part 1 compliant PKI issuing CRLs. 
> My customer later
> on decides to install an OCSP server. According to the 
> wording it seems that
> my PKIX Part 1 compliant software suite is no more compliant with the
> standard. My customer might then complain that I provided him 
> with a non
> compliant software.

I agree that if you choose not to implement functionality required by any
spec, then that product could be non-compliant.  I must again note that the
requirement doesn't require deployment of AII extension, which I believe
meets your original concern.  Irregardless, there's strong merit in
maintaining the text as is . . . .

> It seems to me that this sort of situations should not 
> happen. We need to
> revise the wording now or later.
> At the minimum the SHALL "shall" be turned into a "SHOULD". I 
> did not say  the
> SHALL "should l" be turned into a "SHOULD".  :-)
> 
> Besides that point I also want to deprecate the use of such 
> an extension in
> leaf certificates. This this respect I am proposing again my 
> previous text,
> but changing the SHALL into a SHOULD:
> 
> " 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 [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."

I must respectfully disagree on two points:

1) To reiterate a point I made earlier, the semantics of the AII extension
are defined by Part 1, not the OCSP draft.  So changing OCSP isn't
sufficient.  It's also necessary to change Part 1.  Otherwise, the OCSP spec
would fail to comply with the direction given in Part 1. 

2) Even so, putting a fixed pointer in the CA cert for those that use this
extension is ill-advised.  If the pointer were for some reason to change
over time, it's fairly easy to begin using a new value in newly-issued
end-entity certificates.  One can maintain the service at the old pointer
during an transition period.  If the pointer is in the CA certificate, it's
more difficult to change, particularly if you're talking about self-signed
(or root) certificates.  This is and should be a trusted process.  In some
circumstances, it may be necessary to recall hardware tokens that use a
special trusted store for roots.  Definitely a painful and expensive
process.

Mike

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 27 Jan 1999 10:32:56 +0100

Mike,

> would fail to comply with the direction given in Part 1.

Oncre again, 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.

Part 1 needs no revision. It says MAY be included. So I respectfully disagree
with this argument.

> during an transition period.

The same argument applies with the self-signed certificate: one can maintain the
service at the old pointer
during a transition period.

> If the pointer is in the CA certificate, it's
> (or root) certificates.  This is and should be a trusted process.

True, but self-signed certificates changes over time. They are not for ever.

> In some

This is precisely because I care for the memory size of these hardware tokens
that the extension should not be placed in leaf certificates.

Now, to come back to the real topic, the spirit of PKIX is not to say that every
PKIX compliant implementation SHALL support every optional extension (even if it
is not used by the final customer). I cannot understand why you want to make a
special case for that OPTIONAL extension.

Regards,

Denis

---

From: Juergen Walter <[email-masked]>
Date: Wed, 27 Jan 1999 11:35:31 +0100

Michael,

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. 

[...]
> (or root) certificates.  This is and should be a trusted process.

The root key, i. e. the public key of the directly trusted CA, is
essentially the trusted data object less the self-signed (or root)
certificate, which contains this public key. 

> special trusted store for roots.  Definitely a painful and expensive

This would be definitely not when the CA reissue a self-signed (root)
certificate which certifies the already delivered root key. This process
is less painful and expensive. In a first step the CA has to publish a 
new self-signed root certificate containing the updated information.
This self-signed certificate is signed with the already delivered root
key. In a second step the CA publishs its new self-signed certificate.
In a transitional period there are two self-signed certificates. In your
example the old and the new pointer must be meaningful. In a third step,
after an appropriately chosen transition period, the old self-signed
certificate has to be revoked (reasonCode = superseded???).

The described process fits smart cards environments as well, doesn´t it?

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Wed, 27 Jan 1999 12:20:48 -0500

> instead of root keys as primary trusted data objects. More specific

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