[Smcwg-public] comments on draft SMIME BR

Thu Mar 31 16:06:18 UTC 2022

I finally made it through the pre SMIME BR and have the following comments

Definitions:

   - Application Software Supplier - in the context of SMIME - I think we
   should drop the "Internet browser software or other relying-party
   application software such as"

and at least start with mail user agents (web-based or application based)
and email service providers that process S/MIME Certificates - because that
is the correct context for this document

   - Audit Report - should state A letter from a Qualified Auditor stating
   the Qualified Auditor's opinion on whether an entity's processes and
   controls comply with the appropriate CP and CPS and the mandatory
   provisions of these Requirements

   - Sponsor-validated  - I do not think it should be limited to Individual
   (Natural Person) should be equally applicable to role or group - email
   validated certificates issued  by an Enterprise RA associated with the
   organizationName or org/OU

   - Subject Identity Information - why is the Mailbox Address excluded?

3.1.1 Types of Names

I disagree with - Names in the subject:commonName MUST be identical to the
names as they appear in the identifying documentation or Enterprise RA
records.

Often an Enterprise has a naming convention such as first.last which is not
identical to id documents - they should be allowed to use that in the CN
field

the statement also contradicts the following paragraph about being able to
choose one or several given names in any sequence

3.2.2 what does this mean in terms of enterprise RA?

The CA SHALL NOT delegate the verification of mailbox authorization or
control.

3.2.2.1 - needs a version # for TLS BRs

3.2.2.2 - I thought we agreed to a longer period than 24 hours for the
random value in mailbox validation

3.2.3.1 - B - not all businesses necessarily have a physical address - what
is the definition of business presence at a physical address?

3.2.3.4.1 - why do all businesses have to have  a physical address in this
day and age?  Many only do business using a PO Box.  There are still places
in the US where even some residences use a PO box rather than a physical
address for all US mail.

3.2.3.6.2  1 - why does a company have to be in business for 3 years before
they can get an SMIME cert?

3.2.4.1

2. - why should digital identity need to follow ICAO 9303 part 10 - this
does not allow for PIV or PIV-I authentication
3. - not entirely sure what these mean - the Kantara identity assurance
framework at level 2, NIST SP 800-63 at level 2, or the FBCA CP at Basic or
higher assurance

What's the definition of "distant past"?

3.2.8.4 - 3 A - why can't the phone be the person's personal phone?  Due to
COVID many are using cell phones for business purposes & in the case of my
own very large company that means our personal cell phones, which are also
listed within the company internal directory

4.1.2 - in the case of sponsored emails - does the CA really need a signed
subscriber agreement from each individual - or is it sufficient that the
agreement is between the individual & the Org?

4.2.1 2. - extra in  (Validation of authority in in ...)

4.9.5 - references to Web Site are inappropriate for SMIME certs

4.9.10 - 4. - this doesn't seem to make sense in all cases - if the
validity period is 16 hours updating no more than 4 days after the
thisUpdate is way too late
For OCSP responses with validity intervals greater than or equal to sixteen
hours, then the CA SHALL update the information provided via an Online
Certificate Status Protocol at least eight hours prior to the nextUpdate,
and no later than four days after the thisUpdate.

4.9.10 - unclear if OCSP required for subordinate CA certificate status?

4.9.14-16 - if suspension is not allowed in 4.9.13 - no stip in the
following sections about suspension is not correct - they should probably
be Not Applicable

6.3.2 - still disagree with the 825 max - should be a minimum of 3 years &
the idea of needing to measure in seconds is ridiculous

7.1 - I would still like someone to explain the need for 64 bits of
randomness in the serial number - just because it was added to the
serverAuth BRs in response to the SHA-1 weakness is no reason to add it to
the SMIME cert profiles that already disallow SHA-1

7.1.2.1 - no mention of SIA - so it should be optional, same for SKI
7.1.2.2 - footnote on nameConstraints - don't we consider nameConstraints
to be widely supported at this point - so do we still want the optional
criticality?
no mention of SKI - so optional?
7.1.2.3 - j - why should subjectDirectoryAttributes be prohibited?
again - no mention of SKI

7.1.4.2.2 seems to contradict cert profiles further down
k, - locality should just be optional
l - state or province should just be optional

7.1.4.2.3 & 4 - I thought we had deicded organizationIdentifier did not
need to be present in the cert - just validated
7.1.4.2.4 & 5 -  should be able to use common name rather than given,
surname or pseudonym

7.1.4.3.1 - not sure what this means when/if a CA is going to be
managed/operated by a PKI on behalf of an organization - i.e. when the org
operating the CA is not the same as the org named in the CA

This field MUST be present and the contents MUST contain either the Subject
CA's name or DBA as verified under Section 3.2.3.3 The CA MAY include
information in this field that differs slightly from the verified name,
such as common variations or abbreviations, provided that the CA documents
the difference and any abbreviations used are locally accepted
abbreviations; e.g., if the official record shows "Company Name
Incorporated", the CA MAY use "Company Name Inc." or "Company Name".

7.1.5 - not sure why the first paragraph is included - this header is about
nameConstraints - not Technically constrained CAs

7.1.6 & 7.1.6.2 - cert policies are not allowed in the Root CA certs - so
unclear why Root CA is included here
suggest either not including Root here or making it 7.1.6.1 with a single
sentence Root CA certificates do not contain certificate Policies

7.1.6.3 - why allow/require  anyPolicy?
7.1.9 - since we state certificate policies must be non-critical no stip
here is not appropriate - instead it should say something about there the
expectation that all RPs will support processing cert policies regardless
of criticality - after all we are relying on the ability of the RP to
recognize the various cert policies defined in this doc

7.2.1 - don't we expect all CRLs to be V2?

7.3.2 - why prohibit reasoncode in OCSP extensions?

8.1 Certificates do not issue certificates - new or old.  Certificates can
be used to validate certificates - but the certificates themselves are
issued by CAs

8.3 - don't we want the auditor to be independent of the PKI being audited?

8.4 - Should state the Audit should assess that the CA's operations are in
compliance with their documented CPS and CP in addition to the requirements
in these BRs. In addition to being conducted in accordance with one of the
following schemes.

also - I believe we should be able to delete the following line
However, if the CA or Delegated Third 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 MUST 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.

8.5 - don't we want to state that a CA needs to correct or mitigate any
deficiencies noted by an audit?   To me this would be more important than
the audit can't go over a year - I would rather see an audit cover a 13
month period than a 12 month audit with deficiencies that are not
addressed.  Personally, I think the priorities written into section 8 are
misplaced.

8.6 - rather (or at a minimum in addition) to the SHA-256 fingerprint of
certificates it would be better to include SKI of the CA's key.  After all
the audit should be about the operations of the CA not just CA certificates.
   10 - what is a surveillance audit?  first & only time that term is used
in this doc
   11 - wouldn't we want the same req for listing the BR for webtrust or
any other audit as well - not just ETSI?

8.8 might be better worded as:
The CA SHALL ensure the practices and procedures of each Delegated Third
Party, Enterprise RA, and Technically Constrained Subordinate CA are in
compliance with these Requirements and the relevant CP and/or CPS. The CA
shall document the obligations of Delegated Third Parties, Enterprise RAs,
and Technically Constrained Subordinate CAs and perform internal audits of
their adherence with those obligations on an annual basis. This requirement
can be met by Delegated Third Parties, Enterprise RAs, and Technically
Constrained Subordinate CAs undergoing an annual audit that meets the
criteria specified in Section 8.4.

9.1.2 - if these certificates are really supposed to be publicly trusted I
would think we would want something like this instead of no stip

CA certificates must be publicly available. CAs operating in accordance
with these requirements must not charge additional fees for access to this
information.

9.1.3 - again if the certificates are to be publicly trusted

CAs operating in accordance with these requirements  must not charge
additional fees for revoking certificates or access to CRLs and OCSP status
information.

9.4 with all the new privacy laws and security risks of identity theft
etc.  I really think it is inappropriate to have No Stip in section 9.4 -
at a minimum they should say something about needing to operate in
accordance to the jurisdiction in which the CA operates to protect any
personal information that was gathered in support of identity proofing an
applicant, as well as providing notice & consent before collecting the
information.

9.6.3 4 - rather than the following statement - because sometimes it is a
legitimate use of an SMIME certificate issued to one email of a given user
to use it with a different email owned by the same individual & at least
currently some email software legitimately allows this use

Use of Certificate: An obligation and warranty to use the Certificate only
on email mailboxes listed in the Certificate, and to use the Certificate
solely in compliance with all applicable laws and solely in accordance with
the Subscriber Agreement or Terms of Use;

instead

Use of Certificate: An obligation and warranty to use the Certificate only
on email mailboxes listed in the Certificate, or under the legitimate
control of the subscriber,  and to use the Certificate solely in compliance
with all applicable laws and solely in accordance with the Subscriber
Agreement or Terms of Use;

thanks,

Wendy

Wendy Brown
Supporting GSA FPKI
Protiviti Government Services

 703-965-2990 (cell)

wendy.brown at gsa.gov
wendy.brown at protiviti.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220331/ee6923df/attachment.html>