[Smcwg-public] Cardinality of subject fields

[Corey Bonnell]

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> 
Sent: Tuesday, July 13, 2021 11:01 AM
To: Corey Bonnell <Corey.Bonnell at digicert.com>; 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:

*	OU (if we decide to allow its presence at all)
*	streetAddress
*	organizationalIdentifier (if different registration schemes are
specified)

 

All other attribute types must not appear more than once in each subject.

 

Thoughts?

 

Thanks,

Corey

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20210713/4548d94f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20210713/4548d94f/attachment-0001.p7s>