I don't believe that even if we disallowed other certificate types I
would want to change the proposal. The reason for this is so that we
can get other means of identification into the system. As an example:
If I am sending an enrollment message to a RA which has previously
issued me a name and token. I need to put my name someplace so that it
can look up my token and do the correct things to get a common
encryption key. The correct place to put this identification
information would be in the recipientId structure. This requires the
ability to put in a non X509 identification field. Thus I think my
proposal stands as is.
-----Original Message-----
From: jsp(_at_)jgvandyke(_dot_)com [mailto:jsp(_at_)jgvandyke(_dot_)com]
Sent: Tuesday, December 30, 1997 12:21 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Incorporate some PKCS#7 V2.0 items into CMS
All,
IMHO, CMS should be algorithm independent. If changes are required to
support HMAC (as stated by Jim), then those changes should be considered
for
incorporation into CMS. We should also consider Jim's proposed changes
related to supporting key agreement algorithms such as the derived
password
keys in PKCS#12.
However, I don't believe that we should change CMS to accommodate
non-X.509
certificates. I believe that the S/MIME community has agreed that the
X.509
Certificate syntax will be the standard format for binding an entity's
public key with its identity. Allowing other forms of certificates to
be
used will adversely impact interoperability. I believe that Jim should
re-submit his proposal such that it does not include any changes solely
aimed at accommodating non-X.509 certificates.
One could make the argument that CMS is intended for use by application
environments other than S/MIME some of which may choose to use a format
other than the X.509 Certificate syntax. In that case, it may be
appropriate to make Jim's recommended changes to the CMS format, but to
include text in the S/MIME v3 Message and Cert specs stating that only
X.509
Certificates can be used in S/MIME messages.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================