Subject: Establishing POP capabilities

From: "Christopher Williams" <[email-masked]>
Date: Fri, 31 Mar 2000 10:07:14 +0100

There does not currently seem to be any way for a client to establish which
POP modes are supported which could cause problems.  For example, I may have
developed client software that seeks to establish POP of an encryption key
by engaging in the challenge-response.  However, the authors of the server
software have quite reasonably decided not to implement this means of POP
(as there are better methods available) but the client software has no means
of finding this out, the certification request will fail as POP cannot be
established and the server can only indicate the error by means of an
ambiguous "badPOP" error code.

The POP modes supported by a server could be established in a general
message, something like the following:

{ SupportedPOPModes = {id-it 16}, SEQUENCE OF ObjectIdentifier }

The parameters would be an OID for each POP mode supported; the modes might
be numbered as follows:

RAVerified = {id-pkix-pop 1}
SKPOP = {id-pkix-pop 2}
EKPOPThisMessage = {id-pkix-pop 3}
EKPOPEncryptedCert = {id-pkix-pop 4}
EKPOPChallengeResp = {id-pkix-pop 5}
KAKPOPThisMessage = {id-pkix-pop 6}
KAKPOPThisMessageDHMac = {id-pkix-pop 7}
KAKPOPEncryptedCert = {id-pkix-pop 8}
KAKPOPChallengeResp = {id-pkix-pop 9}

where {id-pkix-pop} = {id-pkix n} = {1 3 6 1 5 5 7 n}

Alternatively, the supported modes could be returned as bits in a BIT
STRING.  Another possibility is to establish the preferred modes for an
encryption key and a key agreement key.

What do people think?

Chris Williams,
NetLexis Ltd.

---

From: Carlisle Adams <[email-masked]>
Date: Fri, 31 Mar 2000 10:26:32 -0500

Hi Chris,

This may be a fair observation, but I honestly don't think that there's
quite the potential for problems that you're envisioning.  If we go through
the choices carefully, I think you'll see what I mean (and you can correct
me if I'm mistaken).

> RAVerified = {id-pkix-pop 1}
 
This one is not an end entity decision; the RA uses this if and only if it
has verified POP before forwarding the request on to the CA.  There's no
ambiguity here.

> SKPOP = {id-pkix-pop 2}
 
Again, no real ambiguity.  If you've got a signing key, use this method.

> EKPOPThisMessage = {id-pkix-pop 3}
 
For the "thisMessage" choice, there's no ambiguity here either.  It is an
end entity decision whether or not to give up its private key to the CA/RA
and, having received the key, how can the CA/RA possibly say it doesn't
support this?

> KAKPOPThisMessage = {id-pkix-pop 6}
 
(Same comment as for EKPOPThisMessage above.)

> KAKPOPThisMessageDHMac = {id-pkix-pop 7}
 
The EE can only use this method if (1) the CA has a DH cert available for
this purpose, and (2) the EE already has this cert.  Given that the CA has
such a cert, it can't claim that it doesn't support this method.  No
ambiguity.

> KAKPOPChallengeResp = {id-pkix-pop 9}
The only things left are the choice between EncryptedCert and
ChallengeResponse for EK and KAK.  Recall, however, that the EE picks one of
these (in the subsequentMessage field) in the request message.  The EE is
not doing POP at this point; it's simply saying which method it wants to
use.  Therefore, if the CA/RA comes back with a "badPOP" error, I would
contend that there is, again, no ambiguity.  The EE can simply re-request
with the other POP method chosen in subsequentMessage.

Note, however, that the spec encourages use of the EncryptedCert choice and,
furthermore, says that the challenge-response choice would typically be used
when an RA is involved and doing POP verification.  Therefore, I think that
the EE should be able to make an intelligent decision regarding what POP
method to choose in the request message.

Carlisle.

> ----------
> From: 	Christopher Williams[SMTP:[email-masked]]
> Sent: 	Friday, March 31, 2000 4:07 AM
> To: 	PKIX Mailing List
> Subject: 	Establishing POP capabilities
>