Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rsc-07.txt

[Russ Housley <[e-mail]>]

Ben:

>> 
>>> Sorry that I was not clear.  Since the goal is to align with RFC 3779,
>>> we should use the same definition as was used there, which is OCTET
>>> STRING (SIZE (2..3)).
>> 
>> this makes more sense to me, as i do not see a win in having rules that
>> apply on wednesdays and fridays and not on other days of the week.  one
>> wants to be able to write tools that are not complicated unnecesarily.
>> 
> I think I am explaining the intent poorly. I will try again.
> 
> The intent is not to align with the ASN.1 definitions of 3779, but with
> the DER wire-format produced by implementations of 3779.
> 
> The previous version of the i-d used types imported from 3779 such
> that the ASN.1 correctly expressed the constraints that we were after
> (no rdi, no inherit, no empty SEQ OF, etc).
> 
> However, we received feedback from implementors that the structures that
> contained the imported types (called AsList and IPList in -06) were
> hostile to code-reuse for implementations dependent on openssl/libressl,
> because of the API exposed by these libraries.
> 
> This resulted in large amounts of almost-duplicate code for these
> implementors.
> 
> Initially, we discussed using ASIdentifiers and IPAddrBlocks (from 3779)
> directly in the RSC module, in order to permit re-use. This would have
> had the significant (in my opinion) downside of requiring the stricter
> constraints to be enumerated *only* in the prose of the draft, despite
> being easily expressible in ASN.1.
> 
> Instead, we identified an ASN.1 construction that represents a strict
> subset of the equivalent 3779 types *when encoded in DER*, whilst still
> expressing the desired constraints.
> 
> Thus any (DER encoded) data conforming to the -07 specification can be
> decoded using an implementation of 3779.
> Similarly, any data encoded using an existing 3779 implementation will
> fail to decode using the -07 module only to the extent that the
> RSC-specific constraints are violated.
> 
> This, I believe, provides the optimal flexibility to implementors.
> Either:
> A) re-use an existing 3779 library, adding constraint-checks by
> hand as necessary, or
> B) generate code directly from the -07 module, and get the correct
> constraint-checking for free (modulo the quality of the ASN.1 compiler
> used)
> 
> The goal is explicitly to deviate from 3779 at the ASN.1 level, whilst
> remaining compatible with 3779 at the DER-encoded bytes level.
> 
> In the specific case of the addressFamily field, allowing the SAFI-byte
> in the ASN.1, but then requiring that it MUST be absent in normative
> text (as is the case in other RPKI RFCs, e.g. 6487) would run contrary
> to the above goals.
> Implementors would be forced to do the constraint check by hand, even if
> they were generating the other constraints from the ASN.1 definitions.
> 
> Hope that makes more sense?

Not for me.  As you explain, you want compatibility with the library.  It produces a 2 octet value.  That is compatible with OCTET STRING (SIZE (2..3)).

I do not want someone to encode a value with the ASN.1 in RFC 3779 and then have a decode failure by an implementation that uses this ASN.1.

You can meet both of these goals...

Russ