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

[Ben Maddison <[e-mail]>]

Hi Russ,

On 05/20, Russ Housley wrote:
> 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.
> > 
[..]
> > 
> > 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)).
> 
Yes, agreed. It is also compatible with OCTET STRING (SIZE (2)).

> 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.
> 
Not all possible values of 3779 types are permitted in the eContent of
an RSC.

If someone encodes a value using an 3779 implementation that, for
example, contains 'inherit' or a 3-octet addressFamily, puts that value
in the eContent of an RSC, and then tries to decode the object, then a
decode error *is* the proper outcome.

Cheers,

Ben