[cabfpub] Code Signing Baseline Requirements

[Sigbjørn Vik]

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


-- 
Sigbjørn Vik
Opera Software