You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Signed objects, especially GroupInfo and KeyPackage, are used in basically two ways:
Instantiate => sign => serialize
Deserialize => verify => instantiate
Given that, it seems like we be able should have two constructors for these objects:
A "signing constructor" of the form Thing(fields..., sig_priv)
A "verifying constructor" of the form Thing(const bytes&, verify_data...) (where verify_data would include things like a tree from which the public key would be taken for GroupInfo)
The type might still need to be default-constructible to facilitate deserialization. Or it might be possible to define tls::get<T>(tls::ostream&), and then do:
Signed objects, especially GroupInfo and KeyPackage, are used in basically two ways:
Given that, it seems like we be able should have two constructors for these objects:
Thing(fields..., sig_priv)
Thing(const bytes&, verify_data...)
(whereverify_data
would include things like a tree from which the public key would be taken for GroupInfo)The type might still need to be default-constructible to facilitate deserialization. Or it might be possible to define
tls::get<T>(tls::ostream&)
, and then do:That would be a bit more boilerplate than
TLS_SERIALIZABLE
, but might be worth it for a clearer API.The text was updated successfully, but these errors were encountered: