[Smcwg-public] Comments and questions on draft SMIME BRs
Adriano Santoni
adriano.santoni at staff.aruba.it
Tue Apr 26 12:16:25 UTC 2022
We also find it unjustified to require EV-style vetting in "Baseline
Requirements".
More comments will follow in subsequent emails.
Thank you,
Adriano
ACTALIS S.p.A.
Il 25/04/2022 16:48, Bruce Morton via Smcwg-public ha scritto:
>
> Entrust would also like to provide some comments to the S/MIME BRs.
> First, great job, we have gone from zero to a set of baseline
> requirements which are now open for community review before finalization.
>
> In some cases, we find the requirements are above current practices,
> so could also be considered above what we have considered to be
> baseline for SSL and Code Signing. The result might be to either
> increase time required for adoption, or potentially reducing identity
> which we currently see in certificates.
>
> Monitoring of Enterprise RAs
>
> * Although this is required from SSL BRs, the Enterprise RA can only
> approve sub-domains and approve certificate issuance. There is
> nothing to monitor for sub-domains, as this is in the Subscriber’s
> control. For approving SSL certificate issuance, this could be as
> simple as 2-factor login. In essence for SSL certificates
> monitoring of an Enterprise RA is a minimal task.
> * For S/MIME certificates, the Enterprise RA would have to verify
> firstName/surname and the front end of the email address. In
> addition, the customer could have many Enterprise RAs, which
> support the issuance of thousands of certificates per year. So how
> do we monitor this activity and do we really need to? Enterprise
> RAs are really technically constrained to verified organizations
> and domain names, so is monitoring required? Could we enforce the
> Enterprise RA requirements in the Subscriber agreement?
> * If auditing/monitoring is required, then should a list of methods
> be provided? If not, then each CA can do whatever they can
> convince their auditor is good enough.
>
> EV Verification
>
> * EV vetting does not appear to be a baseline requirement, it is
> costly and there is no extended benefit which we have from SSL and
> Code Signing. OV vetting does appear to an appropriate baseline
> requirement and is currently used by CAs today.
> * If we have EV vetting for an Organization, how does this extend to
> Certificate Approver, Contract Signer and Certificate Requester
> validation? Do we need this? This is increased vetting for S/MIME
> BR, which is not required by the SSL or Code Signing BRs. We
> already have the Enterprise RA, which can authorize a certificate
> to be issued.
> * Also, there may be too many restrictions which would result in
> decreasing identity. For instance, can we remove 3.2.3.6
> Operational Existence?
>
> S/MIME Revocation
>
> * Should revoked S/MIME certificates be removed from the CRL/OCSP
> responses after the certificate has expired? Since an email can be
> read after certificate expiry, shouldn’t the relying party know
> the revocation status?
>
> Subscriber Private Key Generation
>
> * Section 6.1.2 doesn’t provide any indication that a CA could
> generate the key pair for the subscriber. The CA should be allowed
> to do this and that the section should provide requirements for
> protecting key delivery. This has been addressed in the CSBRs.
>
> Subscriber Key Recovery
>
> * Not addressed. Should we address recovery, if a CA has generated
> the key pair?
>
> Multi-factor
>
> * Should this either be removed or updated? “The CA SHALL enforce
> multi-factor authentication for all accounts capable of directly
> causing certificate issuance.” This appears to be a drop-in
> requirement, which again could be removed or updated for more clarity.
>
> Thanks, Bruce.
>
> *From:* Smcwg-public <smcwg-public-bounces at cabforum.org> *On Behalf Of
> *Christophe Bonjean via Smcwg-public
> *Sent:* Monday, April 25, 2022 4:54 AM
> *To:* smcwg-public at cabforum.org
> *Subject:* [EXTERNAL] [Smcwg-public] Comments and questions on draft
> SMIME BRs
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know
> the content is safe.
>
> ------------------------------------------------------------------------
>
> Hi all,
>
> In reviewing the draft S/MIME Baseline Requirements, GlobalSign has
> the following comments and questions:
>
> **
>
> *Validation level*
>
> With SMIME certificates, the goal is to provide “reasonable assurance”
> that the other party to the communication identified in the
> certificate has control of the domain or email address being asserted.
>
> We realize that additional validation elements as described in the TLS
> EVGs could provide a higher level of assurance than merely "reasonable
> assurance", however certain elements that are central to the TLS EVGs
> may place a significant burden on the Applicant organization (physical
> address, verified method of communication, operational existence).
>
> What's the justification for requiring EV level validation over OV
> level validation?
>
> *Profiles*
>
> Multiple levels of profiles have been defined (legacy, strict) to
> allow for transitioning from legacy to a stricter profile, however the
> principle appears to be not consistently applied.
>
> For example, there is a requirement for subject:givenName and
> subject:surname in the sponsor-validated (section 7.1.4.2.4) and
> individual-validated profile (7.1.4.2.5), both for legacy and strict.
>
> If the intent for the legacy profile is to capture the profile of
> existing certificates, should givenName and surname be required only
> for the strict profile?
>
> *Enterprise RAs*
>
> If Enterprise RAs validate first name, last name and the first part of
> the email address, to which extent could that be considered
> constrained? The requirements of section 8.8 are subject to
> interpretation. If review or auditing is required, should we define
> specific criteria or practices?
>
> *Identity validation: eIDs*
>
> eIDs as defined and notified under eIDAS are currently excluded under
> "Digital Identity Documents" (section 3.2.4.1 option 2), which seems
> to aim at physical identity documents but with a digital component.
>
> Given the defined framework, recognition and practical application of
> eIDs, it seems their purpose would fulfill the identity validation
> requirements of individuals for SMIME certificates. What's the
> rationale for excluding them?
>
> *Identity validation: Sponsor-validated without Enterprise RA*
>
> For sponsor-validated certificates with Enterprise RA, the validation
> of the individual identity information can be based on Enterprise RA
> records (section 3.2.4.1 option 4). For non-Enterprise RA
> sponsor-validated certificates, there is no equivalent option to rely
> on an attestation made by the sponsor for the individual identity
> information (e.g. first name, last name) or affiliation.
>
> Would it be possible to introduce the option to rely on attestation of
> the validated sponsor in the same way as we would rely on the
> Enterprise RA records if it meets the same requirements (Section 1.3.2
> and Section 8.8) for individual identity information and/or affiliation?
>
> *Identity validation: Individual identity information*
>
> Should we also consider incorporating agency sources as a source for
> listed director individual identity information (akin to the
> Enterprise RA records, but publicly available and where the identity
> validation is regulated in the relevant jurisdiction of incorporation)?
>
> *Identity validation: Digital signatures*
>
> For digital signatures (section 3.2.4.1 option 3), could we allow
> additional adopted standards to be used under certain conditions, for
> example:
>
> * CA has a documented procedure to review adopted standards against
> the SMIME BRs to ensure they meet the required assurance level;
> * the CA lists additional accepted standards in their CPS; and
> * CA notifies these additional standards for inclusion within the
> SMIME BRs, but pending acceptance/rejection these standards may be
> used.
>
> *Organizational Units*
>
> Would departments as organizational units fit within the profile? And
> if yes, could they be included in organization-validated or
> sponsor-validated? The current definition of organizationalUnitName
> (section 7.1.4.2.2 item c) seems to be limited to affiliate entities,
> but not departments?
>
> **
>
> *Key generation*
>
> Section 6.1.2 does not currently specify whether it's prohibited or
> allowed to generate private keys for customers?
>
> *Revocation status*
>
> Since emails may be read a while after the validity period of the
> certificate, should status information remain on OCSP/CRL after expiry
> of the certificate?
>
> Thank you
>
> Christophe
>
> /Any email and files/attachments transmitted with it are confidential
> and are intended solely for the use of the individual or entity to
> whom they are addressed. If this message has been sent to you in
> error, you must not copy, distribute or disclose of the information it
> contains. _Please notify Entrust immediately_ and delete the message
> from your system./
>
> _______________________________________________
> Smcwg-public mailing list
> Smcwg-public at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220426/012cf1a0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4557 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220426/012cf1a0/attachment-0001.p7s>
More information about the Smcwg-public
mailing list