Re: [Curdle] AlgorithmIdentifier parameters in draft-ietf-curdle-pkix-03

[str4d <[e-mail]>]

On 03/24/2017 06:16 AM, David Benjamin wrote:
> On Thu, Mar 23, 2017 at 12:49 PM Russ Housley <[e-mail]> wrote:
> 
>>> How would the following language (or something to this effect) work as a
>>> compromise?
>>>
>>>   In this document we defined six new OIDs for identifying the
>>>   different curve/algorithm pairs.  The curves being Curve25519 and
>>>   Curve448.  The algorithms being ECDH, EdDSA in pure mode and EdDSA in
>>>   pre-hash mode.  For all of the OIDs, the parameters MUST be absent.
>>>   Regardless of the defect in the original 1997 syntax, implementations
>>>   MUST NOT write out a parameters value of NULL, and MUST NOT accept a
>>>   parameters value of NULL, EXCEPT where doing so is unavoidable due to
>>>   legacy PKCS8 interpretation within the implementation language's
>>>   standard libraries (such as Java's Sun security provider before
>>>   version XX).
>>
>>
>> EXCEPT is not defined in RFC 2119.

Yeah, my apologies - I was writing in pseudo-language, but am new enough
to this sphere that this RFC isn't yet burned into my brain ^_^;

>>
>> How is your proposed language any different in reality than:
>>
>>   This document specified object identifiers for using Curve25519 and
>>   Curve448 for key agreement and digital signature.  Since none of these
>>   algorithm identifiers need parameters, the parameters MUST be absent.
>>   As a result of the defect in the AlgorithmIdentifier syntax published
>>   in 1997, some implementations produce a parameters value of NULL, even
>>   when the parameters ought to be absent.  Conforming implementations
>>   MUST NOT produce a parameters value of NULL, but conforming
>>   implementations MAY accept a parameters value of NULL for
>>   interoperability.
>>
> 
> I think that encourages normal implementations too much towards laxness,
> which will harm the ecosystem.

Correct. I was trying to come up with something that maintained the
existing strictness as much as possible, because in theory I agree with it.

> I don't particularly care which encoding it
> is (with or without NULL), but there must be only one encoding. We've had
> enough trouble with id-rsaEncryption's ambiguity in BoringSSL that I do not
> think we would be willing implement a new scheme with two encodings.

I'm *already* having to deal with parsing two encodings, due to the
presence of draft-josefsson-pkix-eddsa-04 (which was the active draft
for a proposed encoding when that part of my parser was contributed) -
so the horse has kinda left the barn already in that respect.

> 
> If MUST NOT on the parser is problematic, perhaps SHOULD NOT? That said, I
> do not follow what is wrong with MUST NOT. It sounds like this Java issue
> is purely a local thing, right? That is, you don't expect such malformed
> structures to escape into the ecosystem, but you need to be able to parse
> the structures back out? In that case, there's need to encourage any other
> implementation to be lax here. It's purely so that your parser gets the
> conforming checkbox? But the serializer is already violating the MUST NOT,
> so violate it in the parser too and add an explanatory comment next to the
> code.
> 
> Or am I misunderstanding the situation?

It's not so much that I want a "conforming checkbox" to tick, but that
I'm mindful of how easily context can be lost. You don't want to
encourage laxness by allowing flexibility, but you also don't want
implementors reading the RFC, discovering they can't implement it
correctly, and simply ignoring it - that will result in undefined
behaviour. I would prefer that the RFC explicitly acknowledge that the
MUST NOT may not be practical for *parsing* (as opposed to writing) in
some legacy instances (hopefully only the Java standard libraries), to
provide context to future readers instead of hoping they stumble upon
this mailing list thread, or upon the explanatory comment in my code.

I'll admit I'm a little surprised at my cynicism, but I don't think it
is misplaced. However, I am clearly the only person to have raised this
issue here, so perhaps I'm wrong, and RFC readers will interpret the
MUST NOT in a sensible way. I'd like to hope so.

Jack