[Smcwg-public] Certificate Profiles

[Stephen Davidson]

Thank you Stefan for your feedback - it's helpful for our ongoing discussion.

On the matter of the Extensions - you are correct.  The spreadsheets currently focus only on certain fields which may have quite a bit of variability across profiles. Other fields that are more consistent across profiles will be added later.

Best, Stephen


-----Original Message-----
From: Smcwg-public <smcwg-public-bounces at cabforum.org> On Behalf Of Stefan Selbitschka via Smcwg-public
Sent: Friday, April 9, 2021 9:01 AM
To: smcwg-public at cabforum.org
Subject: [Smcwg-public] Certificate Profiles

Hi,

following the last meeting I reviewed the "Validation-Spreadsheet" and would like to share my thoughts.

General:
========

Extensions:
-----------
In all profiles the extensions are limited and in strict and multipurpose there "Any other extension" is set to "MUST NOT".

If we do this we need a full white list of allowed extensions and I miss at least the following:

- Authority Key Identifier
- Authority Information Access
- Certificate Policies
- CRL Distribution Points
- Subject Key Identifier

May we would add some CT or other extensions ...

As an alternative we could write "Any other extension not listed in RFC5280, ...".


Subject - E-Mail:
-----------------
This is set to "MAY" in all but Sponsored-Validiation where it is a "MUST".
I would change this to "MAY" in all cases or is there any reason for require it in case of a sponsored validation?

Furthermore I would add some restrictions that if an email address is in the subject email field, the same email address must be present in the subjectAltName extension as rfc822name.


Mailbox-Validation:
===================

Empty Subject:
--------------
I do not know the current state of the "minimum certificate behavior check" suggested on March 17. Maybe we should create a git with certificates with different contents and signed and encrypted messages, so that everybody can test this within his own environment and his MUA.

This said the following discussion is focused on my personal experiences and my be dependent on my current environment.

Within the mailbox validation profile, at least with strict and multipurpose, we force the use of the email field instead of discourage it if its the only allowed field. From my experiences most implementation expect a non-empty subject within an S/MIME certificate.

My suggestion would be to set commonName to "MAY: email" in strict an multipurpose as well.

According to RFC5280 4.1.2.6. Subject:
---
If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical.
----

Do we reflect this in our certificate profiles and require the subjectAltName to be critical in this case?



regards

stefan


--
Stefan Selbitschka

rundQuadrat OG - Geschäftsführung

Mariahilfer Straße 61 / 11
1060 Wien

Tel: +43 1 2362568
Mobile: +43 660 7863002

Firmenbuch: 316047a
UID: ATU64609908