Subject: Getting CA capabilities

From: "Christopher Williams" <[email-masked]>
Date: Mon, 10 Apr 2000 10:34:04 +0100

There does not seem to be any way for an EE to obtain details of certain CA
capabilities, e.g. whether the CA supports key generation, whether the CA
supports key archival and retrieval, etc. unless the EE has intimate
knowledge of the CA.  Should the EE's client software be able to obtain
programmatically details about the server software's capabilities?  Is this
a possible GeneralInfo type?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com

---

From: Oscar Jacobsson <[email-masked]>
Date: Tue, 11 Apr 2000 13:44:52 +0200

> a possible GeneralInfo type?

Would this not be best handled via the Authority Information Access
extension? RFC 2459 sure does make it sound like a prime candidate for
distributing such information:

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

//oscar

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 11 Apr 2000 08:39:58 -0400

>validation services and CA policy data."

But that is after the fact.  In CMP, you do not get the CA's cert until you 
get your Initialization Response.

As I pointed out to Chris in private, CMP has an out-of-band I&A process 
for IR's shared secret.  During this process, all CA policy can be handed 
to the EE.

Interestingly, if you were to want to use a QC cert to sign a CP in place 
of the out-of-band I&A and IR, then you DO need a programatic way for the 
EE to get the policy.

To this extent, I do not believe we KNOW all the items and values that 
would be expressed in a policy.  Or at least I have not seen any such 
document.  So for an EE programmer to deal with this, we first need to 
define what IS configurable policy, or at least those policy items that 
impact EE behaviour.

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

---

From: "Christopher Williams" <[email-masked]>
Date: Wed, 12 Apr 2000 16:49:39 +0100

Having thought about it, the Authority Information Access extension is not
the correct place for CA capability information:

1. It's a kludge
2. It's part of a separate (if related) specification; the PKIX
specification is where the issue needs to be addressed.
3. As Robert Moskovitz pointed out, you might not get the CA certificate
until the initialization response.  The initialization request can contain a
request for a server-generated encryption key.

Having the capabilities expressed in a policy document is also not the place
for it.  A human can read the document, but a machine cannot.  I know you
can express policies with ObjectIdentifiers, but this requires a client to
have intimate knowledge of the server - a hypothetical universal PKIX client
program could not understand this information.

With the current specification we can ask a CA what key types it supports
(i.e. we can tell from this if DSA is supported), but we can't ask whether
that CA will generate a DSA key on our behalf and then store it for us.
It's not really an error to ask a CA which doesn't support key generation to
generate a key if you don't know about it in advance, but presumably the CA
has to return something like badRequest.

I think a new GeneralInfo type should be devised.  The value could be a BIT
STRING whose contents indicate a mask of capabilities, e.g. bit 1 could mean
"supports key generation", bit 2 means "supports key archival and recovery",
etc.

Beyond the required capabilities of a compliant information, a lot of the
PKIX specification is pretty esoteric and may actually never be encountered
in a real world implementation.  A method of exchanging capability
information would save implementors from having to code for every
eventuality.

On the subject of making implementors' lives easier, is there any chance of
specifying SHA-1 / HMAC-SHA-1 as the ONLY permissible algorithms for a
password based MAC?  I know the aim of the specification is that it should
be as general as possible, but sometimes it's good to be strict.

----- Original Message -----
From: Robert Moskowitz <[email-masked]>
To: Oscar Jacobsson <[email-masked]>; Christopher Williams
<[email-masked]>
Cc: PKIX Mailing List <[email-masked]>
Sent: 11 April 2000 13:39
Subject: Re: Getting CA capabilities