[Cscwg-public] Final Minutes of F2F Meeting – Code Signing Working Group
Dean Coclin
dean.coclin at digicert.com
Thu Nov 2 16:41:58 UTC 2023
Minutes of CSCWG F2F Meeting
5th October, 2023
Attendees: Adam Jones - (Microsoft), Aleksandra Kurosz - (Asseco Data
Systems SA (Certum)), Andrea Holland - (VikingCloud), Arvid Vermote -
(GlobalSign), Ashish Dhiman - (GlobalSign), Ben Dewberry - (Keyfactor), Ben
Wilson - (Mozilla), Brianca Martin - (Amazon), Bruce Morton - (Entrust),
Christophe Bonjean - (GlobalSign), Clemens Wanko - (ACAB Council), Corey
Bonnell - (DigiCert), Dave Chin - (CPA Canada/WebTrust), Dean Coclin -
(DigiCert), Don Sheehy - (CPA Canada/WebTrust), Doug Beattie - (GlobalSign),
Ellie Lu - (TrustAsia Technologies, Inc.), Eva Vansteenberge - (GlobalSign),
Hannah Sokol - (Microsoft), Inaba Atsushi - (GlobalSign), Inigo Barreira -
(Sectigo), Janet Hines - (VikingCloud), John Mason - (Microsoft), Jozef
Nigut - (Disig), Kateryna Aleksieieva - (Asseco Data Systems SA (Certum)),
Li-Chun Chen - (Chunghwa Telecom), Marcelo Silva - (Visa), Marco Schambach -
(IdenTrust), Martijn Katerbarg - (Sectigo), Mohit Kumar - (GlobalSign), Nate
Smith - (GoDaddy), Naveen Kumar - (eMudhra), Nikolaos Soumelidis - (ACAB
Council), Nitesh Bakliwal - (Microsoft), Paul van Brouwershaven - (Entrust),
Pedro Fuentes - (OISTE Foundation), Rebecca Kelley - (Apple), Rich
Kapushinski - (CommScope), Rollin Yu - (TrustAsia Technologies, Inc.), Roman
Fischer - (SwissSign), Scott Rea - (eMudhra), Stephen Davidson - (DigiCert),
Sven Rajala - (Keyfactor), Thomas Zermeno - (SSL.com), Tim Callan -
(Sectigo), Tim Crawford - (CPA Canada/WebTrust), Tim Hollebeek - (DigiCert),
Trevoli Ponds-White - (Amazon), Tsung-Min Kuo - (Chunghwa Telecom),
Vijayakumar (Vijay) Manjunatha - (eMudhra)
Minutes Approval – Approved for 7th September 2023 and 21st September 2023
Interested Party status – IBM added as interested party
Ballot Proposals Status:-
Cleanup Ballot - Proposal shared , to be pursued forward for discussion
period
Signing Service Ballot – reviewed and have 2 endorsers, to be pursued
forward for discussion period
Remove EV guidelines references - Discussion happened if working group wants
to copy exact requirements from EV guidelines or if they want to first
review what is really required and then add it to the baseline requirements
for Codesigning. Approach decided to bring all the requirements with
reference to EV guidelines in a pull request, highlight which are new
compared to 1.7.1 and then review what is relevant and only then bring it in
Codesigning BRs.
Code Signing Working Group Charter Update – Proposed language update.
Changes done to add scope to manage the issuance and management of
Timestamping for Codesigning determined by Policy OID 2.23.140.1.4.2. It
also has update to Voting structure to reach Quorum as per charter. No
comments from group. To be raised for ballot after 2 weeks to give time to
review.
High Risk Ballot – To be cleaned up and ballot to be provided but after
Service Signing ballot is pursued for discussion and is closer to be
approved.
Individual and Organization verification Mechanism :
Value of point in time location verification and use fields like State and
Locality being discussed – It was highlighted that there could be tools in
the market may be using these fields, so consuming technology may need these
fields but what level of verification is required can be discussed
It was raised that point of location verification and related records are
also being done for traceability purpose so relying party can use that if
required. But some members shared that CAs have lot more accurate
information in their records and if consumer complaints to CA, CA has the
ability to act on that or share that information if seems adequate.
Question came up if there is enough information in Code Signing Certificate
to share in CT logs that may highlight any individuals uniquely who sign
malicious code. It was raised that public availability of this information
may be helping in restricting subscriber to sign malicious code. Discussion
then moved to second part – which was if an individual can specify a Code
project i.e. can a code signing certificate be issued for a specific
project. Possibility was discussed but no conclusion made.
On organization validation side, question raised if there is need for OV and
EV for Code Signing. It was noted that functionality wise, OV and EV
certificates are same in Microsoft ecosystem and Smart screen reputation in
MS Windows is based on Issuer (Issuing CA) and Subscriber.
Different validation levels could be a problem across all certificate types.
So suggestion came that this should be taken by validation sub committee.
There was consensus in general. This was further discussed and point made to
make validation more inline with future needs, and align a level for Code
Signing. No further comments from anyone.
Agenda Items 8 -12
8. Individual and Organization verification mechanism review
9. Private keys in Hardware observations
10. Github open Items
11. Other business
12. Next meeting
8. Last meeting there was a discussion about a Microsoft email wherein they
asked about the differences between IV and OV verification. Ian brough up
the point in time location verification. What is the value of this check?
It is part of the subject DN, and many different technologies have become
dependent on this information. Removal of that information would affect
consuming technologies. As such any changes there could not be supported by
Microsoft.
But how do we handle the address information? It may change from the time
of verification versus when a relying party trusts the DN. Are there
significant differences between IV and OV address verification?
Dimitris points out that the reason we keep this address information is for
traceability purposes.
Bruce says that the CA has more information about the subject than the
certificate. Tim agrees; doesn’t know that it is particularly useful to
have all the information in the cert. Ian points out that the cert’s purpose
is not for the public to find a specific individual, although a CA will have
that information. Dimitris questions if we are having the discussion so
that the ecosystem will be able to identify malicious actors based on the
information in the certs. Bruce mentions the need for CT for code signing
as there is not always enough information in the subject to prevent
malicious entities from obtaining certs from other CAs.
Paul suggests that the information in the subject indicates to the
subscriber that their information is known and that would potentially deter
them from malicious activity. It can also let relying parties know that CAs
have additional information on the subject.
Dimitris mentions that more certs are issued to organizations than to
individuals. Bruce brings up coding groups/ like open source projects.
Some people may want to have a cert specific to their contributions in a
project.
Tim brings up that the project could be verified. Martijn suggests DV code
signing, Tim objects. At least one real person should be identified with the
project. Bruce points out that time is running out and we should focus on
Organization (instead of individual) verification.
There are 2 methods of verification OV/EV, but is there a difference in
functionality from the Microsoft point of view? Ian confirms that there is
no difference in OV/EV certification. SmartScreen is related not to the
policy OID, but the direct issuer of the certificate (CA, not coder). The
adoption of a new ICA could have detrimental effects on SmartScreen rating.
Bruce asks do we need 2 different methods of validation for organizations,
if there is no difference in handling? There may be too many methods, when
considering S/MIME OV. Tim observes that the different methods are not
really “levels” of validation. However, this is a discussion that is wider
than the CSCWG. Suggests that the TLS validation group be elevated to a
multigroup / CABF scope to generate a set list of organizational validation
methods. Then, different groups (CS, S/MIME, etc.) could select the
validation method from that list.
Bruce sums it up by saying that we should bring verification to the future.
9. Private keys in hardware observations – all keys need to be generated in
hardware
any thoughts on this?
Dimitris mentions that IETF is working on remote key attestation draft. Tim
talks about the IETF work; lots of political discussions going on in this
field. There is a decent chance of one or two RFCs coming out in 2024. A
presentation from IETF would be beneficial to the CABF.
IETF is very closely related to the skit work that Microsoft spoke about in
Redmond. We should be ready for incorporation of the RFC when published.
Bruce takes action to reach out to Mike Ownsworth to see if he can speak at
one of our meetings.
Martijn gives anecdotal evidence about customers providing half-a-page
“audits” when trying to obtain a certificate. There may be some work needed
to tighten up the requirements of the HSM audits. General consensus on this
idea was reached.
Paul brings up that there are several hardware devices that cannot handle
attestation. Tim says that we may need to start out with vague guidelines
that strengthen as the ecosystem does.
-- Break --
<two new attendees were mentioned: Dave Chen – Webtrust and Wen-Chun Yang –
Chunghwa Telecom; Wen-Chung was added as a representative>
10. Bruce wants to bring up open Github items, with Martijn’s assistance, as
they are mostly his items.
Items 26, 23, 21, 19, and 18. #19 has been added to the clean-up ballot.
#26 should be included when importing the EVGs, it will be reassessed later
#23 is in the signing service ballot and will be handled there.
#21 OCSP requirements no action taken on this item; closing
#18 Reference loop in §6.1.1.1 – this was corrected in a recent BR update.
11. Any other business?
Dean -mentioned that Adobe is an interested party, but no new news to add.
Ben Wilson – Curious about EV code signing standard. What is the status of
that? Is there a need for it? There should be a reference added to the
document that states that it is no longer valid; no one wanted to take up
the initiative of generating a ballot for this change, but Tim suggests
creating a Github issue to follow up on this.
Don Sheehy was honored for his contributions over the years.
12. Meeting adjourned; next meeting in 2 weeks.
Dean Coclin
CSCWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20231102/3d1b9b0e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5197 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20231102/3d1b9b0e/attachment-0001.p7s>
More information about the Cscwg-public
mailing list