Re: [IPsec] [saag] AD review of draft-moskowitz-ipsecme-ipseckey-eddsa-02
On 11/7/22 09:07, Tero Kivinen wrote: Robert Moskowitz writes: Value Description Format description Reference 0 No key is present[RFC4025] 1 A DSA Public Key [RFC2536] Section 2 [RFC4025] 2 A RSA Public Key [RFC3110] Section 2 [RFC4025] 3 An ECDSA Public Key [RFC6605] Section 4 [RFC4025] TBD1 An EdDSA Public Key [RFC8080] Section 3 [ThisRFC] Adding the section numbers would be useful, as those documents define both DNSKEY and RRSIG resource records, so pointing to one of them helps. I like this second way. Does including the sec occur in any other registries? We will have to ask IANA; it does make sense as you say in this specific case. Yes. For example IKEv2 Transform Type 4 registry has section numbers for Recipient Tests: https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8 We would need to get IANA signoff on this, IMO. With this presedent, I will follow what is in this registry, e.g.: [RFC6989], Sec. 2.1 Bob ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] AD review of draft-moskowitz-ipsecme-ipseckey-eddsa-02
Robert Moskowitz writes: > > Value Description Format description Reference > > 0 No key is present[RFC4025] > > 1 A DSA Public Key [RFC2536] Section 2 [RFC4025] > > 2 A RSA Public Key [RFC3110] Section 2 [RFC4025] > > 3 An ECDSA Public Key [RFC6605] Section 4 [RFC4025] > > TBD1 An EdDSA Public Key [RFC8080] Section 3 [ThisRFC] > > > > Adding the section numbers would be useful, as those documents define > > both DNSKEY and RRSIG resource records, so pointing to one of them > > helps. > I like this second way. Does including the sec occur in any other > registries? We will have to ask IANA; it does make sense as you say in > this specific case. Yes. For example IKEv2 Transform Type 4 registry has section numbers for Recipient Tests: https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8 > We would need to get IANA signoff on this, IMO. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] AD review of draft-moskowitz-ipsecme-ipseckey-eddsa-02
On 11/7/22 06:30, Tero Kivinen wrote: Robert Moskowitz writes: Value Description 1A DSA Public Key is present, in the format defined in [RFC2536] 2A RSA Public Key is present, in the format defined in [RFC3110] 3An ECDSA Public Key is present, in the format defined in [RFC6605] I can remove the reference column? It seems this is always called for. So either we accept the build errors that still result in a usable draft, or we make these entries two lines like: How about we cut the "is present" text. I do not think it gives any useful information. I mean if there is key in format defined in some rfc in this RR, then yes, the key is present, we do not need to repeat that. 0No key is present 1A DSA Public Key in the format defined in [RFC2536] 2A RSA Public Key in the format defined in [RFC3110] 3An ECDSA Public Key in the format defined in [RFC6605] Or we could even split the reference and format in different columns: Value Description Format description Reference 0 No key is present[RFC4025] 1 A DSA Public Key [RFC2536] Section 2 [RFC4025] 2 A RSA Public Key [RFC3110] Section 2 [RFC4025] 3 An ECDSA Public Key [RFC6605] Section 4 [RFC4025] TBD1 An EdDSA Public Key [RFC8080] Section 3 [ThisRFC] Adding the section numbers would be useful, as those documents define both DNSKEY and RRSIG resource records, so pointing to one of them helps. I like this second way. Does including the sec occur in any other registries? We will have to ask IANA; it does make sense as you say in this specific case. We would need to get IANA signoff on this, IMO. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] AD review of draft-moskowitz-ipsecme-ipseckey-eddsa-02
Robert Moskowitz writes: > > Value Description > > > > 1A DSA Public Key is present, in the format defined in [RFC2536] > > 2A RSA Public Key is present, in the format defined in [RFC3110] > > 3An ECDSA Public Key is present, in the format defined in [RFC6605] > > I can remove the reference column? It seems this is always called for. > So either we accept the build errors that still result in a usable > draft, or we make these entries two lines like: How about we cut the "is present" text. I do not think it gives any useful information. I mean if there is key in format defined in some rfc in this RR, then yes, the key is present, we do not need to repeat that. 0No key is present 1A DSA Public Key in the format defined in [RFC2536] 2A RSA Public Key in the format defined in [RFC3110] 3An ECDSA Public Key in the format defined in [RFC6605] Or we could even split the reference and format in different columns: Value Description Format description Reference 0 No key is present[RFC4025] 1 A DSA Public Key [RFC2536] Section 2 [RFC4025] 2 A RSA Public Key [RFC3110] Section 2 [RFC4025] 3 An ECDSA Public Key [RFC6605] Section 4 [RFC4025] TBD1 An EdDSA Public Key [RFC8080] Section 3 [ThisRFC] Adding the section numbers would be useful, as those documents define both DNSKEY and RRSIG resource records, so pointing to one of them helps. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] I-D Action: draft-ietf-ipsecme-ikev2-multiple-ke-09.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Multiple Key Exchanges in IKEv2 Authors : C. Tjhai M. Tomlinson G. Bartlett S. Fluhrer D. Van Geest O. Garcia-Morchon Valery Smyslov Filename: draft-ietf-ipsecme-ikev2-multiple-ke-09.txt Pages : 36 Date: 2022-11-07 Abstract: This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup. The primary application of this feature in IKEv2 is the ability to perform one or more post-quantum key exchanges in conjunction with the classical (Elliptic Curve) Diffie-Hellman key exchange, so that the resulting shared key is resistant against quantum computer attacks. Another possible application is the ability to combine several key exchanges in situations when no single key exchange algorithm is trusted by both initiator and responder. This document updates RFC7296 by renaming a transform type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this transform type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-multiple-ke-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-multiple-ke-09 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
