Lightweight Directory Access Protocol (LDAP) Registrations for PKCS #9
draft-seantek-ldap-pkcs9-08

Multiple attempts to reach the author between February 2021 - April 2021 to restart the process on this document (last handled in 2018) were unsuccessful.  Hence, this document is being marked as "dead".

[Ballot discuss]
This is discuss is entirely my fault and requires action from me...  sorry I didn't catch it sooner that PKCS#9 had not yet been transferred to the IETF for change control.  We can handle this in a couple of ways, I think.  The cleanest is for me to get PKCS#9 transferred and I can start that process right away.

The second option is for me to see if just putting the Intellectual property statement in the IANA registry too would be enough.  I see you have that in the draft.

  License to copy this document is granted provided that it is
  identified as "RSA Security Inc.  Public-Key Cryptography Standards
  (PKCS)" in all material mentioning or referencing this document.

Sorry about this!  I thought we caught all of the remaining ones that had to be transferred.

21 March 2018 - Working on a possible transfer of a license to the IETF to address this discuss.  The sponsoring AD will continue to watch this and hopefully move forward shortly assuming this license transfer will be approved.

[Ballot discuss]
This is discuss is entirely my fault and requires action from me...  sorry I didn't catch it sooner that PKCS#9 had not yet been transferred to the IETF for change control.  We can handle this in a couple of ways, I think.  The cleanest is for me to get PKCS#9 transferred and I can start that process right away.

The second option is for me to see if just putting the Intellectual property statement in the IANA registry too would be enough.  I see you have that in the draft.

  License to copy this document is granted provided that it is
  identified as "RSA Security Inc.  Public-Key Cryptography Standards
  (PKCS)" in all material mentioning or referencing this document.

Sorry about this!  I thought we caught all of the remaining ones that had to be transferred.

21 March 2018 - Working on a possible transfer of a license to the IETF to address this discuss.  The sponsoring AD will continue to watch this and hopefully move forward shortly assuming this license transfer will be approved.  KMM

[Ballot comment]
Need to make sure that IANA's Expert Review completes first.

Kathleen needs to figure out whether restrictive note on RFC 2985 can be lifted and control on it transferred to IETF.

Stephen: I cross checked OIDs against RFC 2985 and http://www.alvestrand.no/ (The latter doesn't contain all of these, but has many).

Mirja: "Updates RFC 2985" seems sensible.

Benoit: I will make sure the Ops-Dir review is taken into consideration.

[Ballot comment]
Romascanu, Dan (Dan)  provided the opsdir review.

comments replicated here.

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








_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

[Ballot comment]
Stephen: I cross checked OIDs against RFC 2985 and http://www.alvestrand.no/ (The latter doesn't contain all of these, but has many).

Mirja: "Updates RFC 2985" seems sensible.

Benoit: I will make sure the Ops-Dir review is taken into consideration.

[Ballot comment]
Stephen: I cross checked OIDs against RFC 2985 and http://www.alvestrand.no/ (The latter doesn't contain all of these, but has many).

Mirja: "Updates RFC 2985" seems sensible.

[Ballot comment]
As mentioned by Dan Romascanu in his OPS DIR review:

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

[Ballot discuss]
This is discuss is entirely my fault and requires action from me...  sorry I didn't catch it sooner that PKCS#9 had not yet been transferred to the IETF for change control.  We can handle this in a couple of ways, I think.  The cleanest is for me to get PKCS#9 transferred and I can start that process right away.

The second option is for me to see if just putting the Intellectual property statement in the IANA registry too would be enough.  I see you have that in the draft.

  License to copy this document is granted provided that it is
  identified as "RSA Security Inc.  Public-Key Cryptography Standards
  (PKCS)" in all material mentioning or referencing this document.

Sorry about this!  I thought we caught all of the remaining ones that had to be transferred.

[Ballot comment]

Did someone check all these attributes vs. what's
deployed in current code? There's the potential for
errors here if that wasn't done, and cross-checked,
which'd be a pity.

I agree with the secdir reviewer's nits [1] and would
recommend they be handled. (I don't think I saw a
response? Apologies if I missed that.)

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06723.html

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-seantek-ldap-pkcs9-06.txt. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First, in Section 7.1 of the current document a request appears to be made to make a new registration in the Internet Directory Numbers (iso.org.dod.internet.directory [1.3.6.1.1.]) registry located at:

https://www.iana.org/assignments/ldap-parameters/

the name and description are not provided.

IANA Question --> Is this the correct registry for the request for registration for an LDAP OID as requested in Section 7.1? If not, what registry is intended.

If this is the correct registry for the request in Section 7.1, this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the Object Identifier Descriptors subregistry of the Lightweight Directory Access Protocol (LDAP) Parameters registry located at:

https://www.iana.org/assignments/ldap-parameters/

a set of new entries will be added to the registry as follows:


Name Type OID Reference
--------------------------------+-----+---------------------------+-------------------
pkcsEntity O 1.2.840.113549.1.9.24.1 [ RFC-to-be ]
naturalPerson O 1.2.840.113549.1.9.24.2 [ RFC-to-be ]
pKCS7PDU A 1.2.840.113549.1.9.25.5 [ RFC-to-be ]
userPKCS12 A 2.16.840.1.113730.3.1.216 [ RFC-to-be ]
pKCS15Token A 1.2.840.113549.1.9.25.1 [ RFC-to-be ]
encryptedPrivateKeyInfo A 1.2.840.113549.1.9.25.2 [ RFC-to-be ]
e A 1.2.840.113549.1.9.1 [ RFC-to-be ]
unstructuredName A 1.2.840.113549.1.9.2 [ RFC-to-be ]
unstructuredAddress A 1.2.840.113549.1.9.8 [ RFC-to-be ]
dob A 1.3.6.1.5.5.7.9.1 [ RFC-to-be ]
dateOfBirth A 1.3.6.1.5.5.7.9.1 [ RFC-to-be ]
pob A 1.3.6.1.5.5.7.9.2 [ RFC-to-be ]
placeOfBirth A 1.3.6.1.5.5.7.9.2 [ RFC-to-be ]
g A 1.3.6.1.5.5.7.9.3 [ RFC-to-be ]
gender A 1.3.6.1.5.5.7.9.3 [ RFC-to-be ]
coc A 1.3.6.1.5.5.7.9.4 [ RFC-to-be ]
countryOfCitizenship A 1.3.6.1.5.5.7.9.4 [ RFC-to-be ]
cor A 1.3.6.1.5.5.7.9.5 [ RFC-to-be ]
countryOfResidence A 1.3.6.1.5.5.7.9.5 [ RFC-to-be ]
pnym A 2.5.4.65 [ RFC-to-be ]
desc A 2.5.4.13 [ RFC-to-be ]

IANA notes that the authors request that a note be added to the following attributes, also to be added to the Object Identifier Descriptors subregistry: "This attribute is to be used in PKCS applications(including PKCS #6, PKCS #7/CMS, and PKCS #12)."

Name Type OID Reference
--------------------------------+-----+---------------------------+-------------------
contentType A 1.2.840.113549.1.9.3 [ RFC-to-be ]
messageDigest A 1.2.840.113549.1.9.4 [ RFC-to-be ]
signingTime A 1.2.840.113549.1.9.5 [ RFC-to-be ]
randomNonce A 1.2.840.113549.1.9.25.3 [ RFC-to-be ]
sequenceNumber A 1.2.840.113549.1.9.25.4 [ RFC-to-be ]
counterSignature A 1.2.840.113549.1.9.6 [ RFC-to-be ]
challengePassword A 1.2.840.113549.1.9.7 [ RFC-to-be ]
extensionRequest A 1.2.840.113549.1.9.14 [ RFC-to-be ]
extendedCertificateAttributes A* 1.2.840.113549.1.9.9 [ RFC-to-be ]
friendlyName A 1.2.840.113549.1.9.20 [ RFC-to-be ]
localKeyId A 1.2.840.113549.1.9.21 [ RFC-to-be ]
signingDescription A 1.2.840.113549.1.9.13 [ RFC-to-be ]
smimeCapabilities A 1.2.840.113549.1.9.15 [ RFC-to-be ]
pkcs9CaseIgnoreMatch M 1.2.840.113549.1.9.27.1 [ RFC-to-be ]
signingTimeMatch M 1.2.840.113549.1.9.27.3 [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the LDAP Syntaxes subregistry of he Lightweight Directory Access Protocol (LDAP) Parameters registry located at:

https://www.iana.org/assignments/ldap-parameters/

two new syntax registrations will be made as follows:

Object Identifier: 1.2.840.113549.1.9.26.1
Syntax: PKCS9String
Owner: IESG
Reference: [ RFC-to-be ]

Object Identifier: 1.2.840.113549.1.9.26.2
Syntax: SigningTIme
Owner: IESG
Reference: [ RFC-to-be ]

IANA understands that the three actions above are the only ones required to be completed upon approval of this document.


Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: alexey.melnikov@isode.com, draft-seantek-ldap-pkcs9@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Lightweight Directory Access Protocol (LDAP) Registrations for PKCS #9) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Lightweight Directory Access Protocol (LDAP) Registrations for PKCS
#9'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-08-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  PKCS #9 includes several useful definitions that are not yet
  reflected in the LDAP IANA registry. This document adds those
  definitions to the IANA registry.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-seantek-ldap-pkcs9/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-seantek-ldap-pkcs9/ballot/


No IPR declarations have been submitted directly on this I-D.

ID-nits complains:

  == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses
    in the document.  If these are example addresses, they should be changed.

But I thin this is red herring: ID-nits thinks that some OIDs are IPv4 addresses.

My AD review:

You are using RFC 2119 keywords without using regular RFC 2119 boilerplate. Please fix in the next revision.

Section 4.1 has "[[TODO: get consensus on this.]]". Is this issue settled now?

I am wondering whether short name registrations should be marked as historic (with *) by IANA?