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

[David Benjamin <[e-mail]>]

On Sun, Apr 30, 2017 at 8:17 PM Brian Smith <[e-mail]> wrote:

> Jim Schaad <[e-mail]> wrote:
> > It is not always possible to detect corruption when you store in an
> unencrypted form.
>
> What kind of corruption would we not be able to detect? It is possible
> that somehow the private key could get corrupted and that there could
> be a corresponding corruption to the public key such that they match
> again, but this seems extremely unlikely unless somebody simply
> replaced the key pair with another key pair.
>
> > It would also not be possible to know if it was the private key or the
> public key that has been corrupted, just that the two values do not match.
>
> This is the case with any kind of cryptographic check, including HMAC
> or whatnot.
>

(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.)


> > > However, unless this is documented in the draft one way or
> > another as a MUST accept or a MUST NOT generate, I think
> > it will be an interop nightmare. In particular, we should avoid
> > the situation where some implementations produce v2 keys
> > so they can add the publicKey field, and where other
> > implementations reject v2 keys because they only parse v1,
> > where the publicKey field isn't allowed.
> >
> > I have not heard that this is an issue today with DH keys.  This
> > makes me think that this is not going to be a big issue.  I expect
> > that most implementations would all for parsing v2 keys even if
> > they then ignore the public key field.
>
> If that's the expectation then let's enshrine that in the spec by
> saying that implementations MUST accept v2 keys for these types of
> keys.
>
> 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.

David