Subject: Certificate Exchange - Use Cases

From: "Richard Bigelow" <[email-masked]>
Date: Tue, 19 Oct 2004 14:58:07 -0400

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.