Re: Taiwan GRCA Root Renewal Request

[Wayne Thayer via dev-security-policy]

Thanks for pointing this out Ryan and Dimitris. You are both correct: we
should direct Taiwan GRCA to change their request from including the root
to including only the subordinate CAs that comply with the Mozilla policy.
The option of adding the non-compliant subordinate CAs to OneCRL does not
meet our policy.

I will determine what additional information we need to change this
inclusion request and will add it to bug 1065896. I then expect to place
this request on hold until we receive the updated information.


- Wayne

On Sun, Jan 28, 2018 at 10:53 PM, Dimitris Zacharopoulos 
wrote:

>
>
> On 26/1/2018 11:54 μμ, Ryan Sleevi via dev-security-policy wrote:
>
> Has any consideration been given to adopt a similar policy as discussed
> with the Government of Korea application 
> -https://bugzilla.mozilla.org/show_bug.cgi?id=1226100#c38
>
>
>
> Just to avoid any possible mis-reading of:
>
> "If you have intermediates for which you cannot disclose, whether it be for 
> personal, operational, or legal reasons, then an appropriate solution, 
> consistent with Mozilla CA Certificate Policy, is to use Technically 
> Constrained Subordinate CAs - as defined within the Baseline Requirements and 
> as reflected within the Mozilla policy. Such TCSCAs are technically limited 
> from the issuance of TLS certificates, and by doing so, are allowed to be 
> operated in a way that is not consistent with the Baseline Requirements nor 
> compliant with Mozilla Policy."
>
>
> Currently, the Baseline Requirements (section 7.1.5) allow for TCSCAs to
> issue TLS Certificates, by requiring the nameConstraints extension,
> limiting the issuance to specific Domain Names and Organizations. These
> TCSCAs MUST follow the Baseline Requirements, with the exceptions provided
> for these types of TCSCAs.
>
> As far as the Mozilla Policy is concerned, if a TCSCAs is technically
> capable of issuing a Certificate for TLS authentication or S/MIME, it MUST
> comply with the Mozilla policy, with the exceptions provided for TCSCAs.
> Section 1.1 of the Mozilla Policy is fairly clear on the scope of the
> policy. If there are possibly more exceptions, it should probably be
> updated to reflect these cases.
>
>
> Dimitris.
>
___
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

[Dimitris Zacharopoulos via dev-security-policy]

On 26/1/2018 11:54 μμ, Ryan Sleevi via dev-security-policy wrote:
> Has any consideration been given to adopt a similar policy as discussed
> with the Government of Korea application -
> https://bugzilla.mozilla.org/show_bug.cgi?id=1226100#c38


Just to avoid any possible mis-reading of:

"If you have intermediates for which you cannot disclose, whether it be for 
personal, operational, or legal reasons, then an appropriate solution, 
consistent with Mozilla CA Certificate Policy, is to use Technically 
Constrained Subordinate CAs - as defined within the Baseline Requirements and 
as reflected within the Mozilla policy. Such TCSCAs are technically limited 
from the issuance of TLS certificates, and by doing so, are allowed to be 
operated in a way that is not consistent with the Baseline Requirements nor 
compliant with Mozilla Policy."


Currently, the Baseline Requirements (section 7.1.5) allow for TCSCAs to
issue TLS Certificates, by requiring the nameConstraints extension,
limiting the issuance to specific Domain Names and Organizations. These
TCSCAs MUST follow the Baseline Requirements, with the exceptions
provided for these types of TCSCAs.

As far as the Mozilla Policy is concerned, if a TCSCAs is technically
capable of issuing a Certificate for TLS authentication or S/MIME, it
MUST comply with the Mozilla policy, with the exceptions provided for
TCSCAs. Section 1.1 of the Mozilla Policy is fairly clear on the scope
of the policy. If there are possibly more exceptions, it should probably
be updated to reflect these cases.


Dimitris.
___
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

[Ryan Sleevi via dev-security-policy]

On Fri, Jan 12, 2018 at 2:27 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, June 1, 2017 at 5:03:15 PM UTC-7, Kathleen Wilson wrote:
> > On Friday, May 26, 2017 at 9:32:57 AM UTC-7, Kathleen Wilson wrote:
> > > On Wednesday, March 15, 2017 at 5:01:13 PM UTC-7, Kathleen Wilson
> wrote:
> > > All,
> > >
> > > I requested that this CA perform a BR Self Assessment, and they have
> attached their completed BR Self Assessment to the bug here:
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1065896#c30
> > >
> > > Aaron has reviewed and verified the BR Self Assessment.
> > >
> > > Therefore, I plan to approve this request from the Government of
> Taiwan (GRCA) to include their "Government Root Certification Authority"
> root certificate, and turn on the Websites and Email trust bits, and
> constrain this root to *.tw.
> > >
> > > If there are no further concerns, then I will close this discussion
> and recommend approval in the bug.
> > >
> >
> > After further consideration, I have decided to wait for the CA to
> provide their updated CP/CPS that will address all of the shortcomings that
> they noted in their BR Self Assessment that they plan to fix in the next
> version of their CP/CPS.
> >
> > So, this discussion will be on hold again until I have received and
> reviewed their updated CP/CPS documents.
>
> We have received the updated CP/CPS and have received and verified the
> most recent audits for this CA. Since we haven't yet implemented the
> changes to our inclusion process proposed by Kathleen a few days ago, I am
> now restarting discussion on this request, and I will post my comments once
> the CP/CPS review is completed.
>
> I plan to recommend that the XCA, MOICA, and MOEACA sub-CAs be added to
> OneCRL because they are neither technically constrained or BR audited.
>

Has any consideration been given to adopt a similar policy as discussed
with the Government of Korea application -
https://bugzilla.mozilla.org/show_bug.cgi?id=1226100#c38
___
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

[Wayne Thayer via dev-security-policy]

This root inclusion request is currently in the public discussion phase [1]

After reviewing Taiwan GRCA's CP, CPS and related documents [2], I have the 
following comments:

==Good==
1. GRCA has requested that this root be constrained to issuing certificates for 
.tw domains.
2. The BR Self Assessment is very detailed and helpful.

==Meh==
1. This root is intended to replace an older root that has the exact same DN. 
Compatibility concerns were raised but testing performed by GRCA found no 
problems.
2. The CP doesn’t contain the ’dated changelog’ required under Mozilla policy 
section 3.3.
3. The audit reports don’t include the version numbers of CA policy documents 
referenced during the audit.
4. The WebTrust for CAs audit report doesn’t list all the subordinate CAs 
covered by the audit. They are listed in a supplemental statement provided by 
the auditor.
5. The CP/CPS docs are still in RFC 2527 format.
6. It is not clear how the policy for authenticating individual identity 
described in section 3.1.9 of the GCA CPS meets the requirements of BR 3.2.3 
and 3.2.5. Please provide more detail.
7. In September it was reported that GRCA was signing OCSP responses with an 
unconstrained SHA-1 certificate: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1397832 The issue has been fixed.
8. Procedures that fulfill Mozilla policy section 2.2(2) requirements for 
validating email addresses are not specified in any documents.

==Bad==
1. The application for inclusion states that only the GCA subordinate can issue 
SSL certificates, and this subordinate has its own CPS that lists SSL-specific 
policies such as CAA. The HCA subordinate also has a BR audit, but GRCA has 
stated that it is no longer used to issue SSL certificates. Should the HCA 
subordinate be added to OneCRL along with the other subordinates (XCA, MOICA, 
and MOECACA) that are not BR audited?
2. According to the audit supplement, the MOICA audit report is qualified due 
to ‘one issue related to system access management’, but the actual audit report 
is not written in English. Please describe the issue and how it was resolved.
3. The GCA CPS describes CAA policies, but GRCA’s issuer domain names are not 
listed as required by BR section 2.2.
4. GCA CPS section 3.1.12 describes the domain authorization process for SSL 
certificates, but it does not comply with Mozilla policy section 2.2(3).

One of the recent updates to the application process [1] is a 3-week time 
period for public comments. I would like to apply that change to this inclusion 
request. Specifically, if GRCA has sufficiently answered the questions that I 
have raised above, and any other discussion on this list has reached a 
conclusion, then I will plan to close the discussion period on 10-Feb.

- Wayne

[1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1065896
___
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

[Wayne Thayer via dev-security-policy]

On Thursday, June 1, 2017 at 5:03:15 PM UTC-7, Kathleen Wilson wrote:
> On Friday, May 26, 2017 at 9:32:57 AM UTC-7, Kathleen Wilson wrote:
> > On Wednesday, March 15, 2017 at 5:01:13 PM UTC-7, Kathleen Wilson wrote:
> > All, 
> > 
> > I requested that this CA perform a BR Self Assessment, and they have 
> > attached their completed BR Self Assessment to the bug here:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1065896#c30
> > 
> > Aaron has reviewed and verified the BR Self Assessment.
> > 
> > Therefore, I plan to approve this request from the Government of Taiwan 
> > (GRCA) to include their "Government Root Certification Authority" root 
> > certificate, and turn on the Websites and Email trust bits, and constrain 
> > this root to *.tw. 
> > 
> > If there are no further concerns, then I will close this discussion and 
> > recommend approval in the bug.
> > 
> 
> After further consideration, I have decided to wait for the CA to provide 
> their updated CP/CPS that will address all of the shortcomings that they 
> noted in their BR Self Assessment that they plan to fix in the next version 
> of their CP/CPS.
> 
> So, this discussion will be on hold again until I have received and reviewed 
> their updated CP/CPS documents.

We have received the updated CP/CPS and have received and verified the most 
recent audits for this CA. Since we haven't yet implemented the changes to our 
inclusion process proposed by Kathleen a few days ago, I am now restarting 
discussion on this request, and I will post my comments once the CP/CPS review 
is completed.

I plan to recommend that the XCA, MOICA, and MOEACA sub-CAs be added to OneCRL 
because they are neither technically constrained or BR audited.

Wayne
___
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

[Kathleen Wilson via dev-security-policy]

On Friday, May 26, 2017 at 9:32:57 AM UTC-7, Kathleen Wilson wrote:
> On Wednesday, March 15, 2017 at 5:01:13 PM UTC-7, Kathleen Wilson wrote:
> All, 
> 
> I requested that this CA perform a BR Self Assessment, and they have attached 
> their completed BR Self Assessment to the bug here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1065896#c30
> 
> Aaron has reviewed and verified the BR Self Assessment.
> 
> Therefore, I plan to approve this request from the Government of Taiwan 
> (GRCA) to include their "Government Root Certification Authority" root 
> certificate, and turn on the Websites and Email trust bits, and constrain 
> this root to *.tw. 
> 
> If there are no further concerns, then I will close this discussion and 
> recommend approval in the bug.
> 

After further consideration, I have decided to wait for the CA to provide their 
updated CP/CPS that will address all of the shortcomings that they noted in 
their BR Self Assessment that they plan to fix in the next version of their 
CP/CPS.

So, this discussion will be on hold again until I have received and reviewed 
their updated CP/CPS documents.

Thanks,
Kathleen


___
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

[Kathleen Wilson via dev-security-policy]

On Wednesday, March 15, 2017 at 5:01:13 PM UTC-7, Kathleen Wilson wrote:
>  
> So, if there are no further questions or comments about this CA's request, 
> then I will close this discussion and recommend approval in the bug.
> 

All, 

I requested that this CA perform a BR Self Assessment, and they have attached 
their completed BR Self Assessment to the bug here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1065896#c30

Aaron has reviewed and verified the BR Self Assessment.

Therefore, I plan to approve this request from the Government of Taiwan (GRCA) 
to include their "Government Root Certification Authority" root certificate, 
and turn on the Websites and Email trust bits, and constrain this root to *.tw. 

If there are no further concerns, then I will close this discussion and 
recommend approval in the bug.

Thanks,
Kathleen
___
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

[Kathleen Wilson via dev-security-policy]

All,

My apologies for taking so long to get back to this discussion about the 
Government of Taiwan's (GRCA's) request to include their Government Root 
Certification Authority root certificate, and turn on the Websites and Email 
trust bits. 

Note that GRCA has suggested that this root be constrained to *.tw.

To my knowledge, the questions and concerns raised about this request have been 
resolved. In particular:

1) There are several intermediate certificates that are technically capable of 
issuing TLS certificates, but have not been 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.

GRCA has provided the requested audit statement: 
https://www.google.com/url?q=https%3A%2F%2Fbug1065896.bmoattachments.org%2Fattachment.cgi%3Fid%3D8835815=D=1=AFQjCNH9syh0sbLxMj35bdC1TDeQslx32w


2) The new root certificate has the same exact full distinguished name as the 
old root certificate. 

My recommendation is that we allow it this time, but not for future root certs 
from this CA. 
 
So, if there are no further questions or comments about this CA's request, then 
I will close this discussion and recommend approval in the bug.

Thanks,
Kathleen
___
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

[Peter Gutmann via dev-security-policy]

Gervase Markham via dev-security-policy  
writes:

>Peter: you are going to have to re-summarise your question. And then, if you
>are asking why Mozilla code works in a certain way, mozilla.dev.security or
>mozilla.dev.tech.crypto are almost certainly far better venues.

Sure, no problem.  I was just replying to a post by Kathleen on this list, and
it seemed like a policy issue so I figured it was the right forum.  I'll CC it
to dev.security as well...

The original post was about the fact the Mozilla runs into lots of problems
with top-down path construction:

>Indeed, and as per your comment here:
>https://bugzilla.mozilla.org/show_bug.cgi?id=1056341#c24

I asked:

So just to satisfy my curiosity, it's been known ever since top-down
construction was first advocated by PKI loon^H^H^Htheoreticians:

https://www.youtube.com/watch?v=CoOrmK4OueY

that you work bottom-up, not top-down.  If that's not obvious just from about
a beer's worth of analysis then it should have been when one of said PKI
theoreticians described trying to implement it at a conference and pointed out
that his implementation ran for three days without terminating, after which he
tried the same thing again.

Did no-one see that this was going to happen?  Why would anyone try and do it
this way?  Rather baffled minds want to know...

Peter.
___
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

[Gervase Markham via dev-security-policy]

On 11/02/17 12:13, Peter Gutmann wrote:
> Is no-one at Mozilla able to explain why they did this?  It's a nontrivial
> piece of code to implement, surely someone must know what the thinking was
> behind doing it this way?

Peter: you are going to have to re-summarise your question. And then, if
you are asking why Mozilla code works in a certain way,
mozilla.dev.security or mozilla.dev.tech.crypto are almost certainly far
better venues.

Gerv
___
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

Re: Taiwan GRCA Root Renewal Request

[Peter Gutmann]

Kathleen Wilson  writes:

>Indeed, and as per your comment here:
>https://bugzilla.mozilla.org/show_bug.cgi?id=1056341#c24

So just to satisfy my curiosity, it's been known ever since top-down
construction was first advocated by PKI loon^H^H^Htheoreticians:

https://www.youtube.com/watch?v=CoOrmK4OueY

that you work bottom-up, not top-down.  If that's not obvious just from about
a beer's worth of analysis then it should have been when one of said PKI
theoreticians described trying to implement it at a conference and pointed out
that his implementation ran for three days without terminating, after which he
tried the same thing again.

Did no-one see that this was going to happen?  Why would anyone try and do it
this way?  Rather baffled minds want to know...

Peter.
___
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

[Kathleen Wilson]

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.

> 
> 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

Re: Taiwan GRCA Root Renewal Request

[Kathleen Wilson]

On Thursday, December 15, 2016 at 10:56:52 AM UTC-8, Brian Smith wrote:
> It is important to fix the DoS issue with the path building when there
> are many choices for the same subject. SKI/AKI matching only fixes the
> DoS issue for benign cases, not malicious cases. Therefore some way of
> limiting the resource usage without relying on AKI/SKI matching is
> needed.


Indeed, and as per your comment here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1056341#c24
___
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

[Brian Smith]

Kathleen Wilson  wrote:
> How about the following?

That sounds right to me.

It is important to fix the DoS issue with the path building when there
are many choices for the same subject. SKI/AKI matching only fixes the
DoS issue for benign cases, not malicious cases. Therefore some way of
limiting the resource usage without relying on AKI/SKI matching is
needed.

I'm not sure how to incorporate the possibility of the issue being
fixed into your text.

Cheers,
Brian
___
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

[Kathleen Wilson]

In regards to updating 
https://wiki.mozilla.org/CA:How_to_apply#Root_certificates_with_the_same_subject_and_different_keys
 ?

How about the following? 
~~
The standards allow for two CA certificates to have the same subject names but 
different subject public keys. Please try to avoid this, because it often leads 
to confusion and compatibility issues. When verifying an end-entity certificate 
chaining up to a root certificate with the same subject name as another root 
certificate, if Firefox is aware of the existence of both root certificates, it 
will try all possible orderings of (subject, issuer) pairs until it finds the 
right one. If there are many certificates all with the same subject and issuer 
names, the number of orderings grows exponentially, so it can take a long time 
to evaluate the certificate chains. Therefore, it is better to avoid these 
kinds of situations.

Note that for root certificates, Firefox ignores the authority key identifier 
and subject key identifier extensions.
~~

RE:
> There could be something trying to enforce that root certificates sharing the 
> same distinguished name MUST be owned by the same entity (well, the private 
> key, and all the accompanying things). That should also be true for 
> subordinate CAs (wrt cross-signing), but this has to be enforced by issuing 
> CAs.

Maybe that should be part of the BRs?

Thanks,
Kathleen


___
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

[Brian Smith]

On Tue, Dec 13, 2016 at 12:36 PM, Kathleen Wilson  wrote:
> Question: Do I need to update 
> https://wiki.mozilla.org/CA:How_to_apply#Root_certificates_with_the_same_subject_and_different_keys
>  ?

That description seems to have been written to describe the behavior
of the old, non-libpkix, NSS verification code. NSS's libpkix probably
works differently than that. Also, that description is not accurate
and is somewhat misleading for mozilla::pkix.

Cheers,
Brian
-- 
https://briansmith.org/
___
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

[Erwann Abalea]

Bonsoir,

Le mardi 13 décembre 2016 23:36:15 UTC+1, Kathleen Wilson a écrit :
[...]
> Question: Do I need to update 
> https://wiki.mozilla.org/CA:How_to_apply#Root_certificates_with_the_same_subject_and_different_keys
>  ?

There could be something trying to enforce that root certificates sharing the 
same distinguished name MUST be owned by the same entity (well, the private 
key, and all the accompanying things). That should also be true for subordinate 
CAs (wrt cross-signing), but this has to be enforced by issuing CAs.
___
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

[Kathleen Wilson]

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.


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

Question: Do I need to update 
https://wiki.mozilla.org/CA:How_to_apply#Root_certificates_with_the_same_subject_and_different_keys
 ?


Please let me know if there is anything else (other than item #1) that this CA 
needs to address before we may move forward with this request.

Thanks,
Kathleen
___
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

[Wen-Cheng Wang]

On Saturday, December 10, 2016 at 3:30:09 AM UTC+2, Erwann Abalea wrote:
> I don't think there is a bug in IIS here. IIRC, you discovered that IIS 
> doesn't send the self-issued certificate when loaded with the 2 self-signed 
> root certs and the self-issued cert (1st gen signing 2nd gen). And IIS' 
> behaviour is right, in that it doesn't know if the browser will need this 
> link certificate. IIRC again, what was proposed for you is that you declare 
> the 2nd gen self-signed cert as untrusted on your side, to force IIS to send 
> the link.
> 

Well, regarding whether it is a bug, I think that depends on whether IIS can 
distinguish self-issued certificates from self-issued certificates? In our 
speculation, we guess that IIS treats any certificate of which issuer DN and 
subject DN are the same as a self-issued certificate. That is why we submit a 
bug report to Microsoft to explain to them that it might be a self-issued 
certificate according to RFC 5280 and the X.509 standards. We guess the reason 
why IIS will not send back our self-issued intermediate certificate to the 
client is that it treat it as a self-signed root certificate (Note that in 
SSL/TLS protocol, the server side does not need to send back self-signed root 
certificates to the client side.) However, if IIS development team does know 
the different between a self-issued certificate and a self-signed certificate, 
and they decide not to support self-issued certificates for some reason. Well, 
you can say that it is not a bug and it is by design.  

> Talking about your duties when playing with such renewals, you already know 
> that the population under GCA 1st gen and GCA 2nd gen is the same with regard 
> to generated serial numbers and CRLs produced (the content of the CRL 
> chaining to GCA 1st gen MUST be identical to the content of the CRL chaining 
> to GCA 2nd gen, unless you implement CRL partitioning).
> 

In our National LDAP Tree, GRCA and GCA are both permanent entities. After they 
performing re-key, they are still the same entities in the National LDAP Tree 
but with different generations of keys. The same situations also apply to 
re-keys of end-entities. When end-entities' key expired, they will simply 
generate new keys and apply for new certificate with the same DNs. Please be 
understood that we have a National LDAP Tree and we intend to keep all 
entities' DNs permanent, unless they really change their names of jurisdictions.

> And the situation gets weirder with the Root. In X.509, GDCA 1st gen and GDCA 
> 2nd gen are a single CA (serial numbers assigned to issued certs, CRLs, etc). 
> And there's a difference here between RFC5280 and X.509. In RFC5280, the CRL 
> chaining to GDCA 1st gen can't give a valid revocation result for a 
> certificate chaining to GDCA 2nd gen, and thus the set of serial numbers for 
> certs issued by each gen of GDCA may or may not be disjoint. It's an unclear 
> area of RFC5280, and it's not fun to sit in here.
> 
> >From what I see, you're doing it correctly from an X.509 point of view. Each 
> >GCA gen produces its partitioned CRL  plus an unpartitioned complete one, 
> >both complete ones are identical in content (except a few seconds delta in 
> >the thisUpdate field, unimportant). And I found 3 CRLs issued under GDCA, 
> >with identical contents. That should also work if RFC5280 rules are followed.
> 

You are right, RFC 5280 is unclear about the relationship between two 
generations of CRLs. In this matter, we indeed follow what the original X.509 
standards says. That is each CA should still issue the Complete CRL even if 
they issue partitioned CRL. 

> Mozilla::pkix doesn't know about self-issued certificates. The library just 
> considers such a certificate as a subordinate CA cert. It happens to work in 
> your specific situation.
> 
> > Other https server such aa Apache have no problem with certificate chains 
> > containing self-issued certificates.
> 
> That may not be true in recent versions, depending on how you configure your 
> server. But again, off-topic.

Yes, actually I think those browsers and https server doesn't know about 
self-issued certificates, they simply treat them as intermediate CA 
certificates. However, you know, the original idea of using self-issued 
certificates to facilitate key-rollover is actually want certificate-using 
systems treat them like intermediate CA certificates.

Wen-Cheng Wang
___
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

[Wen-Cheng Wang]

On Friday, December 9, 2016 at 1:43:27 AM UTC+2, Brian Smith wrote:
> Some people claimed some software may be unable to cope with two
> different CA certificates with the same subject DNs. Nobody claimed
> that Firefox is unable to cope with two CA certificates having the
> same subject DN. It should work fine in Firefox because Firefox will
> attempt every CA cert it finds with the same DN.

Thanks a lot for clarifying this.

> One caveat: If there are "too many" CA certificates with the same
> subject DN, Firefox will spend a very long time searching through
> them. This is a bug in Firefox that's already on file.

We will maintains at most two generations of Root CA certificates with the same 
DN in Mozilla/firefox's trust list. I believe that we will not cause such kind 
of "too many" issue.

> I'm unconvinced that it is worthwhile to add the Key Identifier stuff
> just to accommodate this one public CA plus any private CAs that do
> similarly. I think it's better to ask this CA to instead do things the
> way all the other public CAs do (AFAIK). In other words, this is kind
> of where the Web PKI diverges from PKIX.

Believe me, now we really take consideration that in the next generation of our 
Government Root CA re-key, we might start to change CA DNs between generations, 
like what commercial CAs do.

As I mentioned in my previous mail, we have a national LDAP tree and all 
entities, including the Government Root CA and all subordinate CAs, have been 
assigned their unique and permanent DNs. In the future, when our Government PKI 
starts to change CA DNs between generations, various Root CA nodes and 
Subordinate CA nodes will be generated in the national LDAP tree and 
application systems might get confused. This is one issue that we need to solve 
in the future.

> However, the CA changing its practices could be done on a
> going-forward basis; the existing instances shouldn't be problematic
> and so I don't think they should be excluded on the basis of what they
> already did.

Thanks for this positive opinion. If our root CA will not cause problems to 
Mozilla NSS/Firefox, I really hope that Mozilla can accept our second 
generation Government Root CA certificate. Especially, Firefox users in Taiwan 
have already waited for a long time.

Wen-Cheng Wang
___
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

[Wen-Cheng Wang]

On Thursday, December 8, 2016 at 10:21:53 PM UTC+2, Gervase Markham wrote:
> On 05/12/16 21:10, Wen-Cheng Wang wrote:
> > I mean BR Audit is specifically for CAs that provide SSL
> > certificates. Therefore, it is not possible to conduct on those
> > subordinate CAs that do not provide SSL certificates, 
> 
> AIUI, that's not actually true. As we found out recently when discussing
> another CA whose name escapes me, it's possible to include a subordinate
> CA in an audit even if it's not issuing any certificates.
 
To my understanding, if a CA has not yet issuing any certificate, it is at most 
to perform "readiness assessment" on that CA because there is still no records 
or evidences to proof the conformity.

> > As for how to make sure policies and practices of all our CAs fall
> > under Mozilla's root policy, every time we received Kathleen's
> > notification about the revision of Mozilla's root policy, we reviewed
> > our CP of the Government PKI and CPSs of all CAs seriously. If
> > necessary, we will make amendments to our CP and CPSs so that they
> > can aligned with Mozilla's root policy and we will reply what we plan
> > to do for responding the change of Mozilla's root policy to Kathleen.
> > Since we have conducted WebTrust for CA audits on the whole
> > Government PKI (including the root CA and all its subordinate CAs),
> > the audit results can assure our CAs are all compliant to Mozilla's
> > root policy.
> 
> Our root policy also requires (or will soon require) a BR audit to cover
> all sub-CAs technically capable of issuing server certs.

Currently, in our Government PKI, GCA is the only sub-CA approved, in its CPS, 
by the government Policy Management Authority (PMA) to issuing SSL 
certificates. For other subordinate CAs, if they want to issue SSL 
certificates, they must amend their CPSs and get approved by the government 
PMA. For subordinate CAs that currently does not intend to issuing SSL 
certificates, they have no SSL certificate practices or procedures to be 
disclosed in their CPSs. In such situations, we think it will be not much 
meaningful to conduct the BR audit on them. After all, the main scope of the BR 
audit is to exam the conformity of SSL certificate practices or procedures.

Please see also in the WebTrust for Certification Authorities - Audit 
Applicability Matrix 
(http://www.webtrust.org/principles-and-criteria/item83665.pdf), it says that 
the BR Audit (WebTrust for CA - SSL Baseline + Network) is not required for 
Government CAs or Commercial CAs which only issuing certificates for all other 
uses.

Wen-Cheng Wang

___
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

[Erwann Abalea]

Bonsoir,

Le mardi 6 décembre 2016 09:31:48 UTC+1, Wen-Cheng Wang a écrit :
> Hi Jacob,
> 
> I think you get confused by My colleague Li-Chun's email because he mentioned 
> a lot about using self-issued certificates for key-rollover, AIA certificate 
> chaining support, and the bug of Microsoft IIS (note: not IE browser) in 
> handling self-issued certificates. All these are actually off-topic. We are 
> sorry if his email confused you.

I don't think there is a bug in IIS here. IIRC, you discovered that IIS doesn't 
send the self-issued certificate when loaded with the 2 self-signed root certs 
and the self-issued cert (1st gen signing 2nd gen). And IIS' behaviour is 
right, in that it doesn't know if the browser will need this link certificate. 
IIRC again, what was proposed for you is that you declare the 2nd gen 
self-signed cert as untrusted on your side, to force IIS to send the link.

> Here I would like to clarify that we are not here to asking for supporting 
> self-issued certificates or AIA certificate chaining. We are here to simply 
> request Mozilla to accept our second generation of Government Root CA 
> certificate.
> 
> Currently, our first generation of Government Root CA certificate has 
> alreading been in the trust list of Mozilla. After Mozilla accepting our 
> second generation of Government Root CA certificate, our certificate chains 
> for SSL will look like the following:
> 
> 1. Government Root CA (first generation) --> GCA (first generation) --> SSL 
> Cert
> 2. Government Root CA (second generation) --> GCA (second generation) --> SSL 
> Cert

You're playing with corner cases of X.509/PKIX. You're right that on paper, 
it's clearly defined, it works, etc. In practice, it may not work, and even if 
you can blame and shame a non completely conformant implementation refusing 
this scheme, I don't think it's a situation you should be comfortable in as a 
CA.

Talking about your duties when playing with such renewals, you already know 
that the population under GCA 1st gen and GCA 2nd gen is the same with regard 
to generated serial numbers and CRLs produced (the content of the CRL chaining 
to GCA 1st gen MUST be identical to the content of the CRL chaining to GCA 2nd 
gen, unless you implement CRL partitioning).

And the situation gets weirder with the Root. In X.509, GDCA 1st gen and GDCA 
2nd gen are a single CA (serial numbers assigned to issued certs, CRLs, etc). 
And there's a difference here between RFC5280 and X.509. In RFC5280, the CRL 
chaining to GDCA 1st gen can't give a valid revocation result for a certificate 
chaining to GDCA 2nd gen, and thus the set of serial numbers for certs issued 
by each gen of GDCA may or may not be disjoint. It's an unclear area of 
RFC5280, and it's not fun to sit in here.

From what I see, you're doing it correctly from an X.509 point of view. Each 
GCA gen produces its partitioned CRL  plus an unpartitioned complete one, both 
complete ones are identical in content (except a few seconds delta in the 
thisUpdate field, unimportant). And I found 3 CRLs issued under GDCA, with 
identical contents. That should also work if RFC5280 rules are followed.

> This is the same as the situation of other root CAs performing key-rollover.

It's not that common. I know about ICAO MRTD certs (worked on it for a few 
years, not that long ago), it's a real mess, and it's not a valid example of 
successful PKI deployment.

> One thing different with what other commercial CAs is that we do not change 
> the issuer DN when our root CA perform key-rollover. I have already explain a 
> lot of this in this discussion thread. According our tests, using the same 
> issuer DN between generations of root CA certificates actually will not cause 
> problem for browsers to perform certificate chaining. Therefore, please do 
> not worry about it. 
> 
> > 
> > The mistake was to use a part of those standards which is often
> > problematic in the real world.  For example, according to your
> > presentation, when IIS builds server certificate chains to send to
> > clients, it compares only the DN, causing problems when non-AIA-
> > downloading browsers visit IIS-powered sites with GCA certificates.
> 
> Since this is off-topic, I would not like to spend a lot time and space to 
> discuss self-issued certificate and AIA issues here. However, to make a quick 
> clarification, browsers do not have problem if the certificate chain contains 
> self-issued certificates. Actually, even Microsoft's IE can handle 
> certificate chains containing self-issued certificates. It is Microsoft's IIS 
> can not correctly send the certificate chain to the client side.

Mozilla::pkix doesn't know about self-issued certificates. The library just 
considers such a certificate as a subordinate CA cert. It happens to work in 
your specific situation.

> Other https server such aa Apache have no problem with certificate chains 
> containing self-issued certificates.

That may not be true in 

Re: Taiwan GRCA Root Renewal Request

[Brian Smith]

Gervase Markham  wrote:
> Just to help me be clear: the request is for the inclusion of a root
> with the same DN as a previous root, which will still be included after
> the addition? Or the problem with duplicate DNs occurs further down the
> hierarchy?

Some people claimed some software may be unable to cope with two
different CA certificates with the same subject DNs. Nobody claimed
that Firefox is unable to cope with two CA certificates having the
same subject DN. It should work fine in Firefox because Firefox will
attempt every CA cert it finds with the same DN.

One caveat: If there are "too many" CA certificates with the same
subject DN, Firefox will spend a very long time searching through
them. This is a bug in Firefox that's already on file.

> Does Firefox build cert chains using DNs, or using Key Identifiers as
> Wen-Cheng says it should? I assume it's the former, but want to check.

Firefox doesn't even parse the key identifiers. Using the key
identifiers are only helpful when a CA does the thing that this
particular CA does, using the same subject DN for multiple CA
certificates, to prevent the "too many" problem mentioned above.

I'm unconvinced that it is worthwhile to add the Key Identifier stuff
just to accommodate this one public CA plus any private CAs that do
similarly. I think it's better to ask this CA to instead do things the
way all the other public CAs do (AFAIK). In other words, this is kind
of where the Web PKI diverges from PKIX.

However, the CA changing its practices could be done on a
going-forward basis; the existing instances shouldn't be problematic
and so I don't think they should be excluded on the basis of what they
already did.

Cheers,
Brian
-- 
https://briansmith.org/
___
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

[Gervase Markham]

On 05/12/16 21:10, Wen-Cheng Wang wrote:
> I mean BR Audit is specifically for CAs that provide SSL
> certificates. Therefore, it is not possible to conduct on those
> subordinate CAs that do not provide SSL certificates, 

AIUI, that's not actually true. As we found out recently when discussing
another CA whose name escapes me, it's possible to include a subordinate
CA in an audit even if it's not issuing any certificates.

> As for how to make sure policies and practices of all our CAs fall
> under Mozilla's root policy, every time we received Kathleen's
> notification about the revision of Mozilla's root policy, we reviewed
> our CP of the Government PKI and CPSs of all CAs seriously. If
> necessary, we will make amendments to our CP and CPSs so that they
> can aligned with Mozilla's root policy and we will reply what we plan
> to do for responding the change of Mozilla's root policy to Kathleen.
> Since we have conducted WebTrust for CA audits on the whole
> Government PKI (including the root CA and all its subordinate CAs),
> the audit results can assure our CAs are all compliant to Mozilla's
> root policy.

Our root policy also requires (or will soon require) a BR audit to cover
all sub-CAs technically capable of issuing server certs.

Gerv

___
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

[Wen-Cheng Wang]

Hi Jacob,

I think you get confused by My colleague Li-Chun's email because he mentioned a 
lot about using self-issued certificates for key-rollover, AIA certificate 
chaining support, and the bug of Microsoft IIS (note: not IE browser) in 
handling self-issued certificates. All these are actually off-topic. We are 
sorry if his email confused you.

Here I would like to clarify that we are not here to asking for supporting 
self-issued certificates or AIA certificate chaining. We are here to simply 
request Mozilla to accept our second generation of Government Root CA 
certificate.

Currently, our first generation of Government Root CA certificate has alreading 
been in the trust list of Mozilla. After Mozilla accepting our second 
generation of Government Root CA certificate, our certificate chains for SSL 
will look like the following:

1. Government Root CA (first generation) --> GCA (first generation) --> SSL Cert
2. Government Root CA (second generation) --> GCA (second generation) --> SSL 
Cert

This is the same as the situation of other root CAs performing key-rollover.

One thing different with what other commercial CAs is that we do not change the 
issuer DN when our root CA perform key-rollover. I have already explain a lot 
of this in this discussion thread. According our tests, using the same issuer 
DN between generations of root CA certificates actually will not cause problem 
for browsers to perform certificate chaining. Therefore, please do not worry 
about it. 

> 
> The mistake was to use a part of those standards which is often
> problematic in the real world.  For example, according to your
> presentation, when IIS builds server certificate chains to send to
> clients, it compares only the DN, causing problems when non-AIA-
> downloading browsers visit IIS-powered sites with GCA certificates.

Since this is off-topic, I would not like to spend a lot time and space to 
discuss self-issued certificate and AIA issues here. However, to make a quick 
clarification, browsers do not have problem if the certificate chain contains 
self-issued certificates. Actually, even Microsoft's IE can handle certificate 
chains containing self-issued certificates. It is Microsoft's IIS can not 
correctly send the certificate chain to the client side. Other https server 
such aa Apache have no problem with certificate chains containing self-issued 
certificates.

> 
> It is a technical mistake in believing all software handles multiple
> certificates with the same DN, not a legal mistake in reading a
> document saying this should be permitted.
> 

As I have mentioned, browsers actually do not have problem with the same issuer 
DN between generations of root CA certificates.

Wen-Cheng Wang
___
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

[Wen-Cheng Wang]

Hi Gervase,

On Monday, December 5, 2016 at 9:00:53 PM UTC+8, Gervase Markham wrote:
> On 04/12/16 08:17, Wen-Cheng Wang wrote:
> > You are wight, there are several subordinate CAs under our Government
> > Root CA. Our Government Root CA and all its subordinate have WebTrust
> > for CA audits. However, among those subordinate CAs, only GCA will
> > issue SSL certificates. Therefore, only Government Root CA and GCA
> > have SSL BR audits. Since currently all other subordinate CAs so not
> > issue SSL certificates, it is certainly not possible for them to have
> > SSL BR audits.
> 
> Not possible technically, or not possible by policy?
> 
I mean BR Audit is specifically for CAs that provide SSL certificates. 
Therefore, it is not possible to conduct on those subordinate CAs that do not 
provide SSL certificates, and it is certainly not possible for them to get the 
WebTrust SSL BR seals. That is why in our Government PKI, the WebTrust SSL BR 
seal only covers GRCA (the root CA) and GCA (which provides SSL certificates). 
However, I would like to emphasize that the WebTrust for CA seal cover the 
whole Government PKI (including the root CA and all its subordinate CAs).

> As I understand it, Peter is pointing out that these subordinate CAs are
> not constrained, and so could issue SSL certificates which would be
> trusted in any browser which trusted the root. Therefore, their policies
> and practices have to fall under Mozilla's root policy.
> 
As for how to make sure policies and practices of all our CAs fall under 
Mozilla's root policy, every time we received Kathleen's notification about the 
revision of Mozilla's root policy, we reviewed our CP of the Government PKI and 
CPSs of all CAs seriously. If necessary, we will make amendments to our CP and 
CPSs so that they can aligned with Mozilla's root policy and we will reply what 
we plan to do for responding the change of Mozilla's root policy to Kathleen. 
Since we have conducted WebTrust for CA audits on the whole Government PKI 
(including the root CA and all its subordinate CAs), the audit results can 
assure our CAs are all compliant to Mozilla's root policy.

Wen-Cheng Wang
___
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

[Jakob Bohm]

On 04/12/2016 06:00, capuchin...@gmail.com wrote:

Jakob Bohm於 2016年12月4日星期日 UTC+8上午1時23分16秒寫道：


You have made a fundamental technical mistake.

I do not understand that why do you said that we made a fundamental technical 
mistake? As I had participated in drafting RFC 5280, I am sure that our 
implementation fully conforms to RFC 5280 and of course the original ITU-T 
X.509 standards. Do you mean that our conforming to the standards is a 
fundamental mistake? If so, whay there needs standards?



The mistake was to use a part of those standards which is often
problematic in the real world.  For example, according to your
presentation, when IIS builds server certificate chains to send to
clients, it compares only the DN, causing problems when non-AIA-
downloading browsers visit IIS-powered sites with GCA certificates.

It is a technical mistake in believing all software handles multiple
certificates with the same DN, not a legal mistake in reading a
document saying this should be permitted.



Asking for mandatory AIA is a bad solution.


We are noe asking for mandatory AIA implementation. We are here to asking 
Mozilla to include our second generaion self-signed root certificate of Taiwan 
GRCA, whcih conforms to PKIX standard, to the NSS trust list.



Your previous post said:

> Chunghwa Telecom  suggested to make AIA mandatory and browsers must
> support fetching intermediate certificates through AIA. Supporting
> AIA will also reduce some web site administrators forget to install
> intermediate certificates to their server follow CAs or web server’s
> manuals. (In SSL protocol, SSL servers should send intermediate
> certificate & SSL certificate to SSL client)

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
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

[Gervase Markham]

On 04/12/16 08:17, Wen-Cheng Wang wrote:
> You are wight, there are several subordinate CAs under our Government
> Root CA. Our Government Root CA and all its subordinate have WebTrust
> for CA audits. However, among those subordinate CAs, only GCA will
> issue SSL certificates. Therefore, only Government Root CA and GCA
> have SSL BR audits. Since currently all other subordinate CAs so not
> issue SSL certificates, it is certainly not possible for them to have
> SSL BR audits.

Not possible technically, or not possible by policy?

As I understand it, Peter is pointing out that these subordinate CAs are
not constrained, and so could issue SSL certificates which would be
trusted in any browser which trusted the root. Therefore, their policies
and practices have to fall under Mozilla's root policy.

We plan to make an update to the policy to make it very clear that the
important criterion is technical capability, not intent. See:
https://github.com/mozilla/pkipolicy/issues/27

Gerv
___
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

[Peter Gutmann]

Wen-Cheng Wang  writes:

>Actually, we have tested the capabilities of many browsers in the wild and
>found they can live peacefully with our PKIX-compliant root certs. 

Ah, OK.  That's the right way to do it.

>They are not so weak as you might think.

I bet I can create PKIX-compliant certs (specifically, cert chains) that would
break any browser :-).  But yeah, if you go and test each browser you can
create lowest-common-denominator certs that should work in general.

Peter.
___
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

[Wen-Cheng Wang]

On Sunday, December 4, 2016 at 11:56:13 PM UTC+8, Peter Bowen wrote:
> On Sun, Dec 4, 2016 at 7:26 AM, Wen-Cheng Wang wrote:
> > Gervase Markham於 2016年12月4日星期日 UTC+8下午6時27分55秒寫道：
> >> On 03/12/16 17:42, Peter Bowen wrote:
> >> > As to the inclusion request, I think Mozilla should reject this
> >> > request and add a clear rule to the Mozilla CA policy that each CA
> >> > must have a unique DN.  The DN should be a primary key for the trust
> >> > store and no two entries should have the same DN.
> >>
> >> Just to help me be clear: the request is for the inclusion of a root
> >> with the same DN as a previous root, which will still be included after
> >> the addition? Or the problem with duplicate DNs occurs further down the
> >> hierarchy?
> >
> > Our request is for the inclusion of a root with the same DN as a previous 
> > root.
> >
> > In our Government PKI, we have a national LDAP tree and all the entities 
> > (including the root CA, subordinate CAs, and end entities) have their own 
> > unique DNs in the directory tree. Since our Government Root CA (GRCA) is a 
> > permanent node in our national LDAP tree, it has certainly been assigned an 
> > unique DN. If we change the DN of our Government Root CA (GRCA) each time 
> > it re-key, that will generate multiple nodes of our Government Root CA with 
> > different DNs in our national LDAP tree and that will be quite confusing.
> 
> Based on the publicly available data, it looks like you have multiple
> sets of CAs with the same DN in your tree.  For example MOEACA:
> https://crt.sh/?caid=13914 and https://crt.sh/?caid=13162 have the
> same DN and have different keys.
> 
> I think the larger issue is that you don't have BR audits for the
> subordinate CAs.
> 
You are right, there are several subordinate CAs under our Government Root CA. 
Our Government Root CA and all its subordinate have WebTrust for CA audits. 
However, among those subordinate CAs, only GCA will issue SSL certificates. 
Therefore, only Government Root CA and GCA have SSL BR audits. Since currently 
all other subordinate CAs so not issue SSL certificates, it is certainly not 
possible for them to have SSL BR audits. 

PS: There is another subordinate CA named HCA that used to issue SSL 
certificates too, but HCA had stopped issuing SSL certificates. Therefore, 
currently GCA is the only subordinate CA that will issue SSL certificates. 

Wen-Cheng Wang 

___
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

[Wen-Cheng Wang]

On Sunday, December 4, 2016 at 11:56:13 PM UTC+8, Peter Bowen wrote:
> On Sun, Dec 4, 2016 at 7:26 AM, Wen-Cheng Wang wrote:
> > Gervase Markham於 2016年12月4日星期日 UTC+8下午6時27分55秒寫道：
> >> On 03/12/16 17:42, Peter Bowen wrote:
> >> > As to the inclusion request, I think Mozilla should reject this
> >> > request and add a clear rule to the Mozilla CA policy that each CA
> >> > must have a unique DN.  The DN should be a primary key for the trust
> >> > store and no two entries should have the same DN.
> >>
> >> Just to help me be clear: the request is for the inclusion of a root
> >> with the same DN as a previous root, which will still be included after
> >> the addition? Or the problem with duplicate DNs occurs further down the
> >> hierarchy?
> >
> > Our request is for the inclusion of a root with the same DN as a previous 
> > root.
> >
> > In our Government PKI, we have a national LDAP tree and all the entities 
> > (including the root CA, subordinate CAs, and end entities) have their own 
> > unique DNs in the directory tree. Since our Government Root CA (GRCA) is a 
> > permanent node in our national LDAP tree, it has certainly been assigned an 
> > unique DN. If we change the DN of our Government Root CA (GRCA) each time 
> > it re-key, that will generate multiple nodes of our Government Root CA with 
> > different DNs in our national LDAP tree and that will be quite confusing.
> 
> Based on the publicly available data, it looks like you have multiple
> sets of CAs with the same DN in your tree.  For example MOEACA:
> https://crt.sh/?caid=13914 and https://crt.sh/?caid=13162 have the
> same DN and have different keys.
> 
> I think the larger issue is that you don't have BR audits for the
> subordinate CAs.

You are right, there are several subordinate CAs under our Government Root CA. 
Our Government Root CA and all its subordinate have WebTrust for CA audits. 
However, among those subordinate CAs, only GCA will issue SSL certificates. 
Therefore, only Government Root CA and GCA have SSL BR audits. Since currently 
all other subordinate CAs so not issue SSL certificates, it is certainly not 
possible for them to have SSL BR audits. 

PS: There is another subordinate CA named HCA that used to issue SSL 
certificates too, but HCA had stopped issuing SSL certificates. Therefore, 
currently GCA is the only subordinate CA that will issue SSL certificates. 

Wen-Cheng Wang 


___
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

[Wen-Cheng Wang]

On Sunday, December 4, 2016 at 11:56:13 PM UTC+8, Peter Bowen wrote:
> On Sun, Dec 4, 2016 at 7:26 AM, Wen-Cheng Wang wrote:
> > Gervase Markham於 2016年12月4日星期日 UTC+8下午6時27分55秒寫道：
> >> On 03/12/16 17:42, Peter Bowen wrote:
> >> > As to the inclusion request, I think Mozilla should reject this
> >> > request and add a clear rule to the Mozilla CA policy that each CA
> >> > must have a unique DN.  The DN should be a primary key for the trust
> >> > store and no two entries should have the same DN.
> >>
> >> Just to help me be clear: the request is for the inclusion of a root
> >> with the same DN as a previous root, which will still be included after
> >> the addition? Or the problem with duplicate DNs occurs further down the
> >> hierarchy?
> >
> > Our request is for the inclusion of a root with the same DN as a previous 
> > root.
> >
> > In our Government PKI, we have a national LDAP tree and all the entities 
> > (including the root CA, subordinate CAs, and end entities) have their own 
> > unique DNs in the directory tree. Since our Government Root CA (GRCA) is a 
> > permanent node in our national LDAP tree, it has certainly been assigned an 
> > unique DN. If we change the DN of our Government Root CA (GRCA) each time 
> > it re-key, that will generate multiple nodes of our Government Root CA with 
> > different DNs in our national LDAP tree and that will be quite confusing.
> 
> Based on the publicly available data, it looks like you have multiple
> sets of CAs with the same DN in your tree.  For example MOEACA:
> https://crt.sh/?caid=13914 and https://crt.sh/?caid=13162 have the
> same DN and have different keys.
> 
> I think the larger issue is that you don't have BR audits for the
> subordinate CAs.
> 
> Thanks,
> Peter

You are wight, there are several subordinate CAs under our Government Root CA. 
Our Government Root CA and all its subordinate have WebTrust for CA audits. 
However, among those subordinate CAs, only GCA will issue SSL certificates. 
Therefore, only Government Root CA and GCA have SSL BR audits. Since currently 
all other subordinate CAs so not issue SSL certificates, it is certainly not 
possible for them to have SSL BR audits.

PS: There is another subordinate CA named HCA that used to issue SSL 
certificates too, but HCA had stopped issuing SSL certificates. Therefore, 
currently GCA is the only subordinate CA that will issue SSL certificates.

Wen-Cheng Wang
___
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

[Wen-Cheng Wang]

On Sunday, December 4, 2016 at 5:58:56 PM UTC+8, Peter Gutmann wrote:
> Wen-Cheng Wang writes:
> 
> >However, that does not means our PKIX (RFC-5280) conforimg implementation
> >will cause errors or bugs to current implementations of browsers.
> 
> Given all the bizarre stuff that ended up in the PKIX spec, it would be quite
> easy to create a fully PKIX-compliant cert that had all manner of strange and
> unexpected interactions with browsers (see my previous message for examples).
> The skill required for deploying certs is to know (or at least have a general
> idea of) what will happen to them in the wild, not to assume that whatever
> peculiar thing the PKIX spec says is actually implemented by anyone.

Actually, we have tested the capabilities of many browsers in the wild and 
found they can live peacefully with our PKIX-compliant root certs. They are not 
so weak as you might think.

What I do not understand is why the first responses of people here seems in a 
hurry to reject a PKIX-compliant root cert? Currently, there is no rule in 
Mozilla CA policy that forbid a root CA to retain its DN after re-key. What we 
need to do here is simply to test whether Mozilla NSS can live peacefully with 
our PKIX-compliant root certs. If it does, why not accept it?

> 
> >Actually, in RFC 5280 as well as the original X.509 standard, the recommended
> >official way to distinguish the different generation of CA certificates is by
> >using the chaining of the Issuer Key Identifier extension and Subject Key
> >Identifier extension (as you mentioned) in certification path processing.
> 
> OK, that's one of the less crazy things in the spec, but it still doesn't
> guarantee that much, if anything, does it that way.  In practice, you chain by
> DN, not by key ID.

Of course we chain up the certification path by DN. The Authority Key 
Identifier extension and the Subject Key Identifier extension are to be used to 
facilitate choosing different generation of CA certificates. I do not mean that 
the certification path is chained up by key ID.

Wen-Cheng Wang
___
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

[Peter Bowen]

On Sun, Dec 4, 2016 at 7:26 AM, 王文正  wrote:
> Gervase Markham於 2016年12月4日星期日 UTC+8下午6時27分55秒寫道：
>> On 03/12/16 17:42, Peter Bowen wrote:
>> > As to the inclusion request, I think Mozilla should reject this
>> > request and add a clear rule to the Mozilla CA policy that each CA
>> > must have a unique DN.  The DN should be a primary key for the trust
>> > store and no two entries should have the same DN.
>>
>> Just to help me be clear: the request is for the inclusion of a root
>> with the same DN as a previous root, which will still be included after
>> the addition? Or the problem with duplicate DNs occurs further down the
>> hierarchy?
>
> Our request is for the inclusion of a root with the same DN as a previous 
> root.
>
> In our Government PKI, we have a national LDAP tree and all the entities 
> (including the root CA, subordinate CAs, and end entities) have their own 
> unique DNs in the directory tree. Since our Government Root CA (GRCA) is a 
> permanent node in our national LDAP tree, it has certainly been assigned an 
> unique DN. If we change the DN of our Government Root CA (GRCA) each time it 
> re-key, that will generate multiple nodes of our Government Root CA with 
> different DNs in our national LDAP tree and that will be quite confusing.

Based on the publicly available data, it looks like you have multiple
sets of CAs with the same DN in your tree.  For example MOEACA:
https://crt.sh/?caid=13914 and https://crt.sh/?caid=13162 have the
same DN and have different keys.

I think the larger issue is that you don't have BR audits for the
subordinate CAs.

Thanks,
Peter
___
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

[王文正]

Gervase Markham於 2016年12月4日星期日 UTC+8下午6時27分55秒寫道：
> On 03/12/16 17:42, Peter Bowen wrote:
> > As to the inclusion request, I think Mozilla should reject this
> > request and add a clear rule to the Mozilla CA policy that each CA
> > must have a unique DN.  The DN should be a primary key for the trust
> > store and no two entries should have the same DN.
> 
> Just to help me be clear: the request is for the inclusion of a root
> with the same DN as a previous root, which will still be included after
> the addition? Or the problem with duplicate DNs occurs further down the
> hierarchy?

Our request is for the inclusion of a root with the same DN as a previous root.

In our Government PKI, we have a national LDAP tree and all the entities 
(including the root CA, subordinate CAs, and end entities) have their own 
unique DNs in the directory tree. Since our Government Root CA (GRCA) is a 
permanent node in our national LDAP tree, it has certainly been assigned an 
unique DN. If we change the DN of our Government Root CA (GRCA) each time it 
re-key, that will generate multiple nodes of our Government Root CA with 
different DNs in our national LDAP tree and that will be quite confusing.

Wen-Cheng Wang
___
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

[王文正]

Gervase Markham於 2016年12月4日星期日 UTC+8下午6時18分48秒寫道：
> Hi Wen-Cheng,
> 
> On 04/12/16 06:12, 王文正 wrote:
> > Requiring that Key rollover must be accompanied by DN rotation will
> > contradict with the PKIX standard and the original X.509 standard. 
> 
> Leaving aside the particular situation we are in, in general the Web PKI
> uses X.509 and other standards as a guide, but if something doesn't
> work, or we stop allowing it for security reasons, that's just the way
> it is and that needs to be accepted. Take, for example, non-critical
> name constraints. Not allowed by the RFC, but used in the Web PKI.

Well, I believe that retain the same DN for the root CA after performing key 
rollover will not cause security issues. If it will cause security issues, 
Mozilla certainly has the right to reject our root certificate.

If you are aware of any security issue that might cause by a root CA retaining 
the same DN, please clearly describe what kind of security issue it will cause, 
and then I will submit an technical errata report to PKIX to ask for amending 
RFC 5280.

> 
> I note also that Mozilla's root store policy says:
> 
> "This also includes (but again is not limited to) cases where we believe
> that including a CA certificate (or setting its "trust bits" in a
> particular way) might cause technical problems with the operation of our
> software..."
> 
> If what you are trying to do doesn't work in our software, it may end up
> that we just shrug our shoulders and tell you to do something else.
> That's not definite, but it is a possible outcome you need to be
> prepared for.
> 

That is fair. If our implementation does not work with your software, you 
certainly has the right to not accept our root certificate. Let's just test it 
and we will know if it works.

> > If so, I do know how Mozilla can claim that the NSS is
> > interoperable with PKIX Certificate and CRL profile?
> 
> If you are right, we may just have to stop claiming that :-)

Well, on the other hand, you might embrace more positive thinking. This can be 
a chance to improve the certification path processing algorithm of Mozilla NSS 
to make it truly interoperable with PKIX Certificate and CRL profile :-)

> 
> Gerv

Wen-Cheng Wang
___
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

[Gervase Markham]

On 03/12/16 17:42, Peter Bowen wrote:
> As to the inclusion request, I think Mozilla should reject this
> request and add a clear rule to the Mozilla CA policy that each CA
> must have a unique DN.  The DN should be a primary key for the trust
> store and no two entries should have the same DN.

Just to help me be clear: the request is for the inclusion of a root
with the same DN as a previous root, which will still be included after
the addition? Or the problem with duplicate DNs occurs further down the
hierarchy?

Does Firefox build cert chains using DNs, or using Key Identifiers as
Wen-Cheng says it should? I assume it's the former, but want to check.

Gerv
___
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

[Gervase Markham]

Hi Wen-Cheng,

On 04/12/16 06:12, 王文正 wrote:
> Requiring that Key rollover must be accompanied by DN rotation will
> contradict with the PKIX standard and the original X.509 standard. 

Leaving aside the particular situation we are in, in general the Web PKI
uses X.509 and other standards as a guide, but if something doesn't
work, or we stop allowing it for security reasons, that's just the way
it is and that needs to be accepted. Take, for example, non-critical
name constraints. Not allowed by the RFC, but used in the Web PKI.

I note also that Mozilla's root store policy says:

"This also includes (but again is not limited to) cases where we believe
that including a CA certificate (or setting its "trust bits" in a
particular way) might cause technical problems with the operation of our
software..."

If what you are trying to do doesn't work in our software, it may end up
that we just shrug our shoulders and tell you to do something else.
That's not definite, but it is a possible outcome you need to be
prepared for.

> If so, I do know how Mozilla can claim that the NSS is
> interoperable with PKIX Certificate and CRL profile?

If you are right, we may just have to stop claiming that :-)

Gerv
___
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

[Peter Gutmann]

capuchin...@gmail.com  writes:

>However, that does not means our PKIX (RFC-5280) conforimg implementation
>will cause errors or bugs to current implementations of browsers.

Given all the bizarre stuff that ended up in the PKIX spec, it would be quite
easy to create a fully PKIX-compliant cert that had all manner of strange and
unexpected interactions with browsers (see my previous message for examples).
The skill required for deploying certs is to know (or at least have a general
idea of) what will happen to them in the wild, not to assume that whatever
peculiar thing the PKIX spec says is actually implemented by anyone.

>Actually, in RFC 5280 as well as the original X.509 standard, the recommended
>official way to distinguish the different generation of CA certificates is by
>using the chaining of the Issuer Key Identifier extension and Subject Key
>Identifier extension (as you mentioned) in certification path processing.

OK, that's one of the less crazy things in the spec, but it still doesn't
guarantee that much, if anything, does it that way.  In practice, you chain by
DN, not by key ID.

Peter.
___
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

[王文正]

Peter Bowen於 2016年12月4日星期日 UTC+8上午1時43分00秒寫道：
> On Sat, Dec 3, 2016 at 9:22 AM, Jakob Bohm wrote:
> >
> > Using two different public keys with the same exact full distinguished
> > name is generally not expected to work.  Some implementations may use
> > additional checks (such as the key identifier or certificate serial
> > number) to disambiguate, but this is generally known to be a frequent
> > cause of errors and bugs, such as the ones observed in your
> > presentation.
> >
> > All in all, the "self-issued but not self-signed" concept never worked
> > and is effectively dead.
> 
> I agree with Jakob here.  As was recently pointed out in a discussion
> on the path length constraint for CAs, allowing self-issued but not
> self-signed opens up unexpected vulnerabilities.
> 
> Mozilla should require that there be exactly one public key associated
> with each CA Distinguished Name.  Key rotation should be accompanied
> by DN rotation.
> 
Requiring that Key rollover must be accompanied by DN rotation will contradict 
with the PKIX standard and the original X.509 standard. In the PKIX standard 
and the original X.509 standard, the recommended way is to use Authority Key 
Identifier and Subject Key Identifier chaining for distinguishing different 
generation of cert/CRL signing keys but with the same issuer DN. If Mozilla 
makes the requirement k that ey rollover must be accompanied by DN rotation, it 
means Mozilla NSS trust list will completely rule out those CAs conforming to 
the PKIX standard. If so, I do know how Mozilla can claim that the NSS is 
interoperable with PKIX Certificate and CRL profile?

> > Maybe you need to generate a new third generation "Taiwan-GRCA 2016"
> > root with a unique name, along with the needed [...] certificates, such 
> > that web servers
> > can send at least one valid chain.
> 
> I think that is an excellent suggestion.
> 
> As to the inclusion request, I think Mozilla should reject this
> request and add a clear rule to the Mozilla CA policy that each CA
> must have a unique DN.  The DN should be a primary key for the trust
> store and no two entries should have the same DN.
As far as I known, currently the Mozilla CA policy does no require CAs to 
change their DNs whenever performing key rollover. I believe that Mozilla 
should not make this kind of requirement in the CA policy because that will 
contradict with the PKIX standard as well as the original ITU-T X.509 standard.

> 
> Thanks,
> Peter

Wen-Cheng Wang
Chief PKI Product Manager
Chunghwa Telecom Co., Ltd.
___
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

[capuchin406]

Jakob Bohm於 2016年12月4日星期日 UTC+8上午1時23分16秒寫道：
> 
> You have made a fundamental technical mistake.
I do not understand that why do you said that we made a fundamental technical 
mistake? As I had participated in drafting RFC 5280, I am sure that our 
implementation fully conforms to RFC 5280 and of course the original ITU-T 
X.509 standards. Do you mean that our conforming to the standards is a 
fundamental mistake? If so, whay there needs standards?

> 
> Using two different public keys with the same exact full distinguished
> name is generally not expected to work.  Some implementations may use
> additional checks (such as the key identifier or certificate serial
> number) to disambiguate, but this is generally known to be a frequent
> cause of errors and bugs, such as the ones observed in your
> presentation.
We understand that many commercial CAs change their issuer names of root CA 
whenever they re-keying because in the early days they were not sure whether 
certificate-using softwares (such browsers) have fully implemented 
certification path validation algorithms specified in RFC 5280 or the original 
X.509 standard and therefore they think this is the safest way to make sure 
certificate-using softwares to correctly chain up to the correct generation of 
root certificates. However, that does not means our PKIX (RFC-5280) conforimg 
implementation will cause errors or bugs to current implementations of browsers.

Actually, in RFC 5280 as well as the original X.509 standard, the recommended 
official way to distinguish the different generation of CA certificates is by 
using the chaining of the Issuer Key Identifier extension and Subject Key 
Identifier extension (as you mentioned) in certification path processing.

So, whay not juest test whether our implementation will cause errors to the 
current implememtation of Mozilla NSS libraries?

Actually, Microsoft had already accepted our second generation of GRCA 
self-signed certificate around 1 year ago, we have not encountered certificate 
chaining ambiguity issue that you worried. I think that is because Microsoft's 
current CryptoAPI is in some good degree of comforming to PKIX standard.

Please note that in the official web page of NSS 
(https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Overview), 
Mozilla claims that the NSS is interoperable with PKIX certificate and CRL 
profiles. Therefore, I have confidence that Mozilla NSS can peacefully live 
with our PKIX conforming implementation of CA.

> 
> All in all, the "self-issued but not self-signed" concept never worked
> and is effectively dead.
> 
I would suggest that you should not be so assured. Please note that performing 
key-rollover by using self-issued certificates is mandatory for all Country 
Signing CAs (CSCA) of ICAO eMRTD (e.g. ePassport, or eID). It is that many 
commercial CAs choose to not implemented the key-rollover process suggestted by 
the PKXI standard or the origonal X.509 standard but that does not mean the 
concept never worked and is effectively dead. There are still many governmental 
CAs choose to fully conform to the standards as the best as they can. 

> Asking for mandatory AIA is a bad solution.
> 
We are noe asking for mandatory AIA implementation. We are here to asking 
Mozilla to include our second generaion self-signed root certificate of Taiwan 
GRCA, whcih conforms to PKIX standard, to the NSS trust list. 

> Maybe you need to generate a new third generation "Taiwan-GRCA 2016"
> root with a unique name, along with the needed "2016 with 2016", "2016
> with 2012" and "2016 with original" certificates, such that web servers
> can send at least one valid chain.  IIS could send the chain that ends
> in "2016 with original" (by installing that cert to the
> machine\Intermediaries part of the Windows certificate store and not
> installing the "2016 with 2016" cert on the IIS server), while Apache
> can send a list that ends with all 3 2016 certificates.  The AIA cert
> download URL in certificates issued by 2016 would probably have to
> return "2016 with 2012", while the AIA cert download URL in "2016 with
> 2012" would return "2012 with original", this is based on the assumption 
> that AIA-supporting browsers will check for trusted certs before 
> attempting AIA download and that the most widespread
> AIA-supporting browsers will not be confused by the self-issued "2012
> with original" cert.
> 
> To ensure a pure SHA-256 chain when chaining all the way back to the
> original, it is advisable (if it can be done securely, as is not the
> case with ECC and DSA), for the "2012 with original" and "2016 with
> original" certificates to be signed using SHA-256 and the original key
> pair.
> 
> When providing repudiation/revocation checks for end certificates
> issued using SHA-1 by the original private key, these checks should be
> signed by dedicated SHA-1 "CRL signing" and "OCSP signing" certificates
> issued using SHA-1 by the original private key, which 

Re: Taiwan GRCA Root Renewal Request

[Peter Gutmann]

lcchen.ci...@gmail.com  writes:

>I explained the rollover certificate process outlined in RFC 4210 by signing
>the old public key with the new private key and the new public key with the
>old private key.

Uhh, that stuff was a gedanken experiment dreamed up by some folks in PKIX,
alongside things like PKIX path-kludge certificates, not something you're
supposed to rely on in real life.  I'd be really surprised if any generic
implementation actually handled those things the way PKIX imagined they will.
I certainly wouldn't risk deploying one of those things on the assumption that
it'll be handled properly.  The path-kludge in particular looks like something
that was designed to make PKIs break.

Peter.
___
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

[Peter Bowen]

On Thu, Sep 22, 2016 at 12:57 AM,   wrote:
> Peter Bowen於 2016年9月20日星期二 UTC+8下午11時53分29秒寫道：
>> On Fri, Sep 16, 2016 at 2:00 PM, Kathleen Wilson  wrote:
>> >
>> > * CA Hierarchy: Diagram of CA Hierarchy: http://grca.nat.gov.tw/
>> > All subordinate CAs are operated by Taiwan Government organizations.
>> > GCA is responsible for signing certificates for government agencies. This 
>> > is the only intermediate cert that can issue SSL certs.
>> > XCA is responsible for signing certificates for organizations;
>> > MOICA is responsible for signing certificates for citizens;
>> > MOEACA is responsible for signing certificates for corporations; and
>> > HCA is responsible for signing certificates for health agencies.
>> >
>> > * Audit: Annual audits are performed by KPMG according to the WebTrust 
>> > criteria.
>> > WebTrust CA: https://cert.webtrust.org/SealFile?seal=2050=pdf
>> > WebTrust BR: https://cert.webtrust.org/SealFile?seal=2051=pdf
>>
>> I'm having trouble matching up the audits with the subordinate CAs.
>> There are two different CAs with the same Distinguished Name but
>> different SubjectPublicKeyInfo and KeyIDs (https://crt.sh/?caid=186
>> and https://crt.sh/?caid=1330) which makes it trickier than normal,
>> but either way I'm not seeing all of these subordinates covered in the
>> audit reports.  Can someone please provide a link to each audit report
>> for each subordinate?
>>
>> Thanks,
>> Peter
>
> GRCA WebTrust CA 
> (http://grca.nat.gov.tw/download/Audit/GRCA_Audit_Report_2016.pdf)
>
> GCA WebTrust CA 
> (http://grca.nat.gov.tw/download/Audit/GCA_WTCA_Report_2016.pdf)
> GCA BR (http://grca.nat.gov.tw/download/Audit/GCA_BR_Audit_Report_2015.pdf)
>
> XCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/XCA_Report_2016.pdf)
>
> HCA WebTrust CA 
> (http://grca.nat.gov.tw/download/Audit/HCA_WTCA_Audit_Report_2015.pdf)
>
> MOEACA WebTrust CA 
> (http://grca.nat.gov.tw/download/Audit/MOEACA_Audit_Report_2015.pdf)
>
> MOICA WebTrust CA 
> (http://grca.nat.gov.tw/download/Audit/MOICA_Audit_Report_2015.pdf)

I see the following subordinate CAs under the two Government Root CAs:

C=TW, O=行政院, OU=內政部憑證管理中心
C=TW, O=行政院, OU=工商憑證管理中心
C=TW, O=行政院, OU=政府憑證管理中心
C=TW, O=行政院, OU=政府測試憑證管理中心
C=TW, O=行政院, OU=組織及團體憑證管理中心
C=TW, O=行政院, OU=醫事憑證管理中心
C=TW, O=行政院, OU=內政部憑證管理中心
C=TW, O=行政院, OU=內政部憑證管理中心
C=TW, O=行政院, OU=工商憑證管理中心
C=TW, O=行政院, OU=政府憑證管理中心
C=TW, O=行政院, OU=組織及團體憑證管理中心

None of the CA certificates have an EKU extension, so all are capable
of issuing server authentication certificates.  Therefore each of
these should have a BR audit if the websites bit is going to be
enabled.

Thanks,
Peter
___
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

[Peter Bowen]

On Sat, Dec 3, 2016 at 9:22 AM, Jakob Bohm  wrote:
> On 03/12/2016 09:34, lcchen.ci...@gmail.com wrote:
>>
>> In CA/Browser Forum 34th F2F meeting, the minutes is in
>> https://cabforum.org/2015/03/11/2015-03-11-minutes-of-cupertino-f2f-meeting-34/.
>> Li-Chun Chen (me) of Chunghwa Telecom presented a discussion about
>> "behaviors of web servers and browsers if a PKI follows RFC 4210 & RFC 5280
>> 6.1 for Root CA key Update". The presentation file is in
>> https://cabforum.org/wp-content/uploads/Chunghwatelecom201503cabforumV4.pdf.
>>
>> I explained the rollover certificate process outlined in RFC 4210 by
>> signing the old public key with the new private key and the new public key
>> with the old private key. I also gave the definition of Self-issued
>> certificates (Self-issued certificates are generated to support changes in
>> policy or operations. So there will be values in certificate policies
>> extension filed of self-issued certificates) and Self-signed certificates
>> (CA certificates in which the issuer and subject are the same entity. For a
>> Root CA self-signed certficae, there will be no value in certificate
>> policies extension.) as RFC 5280. Following RFC 5280 6.1, a certificate is
>> self-issued if the same DN appears in the subject and issuer fields.  The
>> Taiwanese Government Root CA (GRCA) has switched over from SHA1 to SHA256
>> (in 2012), but we have encountered IIS issues following the processes found
>> in the RFCs. See Slide pp.8-pp.13. IIS 7 falsely treated GRCA’s Self-Issued
>> certificate (new with old) as a Self-Signed certificate, because it has the
>> same issuer and subject name. We found  SSL Cert –> GCA Cert –> new-with-old
>> GRCA Cert –> old GRCA cert in IIS side, but IIS only sends SSL Cert –> GCA
>> Cert to client.  For Mozilla Firefox, it uses its own trust list and it only
>> trusts old GRCA and  new GRCA is waiting to be built in NSS. So there are
>> lots of complaints of Firefox users connected to IIS sites. Because Windows
>> clients support AIA chasing there are less chaining problems.
>
> Using two different public keys with the same exact full distinguished
> name is generally not expected to work.  Some implementations may use
> additional checks (such as the key identifier or certificate serial
> number) to disambiguate, but this is generally known to be a frequent
> cause of errors and bugs, such as the ones observed in your
> presentation.
>
> All in all, the "self-issued but not self-signed" concept never worked
> and is effectively dead.

I agree with Jakob here.  As was recently pointed out in a discussion
on the path length constraint for CAs, allowing self-issued but not
self-signed opens up unexpected vulnerabilities.

Mozilla should require that there be exactly one public key associated
with each CA Distinguished Name.  Key rotation should be accompanied
by DN rotation.

> Maybe you need to generate a new third generation "Taiwan-GRCA 2016"
> root with a unique name, along with the needed [...] certificates, such that 
> web servers
> can send at least one valid chain.

I think that is an excellent suggestion.

As to the inclusion request, I think Mozilla should reject this
request and add a clear rule to the Mozilla CA policy that each CA
must have a unique DN.  The DN should be a primary key for the trust
store and no two entries should have the same DN.

Thanks,
Peter
___
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

[Jakob Bohm]

On 03/12/2016 09:34, lcchen.ci...@gmail.com wrote:

Kathleen Wilson於 2016年11月15日星期二 UTC+8上午9時20分09秒寫道：

All,

I will greatly appreciate it if you will review this request from Government of 
Taiwan, Government Root Certification Authority (GRCA) to include their 
Government Root Certification Authority root certificate, and turn on the 
Websites and Email trust bits. This root cert will eventually replace the 
previous GRCA root certificate that was included via Bugzilla Bug #274106.

Thanks,
Kathleen



In CA/Browser Forum 34th F2F meeting, the minutes is in 
https://cabforum.org/2015/03/11/2015-03-11-minutes-of-cupertino-f2f-meeting-34/. Li-Chun Chen 
(me) of Chunghwa Telecom presented a discussion about "behaviors of web servers and 
browsers if a PKI follows RFC 4210 & RFC 5280 6.1 for Root CA key Update". The 
presentation file is in 
https://cabforum.org/wp-content/uploads/Chunghwatelecom201503cabforumV4.pdf.

I explained the rollover certificate process outlined in RFC 4210 by signing the old public 
key with the new private key and the new public key with the old private key. I also gave 
the definition of Self-issued certificates (Self-issued certificates are generated to 
support changes in policy or operations. So there will be values in certificate policies 
extension filed of self-issued certificates) and Self-signed certificates (CA certificates 
in which the issuer and subject are the same entity. For a Root CA self-signed certficae, 
there will be no value in certificate policies extension.) as RFC 5280. Following RFC 5280 
6.1, a certificate is self-issued if the same DN appears in the subject and issuer fields.  
The Taiwanese Government Root CA (GRCA) has switched over from SHA1 to SHA256 (in 2012), 
but we have encountered IIS issues following the processes found in the RFCs. See Slide 
pp.8-pp.13. IIS 7 falsely treated GRCA’s Self-Issued certificate (new with old) as a 
Self-Signed certificate, because it has the same issuer and subject name. We found  SSL 
Cert –> GCA Cert –> new-with-old GRCA Cert –> old GRCA cert in IIS side, but IIS 
only sends SSL Cert –> GCA Cert to client.  For Mozilla Firefox, it uses its own trust 
list and it only trusts old GRCA and  new GRCA is waiting to be built in NSS. So there are 
lots of complaints of Firefox users connected to IIS sites. Because Windows clients support 
AIA chasing there are less chaining problems.


Chunghwa Telecom requested Microsoft to  solve the bug of IIS ASAP through 
Premium support last spring. But until now Microsoft IIS team has not yet solve 
the bug.

Chunghwa Telecom  suggested to make AIA mandatory and browsers must support 
fetching intermediate certificates through AIA. Supporting AIA will also reduce 
some web site administrators forget to install intermediate certificates to their 
server follow CAs or web server’s manuals. (In SSL protocol, SSL servers should 
send intermediate certificate & SSL certificate to SSL client)


It seems that  Mozilla Firefox has not yet suppot AIA. So the best solution to 
solve the bug is to  include the new Taiwna Government Root Certification 
Authority root certificate in Mozilla NSS, and turn on the Websites and Email 
trust bits. It will significantly reduces complaints from Mozilla User and 
administrators of Taiwan government entities's websites that use IIS.

In CA/Browser Form 34th F2F meeting minutes, There are [ Additionally, Brian 
Smith commented separately via email, “It is also possible, and recommended, 
for the rollover certificate to be added to Firefox’s certificate store. Then 
Firefox will be able to use it even if IIS doesn’t send it.”]



You have made a fundamental technical mistake.

Using two different public keys with the same exact full distinguished
name is generally not expected to work.  Some implementations may use
additional checks (such as the key identifier or certificate serial
number) to disambiguate, but this is generally known to be a frequent
cause of errors and bugs, such as the ones observed in your
presentation.

All in all, the "self-issued but not self-signed" concept never worked
and is effectively dead.

Asking for mandatory AIA is a bad solution.

Maybe you need to generate a new third generation "Taiwan-GRCA 2016"
root with a unique name, along with the needed "2016 with 2016", "2016
with 2012" and "2016 with original" certificates, such that web servers
can send at least one valid chain.  IIS could send the chain that ends
in "2016 with original" (by installing that cert to the
machine\Intermediaries part of the Windows certificate store and not
installing the "2016 with 2016" cert on the IIS server), while Apache
can send a list that ends with all 3 2016 certificates.  The AIA cert
download URL in certificates issued by 2016 would probably have to
return "2016 with 2012", while the AIA cert download URL in "2016 with
2012" would return "2012 with original", this is based on the assumption 
that AIA-supporting browsers will check 

Re: Taiwan GRCA Root Renewal Request

[lcchen . cissp]

Kathleen Wilson於 2016年11月15日星期二 UTC+8上午9時20分09秒寫道：
> All,
> 
> I will greatly appreciate it if you will review this request from Government 
> of Taiwan, Government Root Certification Authority (GRCA) to include their 
> Government Root Certification Authority root certificate, and turn on the 
> Websites and Email trust bits. This root cert will eventually replace the 
> previous GRCA root certificate that was included via Bugzilla Bug #274106. 
> 
> Thanks,
> Kathleen


In CA/Browser Forum 34th F2F meeting, the minutes is in 
https://cabforum.org/2015/03/11/2015-03-11-minutes-of-cupertino-f2f-meeting-34/.
 Li-Chun Chen (me) of Chunghwa Telecom presented a discussion about "behaviors 
of web servers and browsers if a PKI follows RFC 4210 & RFC 5280 6.1 for Root 
CA key Update". The presentation file is in 
https://cabforum.org/wp-content/uploads/Chunghwatelecom201503cabforumV4.pdf.

I explained the rollover certificate process outlined in RFC 4210 by signing 
the old public key with the new private key and the new public key with the old 
private key. I also gave the definition of Self-issued certificates 
(Self-issued certificates are generated to support changes in policy or 
operations. So there will be values in certificate policies extension filed of 
self-issued certificates) and Self-signed certificates (CA certificates in 
which the issuer and subject are the same entity. For a Root CA self-signed 
certficae, there will be no value in certificate policies extension.) as RFC 
5280. Following RFC 5280 6.1, a certificate is self-issued if the same DN 
appears in the subject and issuer fields.  The Taiwanese Government Root CA 
(GRCA) has switched over from SHA1 to SHA256 (in 2012), but we have encountered 
IIS issues following the processes found in the RFCs. See Slide pp.8-pp.13. IIS 
7 falsely treated GRCA’s Self-Issued certificate (new with old) as a 
Self-Signed certificate, because it has the same issuer and subject name. We 
found  SSL Cert –> GCA Cert –> new-with-old GRCA Cert –> old GRCA cert in IIS 
side, but IIS only sends SSL Cert –> GCA Cert to client.  For Mozilla Firefox, 
it uses its own trust list and it only trusts old GRCA and  new GRCA is waiting 
to be built in NSS. So there are lots of complaints of Firefox users connected 
to IIS sites. Because Windows clients support AIA chasing there are less 
chaining problems.


Chunghwa Telecom requested Microsoft to  solve the bug of IIS ASAP through 
Premium support last spring. But until now Microsoft IIS team has not yet solve 
the bug.

Chunghwa Telecom  suggested to make AIA mandatory and browsers must support 
fetching intermediate certificates through AIA. Supporting AIA will also reduce 
some web site administrators forget to install intermediate certificates to 
their server follow CAs or web server’s manuals. (In SSL protocol, SSL servers 
should send intermediate certificate & SSL certificate to SSL client)


It seems that  Mozilla Firefox has not yet suppot AIA. So the best solution to 
solve the bug is to  include the new Taiwna Government Root Certification 
Authority root certificate in Mozilla NSS, and turn on the Websites and Email 
trust bits. It will significantly reduces complaints from Mozilla User and 
administrators of Taiwan government entities's websites that use IIS.

In CA/Browser Form 34th F2F meeting minutes, There are [ Additionally, Brian 
Smith commented separately via email, “It is also possible, and recommended, 
for the rollover certificate to be added to Firefox’s certificate store. Then 
Firefox will be able to use it even if IIS doesn’t send it.”] 

___
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

[Kathleen Wilson]

All,

I will greatly appreciate it if you will review this request from Government of 
Taiwan, Government Root Certification Authority (GRCA) to include their 
Government Root Certification Authority root certificate, and turn on the 
Websites and Email trust bits. This root cert will eventually replace the 
previous GRCA root certificate that was included via Bugzilla Bug #274106. 

Thanks,
Kathleen
___
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]

Peter Bowen於 2016年9月20日星期二 UTC+8下午11時53分29秒寫道：
> On Fri, Sep 16, 2016 at 2:00 PM, Kathleen Wilson  wrote:
> >
> > * CA Hierarchy: Diagram of CA Hierarchy: http://grca.nat.gov.tw/
> > All subordinate CAs are operated by Taiwan Government organizations.
> > GCA is responsible for signing certificates for government agencies. This 
> > is the only intermediate cert that can issue SSL certs.
> > XCA is responsible for signing certificates for organizations;
> > MOICA is responsible for signing certificates for citizens;
> > MOEACA is responsible for signing certificates for corporations; and
> > HCA is responsible for signing certificates for health agencies.
> >
> > * Audit: Annual audits are performed by KPMG according to the WebTrust 
> > criteria.
> > WebTrust CA: https://cert.webtrust.org/SealFile?seal=2050=pdf
> > WebTrust BR: https://cert.webtrust.org/SealFile?seal=2051=pdf
> 
> I'm having trouble matching up the audits with the subordinate CAs.
> There are two different CAs with the same Distinguished Name but
> different SubjectPublicKeyInfo and KeyIDs (https://crt.sh/?caid=186
> and https://crt.sh/?caid=1330) which makes it trickier than normal,
> but either way I'm not seeing all of these subordinates covered in the
> audit reports.  Can someone please provide a link to each audit report
> for each subordinate?
> 
> Thanks,
> Peter

GRCA WebTrust CA 
(http://grca.nat.gov.tw/download/Audit/GRCA_Audit_Report_2016.pdf)

GCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/GCA_WTCA_Report_2016.pdf)
GCA BR (http://grca.nat.gov.tw/download/Audit/GCA_BR_Audit_Report_2015.pdf)

XCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/XCA_Report_2016.pdf)

HCA WebTrust CA 
(http://grca.nat.gov.tw/download/Audit/HCA_WTCA_Audit_Report_2015.pdf)

MOEACA WebTrust CA 
(http://grca.nat.gov.tw/download/Audit/MOEACA_Audit_Report_2015.pdf)

MOICA WebTrust CA 
(http://grca.nat.gov.tw/download/Audit/MOICA_Audit_Report_2015.pdf)


National Development Council (TW)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Taiwan GRCA Root Renewal Request

[Kathleen Wilson]

This request from Government of Taiwan, Government Root Certification Authority 
(GRCA), is to include their Government Root Certification Authority root 
certificate, and turn on the Websites and Email trust bits. This root cert will 
eventually replace the previous GRCA root certificate that was included via 
Bugzilla Bug #274106.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1065896

And in the pending certificates list:
https://wiki.mozilla.org/CA:PendingCAs

Summary of Information Gathered and Verified: 
https://bugzilla.mozilla.org/attachment.cgi?id=8708619

* Root Certificate Download URL:
http://grca.nat.gov.tw/repository/Certs/GRCA2.cer

* The primary documents are provided in Chinese. The CP and CPS have been 
translated into English. 

CA Document Repository: http://grca.nat.gov.tw/01-06.html
GCA CPS(intermediate that can issue SSL certs): 
http://gca.nat.gov.tw/download/Government_Certification_Authority_Certification_Practice_Statement_V1.8.pdf
GPKI CP: http://grca.nat.gov.tw/download/GPKI_CP_eng_v1.7.pdf
GRCA (Root) CPS: http://grca.nat.gov.tw/download/GRCA_CPS_eng_v1.4.pdf

* CA Hierarchy: Diagram of CA Hierarchy: http://grca.nat.gov.tw/
All subordinate CAs are operated by Taiwan Government organizations. 
GCA is responsible for signing certificates for government agencies. This is 
the only intermediate cert that can issue SSL certs.
XCA is responsible for signing certificates for organizations;
MOICA is responsible for signing certificates for citizens;
MOEACA is responsible for signing certificates for corporations; and
HCA is responsible for signing certificates for health agencies.

* This request is to turn on the Email and Websites trust bits.

** GCA CPS section 3.1.11
(1) IC card certificate
Upon obtaining the certificate IC card, subscriber may propose writing its 
email address onto the certificate.
Upon filing application online with certificate IC card by subscriber, the GCA 
will check its digital signature as authentication of subscriber’s identity, 
and send the email verification letter to the certificate email address.
Subscriber shall use the verification letter content reply system to verify it 
truly owns and controls the email address.
(2) Non-IC card certificate
If required, subscriber may jointly apply for non-IC card certificate and 
simultaneously writing email address onto certificate.
Aside from checking certificate application information, the GCA shall also 
send the email verification letter on writing the email address onto the 
certificate.
Subscriber shall use the verification letter content reply system to verify it 
truly owns and controls the email address.

** GCA CPS section 3.1.12
The GCA should follow the General Application procedure as set forth in section 
3.1.8 for authenticating the organization is true when subscriber applies for 
SSL Certificate. Also, the GCA may use following method to check that the host 
domain name truly exists and belongs to the registered under the applicant.
- Government WHOIS host-government Chinese/English domain name registration 
systems (hhtps://rs.gsn.gov.tw)
- TWNIC Whois Database (http://whois.twnic.net.tw)

* EV Policy OID: Not Requesting EV treatment

* Test Website: https://gcaweb.nat.gov.tw/GCAEE/GCAPriApply/GCAPriApply.html

* CRL URLs:
http://grca.nat.gov.tw/repository/CRL2/CA.crl
http://gca.nat.gov.tw/repository/GCA4/CRL2/complete.crl
The value of nextUpdate is set to 24 hours later than the issuing time 
(thisUpdate).
CP section 4.4.9: For Level 2, CRL issued at least every 3 days. For level 3 
and level 4, CRL issued at least once a day. For Test Level and Level 1 CRL 
Issuance Frequency is not specified.

* OCSP URL:
http://gca.nat.gov.tw/cgi-bin/OCSP2/ocsp_server.exe
OCSP responses from this service have a maximum expiration time of two hours

* Audit: Annual audits are performed by KPMG according to the WebTrust criteria.
WebTrust CA: https://cert.webtrust.org/SealFile?seal=2050=pdf
WebTrust BR: https://cert.webtrust.org/SealFile?seal=2051=pdf

* Potentially Problematic Practices: None Noted
(http://wiki.mozilla.org/CA:Problematic_Practices) 

This begins the discussion of this request from the Government of Taiwan to 
include their Government Root Certification Authority root certificate, and 
turn on the Websites and Email trust bits. At the conclusion of this discussion 
I will provide a summary of issues noted and action items. If there are 
outstanding issues, then an additional discussion may be needed as follow-up. 
If there are no outstanding issues, then I will recommend approval of this 
request in the bug.

Kathleen 





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