Subject: [ldapext] Fwd: Request for LDAP expert review of PEC object identifier descriptors

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 20 Oct 2010 06:20:09 -0700

Any comments?   If so, please direct them to [email-masked].

-- Kurt

Begin forwarded message:

> From: Alba Shahin <[email-masked]>
> Date: October 4, 2010 8:37:48 AM PDT
> To: [email-masked]
> Cc: Sean Turner <[email-masked]>, "Polk, William T." <[email-masked]>, [email-masked]
> Subject: Request for LDAP expert review of PEC object identifier descriptors
> x-spam-score: 1.882
> x-spam-status: No, score=1.882 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001]
> list-id: Discussion of issues related to directories <directory.ietf.org>
> 
> Hello,
>  
> We would like to request an expert review of the LDAP object identifier descriptors defined in PEC (Italian Certified Electronic Mail)
> [ http://www.ietf.org/id/draft-gennai-smime-cnipa-pec-08.txt ] and pasted below.
>  
> (Some minor changes were made below wrt what’s in the draft).
>  
> We look forward to your feedback on this.
>  
> Thank you.
> --Alba
>  
> ----
>  
> 8.2.1. Registration of Object Classes
>  
>    Subject: Request for LDAP Descriptor Registration
>  
>    Descriptor (short name): See comments
>   
>    Object Identifier: See comments
>   
>    Person & email address to contact for further information:
>       See "Author/Change Controller"
>  
>    Usage: object class
>   
>    Specification: (I-D)
>  
>    Author/Change Controller:
>  
>       Claudio Petrucci
>       DigitPA
>       Viale Carlo Marx 31/49
>       00137 Roma
>       Italy
>       EMail: [email-masked]
>  
>    Comments:
>  
>       The following object identifiers and associated object classes
>       are requested to be registered.
>      
>          OID                                       Object Class 
>          -------------------------    -----------------------
>          1.3.6.1.4.1.16572.2.1.1      LDIFLocationURLObject
>          1.3.6.1.4.1.16572.2.1.2      provider
>      
>       
>       Please also see the associated registration request for the
>       providerCertificateHash, providerCertificate, providerName,
>       mailReceipt, managedDomains, LDIFLocationURL, and providerUnit
>       attribute types.
>      
> 8.2.2. Registration of Attribute Types
>  
>    Subject: Request for LDAP Descriptor Registration
>  
>    Descriptor (short name): See comments
>   
>    Object Identifier: See comments
>   
>    Person & email address to contact for further information:
>       See "Author/Change Controller"
>  
>    Usage: attribute type
>   
>    Specification: (I-D)
>  
>    Author/Change Controller:
>  
>       Claudio Petrucci
>       DigitPA
>       Viale Carlo Marx 31/49
>       00137 Roma
>       Italy
>       EMail: [email-masked]
>  
>    Comments:
>  
>       The following object identifiers and associated attribute types
>       are requested to be registered.
>  
>          OID                                      Attribute Type 
>          -------------------------    -------------------------
>          1.3.6.1.4.1.16572.2.2.1      providerCertificateHash
>          1.3.6.1.4.1.16572.2.2.2      providerCertificate
>          1.3.6.1.4.1.16572.2.2.3      providerName
>          1.3.6.1.4.1.16572.2.2.4      mailReceipt
>          1.3.6.1.4.1.16572.2.2.5      managedDomains
>          1.3.6.1.4.1.16572.2.2.6      LDIFLocationURL
>          1.3.6.1.4.1.16572.2.2.7      providerUnit
>  
>  
>       Please also see the associated registration request for the
>       LDIFLocationURLObject and provider object classes.

---

From: Steven Legg <[email-masked]>
Date: Thu, 21 Oct 2010 10:22:27 +1100

I don't have a problem with any of the names requested in that they
don't clash with anything I'm aware of. However, a name like "provider"
is fairly generic and might clash with someone's local definition.
I would suggest prefixing all the names with "pec" to reduce the chance
of conflict (so pecProvider, pecProviderCertificateHash, etc.).

Regards,
Steven

On 21/10/2010 12:20 AM, Kurt Zeilenga wrote:
> Any comments? If so, please direct them to [email-masked]
> <mailto:[email-masked]>.
>
> -- Kurt
>
> Begin forwarded message:
>
>> *From: *Alba Shahin <[email-masked]
>> <mailto:[email-masked]>>
>> *Date: *October 4, 2010 8:37:48 AM PDT
>> *To: [email-masked] <mailto:[email-masked]>
>> *Cc: *Sean Turner <[email-masked] <mailto:[email-masked]>>, "Polk,
>> William T." <[email-masked] <mailto:[email-masked]>>,
>> [email-masked]
>> <mailto:[email-masked]>
>> *Subject: **Request for LDAP expert review of PEC object identifier
>> descriptors*
>> *x-spam-score: *1.882
>> *x-spam-status: *No, score=1.882 tagged_above=-999 required=5
>> tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245,
>> HTML_MESSAGE=0.001]
>> *list-id: *Discussion of issues related to directories
>> <directory.ietf.org <http://directory.ietf.org>>
>>
>> Hello,
>> We would like to request an expert review of the LDAP object
>> identifier descriptors defined in PEC (Italian Certified Electronic Mail)
>> [http://www.ietf.org/id/draft-gennai-smime-cnipa-pec-08.txt] and
>> pasted below.
>> EMail:[email-masked] <mailto:[email-masked]>
>> Comments:
>> EMail:[email-masked] <mailto:[email-masked]>
>> Comments:
> _______________________________________________
> Ldapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ldapext

---

From: Alba Shahin <[email-masked]>
Date: Fri, 22 Oct 2010 13:01:55 +0200

Hello Steven.

Thank you for the comment. We agree that adding a "pec" prefix would make
certain values less prone to misunderstandings, but we'd like to point out
that there are currently several functioning implementations that use the
values as defined in the draft. If possible we would like said draft to be
representative of how things are right now, therefore maintain the values
that are being used by those existing implementations.
We think they should be unambiguous in any case, since those values are
defined within the PEC context under the PEC tree.

Do you think keeping the values as they are now is possible?

Regards,
--Alba

-----Original Message-----
From: Steven Legg [mailto:[email-masked]] 
Sent: giovedì 21 ottobre 2010 01:22
To: [email-masked]; [email-masked]
Cc: Kurt Zeilenga; [email-masked]
Subject: Re: [ldapext] Fwd: Request for LDAP expert review of PEC object
identifier descriptors

I don't have a problem with any of the names requested in that they don't
clash with anything I'm aware of. However, a name like "provider"
is fairly generic and might clash with someone's local definition.
I would suggest prefixing all the names with "pec" to reduce the chance of
conflict (so pecProvider, pecProviderCertificateHash, etc.).

Regards,
Steven

On 21/10/2010 12:20 AM, Kurt Zeilenga wrote:
>> *Cc: *Sean Turner <[email-masked] <mailto:[email-masked]>>, 
>> "Polk, William T." <[email-masked] 
>> <mailto:[email-masked]>>, 
>> identifier descriptors defined in PEC (Italian Certified Electronic 
>> Mail) [http://www.ietf.org/id/draft-gennai-smime-cnipa-pec-08.txt] 
>> and pasted below.
>> Subject: Request for LDAP Descriptor Registration Descriptor (short 
>> name): See comments Object Identifier: See comments Person & email 
>> address to contact for further information:
>> The following object identifiers and associated object classes are 
>> requested to be registered.
>> OID Object Class
>> Subject: Request for LDAP Descriptor Registration Descriptor (short 
>> name): See comments Object Identifier: See comments Person & email 
>> address to contact for further information:
>> The following object identifiers and associated attribute types are 
>> requested to be registered.
>> OID Attribute Type

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 24 Oct 2010 13:33:53 -0700

Alba,

First, I like to note that this 'LDAP expert review' is limited, per BCP 64, to the registration requests, as well as the use of non-registered protocol values (see below).  It's not a review of your technical specification.  However, it's hard for me not to comment on a few obvious technical issues I found by quick scan of this document.  Hence, I will separately send a few technical comments separately (with my IANA "LDAP expert review" hat off).

While the I-D's 8.2 is properly titled 'Registration of LDAP object identifier descriptors', the subsections 8.2.1 and 8.2.2 incorrectly request LDAP OID registration.  This caused some confusion at IANA.  While it fine to use a table to avoid having 9 separate templates, there is no need to have two tables of descriptors.  Using one table, of the form of the "Object Identifier Descriptors" registry in the IANA ldap-parameter file <http://www.iana.org/assignments/ldap-parameters> would be better (both less confusing and easier on IANA (they could just cut-n-paste)).  Please update the I-D to have a single table-based registration request for all 9 requested descriptors.

Like Steve, I generally prefer that descriptor values be more specific and relate more clearly to the application they are designed for.  As Steven suggests, prefixing everything with 'pec' would generally be appropriate.

I do understand the desire of not wanting to require existing implementations to change.  I think here one has to balance the possibility of future real world conflicts, which will require some implementations (PECs or the conflicting ones) to change to co-exist.   Registration with IANA may well aide PECs to "win" such conflicts.   However, so long as the community understands the possibility of such conflicts, and knowing PECs might not win in the real world despite being registered, I don't object to registration of these descriptors as requested.  (The two I am most concerned about are 'provider' and 'mailReceipt'.)

Hence, I, as the assigned LDAP registration "expert", tentatively approve the registration of these 9 descriptors pending update of the IANA consideration section as discussed above, such registration to be made by IANA just prior to publication as an RFC.  Upon update, please notify me so that I can take appropriate action (e.g., notify IANA that all is well).

However, if for any reason the schema were to change (such as due to late comments :-), I strongly advise injecting a 'pec' prefix into every descriptor.

Lastly, I note the I-D suggests the use of naming context named "o=postacert" but no where details how this name was properly delegated for the purposes discussed in the I-D.   Presumedly this is because it's not properly delegated.  Traditionally, LDAP relies on X.500 delegation or DNS-based name delegation.  That is, names properly delegated in X.500 or DNS, each by an appropriate naming authority, are usable in LDAP (via mechanical translation) without the need for any further registration requirement.   Traditionally, top level naming contexts of type o (organization) have been unregulated.  However, this may change in the future due to the popularity of top-level organization naming.

While "o=portacert" is not registrable (at this time), one could registered a domain namefor this purpose of use in constructing an LDAP DN.  (If the authors want to pursue this approach, I would suggest bringing in a DNS expert.*)  If the authors wish to continue to use "o=postacert", I recommend an IESG note be added that this specification utilized unregistered LDAP DN name space which may lead to conflict with other registered or unregistered names.

Regards, Kurt

(* At first, I was thinking of a domain under .arpa could be used, but it seems that this purpose likely met the requirements for .arpa delegation).

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 24 Oct 2010 13:34:47 -0700

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

---

From: Sean Turner <[email-masked]>
Date: Tue, 26 Oct 2010 21:08:33 -0400

On 10/24/10 4:34 PM, Kurt Zeilenga wrote:

> mailReceipt spec should discuss IDNA and EAI.

Wouldn't referring to [SMTP] (RFC 5322) suffice?

OLD:

The 'mailReceipt' attribute contains the provider's email address to 
which take in charge and virus detection PEC notifications are sent.

NEW:

The 'mailReceipt' attribute contains the provider's email address 
[SMTP] to which take in charge and virus detection PEC notifications 
are sent.

> managedDomains spec should discuss IDNA.

Ditto:

OLD:

The 'managedDomains' attribute lists the PEC domains that are handled 
by the provider.

NEW:

The 'managedDomains' attribute lists the PEC domains [SMTP] that are 
handled by the provider.

spt

---

From: Kurt Zeilenga <[email-masked]>
Date: Sat, 30 Oct 2010 18:16:56 -0700

> Wouldn't referring to [SMTP] (RFC 5322) suffice?

Personally, I would prefer a bit more precise statement.  For instance, is it an <address> or some subset of <address>, like <addr-spec>?

But given this is only to be published as Informational, I don't mind too much the lack of precision.

> 
> OLD:
> 
> The 'mailReceipt' attribute contains the provider's email address to which take in charge and virus detection PEC notifications are sent.
> 
> NEW:
> 
> The 'mailReceipt' attribute contains the provider's email address [SMTP] to which take in charge and virus detection PEC notifications are sent.
> 
> The 'managedDomains' attribute lists the PEC domains that are handled by the provider.
> 
> NEW:
> 
> The 'managedDomains' attribute lists the PEC domains [SMTP] that are handled by the provider.

I rather not use the verb "lists" as an attribute holds a set of values (not a sequence).  The placement of PEC seems begs the question "what's a PEC domain?".  I think what's actually meant is:
	The 'managedDomains' attribute holds a set of domains [SMTP] that are handled by a PEC provider.

Note that RFC 5322's domain actually allows values such as [127.0.0.1].  It's not clear such values make sense here.