Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[Kathleen Wilson]

Thanks to all of you who reviewed and commented on this request from DocuSign 
to include the following root certificates, turn on the Websites and Email 
trust bits for all of them, and enable EV treatment for all of them.
+ Certplus Root CA G1 - (SHA512, RSA4096)
+ Certplus Root CA G2 - (SHA384, ECC)
+ OpenTrust Root CA G1 - (SHA256, RSA4096)
+ OpenTrust Root CA G2 - (SHA512, RSA4096)
+ OpenTrust Root CA G3 - (SHA384, ECC)


I am not aware of any issues that would prevent us from moving forward with 
this request. Therefore, I will recommend approval in the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=1025095

I will track the CA's 2 action items in the bug, in parallel with the rest of 
the inclusion process.

1) Update CPS to address the concerns raised in this discussion.
2) Update cert issuance process to prevent use of PrintableString, and enforce 
use of UTF8String instead. 

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen 

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

Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[Kathleen Wilson]

On Tuesday, May 10, 2016 at 8:30:45 AM UTC-7, Erwann Abalea wrote:
> Bonjour,
> 
> Le mardi 10 mai 2016 10:10:49 UTC+2, Kurt Roeckx a écrit :
> > On 2016-05-10 02:07, Kathleen Wilson wrote:
> > > Thanks to all of you who have reviewed and commented on this request from 
> > > DocuSign to include the following root certificates, turn on the Websites 
> > > and Email trust bits for all of them, and enable EV treatment for all of 
> > > them.
> > > + Certplus Root CA G1 - (SHA512, RSA4096)
> > > + Certplus Root CA G2 - (SHA384, ECC)
> > > + OpenTrust Root CA G1 - (SHA256, RSA4096)
> > > + OpenTrust Root CA G2 - (SHA512, RSA4096)
> > > + OpenTrust Root CA G3 - (SHA384, ECC)
> > 
> > I'm only finding 1 certificate during the last week, and it has a 
> > problem with the encoding:
> > https://crt.sh/?id=18733629&opt=x509lint
> > 
> > It's using a PrintableString with "Hautes-Pyrénées" in it, which is 
> > clearly wrong.  A PrintableString has a very limited amount of valid 
> > characters.  All their strings are PrintableStrings.  They should 
> > probably switch most of those to UTF8String.
> 
> It's clearly wrong, yes, and we're checking and changing legacy 
> configuration files to UTF8String (except specific attributes such 
> as countryName or domainComponent). This will be done before 30/06/2016.


Kurt, Thank you for checking. 

As Nick pointed out, DocuSign did notify us that they have this problem and 
intend to resolve this by June 30, 2016.
Reference: https://wiki.mozilla.org/index.html#March_2016_Responses

I propose that we move forward with the inclusion process in parallel, since 
the inclusion process takes longer than that, so we will be able to confirm the 
change before the new roots are included in a release version of Firefox. There 
will be two action items that I will need to track for the CA:
1) Update CPS
2) Update cert issuance process to prevent use of PrintableString, and enforce 
use of UTF8String instead.

Thanks,
Kathleen






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

Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[Erwann Abalea]

Bonjour,

Le mardi 10 mai 2016 10:10:49 UTC+2, Kurt Roeckx a écrit :
> On 2016-05-10 02:07, Kathleen Wilson wrote:
> > Thanks to all of you who have reviewed and commented on this request from 
> > DocuSign to include the following root certificates, turn on the Websites 
> > and Email trust bits for all of them, and enable EV treatment for all of 
> > them.
> > + Certplus Root CA G1 - (SHA512, RSA4096)
> > + Certplus Root CA G2 - (SHA384, ECC)
> > + OpenTrust Root CA G1 - (SHA256, RSA4096)
> > + OpenTrust Root CA G2 - (SHA512, RSA4096)
> > + OpenTrust Root CA G3 - (SHA384, ECC)
> 
> I'm only finding 1 certificate during the last week, and it has a 
> problem with the encoding:
> https://crt.sh/?id=18733629&opt=x509lint
> 
> It's using a PrintableString with "Hautes-Pyrénées" in it, which is 
> clearly wrong.  A PrintableString has a very limited amount of valid 
> characters.  All their strings are PrintableStrings.  They should 
> probably switch most of those to UTF8String.

It's clearly wrong, yes, and we're checking and changing legacy configuration 
files to UTF8String (except specific attributes such as countryName or 
domainComponent). This will be done before 30/06/2016.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[Nick Lamb]

On Tuesday, 10 May 2016 09:10:49 UTC+1, Kurt Roeckx  wrote:
> It's using a PrintableString with "Hautes-Pyrénées" in it, which is 
> clearly wrong.  A PrintableString has a very limited amount of valid 
> characters.  All their strings are PrintableStrings.  They should 
> probably switch most of those to UTF8String.

Ah yes, perhaps it is possible this sort of thing is what DocuSign is referring 
to with

"As of 31st of March 2016, 10755 certificates are concerned by (e). Last 
issuance date will be 06/30/2016. Last expiration date will be 06/30/2019."

Even though the intent of 4e was phase out of legacy encodings like 
TeletexString, shoving things that aren't PrintableStrings into a 
PrintableString is definitely worse.

If that is what they intended by their response, is the implied promise to fix 
it at the end of next month ("last issuance date will be 06/30/2016") 
acceptable to Mozilla? I guess either way we can hope for a clarification from 
DocuSign.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[Kurt Roeckx]

On 2016-05-10 02:07, Kathleen Wilson wrote:

Thanks to all of you who have reviewed and commented on this request from 
DocuSign to include the following root certificates, turn on the Websites and 
Email trust bits for all of them, and enable EV treatment for all of them.
+ Certplus Root CA G1 - (SHA512, RSA4096)
+ Certplus Root CA G2 - (SHA384, ECC)
+ OpenTrust Root CA G1 - (SHA256, RSA4096)
+ OpenTrust Root CA G2 - (SHA512, RSA4096)
+ OpenTrust Root CA G3 - (SHA384, ECC)


I'm only finding 1 certificate during the last week, and it has a 
problem with the encoding:

https://crt.sh/?id=18733629&opt=x509lint

It's using a PrintableString with "Hautes-Pyrénées" in it, which is 
clearly wrong.  A PrintableString has a very limited amount of valid 
characters.  All their strings are PrintableStrings.  They should 
probably switch most of those to UTF8String.



Kurt

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

Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[Kathleen Wilson]

Thanks to all of you who have reviewed and commented on this request from 
DocuSign to include the following root certificates, turn on the Websites and 
Email trust bits for all of them, and enable EV treatment for all of them. 
+ Certplus Root CA G1 - (SHA512, RSA4096)
+ Certplus Root CA G2 - (SHA384, ECC)
+ OpenTrust Root CA G1 - (SHA256, RSA4096)
+ OpenTrust Root CA G2 - (SHA512, RSA4096)
+ OpenTrust Root CA G3 - (SHA384, ECC) 

I believe that all of the questions and concerns that were raised in this 
discussion have been resolved, or will be resolved in the next version of their 
CPS.

I did not see any show-stoppers, so I propose that we move forward with 
approving and including the root certificates listed above, and in parallel I 
will track the CA's action item to update their CPS.

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

Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[Andrew R. Whalley]

Thank you Erwann.  I have no other questions at this time.

On Thu, Apr 28, 2016 at 7:13 AM, Erwann Abalea  wrote:

> Bonjour,
>
> Le vendredi 8 avril 2016 01:38:09 UTC+2, awha...@google.com a écrit :
> > OpenTrust has requested EV treatment in Chrome, with bug:
> https://bugs.chromium.org/p/chromium/issues/detail?id=385090
> >
> > As such I've reviewed the "EV SSL CA Certificate Practice Statement"
> version 0.8 dated Feb 1st 2016, and have the following comments and
> questions for them:
> >
> > 1.1 Overview
> >
> > We encourage honouring CAA records, even though it's not currently
> required.  We also encourage CAs to publish how they would use CAA values
> in the future if they were to support it, to allow domain owners to start
> creating such records.
>
> Ok, we'll adapt our procedures if necessary.
>
>
> > For Club EV and ISP EV, it says they perform "All checks required to
> issue EV Certificates, in accordance with this CPS."  Could you confirm
> that KEYNECTIS EV still performs the final cross check, per 3.2.6
> Validation of Authority.
>
> As described in sections 4.2.1.2 and 4.2.1.3, Club EV and ISP EV offers
> can't be open unless KEYNECTIS EV CA has performed necessary identification
> and authentication processes under dual control (RA operator 1 and RA
> operator 2), to perform this cross-check.
>
>
> > 1.2 Document Name and Identification
> >
> > The application lists 1.3.6.1.4.1.22234.2.5.2.3.1 as the EV OID, but
> this section mentions that you're moving to 1.3.6.1.4.1.22234.2.14.3.11.
> Are both being requested?  If so, please update in the Chromium bug.
>
> The Google Chromium application request will be updated accordingly.
>
>
> > 1.5.4 CPS Approval Procedure
> >
> > Please clarify the exact details regarding "Parts of the CPS are remains
> (sic) confidential and are not published."
>
> Internal procedures, such as management of badges, management of access
> controls (physical and logical), management of secret shares, etc.
>
>
> > 1.6 Definitions and Acronyms
> >
> > Independent confirmation from applicant: definition missing.
>
> We meant to copy/paste the definition from EV guidelines, and missed it.
> This will be corrected in the next CPS revision.
>
>
> > 3.2.2.4 Verification of an Entity Domain Name
> >
> > "For Government Entity Applicants, the CA relies on the domain name
> listed for that entity in the records of the QGIS in Applicant's
> Jurisdiction to verify Domain Name."
> >
> > Please describe how this is covered by one of items 1 to 7 of section
> 3.2.2.4 of the Baseline Requirements.
>
> This is an unfortunate mix, inspired by section 3.2.2.1 (dealing with
> Entity legal existence verifications). This phrase will be removed in the
> next CPS revision. We only use methods 1 to 4.
>
>
> > 4.1.2.1 K.EV offer
> >
> > "at the following address:" - no address is specified
>
> That's an error, the proper address is transmitted with the purchase
> order. This will be corrected in the next CPS revision.
>
>
> > 4.2.1.1 K.EV offer
> >
> > Missing section reference in the 7th bullet
>
> The next 2 bullets should have been right-indented, as in sections 4.2.1.2
> and 4.2.1.3. Will be corrected in the next CPS revision.
>
>
> > 4.9.4 Time within Which CA Must Process the Revocation Request
> >
> > "OPENTRUST RA for revocation is available from 9:00 am to 06:00 pm
> Monday to Friday, except during bank holidays."
> >
> > Baseline Requirements section 4.9.1.1. "The CA SHALL revoke a
> Certificate within 24 hours", and 4.9.3. "The CA SHALL maintain a
> continuous 24x7 ability to accept and respond to revocation requests and
> related inquiries.".  Please confirm that a revocation request can go
> directly to the CA if the RA isn't currently open.
>
> This 9-18 Mon-Fri time frame is only for OPENTRUST RA human personnel.
> KEYNECTIS EV CA online revocation service is available on a 24x7 basis, as
> written on the preceding page.
>
>
> > 5.8 EV CA component termination
> >
> > Several sections of the Baseline Requirements refer to CA being revoked
> making arrangements for another CA to provide revocation support for issued
> certificates.  Would such an arrangement be considered here?
>
> No.
>
>
> > 7.1 Certificate Profile
> >
> > Key length still mentions 1024 bits, without caveat.
> >
> > Public key algorithm still mentions SHA1, without caveat.
>
> 1024 bits and SHA1 were not removed from the CPS, this will be done in the
> next CPS revision.
> In the meantime, we of course follow CABF BR regarding key sizes and
> signature algorithm (keys smaller than 2048 bits are rejected, and
> certificates are signed with SHA2 only since 01/01/2016).
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-secu

Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[Erwann Abalea]

Bonjour,

Le vendredi 8 avril 2016 01:38:09 UTC+2, awha...@google.com a écrit :
> OpenTrust has requested EV treatment in Chrome, with bug:  
> https://bugs.chromium.org/p/chromium/issues/detail?id=385090
> 
> As such I've reviewed the "EV SSL CA Certificate Practice Statement" version 
> 0.8 dated Feb 1st 2016, and have the following comments and questions for 
> them:
> 
> 1.1 Overview
> 
> We encourage honouring CAA records, even though it's not currently required.  
> We also encourage CAs to publish how they would use CAA values in the future 
> if they were to support it, to allow domain owners to start creating such 
> records.

Ok, we'll adapt our procedures if necessary.


> For Club EV and ISP EV, it says they perform "All checks required to issue EV 
> Certificates, in accordance with this CPS."  Could you confirm that KEYNECTIS 
> EV still performs the final cross check, per 3.2.6 Validation of Authority.

As described in sections 4.2.1.2 and 4.2.1.3, Club EV and ISP EV offers can't 
be open unless KEYNECTIS EV CA has performed necessary identification and 
authentication processes under dual control (RA operator 1 and RA operator 2), 
to perform this cross-check.


> 1.2 Document Name and Identification 
> 
> The application lists 1.3.6.1.4.1.22234.2.5.2.3.1 as the EV OID, but this 
> section mentions that you're moving to 1.3.6.1.4.1.22234.2.14.3.11.  Are both 
> being requested?  If so, please update in the Chromium bug.

The Google Chromium application request will be updated accordingly.


> 1.5.4 CPS Approval Procedure
> 
> Please clarify the exact details regarding "Parts of the CPS are remains 
> (sic) confidential and are not published."

Internal procedures, such as management of badges, management of access 
controls (physical and logical), management of secret shares, etc.


> 1.6 Definitions and Acronyms
> 
> Independent confirmation from applicant: definition missing.

We meant to copy/paste the definition from EV guidelines, and missed it. This 
will be corrected in the next CPS revision.


> 3.2.2.4 Verification of an Entity Domain Name
> 
> "For Government Entity Applicants, the CA relies on the domain name listed 
> for that entity in the records of the QGIS in Applicant's Jurisdiction to 
> verify Domain Name." 
> 
> Please describe how this is covered by one of items 1 to 7 of section 3.2.2.4 
> of the Baseline Requirements.

This is an unfortunate mix, inspired by section 3.2.2.1 (dealing with Entity 
legal existence verifications). This phrase will be removed in the next CPS 
revision. We only use methods 1 to 4.


> 4.1.2.1 K.EV offer
> 
> "at the following address:" - no address is specified

That's an error, the proper address is transmitted with the purchase order. 
This will be corrected in the next CPS revision.


> 4.2.1.1 K.EV offer
> 
> Missing section reference in the 7th bullet

The next 2 bullets should have been right-indented, as in sections 4.2.1.2 and 
4.2.1.3. Will be corrected in the next CPS revision.


> 4.9.4 Time within Which CA Must Process the Revocation Request 
> 
> "OPENTRUST RA for revocation is available from 9:00 am to 06:00 pm Monday to 
> Friday, except during bank holidays." 
> 
> Baseline Requirements section 4.9.1.1. "The CA SHALL revoke a Certificate 
> within 24 hours", and 4.9.3. "The CA SHALL maintain a continuous 24x7 ability 
> to accept and respond to revocation requests and related inquiries.".  Please 
> confirm that a revocation request can go directly to the CA if the RA isn't 
> currently open.

This 9-18 Mon-Fri time frame is only for OPENTRUST RA human personnel. 
KEYNECTIS EV CA online revocation service is available on a 24x7 basis, as 
written on the preceding page.


> 5.8 EV CA component termination
> 
> Several sections of the Baseline Requirements refer to CA being revoked 
> making arrangements for another CA to provide revocation support for issued 
> certificates.  Would such an arrangement be considered here?

No.


> 7.1 Certificate Profile
> 
> Key length still mentions 1024 bits, without caveat.
> 
> Public key algorithm still mentions SHA1, without caveat. 

1024 bits and SHA1 were not removed from the CPS, this will be done in the next 
CPS revision.
In the meantime, we of course follow CABF BR regarding key sizes and signature 
algorithm (keys smaller than 2048 bits are rejected, and certificates are 
signed with SHA2 only since 01/01/2016).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[Erwann Abalea]

Bonsoir,

Le vendredi 19 février 2016 00:55:02 UTC+1, Charles Reiss a écrit :
> On 02/18/16 21:40, Erwann Abalea wrote:
> > Bonsoir,
> > 
> > Le mercredi 10 février 2016 00:15:11 UTC+1, Charles Reiss a écrit :
> >> On 02/09/16 20:07, Kathleen Wilson wrote:
> >>> This request by DocuSign (OpenTrust/Keynectis/Certplus) is to
> >>> include the following root certificates, turn on the Websites and
> >>> Email trust bits for all of them, and enable EV treatment for all
> >>> of them. These new certs will eventually replace the 'Certplus
> >>> Class 2' root certificate that was included via Bugzilla Bug
> >>> #335392. + Certplus Root CA G1 - (SHA512, RSA4096) + Certplus
> >>> Root CA G2 - (SHA384, ECC) + OpenTrust Root CA G1 - (SHA256,
> >>> RSA4096) + OpenTrust Root CA G2 - (SHA512, RSA4096) + OpenTrust
> >>> Root CA G3 - (SHA384, ECC)
> >>> 
> >>> Previously the company was known as Keynectis, with the Certplus
> >>> and OpenTrust brands, issuing certs to public or private
> >>> corporations, associations.
> >>> 
> >>> Ownership changed November 3, 2015, from Keynectis to DocuSign
> >>> France, which was acquired by DocuSign Inc. The root keys
> >>> remained at the same physical location operated by the same team.
> >>> During the transfer of activity, all past agreements/contracts
> >>> and so on remain available. People linked to this activity were
> >>> also transferred to the new company.
> >>> 
> >>> The request is documented in the following bug: 
> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1025095
> >>> 
> >>> 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=8692112
> >>> 
> >>> Noteworthy points:
> >>> 
> >>> * The primary documents are the RCA CP, SSL CP, and EV CPS.
> >>> Documents are provided in French and some are translated into
> >>> English.
> >>> 
> >>> Document Repository (French): http://www.OpenTrust.com/PC 
> >>> Document Repository (English): 
> >>> https://www.opentrustdtm.com/security-policies/?lang=en RCA -
> >>> Root Certificate Authorities - CP (English): 
> >>> https://www.opentrustdtm.com//wp-content/uploads/2015/03/OpenTrust_DMS_RCA-Program_OpenTrust_CP-v-1.2s2.pdf
> >>
> >>
> >>
> >>> My reading of section 8.1 of the CP is that if CA is
> >> - _not_ technically constrained (as defined by Mozilla); and - not
> >> "issuing SSL certificates" (e.g. a CA lacking any EKU or name
> >> constraints that only issues certificates to individuals), then, it
> >> can be audited only by auditors who do not meet Mozilla's
> >> definition of an independent auditor. (8.2 allows internal auditors
> >> to be only "sufficiently organizationally separated from that
> >> entity to provide an unbiased, independent evaluation", which seems
> >> like it could include a CA employee.) Is this correct?
> > 
> > For CAs not issuing TLS certificates, an internal audit is performed,
> > as permitted by Mozilla's definition of an independent auditor. See
> > Mozilla Inclusion Policy version 2.2, items 11, 12, 13, and 14.
> 
> Mozilla's definition of independent auditor requires that the auditor "
> not [be] affiliated with the CA as an employee or director". I assume
> that this will be the case for subCAs for which an internal audit is
> performed by virtue of the audit being performed employees of the parent
> CA, a different company.
> 
> I don't believe having CAs audit their unconstrained subCAs is within
> the spirit of Mozilla's policy (since a sufficiently non-compliant subCA
> is an existential risk to the parent CA) though it is probably
> technically in conformance.
> 
> I assume you believe the internal audit fits the third option of item
> 14's second requirement: "the party is bound by law, government
> regulation, and/or a professional code of ethics to render an honest and
> objective judgement regarding the CA" (since I imagine you aren't going
> to be disclosing your financial relationship with external subCAs). Can
> you identify what law, regulation, or code of ethics is involved?

Our Root CA and intermediate CAs are ETSI TS 102042 compliant, and the audit is 
performed by an external auditor (LSTI).
As described in our CP (section 8), we have an internal organization that 
allows fulfilling the requirements set in ETSI TS 102042 section 7.5, including 
the independence of trusted roles regarding to any "commercial, financial, or 
other pressures which might adversely influence trust in the services it 
provides." The organization team at DocuSign France performing the internal 
audits and validating the CP/CPS is the PMA (Policy Management Authority), and 
has no hierarchical relationship with the department operating the CAs. This is 
also in line with TS 102042 section 5.4.1).
This requirement is verified during the annual ETSI TS 102042 audit performed 
by the external auditor.

> [snip]
> > 
> >> Section 9.3.3 of this CP states in par

Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[Erwann Abalea]

Bonsoir,

Le jeudi 18 février 2016 22:42:17 UTC+1, Erwann Abalea a écrit :
[...]
> > These certificates chain to the 'Certplus Class 2' root and contain a
> > trailing space in one of their dNSName SANs:
> > 
> > notBefore in 2016:
> > https://crt.sh/?id=12994171&opt=cablint
> > notBefore in 2015:
> > https://crt.sh/?id=10643272&opt=cablint
> > https://crt.sh/?id=9651778&opt=cablint
> 
> Thank you for the information, we will investigate the events chains that 
> came to the production of these certificates.
> On first analysis, it seems it's a human error during a copy/paste operation, 
> and a clarification of the procedures is necessary.
> 
> The self-audit tool we use for our quarterly self-audits will also be 
> extended to detect that kind of defect.

I forgot an update on this case.

First-hand analysis was right, it was cut/paste errors.
The rules were repeated to our customer service and to our customers acting as 
RAs.
Parallel to that, we're currently modifying the configuration of what is 
exposed to our customers and to the customer service, to check that what is 
declared as an FQDN is correctly formed (only valid characters plus an optional 
star as leftmost label, valid total length, valid labels lengths).
And the self-audit tool is being modified to detect that kind of defect.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[Charles Reiss]

On 02/18/16 21:40, Erwann Abalea wrote:
> Bonsoir,
> 
> Le mercredi 10 février 2016 00:15:11 UTC+1, Charles Reiss a écrit :
>> On 02/09/16 20:07, Kathleen Wilson wrote:
>>> This request by DocuSign (OpenTrust/Keynectis/Certplus) is to
>>> include the following root certificates, turn on the Websites and
>>> Email trust bits for all of them, and enable EV treatment for all
>>> of them. These new certs will eventually replace the 'Certplus
>>> Class 2' root certificate that was included via Bugzilla Bug
>>> #335392. + Certplus Root CA G1 - (SHA512, RSA4096) + Certplus
>>> Root CA G2 - (SHA384, ECC) + OpenTrust Root CA G1 - (SHA256,
>>> RSA4096) + OpenTrust Root CA G2 - (SHA512, RSA4096) + OpenTrust
>>> Root CA G3 - (SHA384, ECC)
>>> 
>>> Previously the company was known as Keynectis, with the Certplus
>>> and OpenTrust brands, issuing certs to public or private
>>> corporations, associations.
>>> 
>>> Ownership changed November 3, 2015, from Keynectis to DocuSign
>>> France, which was acquired by DocuSign Inc. The root keys
>>> remained at the same physical location operated by the same team.
>>> During the transfer of activity, all past agreements/contracts
>>> and so on remain available. People linked to this activity were
>>> also transferred to the new company.
>>> 
>>> The request is documented in the following bug: 
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1025095
>>> 
>>> 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=8692112
>>> 
>>> Noteworthy points:
>>> 
>>> * The primary documents are the RCA CP, SSL CP, and EV CPS.
>>> Documents are provided in French and some are translated into
>>> English.
>>> 
>>> Document Repository (French): http://www.OpenTrust.com/PC 
>>> Document Repository (English): 
>>> https://www.opentrustdtm.com/security-policies/?lang=en RCA -
>>> Root Certificate Authorities - CP (English): 
>>> https://www.opentrustdtm.com//wp-content/uploads/2015/03/OpenTrust_DMS_RCA-Program_OpenTrust_CP-v-1.2s2.pdf
>>
>>
>>
>>> My reading of section 8.1 of the CP is that if CA is
>> - _not_ technically constrained (as defined by Mozilla); and - not
>> "issuing SSL certificates" (e.g. a CA lacking any EKU or name
>> constraints that only issues certificates to individuals), then, it
>> can be audited only by auditors who do not meet Mozilla's
>> definition of an independent auditor. (8.2 allows internal auditors
>> to be only "sufficiently organizationally separated from that
>> entity to provide an unbiased, independent evaluation", which seems
>> like it could include a CA employee.) Is this correct?
> 
> For CAs not issuing TLS certificates, an internal audit is performed,
> as permitted by Mozilla's definition of an independent auditor. See
> Mozilla Inclusion Policy version 2.2, items 11, 12, 13, and 14.

Mozilla's definition of independent auditor requires that the auditor "
not [be] affiliated with the CA as an employee or director". I assume
that this will be the case for subCAs for which an internal audit is
performed by virtue of the audit being performed employees of the parent
CA, a different company.

I don't believe having CAs audit their unconstrained subCAs is within
the spirit of Mozilla's policy (since a sufficiently non-compliant subCA
is an existential risk to the parent CA) though it is probably
technically in conformance.

I assume you believe the internal audit fits the third option of item
14's second requirement: "the party is bound by law, government
regulation, and/or a professional code of ethics to render an honest and
objective judgement regarding the CA" (since I imagine you aren't going
to be disclosing your financial relationship with external subCAs). Can
you identify what law, regulation, or code of ethics is involved?

[snip]
> 
>> Section 9.3.3 of this CP states in part: "PKI components must not
>> disclose certificate or certificate-related information to any
>> third party unless authorized by this policy" while section 9.4.3
>> states: "Any and all information within a certificate is inherently
>> public information and shall not be considered confidential
>> information."
>> 
>> What is the 'certificate information' contemplated by section 9.3.3
>> that is not contained within a certificate?
> 
> Certificate-related information that are protected by privacy laws,
> such as telephone numbers, copies of ID cards, passwords or PIN
> numbers exchanged between the customer and the CA/RA. Event logs are
> also confidential.

In the event of serious certificate misissuance, what information about
those certificates and how they were issued will DocuSign be able to
share with the public?

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

Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[Erwann Abalea]

Bonsoir,

Le mercredi 17 février 2016 02:11:58 UTC+1, Charles Reiss a écrit :
> On 02/09/16 20:07, Kathleen Wilson wrote:
> > This request by DocuSign (OpenTrust/Keynectis/Certplus) is to include
> > the following root certificates, turn on the Websites and Email trust
> > bits for all of them, and enable EV treatment for all of them. These new
> > certs will eventually replace the 'Certplus Class 2' root certificate
> 
> These certificates chain to the 'Certplus Class 2' root and contain a
> trailing space in one of their dNSName SANs:
> 
> notBefore in 2016:
> https://crt.sh/?id=12994171&opt=cablint
> notBefore in 2015:
> https://crt.sh/?id=10643272&opt=cablint
> https://crt.sh/?id=9651778&opt=cablint

Thank you for the information, we will investigate the events chains that came 
to the production of these certificates.
On first analysis, it seems it's a human error during a copy/paste operation, 
and a clarification of the procedures is necessary.

The self-audit tool we use for our quarterly self-audits will also be extended 
to detect that kind of defect.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[Erwann Abalea]

Bonsoir,

Le mercredi 10 février 2016 00:15:11 UTC+1, Charles Reiss a écrit :
> On 02/09/16 20:07, Kathleen Wilson wrote:
> > This request by DocuSign (OpenTrust/Keynectis/Certplus) is to include
> > the following root certificates, turn on the Websites and Email trust
> > bits for all of them, and enable EV treatment for all of them. These new
> > certs will eventually replace the 'Certplus Class 2' root certificate
> > that was included via Bugzilla Bug #335392.
> > + Certplus Root CA G1 - (SHA512, RSA4096)
> > + Certplus Root CA G2 - (SHA384, ECC)
> > + OpenTrust Root CA G1 - (SHA256, RSA4096)
> > + OpenTrust Root CA G2 - (SHA512, RSA4096)
> > + OpenTrust Root CA G3 - (SHA384, ECC)
> > 
> > Previously the company was known as Keynectis, with the Certplus and
> > OpenTrust brands, issuing certs to public or private corporations,
> > associations.
> > 
> > Ownership changed November 3, 2015, from Keynectis to DocuSign France,
> > which was acquired by DocuSign Inc. The root keys remained at the same
> > physical location operated by the same team. During the transfer of
> > activity, all past agreements/contracts and so on remain available.
> > People linked to this activity were also transferred to the new company.
> > 
> > The request is documented in the following bug:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1025095
> > 
> > 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=8692112
> > 
> > Noteworthy points:
> > 
> > * The primary documents are the RCA CP, SSL CP, and EV CPS. Documents
> > are provided in French and some are translated into English.
> > 
> > Document Repository (French): http://www.OpenTrust.com/PC
> > Document Repository (English):
> > https://www.opentrustdtm.com/security-policies/?lang=en
> > RCA - Root Certificate Authorities - CP (English):
> > https://www.opentrustdtm.com//wp-content/uploads/2015/03/OpenTrust_DMS_RCA-Program_OpenTrust_CP-v-1.2s2.pdf
> 
> 
> My reading of section 8.1 of the CP is that if CA is
> - _not_ technically constrained (as defined by Mozilla); and
> - not "issuing SSL certificates"
> (e.g. a CA lacking any EKU or name constraints that only issues
> certificates to individuals), then, it can be audited only by auditors
> who do not meet Mozilla's definition of an independent auditor. (8.2
> allows internal auditors to be only "sufficiently organizationally
> separated from that entity to provide an unbiased, independent
> evaluation", which seems like it could include a CA employee.) Is this
> correct?

For CAs not issuing TLS certificates, an internal audit is performed, as 
permitted by Mozilla's definition of an independent auditor. See Mozilla 
Inclusion Policy version 2.2, items 11, 12, 13, and 14.
During our regular ETSI TS 102042 and ETSI TS 101456 audits, the auditor 
ensures that the internal audit team (a trusted role) is free from any 
pressures that might adversely influence trust in the service it provides. See 
section 7.5 of the aforementioned ETSI TS documents.


> Section 9.3.1 of this CP suggests that "audit results and reports" are
> confidential information, which seems to be at odds with Mozilla's
> public attestation requirement.

The conclusion of the auditor is public, not the findings and mentions. Those 
are transmitted to the supervisory body.


> Section 9.3.3 of this CP states in part:
> "PKI components must not disclose certificate or certificate-related
> information to any third party unless authorized by this policy"
> while section 9.4.3 states:
> "Any and all information within a certificate is inherently public
> information and shall not be considered confidential information."
> 
> What is the 'certificate information' contemplated by section 9.3.3 that
> is not contained within a certificate?

Certificate-related information that are protected by privacy laws, such as 
telephone numbers, copies of ID cards, passwords or PIN numbers exchanged 
between the customer and the CA/RA. Event logs are also confidential.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[Erwann Abalea]

Bonjour,

Le mardi 9 février 2016 22:41:37 UTC+1, David E. Ross a écrit :
> On 2/9/2016 12:07 PM, Kathleen Wilson wrote:
> 
>   [snipped]
> 
> > * Audit: Annual audits are performed by LSTI according to the ETSI TS 
> > 102 042 criteria.
> > http://www.lsti-certification.fr/images/liste_entreprise/Liste%20PSCe.pdf
> > https://bug1025095.bugzilla.mozilla.org/attachment.cgi?id=8590352
> 
> Has an audit been performed with respect to the current ownership and
> management, which changed less than six months ago?

No. Our last complete annual audit was performed in October 2015, and included 
these 5 new roots. The next complete audit is scheduled for October 2016. An 
extension audit will be performed this month (for other CAs, unrelated to this 
request). We asked the auditor to clearly distinguish between the two companies 
(Keynectis and Opentrust/Docusign France) in their next publication, we hope it 
will be done in March.

> > * Potentially Problematic Practices:
> > (http://wiki.mozilla.org/CA:Problematic_Practices)
> > ** Both external CAs and External RAs are allowed.
> > RCA CP describes how Root CA, ICA and all CA (OpenTrust's CA and 
> > Customer's CA) are audited. Please refer to section 1.4, 4.1, 4.2 and 8 
> > of the RCA's CP.
> > ** Externally Operated SubCAs: Currently none, but the CP does allow for 
> > external CAs.
> > *** RCA CP section 1.1: The present CP represents the common 
> > requirements that RCAs, ICAs and CAs have to enforce to be signed by a 
> > RCA or an ICA and designates standards to be implemented by a CA in 
> > order to issue Subscriber (or Subject) Certificates.
> > OpenTrust manages its RCA certificates lifecycle as detailed in [ETSI 
> > 102 042] and [ETSI 101 456]. CAs signed by a RCA or an ICA shall be 
> > audited against ETSI standards (102 042 and/or 101 456) or WebTrust 
> > (http://www.webtrust.org/item64428.aspx) or according to rules defined 
> > by [Adobe] for all types of Subscriber certificates it issues and in the 
> > certification path of the RCA. In case the CA issues SSL and / or email 
> > certificates, as an alternative to the above audits, this CA may be 
> > technically constrained in the CA certificate and audited by Opentrust.
> > *** RCA CP section 4.1.2.3: For SSL/TLS Certificate and email 
> > certificate under [Mozilla] program, choice for the CA certificate
> > between "audit" against ETSI standards, or [CAB Forum] for SSL/TLS, 
> > (refer to section 8 below) or "technical constraint" (refer to section 
> > 10.3 below).
> > - If Subscribers are only internal: Customer may choose to have only 
> > "technical constraint".
> > - If some Subscribers are external: Customer shall choose to have 
> > "audit" against ETSI standards (refer to section 8 below).
> > - If "Technical constraint" choice is made, then following information 
> > shall be provided:
> > -- All the domain name to be set in extension "Name Constraint" for 
> > "dnsNames" if Subscriber Certificate are for SSL certificate and/or 
> > email protection to be set in the CA certificate (refer to section 10.3 
> > below).
> > -- All the domain name to be set in extension "Name Constraint" for 
> > "rfc822names" if Subscriber Certificate are for email protection to be 
> > set in the CA certificate (refer to section 10.3 below).
> > -- All the possible "Extended Key Usage" that are set in the Subscriber 
> > Certificate in order to be set in the CA certificate (refer to section 
> > 10.3 below).
> 
> Have any of the external CAs or RAs been audited since the recent change
> of ownership?

We don't have any unconstrained external CA under these 5 new roots, and no 
external RA.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[Charles Reiss]

On 02/09/16 20:07, Kathleen Wilson wrote:
> This request by DocuSign (OpenTrust/Keynectis/Certplus) is to include
> the following root certificates, turn on the Websites and Email trust
> bits for all of them, and enable EV treatment for all of them. These new
> certs will eventually replace the ‘Certplus Class 2’ root certificate

These certificates chain to the 'Certplus Class 2' root and contain a
trailing space in one of their dNSName SANs:

notBefore in 2016:
https://crt.sh/?id=12994171&opt=cablint
notBefore in 2015:
https://crt.sh/?id=10643272&opt=cablint
https://crt.sh/?id=9651778&opt=cablint



> that was included via Bugzilla Bug #335392.
> + Certplus Root CA G1 - (SHA512, RSA4096)
> + Certplus Root CA G2 - (SHA384, ECC)
> + OpenTrust Root CA G1 - (SHA256, RSA4096)
> + OpenTrust Root CA G2 - (SHA512, RSA4096)
> + OpenTrust Root CA G3 - (SHA384, ECC)
> 
> Previously the company was known as Keynectis, with the Certplus and
> OpenTrust brands, issuing certs to public or private corporations,
> associations.
> [snip]

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

Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[Jakob Bohm]

Commenting only on a two points, snipping rest.

I am not associated with Docusign and this is just some guesswork to
help the process along.  Obviously someone official will have to
directly or indirectly state which of these guesses are correct.

On 10/02/2016 00:14, Charles Reiss wrote:


Section 9.3.1 of this CP suggests that "audit results and reports" are
confidential information, which seems to be at odds with Mozilla's
public attestation requirement.



Could it be that the conclusion of the auditor is public, but the
detailed assessments about the confidential stuff the auditor had
access to (such as internal procedures, exact layout of the building
housing the private keys, discovered code vulnerabilities etc. etc.)
remain confidential?  Similar to how the independent audits of
financial accounts has a public part (the results and a statement by
the auditor that it has been checked to be factually true) and a
private part (commentary for the board and management).



Section 9.3.3 of this CP states in part:
"PKI components must not disclose certificate or certificate-related
information to any third party unless authorized by this policy"
while section 9.4.3 states:
"Any and all information within a certificate is inherently public
information and shall not be considered confidential information."

What is the 'certificate information' contemplated by section 9.3.3 that
is not contained within a certificate?



Could it be a prohibition against publishing the certificates to all
and sundry (e.g. via Google's certificate indexing protocol), even
though the certificates are not technically confidential?

Or could it be that the records and documents used in validating the
certificate application (such as the CSR, signed paperwork, copies of
official documents, callback phone numbers, revocation passwords etc.)
remain confidential?



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: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[Charles Reiss]

On 02/09/16 20:07, Kathleen Wilson wrote:
> This request by DocuSign (OpenTrust/Keynectis/Certplus) is to include
> the following root certificates, turn on the Websites and Email trust
> bits for all of them, and enable EV treatment for all of them. These new
> certs will eventually replace the ‘Certplus Class 2’ root certificate
> that was included via Bugzilla Bug #335392.
> + Certplus Root CA G1 - (SHA512, RSA4096)
> + Certplus Root CA G2 - (SHA384, ECC)
> + OpenTrust Root CA G1 - (SHA256, RSA4096)
> + OpenTrust Root CA G2 - (SHA512, RSA4096)
> + OpenTrust Root CA G3 - (SHA384, ECC)
> 
> Previously the company was known as Keynectis, with the Certplus and
> OpenTrust brands, issuing certs to public or private corporations,
> associations.
> 
> Ownership changed November 3, 2015, from Keynectis to DocuSign France,
> which was acquired by DocuSign Inc. The root keys remained at the same
> physical location operated by the same team. During the transfer of
> activity, all past agreements/contracts and so on remain available.
> People linked to this activity were also transferred to the new company.
> 
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1025095
> 
> 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=8692112
> 
> Noteworthy points:
> 
> * The primary documents are the RCA CP, SSL CP, and EV CPS. Documents
> are provided in French and some are translated into English.
> 
> Document Repository (French): http://www.OpenTrust.com/PC
> Document Repository (English):
> https://www.opentrustdtm.com/security-policies/?lang=en
> RCA - Root Certificate Authorities - CP (English):
> https://www.opentrustdtm.com//wp-content/uploads/2015/03/OpenTrust_DMS_RCA-Program_OpenTrust_CP-v-1.2s2.pdf


My reading of section 8.1 of the CP is that if CA is
- _not_ technically constrained (as defined by Mozilla); and
- not "issuing SSL certificates"
(e.g. a CA lacking any EKU or name constraints that only issues
certificates to individuals), then, it can be audited only by auditors
who do not meet Mozilla's definition of an independent auditor. (8.2
allows internal auditors to be only "sufficiently organizationally
separated from that entity to provide an unbiased, independent
evaluation", which seems like it could include a CA employee.) Is this
correct?


Section 9.3.1 of this CP suggests that "audit results and reports" are
confidential information, which seems to be at odds with Mozilla's
public attestation requirement.


Section 9.3.3 of this CP states in part:
"PKI components must not disclose certificate or certificate-related
information to any third party unless authorized by this policy"
while section 9.4.3 states:
"Any and all information within a certificate is inherently public
information and shall not be considered confidential information."

What is the 'certificate information' contemplated by section 9.3.3 that
is not contained within a certificate?

> 
> SSL CP (French):
> https://www.opentrustdtm.com/wp-content/uploads/2015/11/OpenTrust_DMS_PC-Certificats-OpenTrust-SSL-RGS-et-ETSI-V15.pdf
> 
> EV CPS (English):
> https://www.opentrustdtm.com//wp-content/uploads/2015/03/OpenTrust_DMS_EV_SSL_CA_Certification_Practice_Statement_2014_12_18s.pdf
> 
> 
> 
> * CA Hierarchy: These new root certificates have cross-signed with the
> currently-included ‘Certplus Class 2’ root certificate which expires in
> 2019.
> 
> Certplus Root CA G1 issued:
> - EV CA: KEYNECTIS Extended Validation CA
> 
> Certplus Root CA G2 issued:
> - EV CA: KEYNECTIS Extended Validation CA
> 
> OpenTrust Root CA G1 issued:
> - EV CA: KEYNECTIS Extended Validation CA
> - AATL CA: OpenTrust CA for AATL G1
> 
> OpenTrust Root CA G2 issued:
> - EV CA: KEYNECTIS Extended Validation CA
> - AATL CA: OpenTrust CA for AATL G2
> 
> OpenTrust Root CA G3 issued:
> - EV CA: KEYNECTIS Extended Validation CA
> - AATL CA: OpenTrust CA for AATL G3
> 
> * This request is to turn on the Websites and Email trust bits, and
> enable EV treatment for all 5 of these root certificates.
> 
> Translation of sections of the SSL CP:
> 
> 4.1 Certificate Application
> Sections 4.1, 4.2, 4.3 and 4.4 specify the requirements for an initial
> application for certificate issuance. Sections 4.6, 4.7 and 4.8 specify
> the requirements for certificate renewal.
> 4.1.1Who Can Submit a Certificate Application
> A certificate request is addressed by TC (Technical Contact) or an SSL
> Administrator to RA.
> 4.1.2Enrollment Process and Responsibilities
> The complete application form, signed and dated, shall be addressed to
> RA by CT or SSL Administrator.
> 
> 4.1.2.1 Certificate non RGS: DV (Domain Validated Certificate)
> The following information must be included in the SSL certificate request:
> - The certificate request is signed by the TC (depending on the origin
> of the request), and 

Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[David E. Ross]

On 2/9/2016 12:07 PM, Kathleen Wilson wrote:

[snipped]

> * Audit: Annual audits are performed by LSTI according to the ETSI TS 
> 102 042 criteria.
> http://www.lsti-certification.fr/images/liste_entreprise/Liste%20PSCe.pdf
> https://bug1025095.bugzilla.mozilla.org/attachment.cgi?id=8590352

Has an audit been performed with respect to the current ownership and
management, which changed less than six months ago?


> * Potentially Problematic Practices:
> (http://wiki.mozilla.org/CA:Problematic_Practices)
> ** Both external CAs and External RAs are allowed.
> RCA CP describes how Root CA, ICA and all CA (OpenTrust’s CA and 
> Customer’s CA) are audited. Please refer to section 1.4, 4.1, 4.2 and 8 
> of the RCA’s CP.
> ** Externally Operated SubCAs: Currently none, but the CP does allow for 
> external CAs.
> *** RCA CP section 1.1: The present CP represents the common 
> requirements that RCAs, ICAs and CAs have to enforce to be signed by a 
> RCA or an ICA and designates standards to be implemented by a CA in 
> order to issue Subscriber (or Subject) Certificates.
> OpenTrust manages its RCA certificates lifecycle as detailed in [ETSI 
> 102 042] and [ETSI 101 456]. CAs signed by a RCA or an ICA shall be 
> audited against ETSI standards (102 042 and/or 101 456) or WebTrust 
> (http://www.webtrust.org/item64428.aspx) or according to rules defined 
> by [Adobe] for all types of Subscriber certificates it issues and in the 
> certification path of the RCA. In case the CA issues SSL and / or email 
> certificates, as an alternative to the above audits, this CA may be 
> technically constrained in the CA certificate and audited by Opentrust.
> *** RCA CP section 4.1.2.3: For SSL/TLS Certificate and email 
> certificate under [Mozilla] program, choice for the CA certificate
> between “audit” against ETSI standards, or [CAB Forum] for SSL/TLS, 
> (refer to section 8 below) or “technical constraint” (refer to section 
> 10.3 below).
> - If Subscribers are only internal: Customer may choose to have only 
> “technical constraint”.
> - If some Subscribers are external: Customer shall choose to have 
> “audit” against ETSI standards (refer to section 8 below).
> - If “Technical constraint” choice is made, then following information 
> shall be provided:
> — All the domain name to be set in extension “Name Constraint” for 
> “dnsNames” if Subscriber Certificate are for SSL certificate and/or 
> email protection to be set in the CA certificate (refer to section 10.3 
> below).
> — All the domain name to be set in extension “Name Constraint” for 
> “rfc822names” if Subscriber Certificate are for email protection to be 
> set in the CA certificate (refer to section 10.3 below).
> — All the possible “Extended Key Usage” that are set in the Subscriber 
> Certificate in order to be set in the CA certificate (refer to section 
> 10.3 below).

Have any of the external CAs or RAs been audited since the recent change
of ownership?

-- 
David E. Ross

The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See .
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy