Re: [sidr] Template for RPKI signed objects and revised ROA format [now with attachments!]

[Sean Turner <[e-mail]>]

I really like the way the -roa draft works with the -signed-objects 
draft.  The -roa draft just points to the -signed-objects and says 
what you have to do in addition.  I really think this is the way to go 
for this draft and the -manifest draft.

One thing I noted about the -roa draft is that it's going to need an 
ASN.1 module (well it will be needed before the proto write-up is 
accepted).  The OID for the module should probably come from the same 
arc as the content type but it's not necessary.  Below is a suggested 
module (includes the SIZE constraint on ipAddrBlocks suggested in 
http://www.ietf.org/mail-archive/web/sidr/current/msg01926.html but I 
also added one to addresses).  Three things to note:

  - you could import IPAddress from the 3779 module if you wanted to
  - not sure whether you want an IMPLICIT or an EXPLICIT module
  - added SIZE constraint to addresses

There are some other comments after it too.

-----------------------------------------------------------

RouteOriginAttestation { iso(1) identified-organization(3)
   dod(6) internet(1) security(5) mechanisms(5) smime(7)
   mod(0) TBD }

DEFINITIONS EXPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL --

-- IMPORTS NOTHING --

-- Route Origin Attestation Content Type: OID

id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
   us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }

id-ct OBJECT INDENTIFIER ::= { id-smime 1 }

routeOriginAttestion OBJECT IDENTIFIER ::= { id-ct 24 }

-- Route Origin Attestation Content Type: eContent

RouteOriginAttestation ::= SEQUENCE {
   version      [0] INTEGER DEFAULT 0,
   asID             ASID,
   ipAddrBlocks     SEQUENCE (SIZE(1..MAX)) OF ROAIPAddressFamily }

ASID ::= INTEGER

ROAIPAddressFamily ::= SEQUENCE {
   addressFamily OCTET STRING (SIZE (2..3)),
   addresses     SEQUENCE (SIZE (1..MAX)) OF ROAIPAddress }

ROAIPAddress ::= SEQUENCE {
   address   IPAddress,
   maxLength INTEGER OPTIONAL }

IPAddress ::= BIT STRING

END

-----------------------------------------------------------


Some other nits (Sec #s are from the "new" -roa draft):

1. Sec 1, 1st para: r/and AS Number Resource/and Autonomous System 
(AS) Number Resource

2. Sec 1.1: I'd add that familiarity with [SIGN-OBJ] is also assumed

3. Sec 2: r/OID must/OID MUST

4. Sec 3.3: r/the maxLength must/the maxLength MUST

5. Sec 3/1.1: "NOT RECOMMENDED" is 2119 language, but you need to 
modify the text in 1.1 to include it.  You'll get an error from the 
nits checker if you don't include it as follows:

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
  and "OPTIONAL" in this document are to be interpreted as described
  in RFC-2119 [RFC2119].

6. Sec 4: r/the relying party must first/the relying party MUST first

7. Sec 4: r/the EE certificate/the end-entity (EE) certificate

8. Sec 5: r/must/MUST X2

9. Please add that the security considerations of [SIGN-OBJ] apply.

Cheers,

spt

Matt Lepinski wrote:
> A significant portion of the SIDR ROA-Format draft is spent specifying 
> the ASN.1 syntax for the CMS encapsulation of the ROA object. (Note also 
> that the SIDR manifest document also includes this ASN.1 syntax for an 
> identical CMS encapsulation.)
> 
> It was suggested to the authors of the ROA Format draft that the 
> specification of any future RPKI signed objects would be made much 
> simpler if we split the specification of the CMS encapsulation (which 
> pertains to all RPKI signed objects) off from the stuff that is 
> ROA-specific.
> 
> Therefore, we have produced the two attached drafts for your consideration:
> 
> draft-achi-rpki-signed-object is a generic template designed to simplify 
> the specification of RPKI signed objects.
>     Note that to instantiate the template and create a new type of RPKI 
> signed object all you have to do is:
>     1. Get an OID to identify the ContentType for the new type of signed 
> object
>     2. Specify the ASN.1 syntax for the content of the new type of 
> signed object
>     3. Specify any additional steps that are required for validating the 
> new type of signed object (beyond the standard steps required for all 
> RPKI signed objects which are specified in the rpki-signed-object draft)
> 
> draft-ietf-sidr-roa-format is a much shorter version of the roa-format 
> draft which makes use of the generic signed object template and thus 
> only specifies the ROA-specific stuff (that is, the three things I noted 
> above).
> 
> Note that breaking up the ROA-format document in this fashion in no way 
> changes the syntax or semantics of a ROA (i.e., nothing has changes 
> besides the manner of documentation).
> 
> Please take a look at these documents and let us know if this is a good 
> way forward. (If it is a good way forward we can easily change [i.e., 
> shorten] the manifest document to use this signed-object template as well.)
> 
> - Matt Lepinski
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr