[Smcwg-public] Cardinality of subject fields
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
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>
More information about the Smcwg-public
mailing list