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

[David Benjamin <[e-mail]>]

On Mon, May 8, 2017 at 1:27 PM Jim Schaad <[e-mail]> wrote:

> *From:* David Benjamin [mailto:[e-mail]]
>
> *Sent:* Monday, May 1, 2017 9:15 AM
> *To:* Brian Smith <[e-mail]>; Jim Schaad <
> [e-mail]>
>
>
> *Cc:* curdle <[e-mail]>
> *Subject:* Re: [Curdle] FW: New Version Notification for
> draft-ietf-curdle-pkix-04.txt
>
>
>
> On Sun, Apr 30, 2017 at 8:17 PM Brian Smith <[e-mail]> wrote:
>
> In particular, I have seen PKCS#8 implementations that reject any v2
> PKCS#8 file instead of ignoring the extra fields.
>
>
>
> As the author of one such PKCS#8 implementation, I'd simply missed that v2
> PKCS#8 existed. Happy to add support (by way of ignoring the field
> probably, yeah). Lacking any useful text about what to do, I interpreted
> the version field to be analogous to RSAPrivateKey, another PKCS spec.
> There, an RFC 2437 implementation that attempted to be forwards-compatible
> (by accepting unknown versions and ignoring appended fields) would have
> been confused come RFC 3447, which decided v1 meant a
> semantically-incompatible otherPrimeInfos field.
>
>
>
> RFC 5958 continues this. It does use ASN.1 extension markers, but X.680
> merely says "The action that is taken in each situation is determined by
> the ASN.1 specifier", and RFC 5958 does not appear to say anything.
>
>
>
> 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.
>
>
>
> [JLS] I had thought this was going to be an easy answer, but as I did not
> have any of my ASN.1 documents with me last week I decided to defer
> responding until I retrieved them from the backup drives.  I am happy that
> I did as what I thought was the correct answer isn’t.  I had always thought
> that the rules were that any additional fields could be ignored by a prior
> parser when evaluating the content of the decoded object.  The answer from
> the X.680 is – it depends.
>
>
>
> I guess that people are supposed to define what the correct behavior for
> this is when they put the extensibility flag into an ASN.1 structure.  We
> did not do this when we wrote the document for OneSymmetricKey and we
> should have done so.  From what we were doing, I would say that the answer
> is that all future fields can be ignored when parsing one of these
> structures.  This is the philosophy that was adopted for dealing with
> unknown attributes.  It would make sense to file an Errata to this end on
> RFC 5958 so that we can make sure that this says the expected method of
> doing thigs.
>

That works for me. What would you then say is the intended interpretation
of the version field? Going from PrivateKeyInfo to OneAsymmetricKey makes
sense to bump the version because it is arguably a semi-incompatible
change. (And, regardless, it's too late to undo that.) I would maybe argue
that future versions of OneAsymmetricKey should *not* bump the version
number. It's not clear to me it serves any purpose in this context since a
parser can't do anything useful with unknown values. So perhaps:

- When serializing without publicKey, serializing code SHOULD use v1
(PrivateKeyInfo). v2 (OneAsymmetricKey) would also work, but this will be
less compatible.
- When serializing with publicKey, serializing code MUST use v2,
- When parsing and the version is v1, parse as PrivateKeyInfo (i.e.
non-extensible and publicKey does not exist).
- When parsing and the version is v2, parse as OneAsymmetricKey. When
parsing as OneAsymmetricKey, one MUST ignore trailing fields after the
OPTIONAL publicKey.
- When parsing and the version is anything else, reject. This is some
invalid thing.

I'm also equally fine with some variant of Brian's stricter interpretation,
which effectively means removing the X.680 extensibility markers. I don't
think this is a context where extensibility is needed and, regardless,
we've already got that attributes field. (OneAsymmetricKey itself could
probably have been skipped in favor of defining a publicKey attribute.)

David