[cabfpub] FW: Question on Ballot 83 - Network and Certificate System Security Requirements

Ben Wilson ben at digicert.com
Thu Jul 26 19:08:15 UTC 2012


There are several comments in this thread that have not been supported with
facts or an adequate basis to show the exact problem with the current
wording or to give sufficient support to a change.   A publicly trusted CA
should maintain an offline root.  If the system needs to be up and running,
then it should be air-gapped.  Why would a CA want to expose itself and its
users unnecessarily by maintaining an online root CA that wasn't protected
by an air gap?  In light of Stuxnet and Flame,  do we really think that it
would be a good idea for publicly trusted CAs?    Also, if the security
document had problems, why are they being raised now?  There has been plenty
of time and opportunity before now to submit comments.  I've told others
that I thought it was a little too late to wordsmith and that they should
submit a motion for an errata after adoption.   What do we tell them now?
Also, the proposed wording is too broad for the specific problem and any
exception should be narrowly tailored.   I would think that those root CAs
needing to stay online in order to issue CRLs for certificates previously
issued could be identified and disclosed so that we know the relative impact
of a proposed change.   But as proposed, we are no longer talking only about
legacy Root CAs that need to remain online only for the purpose of issuing
CRLs.   The proposed language appears to grandfather all CAs with an issue
date indicating they were created before the Effective Date.   So what are
we accomplishing and for what purpose?  If I were to entertain an amendment
on the proposed language, then other members would likely vote against the
document (and the proposal below is not amendment to the motion, it is an
amendment to the document).  So I believe the only way to move forward is to
push the current document to vote. 

 

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Bruce Morton
Sent: Thursday, July 26, 2012 11:16 AM
To: 'Rick Andrews'; 'public at cabforum.org'
Subject: Re: [cabfpub] FW: Question on Ballot 83 - Network and Certificate
System Security Requirements

 

Entrust would favor the change recommended below.

 

Bruce.

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Rick Andrews
Sent: Thursday, July 26, 2012 12:10 PM
To: public at cabforum.org
Subject: [cabfpub] FW: Question on Ballot 83 - Network and Certificate
System Security Requirements

 

Sending to a broader audience.

 

Ben, please consider this amendment to your motion.

 

-Rick

 

From: Rick Andrews 
Sent: Tuesday, July 24, 2012 2:30 PM
To: 'chris_bailey at trendmicro.com'; Dean Coclin
Cc: kirk_hall at trendmicro.com; wthayer at godaddy.com; tim.moses at entrust.com
Subject: RE: Question on Ballot 83 - Network and Certificate System Security
Requirements

 

Chris,

 

I believe the document imposes password restrictions only on user accounts,
not hardware like smart cards. But I think we're fine delaying the vote to
give more people a chance to look more deeply at this (I think few people
commented on it before Ben sent it out for balloting).

 

For the air-gap sentence, I propose changing

"Maintain Root CA Systems in a High Security Zone and in an offline state or
air-gapped from all other networks;"

To

"Maintain Root CA Systems in a High Security Zone; to the greatest extent
possible, keep Root CA Systems in an offline state or air-gapped from all
other networks. Minimize the number of legacy Root CA Systems (created
before the Effective Date) that must be kept online, and if possible
restrict them to CRL signing only."

What do you think of that change?

 

-Rick

 

From: chris_bailey at trendmicro.com [mailto:chris_bailey at trendmicro.com] 
Sent: Tuesday, July 24, 2012 1:15 PM
To: Dean Coclin
Cc: kirk_hall at trendmicro.com; Rick Andrews; wthayer at godaddy.com;
tim.moses at entrust.com
Subject: Re: Question on Ballot 83 - Network and Certificate System Security
Requirements

 

Dean,

 

I agree. Additionally, there are other issues that are in this ballot that I
would consider "recommended when practical". For example, there are certain
smart cards that only allow a limited set of characters for the password. If
these smart cards are used for offline backups, do these backups need to be
refreshed every 3 months? I am sure there are other things in here as well,
so I would like some more time to measure the impact to our own
infrastructure and to make sure that it is not going to be an issue for
other CAs as well if this ballot will be required.

 

So, we can either propose a delay in the vote and then offer to change the
language or simply vote no to the ballot.

 

Any thought?

 

 

Thanks,

 

Chris


Sent from my iPad


On Jul 24, 2012, at 12:17 PM, "Dean Coclin" <Dean_Coclin at symantec.com>
wrote:

I'll amend what I said a bit: there are some "legacy" systems that may have
issued off the root in the past and will be required to issue CRLs going
forward off the root. So I think these reqts should specify some sort of
date so that legacy systems should be covered.


Dean

 

From: Dean Coclin 
Sent: Monday, July 23, 2012 2:29 PM
To: 'kirk_hall at trendmicro.com'; Rick Andrews
Cc: wthayer at godaddy.com; tim.moses at entrust.com; chris_bailey at trendmicro.com
Subject: RE: Question on Ballot 83 - Network and Certificate System Security
Requirements

 

It's always good security practice to keep the roots offline. This is pretty
standard in most PKIs as well as in the Federal CP.  We are in support of
this requirement.

 

Dean

 

From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] 
Sent: Monday, July 23, 2012 2:20 PM
To: Dean Coclin; Rick Andrews
Cc: wthayer at godaddy.com; tim.moses at entrust.com; chris_bailey at trendmicro.com
Subject: FW: Question on Ballot 83 - Network and Certificate System Security
Requirements

 

Resending with the right people this time.

 

From: Kirk Hall (RD-US) 
Sent: Monday, July 23, 2012 9:55 AM
To: Derek Lohrey; Wayne Thayer (wthayer at godaddy.com); Tim Moses
(tim.moses at entrust.com)
Cc: Chris Bailey (RD-US)
Subject: Question on Ballot 83 - Network and Certificate System Security
Requirements

 

Gentlemen - in looking at the Network and Certificate System Security
Requirements, we are not convinced that the requirement of keeping the root
CAs offline and/or air gapped makes sense.  None of the breaches to date
involved compromise of the root CAs, and this will limit the ability of a CA
to maintain current root CRLs on a frequent (balanced) basis (having the
roots push out CRLs in a secure environment in an automated fashion), but
arguably will require manual procedures at frequent intervals.

 

Are you in support of this particular requirement?  Is it worth raising this
as an issue, and asking for modification?

 

I know we raised this in the past, but I don't recall that we ever got a
specific response back on why roots in particular had to be kept offline or
air/gapped. 

 

Kirk R. Hall

Operations Director, Trust Services

Trend Micro

+1.503.243.5405

 


TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail
or telephone and delete the original message from your mail system.

 


TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail
or telephone and delete the original message from your mail system.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20120726/7d13d9c6/attachment-0004.html>


More information about the Public mailing list