RE: Certificate Exchange - Use Cases

Comment on draft-ediint-certificate-exchange-00.txt.

In part 2 of a comment submitted 10/19/2004, I interpreted these statements in 4.2.1 and 4.2.2 to mean that the receiver of a request or response message must accept the message if it is signed even if the receiver cannot validate the signing certifiate.
4.2.1 says
	If the receiver supports this use case, they MUST accept this message 
	regardless of the presence of a signature. 
and 4.2.2 says
	The initiator MUST accept this response, regardless of if it is signed.  

This puts a burden on the message receiver, and requires changes in the signature validation.  I now think that the burden should be on the message sender.  The sender should not sign a message if the sender knows that the receiver does not possess the signing certificate.  This can be implemented manually or with a simple status.  The sender can keep track of whether it has sent a signing certificate to each partneer and received an acceptance from that partner.  If not, don't sign the CEM message.  Senders may already keep track of which signing certificate each partner has accepted, so the sender knows whether to use the old or new certificate when switching.  Such senders just need a NO_CERTIFICATE value.  Senders who switch based solely on the RespondByDate will need a new status per partner, or could use manual or other means.

So I now propose to replace part 2 of my 10/19/2004 comment with the following:


4.2.1 says
	If the receiver supports this use case, they MUST accept this message 
	regardless of the presence of a signature. 
and 4.2.2 says
	The initiator MUST accept this response, regardless of if it is signed.  

I interpret these requirements to mean that the receiver of a Request/Response message must accept a signed message, even if the receiver cannot validate the signing certificate.  This puts a burden on the receiver, and requires the receiver to handle these messages in a special way during S/MIME processing.  It is better to put the burden on the sender, and require that senders do not sign messages if they know the receiver does not possess the sender's signing certificate.  This requirement should be stated in section 2.3.  

In the first paragraph of section 2.3, after this sentence

   After obtaining the desired certificate, the initiator of the 
   certificate exchange transmits the certificate in the CEM Request 
   message. 

insert
   If the initiator does not possess the receiver's signature 
   certificate, the initiator SHOULD NOT request a signed MDN. 

After the second paragraph of 2.3 insert

If the initiator does not have an established signing certificate 
for use with this partner, the initiator MUST NOT sign the CEM Request.  

A message sender has established a signing certificate for use 
with a receiver if the sender has previously sent the certificate 
to the receiver by some means and the receiver has indicated acceptance 
of that certificate.  For example, the certificate was sent in a 
previous CEM Request and either the receiver accepted it in a response 
or the RespondByDate of that request has passed.  There may be other 
means of establishing a signing certificate, including manual means.

--------end insert

The recipient might sign the Request's MDN or the Response, and the initiator may not yet possess any signing certificate of the recipient.  (Note that the AS2 specification permits the recipient to sign the MDN even if the initiator did not request a signed MDN.)  So the same requirements apply to the recipient when sending the Response message.  Add to the end of 2.3:


If the recipient does not have an established signing certificate for 
use with the initiator, then 1. the recipient MUST NOT sign the CEM Response,
and 2. if the initiator did not request a signed MDN, 
the recipient MUST NOT sign the MDN for the Request.  


Sections 4.2.1 and 4.2.2 should be modified as follows.  MUST and SHOULD are replaced by other words, and the requirements for sending signed messages are modified in accordance with the language above.

   4.2.1.  Step 1 
    
   Initiator creates an EDIINTCertificateExchangeRequest as described in 
   Section 2.0 Message Format and Section 3.0 XML Schema.  The initiator 
   sends it according to EDIINT-AS2 protocol.  The message is not signed,
   because the initiator does not have an established signing certificate
   for this partner.  Because the initiator does not
   possess the receiver's encryption certificate, encryption is not
   used.  Because the initiator does not possess the receiver's signature 
   certificate, the initiator does not request a signed MDN.  If the MDN is 
   not signed, there is no legal proof the receiver received the message.  
   The receiver accepts this message in accordance with AS2 protocol.  
   In addition, a positive MDN received during this step gives some 
   indication of successful transmission of the message, but does not 
   imply successful action on the certificate.  In the case of an 
   encryption certificate, the initiator must be immediately ready to 
   receive documents encrypted with the new certificate.  In the case of 
   a signing certificate, the initiator can begin signing documents with 
   the new certificate at the RespondByDate or upon receipt of an 
   EDIINTCertificateExchangeResponse from the partner indicating they 
   are ready. If an acceptance response is not received by the 
   RespondByDate, the initiator may or may not begin signing with the 
   new certificate, depending on the implementation's capabilities and 
   the policies of the initiator. 
    
   4.2.2.   Step 2 
    
   Receiver validates the EDIINTCertificateExchangeRequest message at 
   the AS2 level and returns an MDN according to the EDIINT-AS2 
   protocol.  Because the initiator did not request a signed MDN, and also
   because the receiver does not have an established signing certificate
   for the initiator, the MDN
   is not signed.  If the message is a proper AS2 document, the receiver 
   automatically accepts or rejects the new certificate(s), or requires 
   manual intervention.  Caution should be used in automatically 
   accepting the certificate, as it may be impossible to verify the 
   sender is authentic.  If the certificate is automatically accepted or 
   rejected, an EDIINTCertificateExchangeResponse is generated and 
   returned to the initiator.  Since the trading relationship could be 
   hindered if action is not taken prior to the RespondByDate, manual 
   intervention must be done before that date. When the manual 
   intervention determines to accept or reject the certificate, an 
   EDIINTCertificateExchangeResponse is generated and returned to 
   the initiator.  
    
   In both the automatic and manual case, the 
   EDIINTCertificateExchangeResponses are formatted according to 
   Section 2. Message Processing and Section 3. XML Schema Description 
   and sent according to EDIINT-AS2 protocol.  If the original CEM Request
   included the encryption certificate, or if the receiver has the 
   initiator encryption certificate on file, it may be used to encrypt 
   the AS2 message including the EDIINTCertificateExchangeResponse.  
   Otherwise, it may be necessary to send this 
   EDIINTCertificateExchangeResponse unencrypted.  The message is not 
   signed, because the receiver does not have an established signing
   certificate for the initiator.  
   The initiator accepts this response in accordance with AS2 protocol.
   A positive MDN received for the response message 
   indicates successful transmission of the response message. 

   After the receiver accepts the certificate and returns an acceptance 
   response, the receiver may encrypt messages to the initiator with the 
   encryption certificate.  The receiver begins to accept messages from 
   the initiator that are signed with the signing certificate.  The 
   initiator may start signing with the certificate when it receives the 
   acceptance response, or when it receives acceptance responses from 
   all its partners, or after the RespondByDate. 
    


-----Original Message-----
From: [email protected]
[mailto:[email protected]]
Sent: Tuesday, October 19, 2004 11:58 AM
To: IETF EDIINT WG (E-mail)
Subject: Certificate Exchange - Use Cases



Comment on draft-ediint-certificate-exchange-00.txt.

I have 2 comments on section 4.

1. The beginning of section 4 says that it is "only illustrative".  However, section 4 contains several uses of MUST and SHOULD, which are prescriptive words.  These words should be in lower case, to indicate that they are not stating additional requirements, or different language should be used.
2. Section 4.2 does state some requirements that were not stated earlier in section 2 or 3.  These requirements should be in section 2.  The requirements in 4.2 on accepting signed messages should be modified.

1.
In 4.1.1 Step 1, change
   In the case of an encryption certificate, the initiator MUST be 
   immediately ready to receive documents encrypted with the new 
   certificate. 
to
   In the case of an encryption certificate, the initiator is
   immediately ready to receive documents encrypted with the new 
   certificate. 

Change the first paragraph of 4.1.2 to
   Receiver validates the EDIINTCertificateExchangeRequest message at 
   the AS2 level and returns a correct MDN.  If the message is a proper 
   AS2 document, the receiver automatically accepts or rejects the 
   new certificate(s) or requires manual intervention. If the certificate 
   is automatically accepted or rejected, an 
   EDIINTCertificateExchangeResponse is generated and returned to 
   the initiator.  Since the trading relationship could be hindered if 
   action is not taken prior to the RespondByDate, manual intervention 
   must be done before that date. When the manual intervention 
   determines to accept or reject the new certificate, an 
   EDIINTCertificateExchangeResponse is generated and returned to 
   the initiator. Both automatic and manual 
   EDIINTCertificateExchangeResponses are formatted according to 
   Section 2. Message Processing and Section 3. XML Schema Description 
   and sent according to EDIINT-AS2 protocol.  A positive MDN received 
   for the response message indicates successful transmission of the 
   response message. 

2.
4.2.1 says
	If the receiver supports this use case, they MUST accept this message 
	regardless of the presence of a signature. 
and 4.2.2 says
	The initiator MUST accept this response, regardless of if it is signed.  

I interpret these requirements to mean that the receiver of a Request/Response message must accept a signed message, even if the receiver cannot validate the signing certificate.  This requirement should be stated in section 2.3.  

In the first paragraph of section 2.3, after this sentence

   After obtaining the desired certificate, the initiator of the 
   certificate exchange transmits the certificate in the CEM Request 
   message. 

insert
   If the initiator does not possess the receiver's signature 
   certificate, the initiator SHOULD NOT request a signed MDN. 

Change the first sentence of paragraph 3 of section 2.3 from

   Upon receipt of the CEM Request, the recipient trading partner 
   processes the transport message as normal and returns the MDN. 
to

   Upon receipt of the CEM Request, the recipient trading partner 
   processes the transport message as described below and returns the MDN. 

Add the following to the end of 2.3:

	If the initiator signs the CEM Request, the initiator SHOULD include the signing certificate in the signature.  If the recipient partner receives a signed CEM Request, but the recipient does not possess a currently valid signing certificate for the initiator, then the recipient partner may ignore the signature without processing it in any way, return a positive MDN if one is requested, and go on to process the Request.  However, it is RECOMMENDED that the recipient partner process the signature as much as possible, to detect possible corruption of the Request message, as follows.  If the signing certificate is in the signature, or if the recipient possesses the signing certificate, the recipient SHOULD verify that the digest of the message equals the digest in the signature.  If the signing certificate is issued by a CA Certificate that the recipient trusts, the recipient SHOULD verify 
 that the issuer did issue the signing certificate.  If either of these checks is done and!
  fails, the recipient MUST return a negative MDN.  If the recipient does not trust the signing certificate because the signing certificate or one of its issuers has been revoked or has expired or is explicitly not trusted, the recipient SHOULD return a negative MDN.  If the recipient already trusts the signing certificate or one of its issuers and all other tests pass, then the recipient MUST return a positive MDN.  If the recipient has no basis to either trust or not trust the signing certificate, then the recipient MUST return a positive MDN.  (This is contrary to the behavior for non-CEM messages, where the recipient returns a negative MDN if it cannot validate the trust of the signing certificate.)  In this case, the recipient SHOULD require manual intervention to accept the certificates in the Request.

The recipient returns a positive MDN even when it cannot validate trust of the signing certificate because this CEM Request may be the initial distribution of the signing certificate.  The recipient might not yet possess any certificates of the initiator or have any means to validate the signing certificate.  After the initial distribution, the initiator will normally sign the CEM Request with the existing signing certificate, which the recipient can validate.

The burden for the initial distribution is placed on the recipient, as in section 4.2.  The initiator can always send CEM Requests in the same way.

The recipient might sign the Request's MDN or the Response, and the initiator may not yet possess any signing certificate of the recipient.  (Note that the AS2 specification permits the recipient to sign the MDN even if the initiator did not request a signed MDN.)  So the same requirements apply to the initiator when processing the MDN or Response message.  Add to the end of 2.3, after the paragraph above:

	If the recipient signs the MDN for the CEM Request, the recipient SHOULD include the signing certificate in the signature.  If the initiator receives a signed MDN for the CEM Request, but the initiator does not possess a currently valid signing certificate for the recipient, then the initiator may ignore the signature without processing it in any way, and accept the MDN.  However, it is RECOMMENDED that the initiator process the signature as much as possible, to detect possible corruption of the MDN message, as follows.  If the signing certificate is in the signature, or if the initiator possesses the signing certificate, the initiator SHOULD verify that the digest of the message equals the digest in the signature.  If the signing certificate is issued by a CA Certificate that the initiator trusts, the initiator SHOULD verify that the issuer did issue the signing certificate.  If either
  of these checks is done and fails, the initiator MUST reject the MDN.  If the initiator !
 does not trust the signing certificate because the signing certificate or one of its issuers has been revoked or has expired or is explicitly not trusted, the initiator SHOULD reject the MDN.  The behavior when the initiator rejects the MDN is not defined.  If the initiator already trusts the signing certificate or one of its issuers and all other tests pass, then the initiator MUST accept the MDN.  If the initiator has no basis to either trust or not trust the signing certificate, then the initiator MUST accept the MDN.  (This is contrary to the behavior for non-CEM messages, where the initiator rejects a MDN if it cannot validate the trust of the signing certificate.)  

	If the recipient signs the CEM Response, the recipient SHOULD include the signing certificate in the signature.  If the initiator receives a signed CEM Response, but the initiator does not possess a currently valid signing certificate for the recipient, then the initiator may ignore the signature without processing it in any way, return a positive MDN if one is requested, and go on to process the Response.  However, it is RECOMMENDED that the initiator process the signature as much as possible, to detect possible corruption of the Response message, as follows.  If the signing certificate is in the signature, or if the initiator possesses the signing certificate, the initiator SHOULD verify that the digest of the message equals the digest in the signature.  If the signing certificate is issued by a CA Certificate that the initiator trusts, the initiator SHOULD verify that the issuer did 
 issue the signing certificate.  If either of these checks is done and fails, the initiato!
 r MUST return a negative MDN.  If the initiator does not trust the signing certificate because the signing certificate or one of its issuers has been revoked or has expired or is explicitly not trusted, the initiator SHOULD return a negative MDN.  If the initiator already trusts the signing certificate or one of its issuers and all other tests pass, then the initiator MUST return a positive MDN.  If the initiator has no basis to either trust or not trust the signing certificate, then the initiator MUST return a positive MDN.  (This is contrary to the behavior for non-CEM messages, where the initiator returns a negative MDN if it cannot validate the trust of the signing certificate.)  

Sections 4.2.1 and 4.2.2 should be modified as follows.  MUST and SHOULD are replaced by other words, and the requirements for accepting signed messages are modified in accordance with the language above.

   4.2.1.  Step 1 
    
   Initiator creates an EDIINTCertificateExchangeRequest as described in 
   Section 2.0 Message Format and Section 3.0 XML Schema.  The initiator 
   sends it according to EDIINT-AS2 protocol.  Using a digital signature 
   on the AS2 message is optional, as the receiver will not be able to 
   verify until after accepting the signature certificate.  The 
   receiver accepts this message in accordance with section 2.3.
   Unless the initiator 
   possesses the receiver's encryption certificate, encryption is not
   used.  Unless the initiator possesses the receiver's signature 
   certificate, the initiator does not request a signed MDN.  If the MDN is not 
   signed, there is no legal proof the receiver received the message.  
   In addition, a positive MDN received during this step gives some 
   indication of successful transmission of the message, but does not 
   imply successful action on the certificate.  In the case of an 
   encryption certificate, the initiator must be immediately ready to 
   receive documents encrypted with the new certificate.  In the case of 
   a signing certificate, the initiator can begin signing documents with 
   the new certificate at the RespondByDate or upon receipt of an 
   EDIINTCertificateExchangeResponse from the partner indicating they 
   are ready. If an acceptance response is not received by the 
   RespondByDate, the initiator may or may not begin signing with the 
   new certificate, depending on the implementation's capabilities and 
   the policies of the initiator. 
    
   4.2.2.   Step 2 
    
   Receiver validates the EDIINTCertificateExchangeRequest message at 
   the AS2 level and returns an MDN according to the EDIINT-AS2 
   protocol and section 2.3.  If the message is a proper AS2 document, the receiver 
   automatically accepts or rejects the new certificate(s), or requires 
   manual intervention.  Caution should be used in automatically 
   accepting the certificate, as it may be impossible to verify the 
   sender is authentic.  If the certificate is automatically accepted or 
   rejected, an EDIINTCertificateExchangeResponse is generated and 
   returned to the initiator.  Since the trading relationship could be 
   hindered if action is not taken prior to the RespondByDate, manual 
   intervention must be done before that date. When the manual 
   intervention determines to accept or reject the certificate, an 
   EDIINTCertificateExchangeResponse is generated and returned to 
   the initiator.  
    
   In both the automatic and manual case, the 
   EDIINTCertificateExchangeResponses are formatted according to 
   Section 2. Message Processing and Section 3. XML Schema Description 
   and sent according to EDIINT-AS2 protocol.  If the original CEM Request
   included the encryption certificate, or if the receiver has the 
   initiator encryption certificate on file, it may be used to encrypt 
   the AS2 message including the EDIINTCertificateExchangeResponse.  
   Otherwise, it may be necessary to send this 
   EDIINTCertificateExchangeResponse unencrypted.  The message may be 
   signed, but it is possible the initiator will have no way to verify 
   the signature.  The initiator accepts this response in accordance with section 2.3.
   A positive MDN received for the response message 
   indicates successful transmission of the response message.