Put the DH public key in the message. #9
Conversation
There was a problem hiding this comment.
The change looks good to me.
I'm still not completely convinced of the benefit, since any message will likely need to include other meta information anyway (e.g. the subscription for which it was received). But I defer to Costin who knows that part of the system much better.
| A push message MUST include a zero length `keyid` parameter in the content | ||
| coding header. | ||
| A push message MUST include the application server ECDH public key in the | ||
| `keyid` parameter of the encrypted content coding header. |
There was a problem hiding this comment.
Since this is the MUST mandate, would it make sense to move the "The uncompressed point...of the "keyid"." language on lines 187-189 of this diff here?
There was a problem hiding this comment.
The subscription is encoded in the endpoint URL, 'from' is in the Authorization header.
It would have been nice if the binary format was extensible - I understand the motivation
of keeping it as simple as possible, but some tag/len or other mechanism are not that
complicated.
There was a problem hiding this comment.
Well, extensibility is hazardous without knowing what you need it for. At this point, I'd say that it is best achieved by using an entirely different scheme.
Losing extensibility is one of the costs of this optimization. If you really think we need extensibility, then this PR is a bad idea and we should go back to using Crypto-Key.
There was a problem hiding this comment.
It's ok - we can still extend/customize this format by adding info in headers :-)
martinthomson
force-pushed
the
pack_key_hack
branch
3 times, most recently
from
e282eea
to
80c46d5
Compare
martinthomson
force-pushed
the
pack_key_hack
branch
from
80c46d5
to
02ada00
Compare
This removes Crypto-Key and moves the DH public key into the keyid field.