All,
The 28 Jan 98 S/MIME v3 Certificate Handling I-D, Sec 5 specifies
certificate request and response protocols which are redundant to those
specified as part of the PKIX Working Group Certificate Management Protocol
(CMP). Sec 5.2 specifies the use of SignedData encapsulating a CRMF object.
The CRMF object is harmonized with the PKIX WG, but the Service Indicators
described in Sec 5.2.1.2 and 5.2.1.3 are redundant to the information
contained in the PKIX CMP PKIHeader. Furthermore, Sec 5.6 specifies the use
of a degenerate signedData object as the S/MIME-mandatory response protocol.
This protocol is redundant to the CMP PKIHeader and certRepContent.
The IETF PKIX working group is developing a "harmonized",
application-independent, IETF standard set of cert mgmt protocols (see Dec
97 PKIX WG minutes). IMHO, if the S/MIME Certs I-D mandates any cert mgmt
protocols, then those protocols should be the "harmonized",
application-independent IETF standard protocols. If the S/MIME WG wishes
the Certs I-D to go to last call before the IETF "harmonized" protocols are
complete, then I recommend that all text should be removed from the Certs
I-D that mandates cert mgmt protocols. Once the "harmonized" IETF standard
protocols are completed, then a separate S/MIME WG spec could be drafted
which specifies the use of MIME to communicate CMS-protected "harmonized"
cert mgmt protocol messages.
I believe that it would be a mistake for the Certs I-D to mandate
S/MIME-specific cert mgmt protocols (including the degenerate signedData).
I believe that there are a significant number of organizations that would
like to build a common cert mgmt module (CCMM) that can serve all of the
various apps running on a workstation (see below). I believe that an IETF
standard cert mgmt protocol would make it much easier to develop a standard
CCMM API since the data exchanged between the CCMM and the various apps
would be consistently formatted. I would hate to see vendors have to
implement multiple cert mgmt protocols which is the path that we are on if
we mandate degenerate signedData in the Certs I-D and PKIX CMP mandates a
different cert response syntax.
I am not opposed to the adoption of degenerate signedData as the IETF
standard cert response protocol. If degenerate signedData becomes the IETF
standard, then inclusion of that protocol in the S/MIME Certs I-D would be
fine by me.
Consider the following SW modules that could be present (probably not all
simultaneously) on a workstation:
------------ ----------- ------------ ---------
| S/MIME app | | X.400 app | | S-HTTP app | | XYZ app |
| w/CMS | | | | | | NON CMS |
------------ ----------- ------------ ---------
| | | |
-----------------------------------------------
|
Common API
--------------
| Commom Cert |
| Mgmt Module: |
| implements |
| standard |
| PKI protocols|
--------------
|
---------------
| |
--------------- -----------------
|Common database| |Crypto module to |
|of certs, CRLs | |generate keys,etc|
--------------- -----------------
If the IETF defined a common, application-independent cert mgmt protocol,
then implementors could develop a Common Cert Mgmt Module (CCMM) managing a
common database of certs that could be used by multiple apps running on the
workstation. For example, when a user using an application with S/MIME
capabilities needs to generate a new key pair, the CCMM would generate the
keys and build a CRMF object that would then be passed to the S/MIME app
which would protect it within a signedData object for mailing to the CA. As
another example, when a XYZ user without CMS capabilities needs to generate
a new key pair, the CCMM would generate the keys and build a CRMF object
that would then be passed to the XYZ app which would protect it using the
XYZ security heading and transfer it to the CA. This strategy allows the
CCMM to have a common interface to all app environments. It also allows the
CA cert mgmt module to be shared by multiple apps (i.e. the same cert mgmt
object can be communicated via S/MIME, XYZ, etc).
I believe that the same strategy should apply to the cert response object.
For example, the S/MIME app receives a cert response object encapsulated in
a signedData object from the CA. The S/MIME app verifies the signedData
object and then passes the encapsulated cert response object to the CCMM
which then adds the new cert(s) to the common database of certs and performs
related management functions. As another example, a XYZ app receives a cert
response encapsulated in a XYZ security header from the CA. The XYZ app
verifies the XYZ object and then passes the encapsulated cert response
object to the CCMM which then adds the new cert(s) to the common database of
certs and performs related management functions. This strategy allows the
CCM module to have a common interface to all app environments.
This strategy could also be implemented for other types of messages such as
those described in the PKIX CMP I-D.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================