diff --git a/draft-ietf-lamps-rfc4210bis.html b/draft-ietf-lamps-rfc4210bis.html index 69984a8..cce22f7 100644 --- a/draft-ietf-lamps-rfc4210bis.html +++ b/draft-ietf-lamps-rfc4210bis.html @@ -3855,8 +3855,7 @@

5.2.8. Proof-of-Possession Structures

< ToDo: This section should be aligned with Section 4.3 of this document and -RFC 4211 Section 4. It should potentially be restructured -and updated for better readability. Also some inconsistencies in Section 5.2.8.3 resulting from the update of RFC2510 to RFC4210 should be fixed. >

+RFC 4211 Section 4. May be an addition regarding challenge-response pop for KEM-Keys is required.>

If the certification request is for a key pair that supports signing , then the proof-of-possession of the private signing key is demonstrated through use of the POPOSigningKey structure as defined in [RFC4211].

@@ -3995,13 +3994,13 @@
is replaced with "(i.e., the certificate encrypted under the symmetric key derived from the CA's private KAK and the public key for which the certification request is being made)"; (2) the first -parenthetical text of the challenge field of "Challenge" below is +parenthetical text of the challenge field of "Challenge" in the ASN.1 Module of Appendix F is replaced with "(using PreferredSymmAlg (see Section 5.3.19.4 and Appendix D.5) and a symmetric key derived from the CA's private KAK and the public key for which the certification request is being made)". Alternatively, the POP can use the POPOSigningKey structure given in [RFC4211] (where the alg field is DHBasedMAC and the signature -field is the MAC) as a fourth alternative for demonstrating POP if +field is the MAC). As a fourth alternative for demonstrating POP if the CA already has a D-H certificate that is known to the EE.

The challenge-response messages for proof-of-possession of a private decryption key are specified as follows (see [MvOV97], p.404 for diff --git a/draft-ietf-lamps-rfc4210bis.txt b/draft-ietf-lamps-rfc4210bis.txt index c890170..139bc45 100644 --- a/draft-ietf-lamps-rfc4210bis.txt +++ b/draft-ietf-lamps-rfc4210bis.txt @@ -2203,10 +2203,8 @@ Table of Contents 5.2.8. Proof-of-Possession Structures < ToDo: This section should be aligned with Section 4.3 of this - document and RFC 4211 Section 4. It should potentially be - restructured and updated for better readability. Also some - inconsistencies in Section 5.2.8.3 resulting from the update of - RFC2510 to RFC4210 should be fixed. > + document and RFC 4211 Section 4. May be an addition regarding + challenge-response pop for KEM-Keys is required.> If the certification request is for a key pair that supports signing , then the proof-of-possession of the private signing key is @@ -2335,14 +2333,15 @@ Table of Contents Section 5.2.8.2 is replaced with "(i.e., the certificate encrypted under the symmetric key derived from the CA's private KAK and the public key for which the certification request is being made)"; (2) - the first parenthetical text of the challenge field of "Challenge" - below is replaced with "(using PreferredSymmAlg (see Section 5.3.19.4 - and Appendix D.5) and a symmetric key derived from the CA's private - KAK and the public key for which the certification request is being - made)". Alternatively, the POP can use the POPOSigningKey structure - given in [RFC4211] (where the alg field is DHBasedMAC and the - signature field is the MAC) as a fourth alternative for demonstrating - POP if the CA already has a D-H certificate that is known to the EE. + the first parenthetical text of the challenge field of "Challenge" in + the ASN.1 Module of Appendix F is replaced with "(using + PreferredSymmAlg (see Section 5.3.19.4 and Appendix D.5) and a + symmetric key derived from the CA's private KAK and the public key + for which the certification request is being made)". Alternatively, + the POP can use the POPOSigningKey structure given in [RFC4211] + (where the alg field is DHBasedMAC and the signature field is the + MAC). As a fourth alternative for demonstrating POP if the CA + already has a D-H certificate that is known to the EE. The challenge-response messages for proof-of-possession of a private decryption key are specified as follows (see [MvOV97], p.404 for