add note on pkcs8 structures import with choices

[panva]

The import operations should not be limited to seed-only ML-KEM and ML-DSA imports.

---

Preview | Diff

[twiss]

Sorry for the delayed reviews!

I'm not sure about this one. What happens if someone imports a private-key-only PKCS8 key, and then tries to export it in raw-seed format?

And, what if the underlying implementation only supports importing seeds? I'm not sure we can mandate support for private-key-only keys.

And, if we can't mandate it, perhaps we should in fact limit key imports to seed-only keys (and possibly keys with both values)?

It may be good to make an issue about this to discuss with other implementers, perhaps.

[panva]

What happens if someone imports a private-key-only PKCS8 key, and then tries to export it in raw-seed format?

It is ok that an OperationError would be thrown if private-only imported key was attempted to be exported.

I'm not sure about this one.

I feel strongly about allowing imports in any of the choices (albeit not as strong about private-only). The point being that it is not always the case that deployments can influence the key they are given. Limiting imports to the seed-only choice would 100% be a problem.

It may be good to make an issue about this to discuss with other implementers, perhaps.

I think we should still merge this tho.

[twiss]

It is ok that an OperationError would be thrown if private-only imported key was attempted to be exported.

I personally think this is a bit of an ugly / unfortunate interaction, but if we're going to allow that possibility, it should at least be clearly specified.

Allowing private-key-only PKCS8 also complicates the implementation, I imagine. And again, if the underlying implementation doesn't support it, we can't really mandate it. So I think we should have that discussion before merging this. I've opened an issue for that: #29.

[panva]

I want to get a language in allowing this now rather than later to avoid implementations where this is not accounted for. We can always remove and restrict private-only later.