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
