Re: [Sidrops] RPKI Signed Checklists - draft-spaghetti-sidrops-rpki-rsc-00

Job:

I have one suggestion for the ASN.1 module.  I'd rather see the hash of the file as an OCTET STRING (instead of a BIT STRING).  This would be more in line with CMS.

Below is the resulting module if you accept this suggestion.  After filing in the TBDs, this module does compile.

Russ

= = = = = = = = =

   RpkiSignedChecklist-2021
     { iso(1) member-body(2) us(840) rsadsi(113549)   
       pkcs(1) pkcs9(9) smime(16) mod(0) TBD } 

   DEFINITIONS EXPLICIT TAGS ::=
   BEGIN

   IMPORTS
     CONTENT-TYPE, Digest, DigestAlgorithmIdentifier
     FROM CryptographicMessageSyntax-2009 -- in [RFC5911]
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) }

     ASIdOrRange, IPAddressFamily
     FROM IPAddrAndASCertExtn -- in [RFC3779]
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) mod(0)
         id-mod-ip-addr-and-as-ident(30) } ;

   ct-rpkiSignedChecklist CONTENT-TYPE ::=
       { TYPE RpkiSignedChecklist IDENTIFIED BY
         id-ct-signedChecklist }

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

   RpkiSignedChecklist ::= SEQUENCE {
     version  [0]          INTEGER DEFAULT 0,
     resources             ResourceBlock,
     digestAlgorithm       DigestAlgorithmIdentifier,
     checkList             SEQUENCE SIZE (1..MAX) OF FileAndHash }

   FileAndHash ::= SEQUENCE {
     file            IA5String,
     hash            Digest }

   ResourceBlock ::= SEQUENCE {
       asID         [0]       AsList OPTIONAL,
       ipAddrBlocks [1]       IPList OPTIONAL }
       -- at least one of asID or ipAddrBlocks MUST be present
       ( WITH COMPONENTS { ..., asID PRESENT} |
         WITH COMPONENTS { ..., ipAddrBlocks PRESENT } )

   AsList ::= SEQUENCE (SIZE(1..MAX)) OF ASIdOrRange

   IPList ::= SEQUENCE (SIZE(1..MAX)) OF IPAddressFamily

   END

> On Feb 4, 2021, at 12:33 PM, Job Snijders <job=40fastly.com@dmarc.ietf.org> wrote:
> 
> Dear Working Group,
> 
> I've produced a specification which at a high level might appear similar
> to RTA, but has fundamentally different semantics.
> 
> RTA enables multiple signers to attest exactly one hash for an unnamed
> digital object, but RSC on the other hand enables a single signer to
> attest one or more named digital objects.
> 
> I believe the ability to pass filenames around will greatly improve
> operations for administrators.
> 
> Another advantage of RSC should be that in closely following the RFC
> 6488 template the burden of implementation is significantly reduced.
> 
> I would appreciate the working group taking a look and considering
> adoption. After adoption the IANA early allocation procedure can be used
> to obtain OIDs, after which running code can demonstrated, and then
> perhaps onwards to deployment.
> 
> Kind regards,
> 
> Job
> 
> ----- Forwarded message from internet-drafts@ietf.org -----
> 
> Date: Thu, 04 Feb 2021 09:20:26 -0800
> From: internet-drafts@ietf.org
> To: Job Snijders <job@fastly.com>
> Subject: New Version Notification for draft-spaghetti-sidrops-rpki-rsc-00.txt
> 
> 
> A new version of I-D, draft-spaghetti-sidrops-rpki-rsc-00.txt
> has been successfully submitted by Job Snijders and posted to the
> IETF repository.
> 
> Name:		draft-spaghetti-sidrops-rpki-rsc
> Revision:	00
> Title:		RPKI Signed Checklists
> Document date:	2021-02-04
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/archive/id/draft-spaghetti-sidrops-rpki-rsc-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-spaghetti-sidrops-rpki-rsc
> Htmlized:       https://tools.ietf.org/html/draft-spaghetti-sidrops-rpki-rsc-00
> 
> 
> Abstract:
>   This document defines a Cryptographic Message Syntax (CMS) profile
>   for a general purpose listing of checksums (a 'checklist'), for use
>   with the Resource Public Key Infrastructure (RPKI).  The objective is
>   to allow an attestation, in the form of a listing of one or more
>   checksums of arbitrary digital objects (files), to be signed "with
>   resources", and for validation to provide a means to confirm a
>   specific Internet Resource Holder produced the signed checklist.  The
>   profile is intended to provide for the signing of a checksum listing
>   with an arbitrary set of Internet Number Resources.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> 
> ----- End forwarded message -----
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops