nsec5-draft icon indicating copy to clipboard operation
nsec5-draft copied to clipboard
verified publisher icon fcelda

need to define wire format for VRF PKs

Open reyzin opened this issue 8 years ago • 5 comments

Because it is needed in the nsec5 draft.

reyzin avatar May 28 '17 13:05 reyzin

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?

fcelda avatar Jun 17 '17 14:06 fcelda

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...

goldbe avatar Jun 19 '17 16:06 goldbe

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?

fcelda avatar Jun 20 '17 07:06 fcelda

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 avatar Jun 21 '17 17:06 goldbe

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

goldbe avatar Jun 21 '17 18:06 goldbe