[cabfpub] Ballot 132 - EV Code Signing Timestamp Validity Period

[Doug Beattie]

GlobalSign votes YES.

 

 

From: public-bounces at cabforum.org <mailto:public-bounces at cabforum.org>
[mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Tuesday, September 02, 2014 9:30 AM
To: public at cabforum.org <mailto:public at cabforum.org>  (public at cabforum.org
<mailto:public at cabforum.org> )
Subject: [cabfpub] Ballot 132 - EV Code Signing Timestamp Validity Period

 

Ballot 132 - EV Code Signing Timestamp Validity Period 

Rationale for Ballot 132 

1. Ideally, TSA services should be consistent across the multiple services
that rely on them (Code Signing, EV Code Signing, AATLs, etc.) 

2. Time stamps are used not just to time-stamp code, but other objects, such
as signed financial reports and other digital objects. 

3 The EV Guidelines and some government archival systems require that
signatures be capable of automatic verification for approximately ten years.


4. When the EV Guidelines for code signing were developed, it was thought
that a 123-month period would provide a three-month cushion (120 months plus
3). But because the BRs for Code Signing anticipate that a new key pair will
be cycled every 15 months, then a 15-month period should be added to the
10-year TSA certificate validity, not just for code signing, but for all
other uses where those extra months can add a longer period for automatic
validation of the time-stamp. This would equal 135 months (120 months plus
15).  

5. A longer validity period for the TSA certificate is also justified
because the requirement of a new key pair every 15 months will reduce the
risk severity due to a key compromise. 

6. There are additional reasons to allow a longer period, including from
Japan, the time-stamping regulations of the METI pursuant to Article 435 of
the Japanese Companies Act, subsection 2 (Preparation and Retention of
Financial Statements, etc.), subsection 4 (financial schedules to be
retained for ten years from the time of preparation). See
http://www.dekyo.or.jp/tb/english/index.html 

Steve Roylance of Globalsign made the following motion and Ben Wilson of
Digicert and Rob Stradling of Comodo endorsed it: 

--Motion Begins -- 

In Sections 8.2.1 and 9.4 of the EV Code Signing Guidelines replace "one
hundred and twenty three months" with "one hundred and thirty five months"
(in three places in each section) as follows:

8.2.1 Implementation 

Each Issuer MUST develop, implement, enforce, display prominently on its Web
site, and periodically update as necessary its own auditable EV Code Signing
Object practices, policies and procedures, such as a Certification Practice
Statement (CPS) and Certificate Policy (CP) that: 

(A) Implement the requirements of these Guidelines as they are revised from
time-to-time; 

(B) Implement the requirements of (i) the then-current WebTrust Program for
CAs, and (ii) the then-current WebTrust EV Program or ETSI TS 102 042
V2.1.1; and 

(C) Specify the Issuer's (and applicable Root CA's) entire root certificate
hierarchy including all roots that its EV Code Signing Certificates depend
on for proof of those EV Code Signing Certificates' authenticity. With the
exception of revocation checking for time-stamped and expired certificates,
platforms are expected to validate signed code in accordance with RFC 5280. 

When a platform encounters a certificate that fails to validate due to
revocation, the platform should reject the code. When a platform encounters
a certificate that fails to validate for reasons other than revocation, the
platform should treat the code as it would if it had been unsigned.
Ordinarily, a code signature created by a Subscriber may be considered valid
for a period of up to thirty-nine months. However, a code signature may be
treated as valid for a period of up to one hundred and thirty five twenty
three months by means of one of the following methods:   the "Timestamp"
method or the "Signing Authority" method. 

(A) Timestamp Method: In this method, the Subscriber signs the code, appends
its EV Code Signing Certificate (whose expiration time is less than
thirty-nine months in the future) and submits it to an EV Timestamp
Authority to be time-stamped. The resulting package can be considered valid
up to the expiration time of the timestamp certificate (which may be up to
one hundred and thirty five twenty three months in the future). 

(B) Signing Authority Method: In this method, the Subscriber submits the
code, or a digest of the code, to an EV Signing Authority for signature. The
resulting signature is valid up to the expiration time of the Signing
Authority certificate (which may be up to one hundred and thirty five twenty
three months in the future). 

9.4 Maximum Validity Period For EV Code Signing Certificate

Code may be signed at any point in the development or distribution process,
either by a software publisher or a user organization. Signed code may be
verified at any time, including during: download, unpacking, installation,
reinstallation, or execution, or during a forensic investigation.
Subscribers may obtain an EV Code Signing Certificate with a validity period
not exceeding thirty-nine months. Timestamp Authorities and Signing
Authorities may obtain an EV Timestamp Certificate or EV Code Signing
Certificate (respectively) with a validity period not exceeding one hundred
and thirty five twenty three months. The validity period for an EV Code
Signing Certificate issued to a Subscriber MUST NOT exceed thirty-nine
months. The validity period for an EV Code Signing Certificate issued to a
Signing Authority that fully complies with these Guidelines MUST NOT exceed
one hundred and thirty five twenty three months. The validity period for an
EV Timestamp Certificate issued to a Timestamp Authority that fully complies
with these Guidelines MUST NOT exceed one hundred and thirty five twenty
three months. 

-- Motion Ends --

The review period for this ballot shall commence at 2100 UTC on Tuesday, 2
September 2014, and will close at 2100 UTC on Tuesday, 9 September 2014.
Unless the motion is withdrawn during the review period, the voting period
will start immediately thereafter and will close at 2100 UTC on Tuesday, 16
September 2014. Votes must be cast by posting an on-list reply to this
thread. 

A vote in favor of the motion must indicate a clear 'yes' in the response. A
vote against must indicate a clear 'no' in the response. A vote to abstain
must indicate a clear 'abstain' in the response. Unclear responses will not
be counted. The latest vote received from any representative of a voting
member before the close of the voting period will be counted. Voting members
are listed here: https://cabforum.org/members/ 

In order for the motion to be adopted, two thirds or more of the votes cast
by members in the CA category and greater than 50% of the votes cast by
members in the browser category must be in favor. Also, at least seven
members must participate in the ballot, either by voting in favor, voting
against, or abstaining. 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140912/4c4ee7e3/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5615 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20140912/4c4ee7e3/attachment-0001.bin