Skip to content

Commit

Permalink
Script updating gh-pages from 67f8f87. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Nov 27, 2023
1 parent 97583eb commit 7b995d9
Show file tree
Hide file tree
Showing 2 changed files with 106 additions and 49 deletions.
78 changes: 50 additions & 28 deletions draft-ietf-lamps-rfc4210bis.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3517,33 +3517,45 @@ <h5 id="name-key-encapsulation">
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
}
</pre><a href="#section-5.1.3.4-24.2.2" class="pilcrow"></a>
</div>
<p id="section-5.1.3.4-24.2.3">
staticString <span class="bcp14">MUST</span> be "CMP-KEM".<a href="#section-5.1.3.4-24.2.3" class="pilcrow"></a></p>
<p id="section-5.1.3.4-24.2.4">
transactionID, senderNonce, and recipNonce <span class="bcp14">MUST</span> be the values from the message containing the ciphertext ct in KemCiphertextInfo, if present.<a href="#section-5.1.3.4-24.2.4" class="pilcrow"></a></p>
transactionID <span class="bcp14">MUST</span> be the values from the message containing the ciphertext ct in KemCiphertextInfo, if present.<a href="#section-5.1.3.4-24.2.4" class="pilcrow"></a></p>
<p id="section-5.1.3.4-24.2.5">
len <span class="bcp14">MUST</span> be the value from KemBMParameter.<a href="#section-5.1.3.4-24.2.5" class="pilcrow"></a></p>
<p id="section-5.1.3.4-24.2.6">
mac <span class="bcp14">MUST</span> be the MAC algorithm identifier used for MAC-based protection of the message and <span class="bcp14">MUST</span> be the value from KemBMParameter.<a href="#section-5.1.3.4-24.2.6" class="pilcrow"></a></p>
<p id="section-5.1.3.4-24.2.7">
ct <span class="bcp14">MUST</span> be the ciphertext from KemCiphertextInfo.<a href="#section-5.1.3.4-24.2.7" class="pilcrow"></a></p>
For all PKI management operations with more than one exchange the transactionID <span class="bcp14">MUST</span> be set, see <a href="#sect-5.1.1" class="auto internal xref">Section 5.1.1</a>. This is the typical situation when KEM-based message protection is used. <a href="#KEM-Flow2" class="auto internal xref">Figure 4</a> of <a href="#sect-e" class="auto internal xref">Appendix E</a> describes the exceptional case where only one message exchange may be sufficient. In this case, the transactionID <span class="bcp14">SHOULD</span> be used by Bob to ensure domain-separation between different PKI management operations.<a href="#section-5.1.3.4-24.2.5" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-5.1.3.4-24.3">
<p id="section-5.1.3.4-24.3.1">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.<a href="#section-5.1.3.4-24.3.1" class="pilcrow"></a></p>
</ul>
<p id="section-5.1.3.4-25">[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.<a href="#section-5.1.3.4-25" class="pilcrow"></a></p>
<p id="section-5.1.3.4-26">Text from -V07<a href="#section-5.1.3.4-26" class="pilcrow"></a></p>
<p id="section-5.1.3.4-27">~~~~ asn.1
KemOtherInfo ::= SEQUENCE {
staticString PKIFreeText,
transactionID [0] OCTET STRING <span class="bcp14">OPTIONAL</span>,
senderNonce [1] OCTET STRING <span class="bcp14">OPTIONAL</span>,
recipNonce [2] OCTET STRING <span class="bcp14">OPTIONAL</span>,
len INTEGER (1..MAX),
mac AlgorithmIdentifier{MAC-ALGORITHM, {...}}
ct OCTET STRING
}
~~~~<a href="#section-5.1.3.4-27" class="pilcrow"></a></p>
<p id="section-5.1.3.4-28">staticString <span class="bcp14">MUST</span> be "CMP-KEM".<a href="#section-5.1.3.4-28" class="pilcrow"></a></p>
<p id="section-5.1.3.4-29">transactionID, senderNonce, and recipNonce <span class="bcp14">MUST</span> be the values from the message containing the ciphertext ct in KemCiphertextInfo, if present.<a href="#section-5.1.3.4-29" class="pilcrow"></a></p>
<p id="section-5.1.3.4-30">len <span class="bcp14">MUST</span> be the value from KemBMParameter.<a href="#section-5.1.3.4-30" class="pilcrow"></a></p>
<p id="section-5.1.3.4-31">mac <span class="bcp14">MUST</span> be the MAC algorithm identifier used for MAC-based protection of the message and <span class="bcp14">MUST</span> be the value from KemBMParameter.<a href="#section-5.1.3.4-31" class="pilcrow"></a></p>
<p id="section-5.1.3.4-32">ct <span class="bcp14">MUST</span> be the ciphertext from KemCiphertextInfo.<a href="#section-5.1.3.4-32" class="pilcrow"></a></p>
<p id="section-5.1.3.4-33">End of ToDo]<a href="#section-5.1.3.4-33" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-5.1.3.4-34.1">
<p id="section-5.1.3.4-34.1.1">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.<a href="#section-5.1.3.4-34.1.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="section-5.1.3.4-25">There are various ways how Alice can request and Bob can provide the KEM ciphertext, see <a href="#sect-e" class="auto internal xref">Appendix E</a> 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.
<p id="section-5.1.3.4-35">There are various ways how Alice can request and Bob can provide the KEM ciphertext, see <a href="#sect-e" class="auto internal xref">Appendix E</a> 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.<a href="#section-5.1.3.4-25" class="pilcrow"></a></p>
<p id="section-5.1.3.4-26">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.<a href="#section-5.1.3.4-26" class="pilcrow"></a></p>
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.<a href="#section-5.1.3.4-35" class="pilcrow"></a></p>
<p id="section-5.1.3.4-36">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.<a href="#section-5.1.3.4-36" class="pilcrow"></a></p>
</section>
</div>
<div id="sect-5.1.3.5">
Expand Down Expand Up @@ -7057,10 +7069,11 @@ <h2 id="name-variants-of-using-kem-keys-">
<a href="#name-message-flow-when-the-pki-e" class="selfRef">Message Flow when the PKI entity knows that the PKI management entity uses a KEM key pair and has the authentic public key</a>
</figcaption></figure>
</div>
<p id="appendix-E-8">Message Flow when the PKI entity does not know that the PKI management entity uses a KEM key pair:<a href="#appendix-E-8" class="pilcrow"></a></p>
<p id="appendix-E-8">Note: <a href="#KEM-Flow2" class="auto internal xref">Figure 4</a> describes the situation where KEM-based messages protection may not require more that one message exchange. In this case, the transactionID <span class="bcp14">SHOULD</span> be used by the PKI entity to ensure domain-separation between different PKI management operations.<a href="#appendix-E-8" class="pilcrow"></a></p>
<p id="appendix-E-9">Message Flow when the PKI entity does not know that the PKI management entity uses a KEM key pair:<a href="#appendix-E-9" class="pilcrow"></a></p>
<span id="name-message-flow-when-the-pki-en"></span><div id="KEM-Flow3">
<figure id="figure-5">
<div class="alignLeft art-text artwork" id="appendix-E-9.1">
<div class="alignLeft art-text artwork" id="appendix-E-10.1">
<pre>
Step# PKI entity PKI management entity
(Bob) (Alice)
Expand Down Expand Up @@ -7634,19 +7647,25 @@ <h2 id="name-compilable-asn1-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
}

Expand Down Expand Up @@ -7823,10 +7842,13 @@ <h2 id="name-history-of-changes">
<p id="appendix-G-3.3.1">Some editorial changes to Section 5.1.3.4 and Appendix E after discussion with David resolving #30 and discussing at IETF 117<a href="#appendix-G-3.3.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="appendix-G-3.4">
<p id="appendix-G-3.4.1">Added a cross-reference to Section 5.1.1.3 regarding use of OrigPKIMessage to Section 5.1.3.5<a href="#appendix-G-3.4.1" class="pilcrow"></a></p>
<p id="appendix-G-3.4.1">Added ToDo for reviewing the reduced content of KemOtherInfo to Section 5.1.3.4<a href="#appendix-G-3.4.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="appendix-G-3.5">
<p id="appendix-G-3.5.1">Fixed some references in Section 5.2.8.3 which broke from RFC2510 to RFC4210<a href="#appendix-G-3.5.1" class="pilcrow"></a></p>
<p id="appendix-G-3.5.1">Added a cross-reference to Section 5.1.1.3 regarding use of OrigPKIMessage to Section 5.1.3.5<a href="#appendix-G-3.5.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="appendix-G-3.6">
<p id="appendix-G-3.6.1">Fixed some references in Section 5.2.8.3 which broke from RFC2510 to RFC4210<a href="#appendix-G-3.6.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="appendix-G-4">From version 06 -&gt; 07:<a href="#appendix-G-4" class="pilcrow"></a></p>
Expand Down Expand Up @@ -7947,7 +7969,7 @@ <h2 id="name-history-of-changes">
<p id="appendix-G-17.1.1">Performed all updates specified in CMP Updates Section 2 and Appendix A.2.<a href="#appendix-G-17.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="appendix-G-17.2">
<p id="appendix-G-17.2.1">Did some editorial allignment to the XML<a href="#appendix-G-17.2.1" class="pilcrow"></a></p>
<p id="appendix-G-17.2.1">Did some editorial alignment to the XML<a href="#appendix-G-17.2.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="appendix-G-18">Version 00:<a href="#appendix-G-18" class="pilcrow"></a></p>
Expand Down
77 changes: 56 additions & 21 deletions draft-ietf-lamps-rfc4210bis.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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:

Expand Down Expand Up @@ -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
}

Expand Down Expand Up @@ -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

Expand Down Expand Up @@ -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:

Expand Down

0 comments on commit 7b995d9

Please sign in to comment.