Subject: making a decision on CEM

From: "Kyle Meadors" <[email-masked]>
Date: Fri, 10 Feb 2006 11:41:27 -0600

We have been discussing CEM since the first of December so I believe it is
time to make a decision and go forward on it. 6 individuals have weighted in
favor the EDIINT–Features header/Version: 1.2 with a 2 individuals opposed.
From the last DGI interop test, we have 6 companies who did not comment in
this discussion have indicated they are in favor of the EDIINT–Features
header. Given the numbers, I think we have our decision.

CEM is not perfect – AS2 architecture does not allow for true profile
negotiation like ebXML allows – but it can work adequately and is needed.
ecGIF user community is strongly pushing its vendors for support of this.

I can update CEM and EDIINT–Features drafts next week and submit to this
group for review. The comment from Richard Bigelow on a EDIINT–Features only
message for updating your feature lists and sent only to 1.2 trading
partners drew some agreement so I can add that and also clarify the start–up
situation which CEM does not adequately deal with. Any other ideas/language
needed?

Kyle Meadors

Principal, Test Process

Drummond Group Inc.

615.212.0826

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.15.4/255 - Release Date: 2/9/2006

---

From: "Richard Bigelow" <[email-masked]>
Date: Mon, 13 Feb 2006 12:34:21 -0800

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
Inovis
[email-masked] <mailto:[email-masked]>