|
In CEM, I suggest distinguishing between
the protocol for certificate exchange and the specific CEM message structure
and protocols. In CEM draft 2 of 8/8/05, section 2.4 Certificate
Implementation describes requirements on the initiator and recipient of CEM
messages. Paragraphs 2-4 say (<>s added) <When a certificate is intended for use
in data encryption or TLS/SSL server authentication, the initiator MUST
consider the certificate to be Accepted and be prepared for its trading partner
to begin using the certificate upon generating the CEM Request message.>
After a recipient generates a positive CEM Response message for a certificate,
the recipient MUST immediately begin using the certificate in trading with the
initiator of the request. The recipient MAY apply encryption to the CEM
Response message using the new Accepted certificate or MAY apply encryption to
the CEM Response message using the previously Accepted encryption certificate. <When a certificate is intended for use
in digital signatures or TLS/SSL client authentication, the initiator MUST NOT
use the certificate until> the recipient trading partner
generates a CEM Response accepting the certificate or <the respond by date>, which is listed in
the RespondByDate XML element. The initiator MAY use the certificate after the
respond by date, regardless of whether the partner has accepted it or not. The
certificate used for the digital signature of the CEM Request message MUST be
the one which is currently Accepted within the trading partner relationship. <Since implementers of EDIINT often use
the same certificate with multiple trading partners, implementers of CEM MUST
be able to keep both the old and new certificates as Accepted. If the initiator
has generated a CEM Request and exchanged a new encryption certificate to
multiple trading partners, it MUST be able to accept encrypted data which uses
either the older, existing encryption certificate or the newly exchanged
encryption certificate. Likewise, a recipient of a CEM Request MUST be able to
authenticate digital signatures using either the new or old certificates, since
the initiator may not be able to switch certificates until all trading partners
accept the new certificate. Similar provisions MUST be made for certificates
intended for TLS/SSL server and client authentication.> Revoking
a certificate MUST be done outside of CEM. These requirements (particularly the parts
in red and <>s above) can apply to any certificate exchange protocol, not
just to CEM. That is, regardless of how the certificates are exchanged,
the same requirements apply to when the certificates are put in use and to
acceptance of both old and new certificates. There is value in describing
these exchange requirements as a protocol, distinct from the CEM message
structure and request/response protocol. CEM is then an implementation of
the exchange protocol. Describing the exchange protocol separately might
be valuable to people who use certificates in non-ASn protocols or who do not yet
have or do not want to use CEM. (For instance, one company has an
elaborate procedure for coordinating changes at both systems so both sides
change certificates at the same time. This should not be necessary.
I want to lead people away from such procedures, even if they retain manual
methods. CEM would go further and allow automated implementations of the exchange
protocol.) Richard Bigelow -- |