Re: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt

[Brian Smith <[e-mail]>]

David Benjamin <[e-mail]> wrote:
> (Not that it matters, but, to that end, would detecting corruption not be
> just as easily served by stashing a checksum somewhere? If not external to
> the serialization, there is already that attributes field.)

Yep, there would be many ways of doing it, but none standardized.

> Is the intent that OneAsymmetricKey parsers accept a hypothetical v3 with
> further appended fields, or should they reject those to allow for
> RFC-3447-like changes? If so, how do they handle the version <=> extra field
> correspondence? A numerical comparison? Assume all unknown values are newer?
> The version number used in the ASN.1 tags corresponds to the symbolic name
> of the version constants, rather than the numerical value, so it's not
> obvious whether, say, defining v3(-1) would be acceptable.

There are multiple problems with rfc5958 and its use of version field
is one. Here is what I'm planning to do:

For now, for RSAPrivateKey and ECPrivateKey, accept only PKCS#8 v1,
since publicKey isn't necessary for them. Later I might accept PKCS#8
v2 for RSAPrivateKey and ECPrivateKey and verify that publicKey
exactly matches the copy of the public key stored in privateKey.

For key types specified in this draft, I will provide a flag where the
user indicates whether they want to require the pairwise consistency
check to pass. If the flag is "no consistent check needed" then I will
accept v1 (with no publicKey). Otherwise if the flag is "consistency
check needed" then I will only accept v2 where the publicKey field is
present and consistent with the private key.

Cheers,
Brian
-- 
https://briansmith.org/