need to define wire format for VRF PKs

[reyzin]

Because it is needed in the nsec5 draft.

[fcelda]

I think we already have everything we need in octet strings:

• alpha, input, octet string by definition
• beta, VRF hash output, already an octet string because Hash outputs octet string
• pi, VRF proof, octet string because this the result is output of I2OSP

Then we have to communicate keys:

• public key, this is up to the protocol, let the protocol (e.g. NSEC5) to specify what it needs
• private key, this is not communicated so this doesn't have to be specified anywhere

Is there something else I forgot?

[goldbe]

Jan, we need to specify a wire format for the public key.
In the NSEC5 draft we say that the VRF draft specifies the public key format.
If I understand you correctly, you are saying that the VRF draft should NOT do this, but the NSEC5 draft should. I'm not sure I agree with this, (I think the VRF draft should specify the wire format for pub keys). But I am willing to be convinced if you explain your reasoning...

[fcelda]

For existing DNSSEC algorithms, it has always been the DNS protocol that defined the public key wire format used in DNS:

• RSA: https://tools.ietf.org/html/rfc3110#section-2
• DSA: https://tools.ietf.org/html/rfc2536#section-2
• ECDSA: https://tools.ietf.org/html/rfc6605#section-4
• EdDSA: https://tools.ietf.org/html/rfc8080#section-3

Private key format is not defined as the private keys in DNS never appear on wire. The implementers are allowed to pick whatever suites their software.

I'm not strictly against defining wire format for keys in VRF draft. But it seems to me that it is not essential. Some applications might not need to transmit the public key over the wire at all. Is there any benefit of doing that? For some cross protocol compatibility?

[goldbe]

I guess its fine. We don't have to do this in the VRF draft.
We do indeed define the wire format for the NSEC5 keys in the Section 4 of the NSEC5 draft.

One note however, is that our NSEC5 public key uses an UNCOMPRESSED curve point for P256. Do we really want to keep it this way, or should we save the space by compressing the point? We work with compressed points for the rest of VRF.

Thoughts?

[goldbe]

See my comment in 308e6f7.
Jan, Dimitris, can you weigh in?