Re: GRCA: Out-of-date CPS provided in CCADB

[horn917--- via dev-security-policy]

We have updated our CP and English website.
Please see https://grca.nat.gov.tw/GRCAeng/index.html 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

[horn917--- via dev-security-policy]

Wayne Thayer於 2019年3月30日星期六 UTC+8上午4時48分27秒寫道：
> The BRs require EKUs in leaf TLS certs, but there is no equivalent
> requirement for S/MIME certificates. This leads to confusion such as [1] in
> which certificates that are not intended for TLS or S/MIME fall within the
> scope of our policies.
> 
> Simply requiring EKUs in S/MIME certificates won't solve the problem unless
> we are willing to exempt certificates without an EKU from our policies, and
> doing that would create a rather obvious loophole for issuing S/MIME
> certificates that don't adhere to our policies.
> 
> The proposed solution is to require EKUs in all certificates that chain up
> to roots in our program, starting on some future effective date (e.g. April
> 1, 2020). This has the potential to cause some compatibility problems that
> would be difficult to measure and assess. Before drafting language for this
> proposal, I would like to gauge everyone's support for this proposal.
> 
> Alternately, we could easily argue that section 1.1 of our existing policy
> already makes it clear that CAs must include EKUs other than
> id-kp-serverAuth and id-kp-emailProtection in certificates that they wish
> to remain out of scope for our policies.
> 
> This is https://github.com/mozilla/pkipolicy/issues/163
> 
> I will greatly appreciate everyone's input on this topic.
> 
> - Wayne
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1523221


GPKI(Taiwan) will follow Mozilla policy to add EKU to EE certificates
However, the influence range of implementation is very large.
We need to define our own Document Signing EKU and data encryption EKU, and 
coordinate all subordinate Cas(Five CAs) and application system’s owners(more 
than 2,000 application systems). 
It needs a whole year to implement this. Therefore, after multiple evaluations, 
it is decided to officially add the EKU to the user certificate on January 1, 
2021.
It is difficult for us to complete ahead of April 2020.
Can we get more buffer?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Taiwan GRCA Root Renewal Request

[horn917--- via dev-security-policy]

Kathleen Wilson於 2017年2月3日星期五 UTC+8上午6時36分54秒寫道：
> On Tuesday, December 13, 2016 at 2:36:15 PM UTC-8, Kathleen Wilson wrote:
> > Thanks to all of you who have reviewed and commented on this request from 
> > Government of Taiwan, Government Root Certification Authority (GRCA), to 
> > include their renewed Government Root Certification Authority root 
> > certificate, and turn on the Websites and Email trust bits.
> > 
> > To summarize this discussion so far, two primary concerns have been raised, 
> > as follows.
> > 
> > 1) There are several intermediate certificates that are technically capable 
> > of issuing TLS certificates, but have not been audited according to the 
> > BRs. This is a show-stopper.
> > 
> > Reference:
> > https://wiki.mozilla.org/CA:BaselineRequirements#Whole-Population_Audit_of_Intermediate_Certs
> > “BR Audits must always include the whole-population audit of intermediate 
> > certificates that are capable of issuing SSL certs.”
> > 
> > This means that if the intermediate certificate is not technically 
> > constrained via EKU (and name constraints) then it must be audited 
> > according to the BRs. 
> > 
> > We have resolved this particular situation in the past by having the CA get 
> > an audit statement saying that the intermediate certificate has not issued 
> > TLS certificates during the audit period. And requiring that the CA get 
> > such an audit statement annually.
> > 
> 
> The CA has been working with their auditor to get an appropriate audit 
> statement that covers all of the intermediate certs chaining up to this root.
> 

In accordance with Kathleen's advice, our auditor has provided such a audit 
statement.(https://bug1065896.bmoattachments.org/attachment.cgi?id=8835815)

> > 
> > 2) The new root certificate has the same exact full distinguished name as 
> > the old root certificate. I think this is OK.
> > 
> > The CA tested this with Firefox, and provided their test results:
> > https://bugzilla.mozilla.org/attachment.cgi?id=8818360
> >
> 
> The new root cert having the same DN as the old root cert appears to work
> from a technical standpoint (i.e. mozilla::pkix will find the right path if 
> all necessary certificates are present). However, the duplicate names have 
> already caused unnecessary confusion: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1304264
> 
> This "new" root certificate was created in 2012, is included in Microsoft's 
> program, and has several active intermediate certs. So it might not be 
> reasonable to ask the CA to generate a new root certificate at this point in 
> time. However, I urge the CA to take note, and not repeat this with the next 
> generation of their root certificate.
> 
> Kathleen

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