[cabfpub] Code Signing Baseline Requirements

[Dean Coclin]

Hello Sigbjørn,

Thanks again for your comments. We are almost finished reviewing them all
and will have responses out by end of next week. If you can attend the
working group meeting in Istanbul, it would be most helpful to the team to
discuss some of your comments live.

Regarding your comment below, since the formation of the working group, we
have attempted to be open and inclusive by advertising the process publicly.
This managed to attract about 20 participating companies both from within
and outside the forum. We did manage to get some users early on as members
of the WG (by signing the IPR) and they have been part of the overall
process. We continue to publish public drafts of our work and request for
comments at various points in the lifecycle of the work product. While it
would always be beneficial to have more user input, at some point we have to
come up with a final product that the forum can vote on. 


Thanks
Dean

-----Original Message-----
From: Sigbjørn Vik [mailto:sigbjorn at opera.com] 
Sent: Monday, August 31, 2015 10:09 AM
To: Dean Coclin; CABFPub
Cc: codesigning at cabforum.org
Subject: Re: [cabfpub] Code Signing Baseline Requirements

After having had some time to mull over the Code Signing BRs at a higher
level, I have a few additional comments. We are very positive to there being
stricter rules for code signing. The current draft imposes a number of
restrictions on subscribers, so subscribers ought to be involved in the
development. We want to ensure that such rules are wanted, understood and
beneficial by those subscribers. I previously highlighted one case where the
new rules (16.3) for how to handle private keys would lead Opera to using a
more cumbersome and insecure process for some of its signing procedures (by
requiring private key and laptop to be stored separately).

So my higher level comments are that I think the draft looks somewhat skewed
towards the perspective of issuers, and I am not certain how well it
benefits subscribers, and thus the ecosystem. Re-reading it from the point
of a subscriber, I see more issues with it (below). If the BRs are to
mandate certain subscriber behavior, then we'd like to be assured that
subscriber representatives have been part of the development of the
document. Opera, and presumably other members of the CABForum, does not have
sufficient background for this. For a document mandating subscriber
behavior, CABForum might not even be the right place. I note that web BRs do
not contain as detailed requirements on subscribers.

Some possible course of actions:
* Get some code signing communities actively involved in finalizing the
document
* Reduce the subscriber requirements to the same level as the existing BRs
* Move subscriber requirements to a separate document, to be approved by
different groups



"Suspect code: Code that contains [...] serious vulnerabilities." This,
combined with "not using the Certificate to sign Suspect Code" is quite
likely not possible for e.g. browsers. We may have a serious vulnerability
in a product, which might take some time to fix.
Meanwhile, we keep fixing other issues, and we need to get such fixes out to
users, which we do by signing the code, even if we know it contains a
serious vulnerability in another location. Likewise, the subscriber agreeing
to "inform the signing service if [...] that code [...] contained [...] a
serious vulnerability" is not possible for many subscribers.

7.3 "For the benefit of the Issuer" - We do not write these specifications
for the benefit of the issuer. We write them for the benefit of the end
user.

10.3.2.5 This should be a requirement on the issuer, not to enter into
contracts which may be invalidated by updated guidelines. A subscriber
cannot be held liable for this. In many cases, even if a subscriber has
agreed in writing to "this agreement may be altered unilaterally by the
issuer at any time without notice", such a clause may be held illegal.
If the issuer has entered into contracts made void by updated BRs, it is the
issuer who made a mistake, not the subscriber.

16.3 For a serious software company, one must have an emergency backup of
the private key. (Securely stored off-site, e.g. on paper in a safe
somewhere.) This means only option 3 is available.

On 15-Aug-15 04:41, Dean Coclin wrote:
> Thanks for the detailed comments Sig. We will review at our next 
> Working Group meeting and let you (and everyone) know the results.
> 
> Dean
> 
> -----Original Message-----
> From: Sigbjørn Vik [mailto:sigbjorn at opera.com]
> Sent: Friday, August 14, 2015 5:37 AM
> To: Dean Coclin; CABFPub
> Cc: codesigning at cabforum.org
> Subject: Re: [cabfpub] Code Signing Baseline Requirements
> 
> Hi,
> 
> Thanks for the good work on this, looks like a definite improvement.
> This is the first time I am reading through it, so several random
comments.
> 
> Why is the document copyrighted? Am I allowed to copy snippets and 
> comment on them as I do in this mail? Can CAs copy individual clauses, 
> on order to explain something to their subscribers? If I even have to 
> ask this, the document probably shouldn't be copyrighted.
> 
> "These Requirements are not mandatory [...] unless [...] they become 
> adopted and enforced by an Application Software Supplier." - So if any 
> single supplier adopts them, they are mandatory for all CAs in all
contexts?
> 
> "Application Software Supplier"
> There are multiple software suppliers involved. They may be the same, 
> or they may be distinct, the definition assumes they are all made by 
> the same company.
> "Root Store" - Those keeping and distributing the collection of roots, 
> and dealing with CAs.
> "Certificate Verification Software" - Software that uses the root 
> store to validate certificates.
> "Relying Applications" - Software that uses the verification software 
> in order to make trust decisions.
> On my browser; Opera is the relying application, using verification 
> software from Google, which uses the root store from Microsoft. 
> Neither is an "Application Software Supplier" by the given definition.
> We had the same discussion for the document on recommendations for the 
> processing of EV Certificates, it would be good to reuse the 
> definitions from there. Some of the "Application Software Supplier" 
> references are to one of the types, while other references are to 
> others, they should be updated accordingly.
> 
> "LLCs", "CISA", "DBA" - not defined anywhere
> 
> "does not necessarily hold the copyright to the software" - the 
> assumption that the software is copyrighted might not hold. Change "the"
> to "any".
> 
> "Suspect code" - the title reads "suspected malware", but the 
> definition reads "confirmed malware". Either should be changed.
> 
> Takeover attack - why does it have to be illegal? I can conjure up 
> examples where key compromise happens legally. E.g. many types of 
> social engineering are not illegal.
> 
> 7.2.4 replace ";" with "," to match the other clauses
> 
> "any included spaces in REG, STATE, or ORG MUST be Unicode 002D"? Did 
> you mean "MUST be replaced by", or did you mean "0020"?
> 
> What does "Reserved" imply?
> 
> "The CA MUST obligate the Subscriber to use passwords that are 
> randomly generated with at least 16 characters containing uppercase 
> letters, lowercase letters, numbers, and symbols to transport private 
> keys." - What does it mean to transport the key? Does transporting the 
> HW containing the key from the safe count? Maybe replace with 
> "electronic transmission"? Does it make sense to dictate the password 
> strength without dictating the encryption strength/methods?
> 
> "The Applicant MUST make the following obligation: [...] that the CA 
> will revoke the Certificate without requiring prior notification if 
> there is unauthorized access to the Private Keys." This is an 
> obligation only the CA can make. Note that the CA must be able to 
> revoke without prior notification also in cases where there has been no
unauthorized access.
> 
> "To promptly [...] request that the CA revoke the Certificate if [...] 
> there is any suspected misuse or compromise of the Private Key". So if 
> an internet post says "I suspect this is malware", the subscriber is 
> obliged to request a revocation based on that suspicion?
> "The CA MUST revoke the affected Certificate [...] if [...] the 
> Signing Service failed to notify the CA within 24 hours after 
> identifying a suspected private key compromise." - Same as above
> 
> "malware" - use the previously defined "Suspect code"
> 
> "illegal activity such as phishing, fraud, malware distribution, etc." 
> - malware distribution is not necessarily illegal. Packaging and 
> reporting malware samples to AV-vendors is quite common. Some 
> governments reserve the right to distribute malware themselves. 
> Illegal in what jurisdiction by the way?
> 
> "Verify the Subject’s identity using a government photo ID under 
> Section 11.2.1" - What about using the other method mentioned in 11.2.1?
> 
> "The CA MUST also maintain and check an internal database listing 
> Certificates [...]" Why must this database be internal, and what 
> exactly does that imply? Does that mean that open programs like Let's 
> Encrypt cannot do code signing?
> 
> "the CA must revoke the certificate except if the CA has documented 
> proof (e.g., OCSP logs) that this will cause significant impact to the 
> general public." - in such a case, the CA should be required to notify 
> the CABForum
> 
> "13.2.1Mechanisms" - missing formatting
> 
> "the Platform SHOULD" - OS specifications do not belong in this document.
> Replace with lowercase "should" as in the above paragraph.
> (Makes no technical difference, but avoids the hint that this is an 
> OS-level specifications document.)
> 
> "Platforms SHOULD consult blacklists for Suspect Code" - remove, not 
> related to the rest of the document. I don't think any major platforms 
> do this, or plan to do it, so it will only make the document look less
relevant.
> 
> "The Signing Service MUST run a regularly updated antivirus solution 
> to scan the service for possible virus infection." So custom OSes are 
> not allowed to run signing services (only those that are so mainstream 
> they get both viruses and AV written for them)? Entirely off-line 
> machines (human physical intervention like a USB-stick required for 
> signing) will not be allowed (as regularly updating AV might not then 
> be doable)? AV is good, but I do not think it is the only solution. 
> How about: "The Signing Service MUST be designed securely, a regularly 
> updated antivirus solution [to ...] SHOULD be part of the design."
> 
> "Another type of hardware storage token with a unit design form factor 
> of SD Card or USB token. The Subscriber MUST also warrant that it will 
> keep the token physically separate from the device that hosts the code 
> signing function until a signing session is begun."
> This seems overly specific. This solution for code signing would then 
> not be
> allowed: Keep a laptop in a safe, store the cert and code signing 
> function on it, and sign files transferred by USB-stick. To me, the 
> prescribed solution above seems less secure, as the device that hosts 
> the code signing function might be compromised, which is almost as bad 
> as compromising the key. How about a fourth point, that other, at 
> least as secure methods may be negotiated with the CA. The CA will 
> then bring such methods to the attention of the CABForum.
> 
> "The validity for a Time Stamp Certificate must not exceed 135 months" 
> - missing final "."
> 
> Document title is missing a space
> 
> Not commenting on the legalese, apart from saying that I think things 
> can be expressed simpler and more understandable in plain English...
> 
> --
> Sigbjørn Vik
> Opera Software
> 


--
Sigbjørn Vik
Opera Software
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5747 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150916/5d3823a6/attachment.p7s>