[cabfpub] Code Signing Baseline Requirements

[Sigbjørn Vik]

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