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: owner-ietf-ediint@xxxxxxxxxxxx
[mailto:owner-ietf-ediint@xxxxxxxxxxxx]
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.
|
