Subject: FW: draft-ediint-certificate-exchange-00

From: "Scott Hollenbeck" <[email-masked]>
Date: Mon, 4 Oct 2004 12:43:05 -0400

WG members:

Some follow-up on my own notes from a week or so ago.  One of the security
area directors also has questions about the ediint-certificate-exchange I-D.
Would anyone care to respond to Russ' comment about PKIX overlap?

-Scott-

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Wednesday, September 29, 2004 9:43 AM
Subject: draft-ediint-certificate-exchange-00

The Abstract of this document says: "... EDIINT Certificate Exchange 
Messaging provides the format and means to effectively exchange 
certificates for use within trading partner relationships. ..."

This seems to overlap with the charter of PKIX WG, and I do not think that 
an additional mechanism for certificate distribution is desirable.

Can someone provide background that would make me fee comfortable about 
this work?

Russ

---

From: "Kyle Meadors" <[email-masked]>
Date: Wed, 13 Oct 2004 15:53:45 -0500

This is from Dale Moberg, co-author of the CEM draft.

In reply to:

"Some follow-up on my own notes from a week or so ago.  One of the security
area directors also has questions about the ediint-certificate-exchange I-D.

"Would anyone care to respond to Russ' comment about PKIX overlap? 
 -Scott-

"The Abstract of this document says: "... EDIINT Certificate Exchange
Messaging provides the format and means to effectively exchange certificates
for use within trading partner relationships. ..."

"This seems to overlap with the charter of PKIX WG, and I do not think that
an additional mechanism for certificate distribution is desirable.

===

Here is some context that should indicate how ediint-certificate-exchange
differs from the PKIX CMP and related initiatives.

===

Here is my understanding of EDIINT conventions and requirements and its
relation to CMP.

This is from a developer's perspective but also from one who helped users
formulate the draft in EDIINT about certificate exchange.

While it is not mentioned in the initial draft, it probably should be
recommended that applications support the use of CMP to interact with their
CA/RA, at least to get certificates.

Users said in effect that CMP was too complicated and was not how it was
being done in practice-- they wanted to use EDIINT messages to send their
new certificates directly to their trading partners. Leaving it to partners
to check for expired certificates and try to find the new ones was not
feasible.

Unfortunately existing practice for peer to peer publication of updated
certificates was variable, and frequently interoperability problems arose.

As a matter of custom/convention, EDIINT applications mail/transfer their
certificates to the corresponding application that then decide whether to
trust the certificates that are received based on the local policy.

Quite commonly, the certificates are self-signed, version 3 certificates,
sometimes using a dual key model (key exchange and signing). 

So the message flow is peer to peer, with each side responsible for
"pushing" its certificate to the other side. Obtaining certs/crls from a CA
is not something that is expected or widely supported.  

I don't think this peer to peer message pattern is present in CMP although
some of the message bodies might be adapted for this purpose.

One very large retail user realized that it would need to reissue
certificates to well over 10,000 trading partners and wanted a lightweight
interoperable protocol to solve this problem. 

They wanted to send out the certificates at their discretion. I am uncertain
that their CA/RA even supports CMP.

The EAN.UCC Business Message Standards - Global Standards Management Process
(GSMP)-- organized the requirements collection and draft preparation.

They wanted XML requests and responses that simply asked the peer to begin
trust of the enclosed certificate. It can be signed over using a CMS
detached signature if trust is already in place, just as with ordinary
EDIINT messages.

Also, users wanted a provision for attaching, in the future, a profile that
stated how they expected the EDIINT protocol to occur (that is, the specific
features and capabilities that were to be used).

So the requirements--simplicity, XML based messages, reuse of EDIINT message
patterns, provision for extension to profiles--did not cleanly match CMP.
The main difference to my mind is that CMP assumes a peer to RA/CA
interaction. EDIINT assumes, more or less, that you are mailing/POSTing an
attachment to a peer. 

It would be difficult, if not impossible, to prohibit this mechanism for
sending certificates peer to peer. Attachments with certificates are
something MIME allows, and MIME supporting transfer protocols, SMTP HTTP
etc, allow distributing certificates in this manner.

The draft only standardizes this practice so that it can become more
interoperable by setting down an EDIINT "way" to send certificates to
trading partners. 

Dale Moberg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Scott Hollenbeck
Sent: Monday, October 04, 2004 11:43 AM
To: [email-masked]
Cc: 'Russ Housley'
Subject: FW: draft-ediint-certificate-exchange-00

WG members:

-Scott-

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Wednesday, September 29, 2004 9:43 AM
Subject: draft-ediint-certificate-exchange-00

Russ

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.769 / Virus Database: 516 - Release Date: 9/24/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.775 / Virus Database: 522 - Release Date: 10/8/2004