[cabfpub] Code Signing Baseline Requirements

[Dean Coclin]

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
-------------- 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/20150814/a8ee197c/attachment.bin