[Smcwg-public] a few remaining comments on the SMIME BRs that I still have not seen addressed
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Wed Aug 31 11:56:38 UTC 2022
I kind of agree with Wendy, however if a requirement is clear from the
TLS BRs and applicable to the S/MIME BRs, it would be best to copy it
over. If it's not clear we should improve. It it's not applicable, we
should definitely update or remove :-)
Dimitris.
On 31/8/2022 2:37 μ.μ., Wendy Brown - QT3LB-C via Smcwg-public wrote:
> Stephen -
> This document is about SMIME certificates not TLS.
> Just because there is language in the TLS BRs that was initially
> copied into the document as a start is no reason that it has to remain
> in tis document if it is clearly about TLS certificates and not
> related to SMIME certificates, or if it is unclear. I thought the
> idea was to create baseline requirements related to SMIME certificates.
>
> Thanks,
>
> Wendy
>
>
> Wendy Brown
>
> Supporting GSA
>
> FPKIMA Technical Liaison
>
> Protiviti Government Services
>
> 703-965-2990 (cell)
>
>
> On Tue, Aug 30, 2022 at 4:22 PM Stephen Davidson
> <Stephen.Davidson at digicert.com> wrote:
>
> Hello Wendy –
>
> Thanks for your input. Responses inline below.
>
> Regards, Stephen
>
> **
>
> 1.3.2 #4 - It seems to me that a Delegated Party must comply with
> the CA’s CP regardless of whether or not they have a separate
> document to follow since trust stores will be evaluating CAs based
> on the CA's CP/CPS and may not have visibility into all Delegated
> Parties’ Practice statements.
>
> >> Standard language from TLS BR
>
> 1.3.2.1#2 - If the CA is doing the mailbox validation, then the
> Enterprise RA is not involved, and this sentence is misplaced. "If
> the Certificate Request is for a Mailbox-validated profile, the CA
> SHALL confirm that the mailbox holder has control of the requested
> Mailbox Address(es) in accordance with Section 3.2.2.2."
>
> On the other hand if the Enterprise RA is doing the validation of
> the mailbox, maybe because they have assigned the mailbox to the
> individual, the CA only needs to ensure that the Enterprise has
> control of the email domain.
>
> >> Sentence was previously requested to clarify that
> Mailbox-validation may only be done by CA, not Enterprise RA.
>
> Normally 1.3.5 would be about other participants assisting in the
> operation of a CA rather than just writing the document - however
> if this context is appropriate for the BRs, I'm OK - but why are
> only specific Associate Members called out here - that makes it
> read as though all other non-voting participants do endorse &
> approve of the final product and that may not necessarily be the
> case.
>
> 1.3.5 Other participants
>
> Other groups that have participated in the development of these
> Requirements include the CPA Canada WebTrust for Certification
> Authorities task force and the Accredited Conformity Assessment
> Bodies’ Council (ACAB’C). Participation by these groups does not
> imply their endorsement, recommendation, or approval of the final
> product.
>
> >> Based on standard language from TLS BR
>
> Definition of Applicant - it would read better as "Once the
> Certificate is issued" instead of "Once the Certificate issues"
>
> And the example is out of place in a document about SMIME
> certificates - "For Certificates issued to devices, the Applicant
> is the entity that controls or operates the device named in the
> Certificate, even if the device is sending the actual Certificate
> Request."
>
> >> Standard language from TLS BR. Language does apply to email
> gateways.
>
> 4.9.5 #4 The example is not relevant for SMIME certificates and
> should be deleted:
>
> The entity making the complaint (for example, a complaint from a
> law enforcement official that a Web site is engaged in illegal
> activities should carry more weight than a complaint from a
> consumer alleging that they didn't receive the goods they ordered);
>
> >> Standard language from TLS BR
>
> 4.12.1 - Should something be said about certificates that contain
> non-repudiation should NOT be escrowed?
>
> >> We did discuss this in early versions – and it was agreed to
> stick to a baseline here and that enhancements to the key escrow
> section would likely be a subject for future ballots.
>
> 6.2.1 or 6.2.7 Should place some requirements on the storage of
> subscriber private keys
>
> >> Future discussion.
>
> 6.3.2 - Why is 825 Days still listed? I thought Apple relaxed
> their requirement why are we maintaining it here as there seemed
> to be a lot of disagreement with the shorter validity period for
> certificates where the private key is held in hardware and can’t
> easily support automated renewal.
>
> >> This was discussed at length with Certificate Consumers
> indicating a preference to move to shorter validity periods.
>
> 7.1 - Please explain the requirement for "non-sequential
> Certificate serial numbers greater than zero (0) and less than
> 2^159 containing at least 64 bits of output from a CSPRNG" – I
> understood its purpose with SHA-1 – but not SHA-2 or beyond. There
> is no reason to retain this just because it is in the serverAuth
> BRs unless there is a good security reason for it.
>
> >> comes from Mozilla.
>
> 7.1.2 There has been so much discussion in the serverauth group of
> whether the BRs should be read as default deny or not, that I
> think it needs to be made clear that if an extension is not
> mentioned it may still be included – for example SIA should be
> allowed on Root CA certificates and Subordinate CA certificates so
> that PKIs may make use of monitoring tools that may build from the
> top down. As long as these extension are not critical, it should
> not impact consumers.
>
> >> see 7.1.2.4
>
> -
>
> 7.1.4.2.5 - user id and dnQualifier should be listed as MAY at
> least for the legacy as I believe they are used today in order to
> distinguish subjectDN within an organization.
> Trying to get organizations to standardize on the serialNumber in
> the future might be OK but don’t break current implementations
> with the Legacy profile.
>
> >> In Legacy generation other attributes are allowed (bottom line
> of table)
>
> 8.4 the Delegated 3rd Party practices may be optional but even if
> optional if they exist, they still need to comply with the CA’s CP/CPS
>
> >> see 1.3.2, text has also been improved.
>
> 8.4 I think the following should be deleted, unless the 3 year
> cycle is actually required by existing CAs. I believe it
> originally came into the BRs due to an old FPKI practice of
> allowing a triennial audit that is no longer allowed.
>
> However, if the CA or Delegated Party is under the operation,
> control, or supervision of a Government Entity and the audit
> scheme is completed over multiple years, then the annual audit
> SHALL cover at least the core controls that are required to be
> audited annually by such scheme plus that portion of all non-core
> controls that are allowed to be conducted less frequently, but any
> non-core control SHALL NOT be audited less often than once every
> three years.
>
> >> Thank you for highlighting this; have removed and suggested
> changes at the TLS BR at
> https://github.com/cabforum/servercert/issues/387
>
> 8.6 #3 - The audit should be about CAs & their operations not just
> the CA certificate.
> It is equally, if not more important, to actually list the CA Name
>
> >> Based on standard language from TLS BR
>
> 8.6 #4 - Again – the audit should have been about the CA – not
> just an audit of a CA certificate
>
> >> Based on standard language from TLS BR
>
> 9.6.1 #2i - Presumably either the subject or an authorized rep
> requested the cert, not necessarily both in all cases
>
> >> correct
>
> 9.6.3 #4 I believe this is too strict – maybe only with Mailboxes
> list in the Certificate or under the control of the subject
> identified in the cert. At least 1 current large email system
> allows the use of unrelated certificates – a capability that many
> may rely on (I know I do)
>
> >> The intent is to restrict the use of certs to the associated
> mailboxes.
>
> 9.6.3#6 - may be too strict – what about the case of encryption
> certs the corresponding private key can still be used to decrypt
> previously received emails
>
> >> Based on standard language from TLS BR updated for context –
> and the sense is to prevent future use of known-compromised keys.
>
>
> _______________________________________________
> 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/20220831/c090e95f/attachment-0001.html>
More information about the Smcwg-public
mailing list