Re: Seeking guidance on proceeding with KISA root inclusion request

2014-03-10 Thread Eddy Nigg

On 03/07/2014 07:10 AM, From spark0...@gmail.com:
According to Mozilla's definition of independent party, KISA is 
independent organization from Sub-CAs(not employees nor director)


The minute a CA signs a certificate of/for another CA, it's not 
independent at all. In fact a tight relationship exists between the two 
parties and a CA can't audit another CA. For this the BR sets forth a 
requirement for an independent audit by a (different) auditing firm than 
the CA signer/issuer, in order to avoid any conflict of interests.


--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Question about BR audit

2014-03-10 Thread Kathleen Wilson

On 3/6/14, 9:58 AM, Kathleen Wilson wrote:

On 3/3/14, 10:33 AM, Kathleen Wilson wrote:

All,

I received the following question from an auditor, and would appreciate
hearing your opinions on it. This question is in regards to a new CA
inclusion request. New CAs are frequently not members of the CA/Browser
Forum, so they tend to find out about the Baseline Requirements audit
when they apply for inclusion.


For those CA who have done the compliance with the Baseline Requirements
for the first time, will your root certificate program accept a
point-in-time readiness assessment audit against the WebTrust Baseline
Requirements Program?



For reference, our documented expectations are here:
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Audit_Criteria

Thanks,
Kathleen




Based on the discussion so far, it appears that folks are OK with new
CAs getting a point-in-time readiness assessment audit the first time
they get a Baseline Requirements audit, as long as the CA has also been
getting the other audits (WebTrust CA or ETSI TS 102 042) done annually.

https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy


Currently says:
"Any Certificate Authority being considered for root inclusion after
February 15, 2013 must comply with Version 2.1 of Mozilla's CA
Certificate Policy."

Mozilla's CA Certificate Policy version 2.1 and later requires a BR
audit, but doesn't say anything about a point-in-time readiness audit.

How about if I update the wiki page as follows?

"Any Certificate Authority being considered for root inclusion after
February 15, 2013 must comply with Version 2.1 of Mozilla's CA
Certificate Policy. This includes having a Baseline Requirements audit
performed if the websites trust bit is to be enabled. Note that the CA's
first Baseline Requirements audit may be a Point in Time audit."

Thanks,
Kathleen





I made the proposed change to the wiki page.

https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy
"Any Certificate Authority being considered for root inclusion after 
February 15, 2013 must comply with Version 2.1 or later of Mozilla's CA 
Certificate Policy. This includes having a Baseline Requirements audit 
performed if the websites trust bit is to be enabled. Note that the CA's 
first Baseline Requirements audit may be a Point in Time audit."


Please let me know if you see any problems with this change.

Thanks,
Kathleen

PS: I also updated a few of the links in that page.









___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Seeking guidance on proceeding with KISA root inclusion request

2014-03-10 Thread spark0102
2014년 3월 11일 화요일 오전 8시 6분 55초 UTC+9, Eddy Nigg 님의 말:
> On 03/07/2014 07:10 AM, From spark0...@gmail.com:
> 
> > According to Mozilla's definition of independent party, KISA is 
> 
> > independent organization from Sub-CAs(not employees nor director)
> 
> 
> 
> The minute a CA signs a certificate of/for another CA, it's not 
> 
> independent at all. In fact a tight relationship exists between the two 
> 
> parties and a CA can't audit another CA. For this the BR sets forth a 
> 
> requirement for an independent audit by a (different) auditing firm than 
> 
> the CA signer/issuer, in order to avoid any conflict of interests.

This might be a normal case for CA and Sub-CA in the business and that's why I 
am mentioning Korea Electronic Signature Act.
I do understand why BR is requesting for 'independency' of the auditor, but 
because KISA is designated by law to audit the accredited CAs, our relationship 
is clear(no corruption or mis-audit can happen). It is between the auditor and 
auditee. We also do not have any conflict of interest between KISA and Sub-CAs 
because we do not make any profit from the sub-CAs. 

> 
> 
> 
> -- 
> 
> Regards
> 
> 
> 
> Signer:  Eddy Nigg, StartCom Ltd.
> 
> XMPP:start...@startcom.org
> 
> Blog:  http://blog.startcom.org/
> 
> Twitter: http://twitter.com/eddy_nigg

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Seeking guidance on proceeding with KISA root inclusion request

2014-03-10 Thread Al Billings
On 3/10/14, 6:58 PM, spark0...@gmail.com wrote:
> This might be a normal case for CA and Sub-CA in the business and that's why 
> I am mentioning Korea Electronic Signature Act.
> I do understand why BR is requesting for 'independency' of the auditor, but 
> because KISA is designated by law to audit the accredited CAs, our 
> relationship is clear(no corruption or mis-audit can happen). It is between 
> the auditor and auditee. We also do not have any conflict of interest between 
> KISA and Sub-CAs because we do not make any profit from the sub-CAs. 

The reasoning here is that there should be no ongoing financial
relationship causing a conflict of interest, I believe.

Al

-- 
Program Manager
Firefox Platform Security Team




smime.p7s
Description: S/MIME Cryptographic Signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy