Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-06.txt

[Russ Housley <[e-mail]>]

Ben:

Different ASN.1 libraries are better at checking various constraints.

For example, in pyasn1, these two are equivalent:

   ver = rfc5280.Version(2)
   ver = rfc5280.Version('v3')

However, it does not complain if a value that does not have a name is encoded.  That is, it just uses the named values as a more readable way to set specific INTEGER values.


RFC 5280 uses:

   TBSCertificate  ::=  SEQUENCE  {
        version         [0]  Version DEFAULT v1,
        ...

   Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }


RFC 5652 uses:

   SignedData ::= SEQUENCE {
      version CMSVersion,
      ...

      CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }


RFC 6486:

   Manifest ::= SEQUENCE {
      version     [0] INTEGER DEFAULT 0,
      ...


I think all of them are roughly the same to implement, but I tend to like the ability to talk about values like "v2" in the text.

Russ


> On Oct 8, 2021, at 3:53 AM, Ben Maddison <benm=[e-mail]> wrote:
> 
> Signed PGP part
> Hi Russ, Tim,
> 
> On 10/06, Russ Housley wrote:
>> 
>> <snip/>
>> 
>> This is just a matter of style I think.
>> 
> I've been thinking about this some more, and actually I think that this
> choice *is* important when considering asn1 -> code compiler friendliness.
> 
> Consider:
>    Foo ::= SEQUENCE {
>        bar Bar,
>        baz Baz,
>        qux INTEGER
>    }
> 
>    Bar ::= INTEGER
> 
>    Baz ::= INTEGER {
>        a(0), b(1), c(2)
>    }
> 
> Compiling this to (for the sake of example) rust would be expected to
> produce something like:
>    struct Foo {
>        bar: Bar,
>        baz: Baz,
>        qux: usize,
>    }
> 
>    struct Bar(usize);
> 
>    enum Baz {
>        a = 0,
>        b,
>        c,
>    }
> 
> Of course other language type systems have more-or-less direct
> parallels.
> 
> Each has advantages and disadvantages:
> 
> -   the "qux" style can be used directly as an integer with no
>    additional work, but you get no safeguards from the type system to
>    prevent using a bare integer where you expected a "qux" value;
> 
> -   the "baz" style gives the type system the ability to distinguish Baz
>    integers from other integers, at the expense of some extra work to
>    define the operations on Baz types that are permitted; and
> 
> -   the "bar" style is not usable as an integer at all (at least not
>    conveniently). The integer value is just there to distinguish the
>    variants in memory.
> 
> I think this leads to the following general guidance:
> 
> 1.  Use a bare INTEGER ("qux"-style) for unit-less, context-less integer
>    values, that can be sensibly combined in an operation with any other
>    integer value.
>    This seems to be rare in practise to me, so should probably be
>    limited to situations where simplicity is more important than
>    correctness.
> 
> 2.  Use a named type of type INTEGER ("bar"-style) for numbers that
>    can be combined or compared with other numbers of a particular type.
> 
>    For example:
>        bob.age != sue.age          # makes sense
>        bob.height + sue.shoe_size  # probably a bug!
> 
> 3.  Use enumerations ("baz"-style) when the *only* sensible operation
>    that exists on the underlying numbers is equality comparison.
> 
> In the present case, I would suggest that the 'version' field falls
> under category #2, since `foo.version < bar.version` could make sense in
> some situations.
> 
> So, I would suggest:
> 
>    Manifest ::= SEQUENCE {
>        version [0] Version DEFAULT 0,
>        ...
>    }
>    Version ::= INTEGER
> 
> Note that this is orthogonal to whether we explicitly limit the
> permitted value to 0, which can be done in any of the three schemes.
> I have no particular view on whether that is a good idea or not.
> 
> Cheers,
> 
> Ben
> 
>