[Cscwg-public] Draft CSCWG Minutes October 5, 2023 - Second Half

[Dean Coclin]

Here are the minutes from the 2nd half of our F2F meeting. The first half
were sent last week.

 

Minutes from the Code Signing Certificate Working Group

October 5, 2023 – 2nd half of Meeting

 

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 – Webstrust 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.  

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20231031/c5bd0127/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/20231031/c5bd0127/attachment-0001.p7s>