Actually, RIPE has implemented NRTMv4: https://github.com/RIPE-NCC/whois/releases/tag/whois-1.106 [https://opengraph.githubassets.com/e32c2bc44f149263e900a91411646105e2efb907fcf9e39b4759c0f6899ba05b/RIPE-NCC/whois/releases/tag/whois-1.106]<https://github.com/RIPE-NCC/whois/releases/tag/whois-1.106> Release Whois Release 1.106 · RIPE-NCC/whois<https://github.com/RIPE-NCC/whois/releases/tag/whois-1.106> Whois Release 1.106 includes the following main change: NWI-19 Implement AS_SET NONAUTH Implement "networks" and "autnums" elements in RDAP entity response RDAP changes NRTMv4 implementation Impro... github.com The endpoint is also available at https://ftp.ripe.net/ripe/dbase/nrtmv4/ ________________________________ From: Sasha Romijn <[email protected]> Sent: Wednesday, March 22, 2023 07:16 To: Huang, Shengyuan <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Dainotti, Alberto <[email protected]> Subject: Re: Clarification on next_signing_key format of NRTM v4
Hello, On 22 Mar 2023, at 8:09, Huang, Shengyuan wrote: > I am trying to implement a client for NRTM server since RADb is supporting > it. I have some confusion about the signing key. This surprises me - to my knowledge RADB only has a current implementation of NRTM v3. There is no NRTM v4 code in production that I know of yet. > The current draft says: "...If present, it MUST be an Ed25519 [RFC8032] > public key encoded in base64 [RFC4648], which matches the private key the > mirror server will start using to sign the Update Notification File in the > near future. " > > However, in the example, the field "next_signing_key": "96..ae" looks like a > byte representation instead of a base64 representation of a ed25519 public > key. (Since the key length of a ed25519 public key is not a multiple of 3, > the base64 representation must ends with a "=".) You are entirely right, these are inconsistent. My first thought is that we should use hexadecimal byte encoding, making it the same as for file hashes. I don’t feel strong on that though as long as it is consistent with the example. Sasha
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
