x509-cert: make key storage a parameter for Certificate
#803
Conversation
baloo
force-pushed
the
baloo/owned-api/parameterized-cert
branch
from
fd3ead8 to
37c874a
Compare
baloo
force-pushed
the
baloo/owned-api/parameterized-cert
branch
from
37c874a to
89aff8f
Compare
|
I am not very happy with those changes on the derive crate. The management of lifetimes is a hack. |
| } | ||
|
|
||
| impl<'a> TbsCertificate<'a> { | ||
| impl<SignParams, KeyParams, Key> TbsCertificate<SignParams, KeyParams, Key> { |
There was a problem hiding this comment.
Rather than making these generic, I think they can just be fixed to Any, Any, and BitString respectively, at least for now.
That will give you a fully owned representation of TbsCertificate and Certificate which can also handle any kind of signature algorithm, without the additional complexity of generics and variadic representations.
If you really do want to make it generic, I would suggest adding something like pub trait Profile to be impl'd on ZSTs which can act as a carrier for families of type parameters (and potentially constant values as well), rather than using a large number of generic parameters.
There was a problem hiding this comment.
Let's go with fully own for now, but I'll resubmit another PR to follow up on the profile idea.
I think it will ease things a lot on the derive as I can encode bounds on the trait instead. It could very much help with bringing non-owned extensions back as well.
|
replaced by #803 |
As discussed in #803 let's make `Certificate` an owned type
2 participants
This introduces the owned api for x509 certificates.