[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
[ldapext] Review of draft-gennai-smime-cnipa-pec-08.txt
I did not become aware of this I-D and its use of LDAP until recently. Here is a quick review. It's quick in that I didn't try to understand the application the schema is intended to support, just looked at the LDAP bits.
I don't understand the use of naming context "o=postacert". The use of hardcoded DN seems bad to me, and it's unregistered as well. It's unclear whether each deployment of an implementation of this specification is required to use this context. If so, that seems problematic. It would, for instance, preclude two deployments from sharing the same directory system.
The specification includes DN strings, such as "providerName=<name>, o=postacert", which do not conform to LDAP DN. It is recommend that DNs in RFCs be presented as discussed in LDAP DN, e.g <providerName=<name>,o=postacert>.
It is odd and somewhat problematic to match a hash via case-sensitive matching, and to store it as a hexadecimal string. The specification doesn't actually state what it means by 'hexadecimal'. There many ways to write hexadecimal, and certainly case-sensitive matching isn't going to all hexadecimal representations of a particular hash value as equivalent. It would be fare better to store the actual hash as an octet string and do octet wise matching, that is, providerCertificateHash should have syntax octetString and equality rule octetStringMatch. This avoid unnecessary hex encoding/decoding in implementations.
And storing and search for a hash here seems quite odd to me. It's would seem better to just search for the certificate.
Note that {40} in 1.3.6.1.4.1.1466.115.121.1.26{40} does not define a maximum length. It basically extraneous in LDAPv3 (see the LDAP "models" RFC).
The specification of providerCertificate references RFC 2252, which was obsoleted. The specification of the certificate syntax is now in RFC 4523. Note that that ;binary MUST, per RFC 4523, be used with providerCertificate. The specification should echo this require (use the same language used in the specification of userCertificate, see RFC 4523). Also note that the certificate syntax is NOT restricted to DER.
The draft contains a note about the deprecation of the binary syntax. Given the document doesn't use the binary syntax, this is extraneous at best. It seems the authors may have confused ;binary transfer should not be confused with the binary syntax. ;binary transfer is detailed in RFC 4522, and as noted above, MUST be used when requesting and transferring values the certificate syntax.
mailReceipt spec should discuss IDNA and EAI. And {256} is extraneous.
managedDomains spec should discuss IDNA.
providerUnit contains a {32768} which is extraneous.
No LDAP object class descriptions is provided for LDIFLocationURLObject or provider classes, or if what is provided was intended to be an LDAP object class description, it doesn't conform to object class description syntax.
Regarding the LDIFLocationURL, the document likely ought to say something about the MIME type, character set encoding, etc., of the document to returned by the URL.
-- Kurt
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext