RE: PKCS#7 in PKIX-3

[Carlisle Adams <Cadams@xxxxxxxxxxx>]

Hi Warwick,

>----------
>From: 	wford@verisign.com[SMTP:wford@verisign.com]
>Sent: 	Friday, January 31, 1997 7:57 PM
>To: 	ietf-pkix@tandem.com
>Subject: 	Re: PKCS#7 in PKIX-3
>
>From observation of many prior standardization activities, I suggest that
>solutions built by incrementally advancing existing, accepted,
>well-understood solutions have been far more successful than attempts to
>define something totally new, even if the latter was technically superior.
>
>I believe this same feeling was supported by strong concensus in the San
>Jose PKIX meeting.  If PKCS#7 satisfies requirements for many people, and
>some incremental extensions to PKCS#7 would satisfy requirements for
>everyone, then this is clearly far more likely to be accepted as a standard
>than a totally new invention such as the proposal in the December I-D.

I agree with this reasoning.  However, I would argue that PKCS#7 does
*not* "satisfy requirements for many people", within the PKIX-3
environment, because initialization (for example) cannot be done using
PKCS#7 in its current form.  It does not make sense to *mandate* a
protection mechanism which does not even allow you to get *started* in
this protocol.  What you need to do is to mandate something which *will*
work, and optionally allow anything else to be used wherever it can be
used.  This is what PKIX-3, as currently defined, already does.

Why do I think that PKCS#7 will not work for initialization?  Let me
dredge up an old posting:

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.

As I have said to Peter (just posted), I'm certainly willing to migrate
to PKCS#7 as "the" PKIX-3 protection mechanism once it has evolved to
the point where these issues are solved.  But since we don't know how
long a process that might be it seems pointless to hold up progression
of PKIX-3 indefinitely (especially since it already does what we want,
including allowing PKCS#7, as is, wherever this can be used!).

>
>
>I would appreciate hearing opinions from other members of the list.

So would I.
>
--------------------------------------
Carlisle Adams
Entrust Technologies
cadams@entrust.com
---------------------------------------
>