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

From: Job Snijders <[email-masked]>
Date: Thu, 4 Feb 2021 18:33:06 +0100

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 [email-masked] -----

Date: Thu, 04 Feb 2021 09:20:26 -0800
From: [email-masked]
To: Job Snijders <[email-masked]>
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 -----

---

From: Russ Housley <[email-masked]>
Date: Thu, 4 Feb 2021 15:33:48 -0500

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=[email-masked]> wrote:
> 
> Dear Working Group,
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Job Snijders <[email-masked]>
Date: Thu, 4 Feb 2021 22:02:10 +0100

On Thu, Feb 04, 2021 at 03:33:48PM -0500, Russ Housley wrote:
> 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.

Thank you Russ! I appreciate your suggestion and will incorporate it.

Kind regards,

Job

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 5 Feb 2021 10:01:09 +0100

Dear Job, WG,

> On 4 Feb 2021, at 18:33, Job Snijders <job=[email-masked]> wrote:
> 
> Dear Working Group,
> 

I have spoken with the other co-authors of the RTA document. We are not oppositional to this work.

I think some words to this extend were expressed earlier, but again, if the working group prefers to have a single signed object which does not include a certificate and CRL chain for out-of-band validation, then a much simpler profile based on rpki signed objects (6488), as you are proposing, makes perfect sense.

I believe that a possible constructive way forward would be to adopt your proposal and define single signed RSC objects there. I will repeat my support in the appropriate thread.

The existing work on RTA can then be modified to leverage RSCs for other use cases. So rather then re-defining the signatures, RTAs could include one or more RSC objects. E.g.:

1) out-of-band validation

RTA could define a profile where a user can be sent an RSC, and some or all CA certificates and CRLs needed for validation for complete out-of-band validation. The CMS profile allows to include these, but 6488 does not, and if we do not wish to complicate RSC with this concern, then a level of indirection can help.

2) multi-signing

For those use cases where multiple signatures across different resource sets *are* required (yes, I know this is a corner case), the RTA can define a profile where multiple single signed RSC objects are bundled together.

Of course there are details to cover, but hopefully this gives a good high-level idea, and this approach will allow us all to work constructively together on complementary work.

So, we intend to draft a new version of the RTA specification along these lines. Please speak up if you feel this is not a good way forward.

Kind regards
Tim

---

From: Job Snijders <[email-masked]>
Date: Fri, 5 Feb 2021 23:07:01 +0100

Dear working group,

I.... hopefully managed to generate the world's first RPKI Signed
Checklist! It is possible this RSC was generated incorrectly, I don't
have a proper validator yet. Generating this RSC .sig involved an ASN.1
to C to XML to DER conversion process, the Lament Configuration, and vi.

Attached to this email are 3 files:

    432K Feb  5 21:31 b42_ipv6_loa.png             \_ arbitrary files
    212B Feb  5 21:31 b42_service_definition.json  /
    1.6K Feb  5 21:31 checklist.sig                <!-- the RSC!

The 'b42_ipv6_loa.png' and 'b42_service_definition.json' files are part
of an imaginary private business to business process in which I try to
prove to a service provider I'm authorized to use 2001:67c:208c::/48.

The 'b42_service_definition.json' could be part of a challenge/response
process initiated by the ISP. The RPKI can now be used to sign arbitrary
files, even hand-written BYOIP Letters Of Authority (LOAs) like the .png :-)

The content-type OID in 'checklist.sig' is '1.3.6.1.4.1.41948.49'. This
OID is a placeholder from the PEN realm, for testing until an assignment
in the relevant SMI registry has been created. Make sure to keep this
OID on a feature branch or hidden behind a compile time option! The
on-the-wire format can still change in future versions of the draft!

The EE certificate in 'checklist.sig' should be validatable via SKI
2C:CA:BC:2A:5D:CB:91:61:AA:B6:27:1A:68:B9:7A:20:01:92:B0:9E (a copy can
be found here: http://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/LMq8Kl3LkWGqticaaLl6IAGSsJ4.cer.html)
towards the RIPE NCC Trust Anchor.

The 'checklist.sig' eContent is also available in XML format here:
https://github.com/job/draft-rpki-checklists/blob/main/example/b42.xml

The ASN.1 module is here https://datatracker.ietf.org/doc/html/draft-spaghetti-sidrops-rpki-rsc-01

I hope this helps interested parties to implement signers or validators.

Kind regards,

Job

---

From: George Michaelson <[email-masked]>
Date: Mon, 8 Feb 2021 08:39:23 +1000

> to C to XML to DER conversion process, the Lament Configuration, and vi.

When we designed what became RTA, this kind of provisioning problem
was exactly what we wanted it to target.

I don't much mind what you call it, having something able to generate
an EE signature over external objects and associate them with some
address and AS resources is great.

Well done Job.

-George

---

From: Job Snijders <[email-masked]>
Date: Thu, 11 Feb 2021 03:36:33 +0100

Dear group,

> prove to a service provider I'm authorized to use 2001:67c:208c::/48.

Alas... the February 5th 'checklist.sig' file was not correctly
generated.

Tom Harrison from APNIC was so kind to point out two errors:

* The X509 v3 CRLDP extension was missing from the embedded EE
  certificate. RFC 65487 Section 4.8.6 mandates the presence of this
  extension.
* The "IPAddress" BIT STRING in the "ResourceBlock" was malformed.

For testing purposes a newly generated 'checklist.sig' (rectifying the
above issues) has been attached to this message. Again the temp OID is
1.3.6.1.4.1.41948.49.

Thank you for the feedback!

Kind regards,

Job