RE: making a decision on CEM
"Richard Bigelow" <[email protected]> Mon, 13 Feb 2006 12:34:21 -0800
| Newsgroups | gmane.ietf.ediint |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. ------_=_NextPart_001_01C630DC.DF43CF7C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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) =20 <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. =20 <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. =20 <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. =20 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.) =20 Richard Bigelow Inovis [email protected] <mailto:[email protected]>=20 -- 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 ------_=_NextPart_001_01C630DC.DF43CF7C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:ns0=3D"urn:schemas-microsoft-com:office:smarttags"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:Batang; panose-1:2 3 6 0 0 1 1 1 1 1;} @font-face {font-family:"\@Batang"; panose-1:0 0 0 0 0 0 0 0 0 0;} @font-face {font-family:Verdana; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} p.Source, li.Source, div.Source {margin-top:0in; margin-right:-.75in; margin-bottom:0in; margin-left:.2in; margin-bottom:.0001pt; font-size:9.0pt; font-family:"Courier New";} span.EmailStyle18 {mso-style-type:personal; font-family:Arial; color:windowtext;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:Arial; color:navy;} p.RFCText, li.RFCText, div.RFCText {margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.3in; margin-bottom:.0001pt; line-height:12.0pt; font-size:12.0pt; font-family:"Courier New";} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </style> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>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)<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DRFCText><font size=3D3 color=3Dred face=3D"Courier New"><span style=3D'font-size:12.0pt;color:red'><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.></span></font> 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.<o:p></o:p></p> <p class=3DRFCText><font size=3D3 face=3D"Courier New"><span = style=3D'font-size:12.0pt'><o:p> </o:p></span></font></p> <p class=3DRFCText><font size=3D3 color=3Dred face=3D"Courier New"><span style=3D'font-size:12.0pt;color:red'><When a certificate is intended = for use in digital signatures or TLS/SSL client authentication, the initiator = MUST NOT use the certificate until></span></font> the recipient trading = partner generates a CEM Response accepting the certificate or <font = color=3Dred><span style=3D'color:red'><the respond by date></span></font>, 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.<o:p></o:p></p> <p class=3DRFCText><font size=3D3 face=3D"Courier New"><span = style=3D'font-size:12.0pt'><o:p> </o:p></span></font></p> <p class=3DRFCText><font size=3D3 color=3Dred face=3D"Courier New"><span style=3D'font-size:12.0pt;color:red'><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.> = </span></font>Revoking a certificate MUST be done outside of CEM.<o:p></o:p></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>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.)<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <div> <p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New = Roman"><span style=3D'font-size:12.0pt;color:navy'>Richard Bigelow<br> </span></font><ns0:Street w:insAuthor=3D"IPNet" = w:insDate=3D"2006-02-13T11:49:00Z" w:endInsAuthor=3D"IPNet" = w:endInsDate=3D"2006-02-13T11:49:00Z"><ns0:address w:insAuthor=3D"IPNet" w:insDate=3D"2006-02-13T11:49:00Z" = w:endInsAuthor=3D"IPNet" w:endInsDate=3D"2006-02-13T11:49:00Z"><font color=3Dnavy><span = style=3D'color:navy'>Inovis</span></font></ns0:address></ns0:Street><ns0:= Street w:insAuthor=3D"IPNet" w:insDate=3D"2006-02-13T11:49:00Z" = w:endInsAuthor=3D"IPNet" w:endInsDate=3D"2006-02-13T11:49:00Z"><ns0:address = w:insAuthor=3D"IPNet" w:insDate=3D"2006-02-13T11:49:00Z" w:endInsAuthor=3D"IPNet" w:endInsDate=3D"2006-02-13T11:49:00Z"><font color=3Dnavy><span = style=3D'color:navy'><br> </span></font></ns0:address></ns0:Street><font color=3Dnavy><span style=3D'color:navy'><a href=3D"mailto:[email protected]"><font = size=3D1 face=3DVerdana><span = style=3D'font-size:9.0pt;font-family:Verdana'>[email protected]<= /span></font></a></span></font><o:p></o:p></p> </div> </div> </body> </html> <BR> <P><FONT SIZE=3D2>--<BR> No virus found in this outgoing message.<BR> Checked by AVG Free Edition.<BR> Version: 7.1.375 / Virus Database: 267.15.4/255 - Release Date: = 2/9/2006<BR> </FONT> </P> ------_=_NextPart_001_01C630DC.DF43CF7C--