Skip to main content

Last Call Review of draft-seantek-ldap-pkcs9-05
review-seantek-ldap-pkcs9-05-opsdir-lc-romascanu-2016-08-16-00

Request Review of draft-seantek-ldap-pkcs9
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-08-17
Requested 2016-07-25
Authors Sean Leonard
I-D last updated 2016-08-16
Completed reviews Genart Telechat review of -06 by Matthew A. Miller (diff)
Secdir Last Call review of -05 by Yoav Nir (diff)
Opsdir Last Call review of -05 by Dan Romascanu (diff)
Assignment Reviewer Dan Romascanu
State Completed
Request Last Call review on draft-seantek-ldap-pkcs9 by Ops Directorate Assigned
Reviewed revision 05 (document currently at 08)
Result Ready
Completed 2016-08-16
review-seantek-ldap-pkcs9-05-opsdir-lc-romascanu-2016-08-16-00

Hi,



I have reviewed draft-seantek-ldap-pkcs9-06.txt as part of the Operational
directorate's ongoing effort to review all IETF documents being processed by
the IESG.  These comments were written with the intent of improving the
operational
 aspects of the IETF drafts. Comments that are not addressed in last call may
 be included in AD reviews during the IESG review.  Document editors and WG
 chairs should treat these comments just like any other last call comments.



This I-D adds IANA considerations relevant to RFC 2985 which is the
Informational RFC version of the Public Key Cryptography Standards #9, a
product of RSA Laboratories. Basically it creates an LDAP OID which makes
possible registration
 of a relevant subset of attributes, their descriptors and syntax that can be
 stored in an LDAP directory.



An RFC 5706 review does not apply. I have not detected any immediate
operational impact, and the definition of the registers under IANA can only
better structure the management tasks.



I believe the document is 'Ready' for publication from the OPS-DIR perspective.



The following comments are not related directly to the operational aspects, but
can improve the quality of the document and its readability and usability by IT
personal and network operators:



-



It would help to expand PKCS and include one paragraph that describes where it
comes from and how it is used – this may be very trivial for security experts
but not to all operators or other users of the future
 RFC

-



The following sentence in section 4 is cumbersome because of the double
negation, I suggest to reformulate it: ‘

The attributes in Appendix B.3 that are

not highly unlikely to be stored in a Directory are registered via this
document.

’

-



Section 4.1 includes the phrase: ‘Since all specifications are under the change
control of the IETF, …’ – actually the abstract of RFC 2985 makes clear that
‘change control is retained within the PKCS process’
 (which as I understand belongs to the RSC Laboratories. If things have changed
 since the publication of RFC 2985 (November 2000) it would be useful to
 document this



Regards,



Dan