[cabfpub] Code Signing Baseline Requirements
sigbjorn at opera.com
Thu Sep 17 07:13:52 UTC 2015
On 16-Sep-15 21:47, Dean Coclin wrote:
> 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.
Unfortunately, I'll be arriving Tuesday night, too late to join the
working group meetings. I'll be more than happy to clarify by email, I
can join the codesigning list for a limited cc list as well.
> 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.
> -----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
> * 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
> 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.
>> -----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
>> 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
>> 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
>> "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
>> "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
More information about the Public