[cabfpub] Code Signing Baseline Requirements

[Dean Coclin]

We've put some answers to your questions below.  Thank you very much for
your detailed review. This version is now complete and will be posted
publicly after our meeting next week.

Thanks,
Dean, on behalf of the Code Signing Working Group

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

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

>> The document is copyrighted (as are all CABF documents and agreed to by
the IPR) but right below that, we grant you the right to license, reproduce,
et.
	
2. "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?

>>Yes, that is correct.

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

>> After discussing in the working group, we decided there isn’t a need to
separate out the groups into these various categories.  The only obligations
in the Code Signing Baseline requirements are on CAs.  The only party making
obligations on CAs are root store operators. Relying Applications and
Certificate Verification Software are incidental parties but ones that can
neither set obligations on CAs nor have obligations set on them by CA/B
policy. Although they are impacted by the guidelines, they are outside the
parties addressed in the document.

4. "LLCs", "CISA", "DBA" - not defined anywhere

>>Jeremy to add these to the BRs via ballot. We'd rather put them in there
than this document.

5. "does not necessarily hold the copyright to the software" - the
assumption that the software is copyrighted might not hold. Change "the"
to "any".

>>OK we changed it.

6. "Suspect code" - the title reads "suspected malware", but the definition
reads "confirmed malware". Either should be changed.

>>The group decided to leave this as is.

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

>>We don't agree with that as it carves out an exception with those that are
complying with legal government orders.

8. 7.2.4 replace ";" with "," to match the other clauses

>>Change accepted

9. "any included spaces in REG, STATE, or ORG MUST be Unicode 002D"? Did you
mean "MUST be replaced by", or did you mean "0020"?

>>Change accepted

10. What does "Reserved" imply?

>> This implies that the sections in the BRs match the sections in this
document. It's reserved for future use as there is no application today.
It's the same as "no stipulation"

11. "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?

>>Yes, this should be electronic transmission methods. It would be tough for
the CA to obligate the subscriber to dictate encryption strength.

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

>> This is an acknowledgement by the Applicant in the Subscriber Agreement
that the CA can revoke it without notifying the Applicant.  The obligation
here is that the CA include the obligation in their customer agreements.

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

>>Should be only the subscriber

14. "malware" - use the previously defined "Suspect code"
>> Done

15. "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?

>>We deleted this.

16. "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?

>>We don't specify one over the other.

17. "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?

>This just says that the CA MUST keep its own database of certs it has
previously revoked because of suspect code or rejected for other reasons.
Since we didn't address information sharing in this release, it's up to each
CA to maintain such a database.

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

>>Not changed in this version. Not sure what the Forum would do with such
information.

19. "13.2.1Mechanisms" - missing formatting

>>Fixed

20. "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.)

>> "should” was changed to a lower case should, meaning it’s not part of the
requirements and only a  recommendation. We have recommendations in all of
our requirements. 

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

>>Replaced with lowercase

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

>> It was decided not to allow it in this version. The "signing services"
envisioned here are run by CAs or their designees to handle requests from
enterprises to sign code. We don't envision entirely off line machines as
being practical in this application. 

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

>>It was decided not to allow it in this version. The intent was to separate
the keys from the PC which may be connected to a network to avoid Trojans
which harvest private keys.

24. "The validity for a Time Stamp Certificate must not exceed 135 months" -
missing final "."
>>Fixed

25. Document title is missing a space
>>Fixed

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5747 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20151029/7931a83d/attachment-0001.bin