Ah I just realized RADb is supporting the old version of NRTM, not the draft version… so my client wont have any real world usage. I will just use IRRd for synchronization then. (I was rate limited by RADb’s WHOIS, and then saw their page saying they support NRTM. The first result of Google search led me to the draft, and I couldn’t find an NRTM client in a quick search. So I thought everything’s all new and were in some experiment state XD)
> 在 2023年3月22日，上午7:17，Sasha Romijn <[email protected]> 写道： > > 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
