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

[Bruce Morton]

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<mailto:kirk_hall at trendmicro.com>; wthayer at godaddy.com<mailto:wthayer at godaddy.com>; tim.moses at entrust.com<mailto: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> [mailto:chris_bailey at trendmicro.com]<mailto:[mailto:chris_bailey at trendmicro.com]>
Sent: Tuesday, July 24, 2012 1:15 PM
To: Dean Coclin
Cc: kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>; Rick Andrews; wthayer at godaddy.com<mailto:wthayer at godaddy.com>; tim.moses at entrust.com<mailto: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<mailto: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<mailto:kirk_hall at trendmicro.com>'; Rick Andrews
Cc: wthayer at godaddy.com<mailto:wthayer at godaddy.com>; tim.moses at entrust.com<mailto:tim.moses at entrust.com>; chris_bailey at trendmicro.com<mailto: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> [mailto:kirk_hall at trendmicro.com]<mailto:[mailto:kirk_hall at trendmicro.com]>
Sent: Monday, July 23, 2012 2:20 PM
To: Dean Coclin; Rick Andrews
Cc: wthayer at godaddy.com<mailto:wthayer at godaddy.com>; tim.moses at entrust.com<mailto:tim.moses at entrust.com>; chris_bailey at trendmicro.com<mailto: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<mailto:wthayer at godaddy.com>); Tim Moses (tim.moses at entrust.com<mailto: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/5e560148/attachment-0004.html>