updated Section 5.1.1 on transactionID handling and Section 5.1.3.4 o…

…n content of KemOtherInfo

draft-ietf-lamps-rfc4210bis.md

@@ -1453,7 +1453,7 @@ transaction.  This is needed for all transactions that consist of
 more than just a single request/response pair.  For transactions that
 consist of a single request/response pair, the rules are as follows.
 A client MUST populate the transactionID field if the message
-contains an infoValue of type KemCiphertextInfo. In all other cases
+contains an infoValue of type KemCiphertextInfo, see {{sect-5.1.3.4}}. In all other cases
 the client MAY populate the transactionID field of the request.  If a
 server receives such a request that has the transactionID field set,
 then it MUST set the transactionID field of the response to the same
@@ -1462,9 +1462,6 @@ transactionID field, then it MUST populate the transactionID field if
 the message contains a KemCiphertextInfo field. In all other cases
 the server MAY set transactionID field of the response.
 
-Note: With KEM-based message protection the transactionID is used to
-ensure domain-separation of the derived shared secret key, see {{sect-5.1.3.4}}.
-
 For transactions that consist of more than just a single
 request/response pair, the rules are as follows.  Clients SHOULD
 generate a transactionID for the first request.  If a server receives
@@ -1872,7 +1869,6 @@ This approach employs the conventions of using a KDF as described in {{I-D.ietf-
     KemOtherInfo ::= SEQUENCE {
       staticString      PKIFreeText,
       transactionID     OCTET STRING,
-      pk                BIT STRING,
       ct                OCTET STRING
     }
   ~~~~
@@ -1881,9 +1877,7 @@ This approach employs the conventions of using a KDF as described in {{I-D.ietf-
 
   transactionID MUST be the values from the message containing the ciphertext ct in KemCiphertextInfo.
 
-  Note: For all PKI management operations with more than one exchange the transactionID MUST be set anyway.  In case of Bob provided a infoValue of type KemCiphertextInfo to Alice in the initial request message, see {{KEM-Flow2}} of {{sect-e}}, the transactionID MUST be used by Bob to ensure domain-separation between different PKI management operations.
-
-  pk MUST be the authentic public KEM key of Alice.
+  Note: The transactionID is used to ensure domain-separation of the derived shared secret key between different PKI management operations. For all PKI management operations with more than one exchange the transactionID MUST be set anyway, see {{sect-5.1.1}}.  In case of Bob provided a infoValue of type KemCiphertextInfo to Alice in the initial request message, see {{KEM-Flow2}} of {{sect-e}}, the transactionID MUST be set by Bob.
 
   ct is the ciphertext from KemCiphertextInfo.