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.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
