PKIX-3 San Jose Discussions...

[Carlisle Adams <Cadams@xxxxxxxxxxx>]

Hi All,

At the San Jose meeting, there was some discussion about the
"proper" relationship between the PKCS series (mainly 7 and
10) and PKIX part 3.

There were two suggestions mooted, which should be 
treated *independently*. The purpose of this mail is to
start the discussion so that we reach consensus on the
two issues. (So if lots of discussion ensues, please 
indicate in the subject line which issue you're addressing).

Before looking at the details it's probably worth stating
that at the S/MIME BOF in San Jose, RSADSI indicated a 
willingness to allow the PKCS series to be recast as
informational RFCs which should remove whatever procedural
problems might otherwise exist.

One proposal which was supported at the meeting was
the requirement contained within the current draft that
proof-of-possession is mandatory where applicable. This means
that proof-of-possession is part of the profile and not
a policy issue. (This has some bearing on the PKCS10 issue.)


1. Use of PKCS7 to protect PKIMessages

The suggestion here is to drop the PKIProtection bit string
and related fields and to call for PKIMessages to be protected
using PKCS7 when required. The idea is to wrap the PKIHeader and
PKIContent as a PKCS7 contentInfo type which contains the signature
(or whatever) which protects the PKIMessage.

It initially appeared that PKCS7, with some modifications, can support 
the various options which we need for protection of PKIMessages 
(i.e. signatures, DH protection, MACs).

This proposal seemed to be supported in a straw-poll in San Jose, which
at the time we were happy with. However, whilst at first sight this 
seems to offer an attractive option to re-use existing technology, 
there are some problems which appear to require modification of any 
existing PKCS7 implementation (see below). 

This means existing applications (e.g., S/MIME user agents) can't be 
used to protect all PKI messages, which, in turn, means the deployed 
base would have to be modified in either case.

So we've changed our minds on this one, and would now propose 
sticking with the protection fields in the current draft.


2. Catering for PKCS10 certification requests

The point here is that there are a lot of existing end-entity
implementations which produce PKCS10 certification requests.
We would like to (and maybe need to?) provide a way for
such end-entity implementations to be able to work within
the internet PKI which we're all developing in this working group.

(Note: it's important to be clear about what PKCS10 supports -
*please* read the PKIX part 3 draft and PKCS10 spec. before getting 
involved in commenting on this one.)

The proposal is to add a new PKIContent type which is a PKCS10
certification request. This is actually already done within
the NIST MISPC document, so you can look there for details of
how to do it. (Actually, we intend cogging their text if the proposal
is accepted and Tim lets us :-)

Some details of how to fit a PKCS10 request into the PKIX part 3
exchanges is still TBD (e.g., we'd need to specify exactly which
header fields should be used, and how they relate to attributes
which may (or may not) be included within the PKCS10 request).

Our sense of the opinion at the meeting was that there was some
support for including PKCS10, but that there wasn't agreement on
how to position it in the document. The choices seemed to be:

	- PKCS10 is included as a "legacy" format which we 
	  discourage end-entity implementors from using and which 
	  in any case is only to be used in requests for certification 
	  of RSA signature key pairs;
	- PKCS10 is included as a "live" format -- possibly instead
          of the existing PKIX-3 format -- in which case we have to 
	  extend and profile it to cater for the remaining 
          proof-of-possession cases (difficult (impossible?) for 
          key pairs which can be used for encryption only);
	- somewhere in between, in which case we discourage its use 
          but profile PKCS10 for use with, e.g., D-H keys as well as
          RSA signature keys.

Our preference is for the first choice. Some arguments are included
below.

Regards,
Stephen and Carlisle.

PKCS7 pros & cons.

1. (Minor pro):  
Using PKCS7 allows for re-use of some existing code (but not as much 
as one would initially expect (which is why the pro is only "minor");
see the following three points). 

2. (con):        
PKCS7 isn't well suited for cases in which one protects a message before
getting allocated a name/certificate.  This is important for
initialization 
and for key recovery, where the end-entity may not know anything about
itself
or its environment prior to the exchange with the CA/RA.  Thus, the
mandatory field IssuerAndSerialNumber in SignerInfo (which is used to
identify the signer's certificate) will require a new (and very liberal)
interpretation in this context, meaning that existing implementations
would
have to be modified to deal with this situation.

3. (con):
It is not at all clear how to use the PKCS7 spec. to do a MAC on a 
message.  "Digesting" seems to apply to hashing only, and MACing does
not appear to fit very well in the SignedData construct.  Given that
MACing is important for some operations (again, initialization and
key recovery come to mind, in which the messages may be protected by
a MAC based on secret out-of-band information), further specification
or profiling of PKCS7 would be necessary before it could be used 
within PKIX-3.

4. (con):
Using D-H to calculate the signature bits for a PKCS7 signedData is 
quite different from using RSA to sign (i.e., although it is quite
possible to force the results into the same syntax, the semantics of
the "encryptedDigest" field of the SignerInfo construct is entirely
changed, resulting in a significant modification to existing PKCS7
implementations).  Thus, for example, an existing S/MIME user agent
will be very unlikely to produce the desired result.

5. (Minor con):
The protection scheme in the draft requires us to profile 2 fields;
using PKCS7 would mean having to profile ~12 fields (or wait on
someone else to produce such a profile).

6. (Minor con):  
Using PKCS7 makes PKIX-3 less self-contained and really relies on the
PKCS documents coming within the IETF (in terms of change-control).
While we have some fairly high assurance that this *will* happen, it is
worth noting that it hasn't *actually* happened yet.


Arguments for our PKCS10 position:

1. (strong):
A single message can never be used to prove possession of an RSA 
decryption-only private key. PKCS10 is a kind of "fire-and-forget"
scheme,
whereas PKIX-3 defines exchanges which do allow for the above proof.  
Therefore, PKCS10 is fine for some cert. requests but will definitely
not 
work for others; PKIX-3 defines a set of exchanges which can be used for
all cert. requests.

2. (strong):
The deployed base only issues PKCS10 requests for a limited set of 
algorithms.  PKIX-3 has no such limitations.

3. (medium):
A non-trivial specification effort is required in order to allow PKCS10
to cover a wider range of cert. request cases (see, for example, the 
proposal for doing a D-H cert. request using PKCS10).  This does little 
more than repeat the work already done to arrive at the current PKIX-3 
draft and, at any rate, still does not cover all cases.

4. (medium):
The effort required to change a PKCS10 implementation to cater for 
a wider range of cases is about the same as implementing the messages
in the current draft (i.e., the code reuse argument begins to look a
bit thin..).


In short, we see fairly little benefit to including either PKCS7 or 
PKCS10 in PKIX-3 (due to the need for a non-trivial amount of
specification 
work from the PKIX group, coupled with a less-than-expected amount of
code reuse).
Since PKCS10 is useful "as-is" for some certification requests, however,
we see no problem in including it as a message type for those purposes
(but recommending migration to the more general/flexible FullCertRequest
exchanges as soon as possible).  The advantage of PKCS7 is even less
clear
(due to the difficulty with unknown DNs and the need for further
specification
on how to do MACing), and our real preference is to stick with the very
simple
and flexible ProtectionBits, as defined in the current draft.

Comments are appreciated (and hereby solicited) on any of the above
points.
[Recall that our goal (as stated at San Jose) is to get a revised draft
out
and into working group last call by January...]

--------------------------------------
Carlisle Adams
Nortel Secure Networks
cadams@entrust.com
---------------------------------------
>