Subject: [sidr] Comments on draft-archi-rpki-signed-object

From: Sean Turner <[email-masked]>
Date: Mon, 20 Sep 2010 20:49:27 -0400

I think this draft is in very good shape.  Here are my (mostly minor)
comments on this I-D.  IMHO this draft is good to go after
incorporating these changes.

spt

----------

1) Abstract: r/the Resource Public Key Infrastructure/the Resource
Public Key Infrastructure (RPKI)

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

3) Sec 1, 1st para: r/act as CAs/act as Certification Authorities (CAs)

4) Sec 1, last para: r/ASN.1/Abstract Syntax Notation One (ASN.1)

5) Sec 1, last para: Please add normative references to the 
appropriate ITU-T standards for ASN.1 (not sure which year you want to 
point to -maybe the same as CMS?).

6) Sec 1.1, 1st para: It's probably also worth throwing CMS in to the
list:

OLD:

It is assumed that the reader is familiar with the terms and concepts
described in "Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile" [RFC5280]> and "X.509
Extensions for IP Addresses and AS Identifiers" [RFC3779].

NEW:

It is assumed that the reader is familiar with the terms and concepts
described in "Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile" [RFC5280], "X.509
Extensions for IP Addresses and AS Identifiers" [RFC3779], and
"Cryptographic Message Syntax (CMS)" [RFC5652].

7) Sec 1.1 and Sec 8: r/RFC 2119/[RFC2119] or r/RFC 2119/RFC 2119 
[RFC2119] and add the following as a
normative reference:

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

8) Sec 2.2, last para: r/set must/set MUST

9) Sec 2.1.3.1 (or in section 4): Should we specify whether the
document that specifies the OID be standards track?

10) Sec 2.1.3.2: sequence and SEQUENCE are both used.  Should they 
both be capitalized?

11) Sec 2.1.4: r/RPKI EE certificate/RPKI End Entity (EE) certificate

12) Sec 2.1.6: r/defined under CMS/defined in CMS

13) Sec 2.1.6.4: Add references to CMS for the different attributes:

OLD:

  The signedAttr element MUST be present and MUST include the content-
  type and message-digest attributes.  The signer MAY also include the
  signing-time signed attribute, the binary-signing-time signed
  attribute, or both signing-time attributes.

NEW:

  The signedAttr element MUST be present and MUST include the content-
  type and message-digest attributes [RFC5652].  The signer MAY also
  include the signing-time signed attribute [RFC5652], the
  binary-signing-time signed attribute [RFC4049], or both signing-time
  attributes.

14) Sec 2.1.6.4.1: r/attrValues must contain/attrValues MUST contain

15) Sec 2.1.6.4.2, last para: I think you should be pointing to Sec
5.4 not 11.1 in 5652.

16) Sec 2.1.6.4.4: Should there be a MUST NOT for BinarySigningTime
affecting the validity of the object (like SigningTime)?

17) Sec 3 Step 1.c (to match 2.1.6.2): r/SubjectKeyIdentifier
(SKI)/SubjectKeyIdentifier

18) Sec 3: Doesn't there need to be a step that checks that only the
four attributes are included?  There's a MUST NOT contain any other
attributes in 2.1.6.4.

19) Sec 3 Step 3: r/end-entity certificate in the resource PKI/EE
certificate in the RPKI

20) Sec 4 Step 2: r/The syntax must/The syntax MUST

21) Sec 4 Step 3: r/Attribute must/Attribute MUST

22) Sec 5: Add that the security considerations of RFC5652 apply.