diff --git a/draft-ietf-lamps-rfc4210bis.html b/draft-ietf-lamps-rfc4210bis.html index 6f41aac..e6f75d0 100644 --- a/draft-ietf-lamps-rfc4210bis.html +++ b/draft-ietf-lamps-rfc4210bis.html @@ -3517,33 +3517,45 @@
KemOtherInfo ::= SEQUENCE { staticString PKIFreeText, transactionID [0] OCTET STRING OPTIONAL, - senderNonce [1] OCTET STRING OPTIONAL, - recipNonce [2] OCTET STRING OPTIONAL, - len INTEGER (1..MAX), - mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} - ct OCTET STRING }

staticString MUST be "CMP-KEM".

-transactionID, senderNonce, and recipNonce MUST be the values from the message containing the ciphertext ct in KemCiphertextInfo, if present.

+transactionID MUST be the values from the message containing the ciphertext ct in KemCiphertextInfo, if present.

-len MUST be the value from KemBMParameter.

-

-mac MUST be the MAC algorithm identifier used for MAC-based protection of the message and MUST be the value from KemBMParameter.

-

-ct MUST be the ciphertext from KemCiphertextInfo.

+For all PKI management operations with more than one exchange the transactionID MUST be set, see Section 5.1.1. This is the typical situation when KEM-based message protection is used. Figure 4 of Appendix E describes the exceptional case where only one message exchange may be sufficient. In this case, the transactionID SHOULD be used by Bob to ensure domain-separation between different PKI management operations.

-
  • -

    OKM is the output keying material of the KDF used for MAC-based message protection of length len and is called ssk in this document.

    + +

    [ToDo: The fields senderNonce, ReciepNonce, len, mac, and ct were removed from the KemOtherInfo sequence. The authors are waiting for experts reviews providing guidance if theses fields are necessary for the security of the KEM-bases message protection.

    +

    Text from -V07

    +

    ~~~~ asn.1 + KemOtherInfo ::= SEQUENCE { + staticString PKIFreeText, + transactionID [0] OCTET STRING OPTIONAL, + senderNonce [1] OCTET STRING OPTIONAL, + recipNonce [2] OCTET STRING OPTIONAL, + len INTEGER (1..MAX), + mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} + ct OCTET STRING + } + ~~~~

    +

    staticString MUST be "CMP-KEM".

    +

    transactionID, senderNonce, and recipNonce MUST be the values from the message containing the ciphertext ct in KemCiphertextInfo, if present.

    +

    len MUST be the value from KemBMParameter.

    +

    mac MUST be the MAC algorithm identifier used for MAC-based protection of the message and MUST be the value from KemBMParameter.

    +

    ct MUST be the ciphertext from KemCiphertextInfo.

    +

    End of ToDo]

    + -

    There are various ways how Alice can request and Bob can provide the KEM ciphertext, see Appendix E for details. The KemCiphertextInfo can be requested using a genm message with an InfoTypeAndValue structure of type id-it-KemCiphertextInfo where the value is absent and can be provided in the following genp message with an InfoTypeAndValue structure of the same type. +

    There are various ways how Alice can request and Bob can provide the KEM ciphertext, see Appendix E for details. The KemCiphertextInfo can be requested using a genm message with an InfoTypeAndValue structure of type id-it-KemCiphertextInfo where the value is absent and can be provided in the following genp message with an InfoTypeAndValue structure of the same type. Alternatively, the generalInfo field of the header of a PKIMessage can be used to request and provide a KemCiphertextInfo structure, also using an InfoTypeAndValue structure of type id-it-KemCiphertextInfo in each direction. -The procedure works also without Alice explicitly requesting the KEM ciphertext, in case that Bob knows beforehand a KEM key of Alice and can expect that she is ready to use it.

    -

    If both the initiator and responder in a PKI management operation have KEM key pairs, this procedure can be applied by both entities independently, establishing and using different shared secret keys on either side.

    +The procedure works also without Alice explicitly requesting the KEM ciphertext, in case that Bob knows beforehand a KEM key of Alice and can expect that she is ready to use it.

    +

    If both the initiator and responder in a PKI management operation have KEM key pairs, this procedure can be applied by both entities independently, establishing and using different shared secret keys on either side.

    -

    Message Flow when the PKI entity does not know that the PKI management entity uses a KEM key pair:

    +

    Note: Figure 4 describes the situation where KEM-based messages protection may not require more that one message exchange. In this case, the transactionID SHOULD be used by the PKI entity to ensure domain-separation between different PKI management operations.

    +

    Message Flow when the PKI entity does not know that the PKI management entity uses a KEM key pair:

    -
    + 
     Step# PKI entity                           PKI management entity
       (Bob)                                (Alice)
@@ -7634,19 +7647,25 @@ 
    
 KemOtherInfo ::= SEQUENCE {
    staticString     PKIFreeText,
    -- MUST be "CMP-KEM"
-   transactionID    OCTET STRING,
-   senderNonce      OCTET STRING,
-   recipNonce       OCTET STRING,
-   -- The tree fields above MUST contain the values from the message
+   transactionID    OCTET STRING OPTIONAL,
+   -- MUST contain the values from the message previously received
+   -- containing the ciphertext (ct) in KemCiphertextInfo
+   -- MUST be used when the client side uses KEM-based message
+   -- protection
+   -- SHOULD be used when the server side only uses KEM-based Message
+   -- protection
+--   senderNonce      OCTET STRING OPTIONAL,
+--   recipNonce       OCTET STRING OPTIONAL,
+   -- The two fields above MUST contain the values from the message
    -- previously received containing the ciphertext (ct) in
    -- KemCiphertextInfo
-   len              INTEGER (1..MAX),
+--   len              INTEGER (1..MAX),
    -- MUST be the value from KemBMParameter
-   mac              AlgorithmIdentifier{MAC-ALGORITHM, {...}}
+--   mac              AlgorithmIdentifier{MAC-ALGORITHM, {...}}
    -- MUST be the MAC algorithm identifier used for MAC-based
    -- protection of the message and MUST be the value from
    -- KemBMParameter
-   ct               OCTET STRING
+--   ct               OCTET STRING
    -- MUST be the ciphertext from that KemCiphertextInfo
   }
 
@@ -7823,10 +7842,13 @@ 
    
           
    Some editorial changes to Section 5.1.3.4 and Appendix E after discussion with David resolving #30 and discussing at IETF 117
  • -

    Added a cross-reference to Section 5.1.1.3 regarding use of OrigPKIMessage to Section 5.1.3.5

    +

    Added ToDo for reviewing the reduced content of KemOtherInfo to Section 5.1.3.4

  • -

    Fixed some references in Section 5.2.8.3 which broke from RFC2510 to RFC4210

    +

    Added a cross-reference to Section 5.1.1.3 regarding use of OrigPKIMessage to Section 5.1.3.5

    +
    • +
  • +

    Fixed some references in Section 5.2.8.3 which broke from RFC2510 to RFC4210

    • From version 06 -> 07:

    @@ -7947,7 +7969,7 @@

    Performed all updates specified in CMP Updates Section 2 and Appendix A.2.

  • -

    Did some editorial allignment to the XML

    +

    Did some editorial alignment to the XML

    • Version 00:

    diff --git a/draft-ietf-lamps-rfc4210bis.txt b/draft-ietf-lamps-rfc4210bis.txt index f671412..28ce78a 100644 --- a/draft-ietf-lamps-rfc4210bis.txt +++ b/draft-ietf-lamps-rfc4210bis.txt @@ -1891,26 +1891,47 @@ Table of Contents KemOtherInfo ::= SEQUENCE { staticString PKIFreeText, transactionID [0] OCTET STRING OPTIONAL, - senderNonce [1] OCTET STRING OPTIONAL, - recipNonce [2] OCTET STRING OPTIONAL, - len INTEGER (1..MAX), - mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} - ct OCTET STRING } staticString MUST be "CMP-KEM". - transactionID, senderNonce, and recipNonce MUST be the values from - the message containing the ciphertext ct in KemCiphertextInfo, if - present. + transactionID MUST be the values from the message containing the + ciphertext ct in KemCiphertextInfo, if present. - len MUST be the value from KemBMParameter. + For all PKI management operations with more than one exchange the + transactionID MUST be set, see Section 5.1.1. This is the typical + situation when KEM-based message protection is used. Figure 4 of + Appendix E describes the exceptional case where only one message + exchange may be sufficient. In this case, the transactionID + SHOULD be used by Bob to ensure domain-separation between + different PKI management operations. - mac MUST be the MAC algorithm identifier used for MAC-based - protection of the message and MUST be the value from - KemBMParameter. + [ToDo: The fields senderNonce, ReciepNonce, len, mac, and ct were + removed from the KemOtherInfo sequence. The authors are waiting for + experts reviews providing guidance if theses fields are necessary for + the security of the KEM-bases message protection. - ct MUST be the ciphertext from KemCiphertextInfo. + Text from -V07 + + ~~~~ asn.1 KemOtherInfo ::= SEQUENCE { staticString PKIFreeText, + transactionID [0] OCTET STRING OPTIONAL, senderNonce [1] OCTET STRING + OPTIONAL, recipNonce [2] OCTET STRING OPTIONAL, len INTEGER (1..MAX), + mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} ct OCTET STRING } ~~~~ + + staticString MUST be "CMP-KEM". + + transactionID, senderNonce, and recipNonce MUST be the values from + the message containing the ciphertext ct in KemCiphertextInfo, if + present. + + len MUST be the value from KemBMParameter. + + mac MUST be the MAC algorithm identifier used for MAC-based + protection of the message and MUST be the value from KemBMParameter. + + ct MUST be the ciphertext from KemCiphertextInfo. + + End of ToDo] * OKM is the output keying material of the KDF used for MAC-based message protection of length len and is called ssk in this @@ -5013,6 +5034,11 @@ Appendix E. Variants of Using KEM Keys for PKI Message Protection management entity uses a KEM key pair and has the authentic public key + Note: Figure 4 describes the situation where KEM-based messages + protection may not require more that one message exchange. In this + case, the transactionID SHOULD be used by the PKI entity to ensure + domain-separation between different PKI management operations. + Message Flow when the PKI entity does not know that the PKI management entity uses a KEM key pair: @@ -5580,19 +5606,25 @@ Appendix F. Compilable ASN.1 Definitions KemOtherInfo ::= SEQUENCE { staticString PKIFreeText, -- MUST be "CMP-KEM" - transactionID OCTET STRING, - senderNonce OCTET STRING, - recipNonce OCTET STRING, - -- The tree fields above MUST contain the values from the message + transactionID OCTET STRING OPTIONAL, + -- MUST contain the values from the message previously received + -- containing the ciphertext (ct) in KemCiphertextInfo + -- MUST be used when the client side uses KEM-based message + -- protection + -- SHOULD be used when the server side only uses KEM-based Message + -- protection + -- senderNonce OCTET STRING OPTIONAL, + -- recipNonce OCTET STRING OPTIONAL, + -- The two fields above MUST contain the values from the message -- previously received containing the ciphertext (ct) in -- KemCiphertextInfo - len INTEGER (1..MAX), + -- len INTEGER (1..MAX), -- MUST be the value from KemBMParameter - mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} + -- mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} -- MUST be the MAC algorithm identifier used for MAC-based -- protection of the message and MUST be the value from -- KemBMParameter - ct OCTET STRING + -- ct OCTET STRING -- MUST be the ciphertext from that KemCiphertextInfo } @@ -5763,6 +5795,9 @@ Appendix G. History of Changes * Some editorial changes to Section 5.1.3.4 and Appendix E after discussion with David resolving #30 and discussing at IETF 117 + * Added ToDo for reviewing the reduced content of KemOtherInfo to + Section 5.1.3.4 + * Added a cross-reference to Section 5.1.1.3 regarding use of OrigPKIMessage to Section 5.1.3.5 @@ -5865,7 +5900,7 @@ Appendix G. History of Changes * Performed all updates specified in CMP Updates Section 2 and Appendix A.2. - * Did some editorial allignment to the XML + * Did some editorial alignment to the XML Version 00: