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

[Ben Maddison <[e-mail]>]

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