[cabfpub] Code Signing Baseline Requirements

[Sigbjørn Vik]

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