Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-06.txt

From: Christopher Morrow <[email-masked]>
Date: Thu, 23 Sep 2021 13:38:53 -0400

Howdy!
I believe this document is at the point where WGLC is the next step?
I believe also we are adding Russ Housley as person running the show
through the final boss fight with IETF@/IESG.
I know I'd like to say: "Thanks to Stephen for his work on this, it's
certainly been a journey :)"

Provided this is the state the authors agree on and they want to move to
WGLC.... please verify that is the case on-list :)

On Mon, Jul 26, 2021 at 9:26 AM <[email-masked]> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the SIDR Operations WG of the IETF.
>
>         Title           : Manifests for the Resource Public Key
> Infrastructure (RPKI)
>         Authors         : Rob Austein
>                           Geoff Huston
>                           Stephen Kent
>                           Matt Lepinski
>         Filename        : draft-ietf-sidrops-6486bis-06.txt
>         Pages           : 17
>         Date            : 2021-07-26
>
> Abstract:
>    This document defines a "manifest" for use in the Resource Public Key
>    Infrastructure (RPKI).  A manifest is a signed object (file) that
>    contains a listing of all the signed objects (files) in the
>    repository publication point (directory) associated with an authority
>    responsible for publishing in the repository.  For each certificate,
>    Certificate Revocation List (CRL), or other type of signed objects
>    issued by the authority that are published at this repository
>    publication point, the manifest contains both the name of the file
>    containing the object and a hash of the file content.  Manifests are
>    intended to enable a relying party (RP) to detect certain forms of
>    attacks against a repository.  Specifically, if an RP checks a
>    manifest's contents against the signed objects retrieved from a
>    repository publication point, then the RP can detect "stale" (valid)
>    data and deletion of signed objects.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-6486bis-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-6486bis-06
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 23 Sep 2021 14:12:26 -0400

I confirm that I will become an editoer for this document if none of the existing authors want to do so.

Russ

> On Sep 23, 2021, at 1:38 PM, Christopher Morrow <[email-masked]> wrote:
> 
> Howdy!
> I believe also we are adding Russ Housley as person running the show through the final boss fight with IETF@/IESG.
> I know I'd like to say: "Thanks to Stephen for his work on this, it's certainly been a journey :)"
> 
> Provided this is the state the authors agree on and they want to move to WGLC.... please verify that is the case on-list :)
> 
> 
> On Mon, Jul 26, 2021 at 9:26 AM <[email-masked] <mailto:[email-masked]>> wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>         Title           : Manifests for the Resource Public Key Infrastructure (RPKI)
>         Authors         : Rob Austein
>                           Geoff Huston
>                           Stephen Kent
>                           Matt Lepinski
> https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/ <https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/>
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-6486bis-06 <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-6486bis-06>
> 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-6486bis-06 <https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-6486bis-06>
> 
> 
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sidrops <https://www.ietf.org/mailman/listinfo/sidrops>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 23 Sep 2021 17:15:34 -0400

Russ,

I believe the last batch of edits addressed all of the outstanding 
questions., I posted the revised version during the IETF meeting, and, 
perhaps predictably, received no feedback.

So, let's just initiate WGLC and see what happens, OK>

Steve
>> On Sep 23, 2021, at 1:38 PM, Christopher Morrow 
>> <[email-masked] <mailto:[email-masked]>> 
>> wrote:
>>
>> Howdy!
>> I believe also we are adding Russ Housley as personï¿½running the show

---

From: Russ Housley <[email-masked]>
Date: Thu, 23 Sep 2021 17:41:58 -0400

Steve:

Totally fine with me.

Russ

> On Sep 23, 2021, at 5:15 PM, Stephen Kent <stkent=[email-masked]> wrote:
> 
> Russ,
> 
> I believe the last batch of edits addressed all of the outstanding questions., I posted the revised version during the IETF meeting, and, perhaps predictably, received no feedback.
> 
>>> On Sep 23, 2021, at 1:38 PM, Christopher Morrow <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Howdy!
>>> I believe also we are adding Russ Housley as personï¿½running the show through the final boss fight with IETF@/IESG.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 24 Sep 2021 07:54:04 -0400

This version of the ID was published during the last IETF meeting, and 
has received no comments since then.

I'd like to initiate WGLC at this time.

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 24 Sep 2021 15:07:20 +0200

Hi,

> On 24 Sep 2021, at 13:54, Stephen Kent <stkent=[email-masked]> wrote:
> 
> This version of the ID was published during the last IETF meeting, and has received no comments since then.

Steve, thank you for your perseverance.

I reviewed this once more. My apologies for not responding earlier.

Thank you for clarifying (in -05) that the previous manifest MUST be revoked.

What is still missing, I believe, is similar normative language when it comes to
replacing existing other named files (ROA, certificates etc).

If the working group feels that any replaced (non-CRL) files defined in the
manifest scope MUST also be revoked if they are not expired then I think it
would be good to include a sentence to this effect. Perhaps we could amend the
start of the second paragraph of section 5.2:

CURRENT:
 
   An authority MUST issue a new manifest in conjunction with the
   finalization of changes made to objects in the publication point.

SUGGESTED:

   An authority MUST issue a new manifest in conjunction with the
   finalization of changes made to objects in the publication point.
   If any named objects in the publication point were replaced then
   the authority MUST ensure that the file hash is updated accordingly
   in the new manifest. In addition to this the authority MUST revoke
   the previous object, if it is of a type that can be revoked (i.e. not
   a CRL) and it is not expired.

Note that I made an argument earlier in favour of not revoking objects which
section 6 now says MUST NOT be used anyway. But rather than trying to re-ignite,
I have accepted people want redundancy, I am looking for clarity on all
revocations so we don't end up with different interpretations again in future.

Kind regards,
Tim

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 24 Sep 2021 13:43:31 -0400

Howdy!
So, I think the 6486bis document authors are asking:
  "Go directly to WGLC, and please take Tim's question/comment as the
first comment in the WGLC"

Further to that I'll send a new WGLC start message... in a few moments :)

---

From: Stephen Kent <[email-masked]>
Date: Sun, 26 Sep 2021 20:57:39 -0400

Tim,

I'll wait to see what other WG members suggest before making this 
change, but I do not see a problem with replacing the current test with 
your proposed revision.

Steve

>> Hi,
>>
>>> On 24 Sep 2021, at 13:54, Stephen Kent<stkent=[email-masked]>  wrote:
>>>

---

From: Ben Maddison <[email-masked]>
Date: Thu, 30 Sep 2021 19:13:02 +0200

Hi Steve, Russ, all,

On 09/26, Stephen Kent wrote:
> 
> Tim,
> 
> I'll wait to see what other WG members suggest before making this change,
> but I do not see a problem with replacing the current test with your
> proposed revision.
> 
I think that Tim's suggestion is a good one.
We should err on the side of being explicit about this sort of thing.

Additionally, some minor nits/suggestions/questions:

section 2.
    current:
        all published signed objects that are verifiable using EE
        certificates [RFC6487] issued by this CA.
    suggested:
        all published signed objects that are verifiable using EE
        certificates [RFC6487] issued by this CA, other than the
        manifest itself.

section 4.2.1 - manifestNumber:
    Should the document describe what should be done if the
    manifestNumber reaches 2^20, or was it judged that this is large
    enough that it will never happen?

    In the latter case, we should mandate that the value be incremented
    *by 1* to avoid the possibility that an implementation increments in
    large enough steps to hit the maximum eventually.

section 4.2.1 - nextUpdate:
    current:
        If the authority alters any of the items that it has published
        in the repository publication point, then the authority MUST
        issue a new manifest before the nextUpdate time.

    I read the above as saying that the manifest must be re-issued
    before the nextUpdate time only if the repository contents have changed.

    Unless I am missing something very obvious, the CA must re-issue the
    manifest before that time, regardless of whether anything has
    changed?

    suggested:
        If the authority alters any of the items that it has published
        in the repository publication point, then the authority MUST
        issue a new manifest.
        In any event, the authority MUST issue a new manifest
        (possibly containing an unchanged fileList) before the
        nextUpdate time.

section 7:
    "... a CRL issued by the CA [RFC6481],corresponding to the scope ..."
                                          ^
                            missing space |

appendix A:
    The ASN.1 module should define an instance of the CONTENT-TYPE
    class:

    ```
    IMPORTS
      CONTENT-TYPE FROM CryptographicMessageSyntax-2010 -- in [RFC6268]
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
          pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }

    ct-rpkiManifest CONTENT-TYPE ::=
        { TYPE Manifest IDENTIFIED BY id-ct-rpkiManifest }
    ```

Please let me know if anything requires elaboration.

Cheers,

Ben

---

From: Russ Housley <[email-masked]>
Date: Thu, 30 Sep 2021 14:51:14 -0400

>        { TYPE Manifest IDENTIFIED BY id-ct-rpkiManifest }

I agree, it would be good to include an updates ASN.1 module.  To do so, we need to ask IANA to assign a module identifier.

The improved module is here:

   RPKIManifest-2021
      { iso(1) member-body(2) us(840) rsadsi(113549)
        pkcs(1) pkcs9(9) smime(16) mod(0) TBD }
    
   DEFINITIONS EXPLICIT TAGS ::=
   BEGIN
   
   -- EXPORTS ALL --

   IMPORTS

   CONTENT-TYPE
      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) } ;

   -- Manifest Content Type

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

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

   id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }

   Manifest ::= SEQUENCE {
      version        [0] INTEGER DEFAULT 0,
      manifestNumber     INTEGER (0..MAX),
      thisUpdate         GeneralizedTime,
      nextUpdate         GeneralizedTime,
      fileHashAlg        OBJECT IDENTIFIER,
      fileList           SEQUENCE SIZE (0..MAX) OF FileAndHash
      }

   FileAndHash ::= SEQUENCE {
      file  IA5String,
      hash  BIT STRING
      }

   END

I checked that it compiles once a module number is filled in.

Russ

---

From: Ben Maddison <[email-masked]>
Date: Thu, 30 Sep 2021 22:52:13 +0200

Hi Russ,

On 09/30, Russ Housley wrote:
> ...
Why CMS-2009 rather than CMS-2010?

Cheers,

Ben

---

From: Russ Housley <[email-masked]>
Date: Thu, 30 Sep 2021 17:11:26 -0400

> On Sep 30, 2021, at 4:52 PM, Ben Maddison <benm=[email-masked]> wrote:
> 
> Signed PGP part
> Hi Russ,
> 

Thanks.  It is better to use RFC 6268...

   RPKIManifest-2021

   -- EXPORTS ALL --

   IMPORTS

     CONTENT-TYPE
     FROM CryptographicMessageSyntax-2010 -- in [RFC6268]
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;

   -- Manifest Content Type

   Manifest ::= SEQUENCE {

   END

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 1 Oct 2021 08:47:51 +0200

Hi,

I saw this:

> On 30 Sep 2021, at 23:11, Russ Housley <[email-masked]> wrote:
> 

This is how it was done, and also what the e.g. the ROA profile uses.

However, reading the ASPA profile I came across another way, like:

     version        [0] VERSION DEFAULT v0,

     VERSION ::= INTEGER { v0(0) }

This does not change the profile really afaik, but I believe this
explicitly limits the available options of 'version' to just 'v0',
i.e. an INTEGER with value 0. So, this may be a bit better in that
regard.

Tim