[Smcwg-public] Cardinality of subject fields

Tue Jul 27 17:51:41 UTC 2021

On 27/7/2021 8:43 μ.μ., Corey Bonnell wrote:
>
> Hi Dimitris,
>
> I think we agree that multiple instances of OU can appear if OU is 
> allowed, at least in the near term (Legacy).
>
> I’m not quite sure what you mean by “lack of support” for multiple 
> instances of streetAddress and orgId; to the best of my knowledge, 
> multiple instances of these attribute types pose no issue with 
> processing in client software today. Can you clarify?
>
organizationIdentifier has been used in open banking and PSD2. I don't 
think the relying party software they built expects multiple instances 
of organizationIdentifier and it might cause problems.

Totally unsure about streetAddress but I believe we discussed about that 
in our latest call and we don't know of any application that uses 
streetAddress for S/MIME anyway.

Dimitris.

> Thanks,
>
> Corey
>
> *From:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
> *Sent:* Saturday, July 24, 2021 5:45 AM
> *To:* Corey Bonnell <Corey.Bonnell at digicert.com>; SMIME Certificate 
> Working Group <smcwg-public at cabforum.org>; Sebastian Schulz 
> <sebastian.schulz at globalsign.com>
> *Subject:* Re: [Smcwg-public] Cardinality of subject fields
>
> Hi Corey,
>
> So, to summarize, the current proposals for multiple values in the 
> subjectDN are the following:
>
>  1. OU (probably makes sense to allow multiple instances until we
>     decide further actions)
>  2. streetAddress (probably makes sense to forbid because of lack of
>     support)
>  3. organizationIdentifier (probably makes sense to forbid multiple
>     instances because of lack of support by Certificate Consumers)
>
> Is this a fair summary?
>
> Dimitris.
>
> On 13/7/2021 11:40 μ.μ., Corey Bonnell via Smcwg-public wrote:
>
>     Hi Seb,
>
>     Generally, I agree with you that multiple instances of a given
>     attribute type may introduce complexity, although I think for the
>     orgId case, there is value in allowing multiple registration
>     schemes to assist RP software in automated lookups of
>     supplementary information regarding the Subject.
>
>     The rationale for including streetAddress as an allowed duplicate
>     attribute type stems solely from historical practice seen in the
>     TLS world. It appears that a common practice was/is to include the
>     street information in one streetAddress RDN and any
>     apartment/suite, etc. information in a subsequent RDN. If we
>     decide that is not desirable for S/MIME, then we can forbid that
>     attribute type from appearing more than once. I don’t have strong
>     feelings either way.
>
>     I suppose the cardinality of OU will go alongside the discussion
>     of what we want to do with OU in general; as you mentioned,
>     permitting its presence (or “presences”) in Legacy and
>     Multipurpose but restricting it in Strict may be a viable way of
>     providing a transition path.
>
>     Thanks,
>
>     Corey
>
>     *From:* Sebastian Schulz <sebastian.schulz at globalsign.com>
>     <mailto:sebastian.schulz at globalsign.com>
>     *Sent:* Tuesday, July 13, 2021 11:01 AM
>     *To:* Corey Bonnell <Corey.Bonnell at digicert.com>
>     <mailto:Corey.Bonnell at digicert.com>; smcwg-public at cabforum.org
>     <mailto:smcwg-public at cabforum.org>
>     *Subject:* RE: Cardinality of subject fields
>
>     Hey Corey, Hey All,
>
>     Agreed – would be good to clarify that right off the bat. Is there
>     a reason why multiple instances of the S field should be
>     supported? For the organisational Identifier the different
>     registration schemes are a valid point.
>
>     Generally, I’d say that having multiple instances of attributes
>     present significantly complicates validation and increases the
>     risk of the certificate representing outdated information at some
>     point during its validity. But given your argument for OID and the
>     widespread use of multiple OU for all sorts of information it
>     might be yet another case of something we’d want to avoid for
>     “Strict” and allow for other profiles?
>
>     Best,
>
>     Seb
>
>     *Sebastian Schulz*
>     /Product Manager Client Certificates/
>
>     *From:* Smcwg-public <smcwg-public-bounces at cabforum.org
>     <mailto:smcwg-public-bounces at cabforum.org>> *On Behalf Of *Corey
>     Bonnell via Smcwg-public
>     *Sent:* 13 July 2021 15:16
>     *To:* SMIME Certificate Working Group <smcwg-public at cabforum.org
>     <mailto:smcwg-public at cabforum.org>>
>     *Subject:* [Smcwg-public] Cardinality of subject fields
>
>     Hello,
>
>     When reviewing the proposed set of allowed/required subject fields
>     for the profiles we have discussed this far, I realized that there
>     is room for better clarity regarding the allowed number of each
>     attribute type that may be present in each subject. For example,
>     the current specification leaves it unclear whether multiple CN
>     attributes may be present in the subject Name. The cardinality of
>     each attribute type is currently left unstated in the TLS BRs,
>     which has led to a lack of clarity and disagreements on the
>     allowed number of various attribute types.
>
>     To prevent this confusion and provide concrete written guidance, I
>     suggest that we add a column to the profiles spreadsheet that
>     indicates whether multiple instances of an attribute type are allowed.
>
>     To start, I propose that the following attributes be allowed to
>     appear more than once:
>
>      1. OU (if we decide to allow its presence at all)
>      2. streetAddress
>      3. organizationalIdentifier (if different registration schemes
>         are specified)
>
>     All other attribute types must not appear more than once in each
>     subject.
>
>     Thoughts?
>
>     Thanks,
>
>     Corey
>
>
>
>     _______________________________________________
>
>     Smcwg-public mailing list
>
>     Smcwg-public at cabforum.org  <mailto:Smcwg-public at cabforum.org>
>
>     https://lists.cabforum.org/mailman/listinfo/smcwg-public  <https://lists.cabforum.org/mailman/listinfo/smcwg-public>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20210727/a23ef3d6/attachment.html>