Re: Certificates with less than 64 bits of entropy

[Matt Palmer via dev-security-policy]

On Fri, Aug 18, 2017 at 04:04:48PM +, Stephen Davidson via 
dev-security-policy wrote:
> Siemens has previously indicated that the affected certificates are
> installed on high profile websites and infrastructure for Siemen’s group
> companies around the world, and that a rushed revocation would create more
> damage than could be expected from the serial number noncompliance.

Have they considered that the potential outcome of a failure to demonstrate
an ability and willingness to abide by the BRs and Mozilla policy could
include having their intermediate CA certificate distrusted?  Would that
create more damage than a "rushed revocation"?

That revocation would need to be "rushed" at all speaks volumes to Siemens'
unfamiliarity with the requirements under which they operate, or else their
unwillingness to abide by those requirements.  Revoking certificates within
24 hours of notification of misissuance is a requirement, and they should
know that, have planned for it, and have their systems and processes
designed in such a way as to be able to adhere to it.  If that were the
case, it would not be a "rushed" revocation and reissuance, but just
business as usual.

- Matt

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

Re: Bugzilla Bugs re CA issuance of non-compliant certs

[Kathleen Wilson via dev-security-policy]

On Friday, August 18, 2017 at 6:35:23 AM UTC-7, Gervase Markham wrote:
> On 17/08/17 00:18, Kathleen Wilson wrote:
> > == Let’s Encrypt == 
> > RESOLVED (no bug needed)
> 
> > == Staat der Nederlandend / PKIoverheid ==
> > RESOLVED (no bug needed)
> 
> While the timely responses and performance of these CAs is commendable,
> it may be worth opening a bug and recording the events and the outcome,
> so that our bug database remains the canonical source of information
> regarding misissuances that Mozilla knows about.
> 
> Kathleen: If your bug-filing fingers are not yet entirely worn out,
> could they stretch to two more? :-)

Let's Encrypt
https://bugzilla.mozilla.org/show_bug.cgi?id=1391867

Staat der Nederlandend 
https://bugzilla.mozilla.org/show_bug.cgi?id=1391864

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

Re: O=U.S. Government for non-USG entity (IdenTrust)

[identrust--- via dev-security-policy]

On Thursday, August 17, 2017 at 2:35:15 PM UTC-4, Jonathan Rudenberg wrote:
> > On Aug 17, 2017, at 14:24, identrust--- via dev-security-policy 
> >  wrote:
> > 
> > Hello, In reference to 3)"Certificates that appear to be intended as client 
> > certificates, but have the anyExtendedKeyUsage EKU, putting them in scope 
> > for the Mozilla Root Policy."
> > The following 6 client certificates that have been identified as server 
> > certificates and have been flagged as non-compliant.  However, these 
> > certificates do not contain FQDN, IP Address, nor ‘TLS Web Server 
> > Authentication’ EKU.  As such in order for us to proceed with our analysis 
> > and determine if any remediation is required, we need clarification in the 
> > exact nature of non-compliance as it relates to Mozilla Root Policy or CAB 
> > Forum Baseline Requirement (ideally with pointer to the specific 
> > requirement in the corresponding documents).
> 
> The Mozilla Root Store Policy section 1.1 (Scope) says:
> 
> > This policy applies, as appropriate, to certificates matching any of the 
> > following (and the CAs which control or issue them):
> > …
> > 3. End-entity certificates which have at least one valid, unrevoked chain 
> > up to such a CA certificate through intermediate certificates which are all 
> > in scope, such end-entity certificates having either:
> > - an Extended Key Usage (EKU) extension which contains one or more of 
> > these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, 
> > id-kp-emailProtection; or: …
> 
> The six certificates linked contain the anyExtendedKeyUsage KeyPurposeId and 
> were issued by an intermediate that is also in scope, so they are in scope 
> for the Mozilla Root Policy and by extension the Baseline Requirements.
> 
> Jonathan

As an update to the reported issue of misclassification of client certificates 
as server certificates, based on our continuing internal investigations, 
feedback from our user community, and also taking into account the feedback 
posted in this forum, we plan to proceed as follows:
1.Nolater than August 31, 2017 we will discontinue new or reissuance of human 
certificate with the anyExtendedKeyUsage extension from all IdenTrust ACES CAs. 
2.We will allow continued use of the current certificates and replace or let 
them expire through natural lifecycle because: 
a. These certificates are not sever certificates
b. All certificates issued are from audited CA(s) with public disclosure of 
audit result
c. The legacy application usage requires anyExtendedKeyUsage extension at the 
present time though we are phasing out support of such application.
d. These certificates do not pose a security concern meriting immediate 
revocation
e.  Replacement of these certificates will result in significant negative 
impact on our customers.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

WISeKey mis-issued EV certificates with wrong validity (Post-Morten)

[pfuentes--- via dev-security-policy]

Dear all, I'm Pedro Fuentes, from WISeKey
this is to raise an issue communicated to us by Alex Gaynor, about some test EV 
certificates that we issued with wrong validity period.
We identified the issue as a human error while defining the initial template 
for the tests issued for our test domain hightrusted.com, these certificates 
aren't in use.
These test issuance were done between November 2016 and January 2017.

We verified that the templates were properly configured after these tests and 
newer certificates disallow validities nor compliant with the requirements.

The mis-issued certificates will be revoked on the minimum possible delay.

I'll use this message to confirm the closure of the incident and provide any 
additional information that could be needed.

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

The State of CRLs Today

[J.C. Jones via dev-security-policy]

All,

As part of some related research, I did some analysis of availability,
size, and download latency of the CRLs currently known in Censys. There
are a number of CRLs missing, or whose DNS no longer resolves; a number
of graphs of size and latency, and the code.

https://tacticalsecret.com/the-state-of-crls/

Cheers,

J.C.

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

Misissuance response status update

[Jonathan Rudenberg via dev-security-policy]

For those who aren’t following Bugzilla closely, here’s a quick update on where 
things are with the large batch of misissuance bugs that was filed this week.

Most CAs have provided an initial response, and many have finished their 
initial incident reviews and provided details.

Only two CAs have not responded at all yet:

- Entrust
- Godaddy (note that this bug was filed a day later than the rest due to an 
oversight on my part)

I suspect that many community members will be interested in the ongoing 
response and some may want to provide helpful feedback. You can see a list of 
all the bugs here: 
https://wiki.mozilla.org/CA/Incident_Dashboard#Open_CA_Compliance_Bugs

If you want to get email updates on a specific bug, log into Bugzilla and press 
the ‘Follow’ button.

If you’d like to follow all of the bugs via email, you can subscribe to the 
whole component by going to this link: 
https://bugzilla.mozilla.org/userprefs.cgi?tab=component_watch and selecting 
the NSS product and the “CA Certificate Mis-Issuance" component.

Another recent item that is relevant is a discussion about “Metadata-only 
subject fields” on the CAB Forum public mailing list: 
https://cabforum.org/pipermail/public/2017-August/011846.html

Cheers,

Jonathan


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

Re: O=U.S. Government for non-USG entity (IdenTrust)

[identrust--- via dev-security-policy]

On Wednesday, August 16, 2017 at 1:45:12 PM UTC-4, Jonathan Rudenberg wrote:
> > On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy 
> >  wrote:
> > 
> > I looked through the CT logs and found 15 more unexpired unrevoked 
> > certificates that are trusted by NSS and appear to have the same inaccurate 
> > organizationName of “U.S. Government” for a non-USG entity.
> > 
> > The list is here: https://misissued.com/batch/10/
> > 
> > Can you explain why your review missed these? Are there any more in 
> > addition to these 15 and previous 5?
> > 
> > Jonathan
> 
> After looking into this more, I’ve found that the majority of certificates 
> issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA 1” intermediates 
> are not BR-compliant.
> 
> The issues fall into three categories:
> 
> 1) Certificates with HTTPS OCSP URLs
> 2) Certificates with otherName SANs
> 3) Certificates that appear to be intended as client certificates, but have 
> the anyExtendedKeyUsage EKU, putting them in scope for the Mozilla Root 
> Policy.
> 
> I’ve found 33 certificates that have one or more of these issues that are 
> unexpired and unrevoked.
> 
> Here is the full list: https://misissued.com/batch/11/ (note that it is a 
> superset of the batch I posted earlier today)
> 
> Jonathan

In ref to "2) Certificates with otherName SANs  above", we have identified 30 
certificates with this issue that are also part of the same population of 
certificates with the https and o=US government issue.

As indicated in the previous reports addressing the HTTP and o=US Government, 
we have corrected the ACES certificate profile and have been proactively 
contacting clients via email notifications and phone calls inviting them to 
replace those certificates. On August 31, 2017 at the latest, we will be making 
a decision regarding any outstanding certificates with this or with the other 2 
issues and posting  an update to the forum.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Responding to a misissuance

[Doug Beattie via dev-security-policy]

> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org]
> Sent: Friday, August 18, 2017 9:42 AM
> To: Doug Beattie ; richmoor...@gmail.com;
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Responding to a misissuance
> 
> On 18/08/17 13:03, Doug Beattie wrote:
> > And if there is any guidance on processing misissuance reports for
> > Name constrained sub-CA vs. not name constrained, that would be
> > helpful also.
> 
> What parts of a response do you think might be different for name-
> constrained sub-CAs?

Technically constrained CAs need to follow the BRs, but the "damage" they can 
do is limited to the set of domains they are constrained to, so I had assumed a 
different process might result.  But, given your pointed question, I can’t 
actually come up with what would be different.

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

RE: Certificates with less than 64 bits of entropy

[Stephen Davidson via dev-security-policy]

Thanks Ryan, and I note your further posting regarding prompt response.  Noting 
your desire for detail, I have hesitated to respond with partial answers as 
both Siemens and QuoVadis are working hard to fix the issues with the Siemens 
CA and to replace the certificates as quickly as possible.

However, I don’t wish to delay getting more information to you, and ask for 
your patience if complete information comes in iterations.

Siemens has previously indicated that the affected certificates are installed 
on high profile websites and infrastructure for Siemen’s group companies around 
the world, and that a rushed revocation would create more damage than could be 
expected from the serial number noncompliance.  

We have been working with Siemens to dramatically advance the date by which the 
affected certificates can be replaced and revoked.  Siemens predicts that the 
vast majority of the certificates can be replaced by September 30, 2017 with 
the few difficult cases following.

Addressing your questions:
1)  The failure was one of process rather than deployed code.  QuoVadis 
made an indepth review of the Siemens CA, policies and practices when we took 
over the rootsigning, just before the BR changes which raised the serial 
entropy requirements.  At that time it was compliant.   QuoVadis formally 
updates Siemens on changes to applicable standards, and the Siemens PKI team 
independently monitors groups like the CABF public and m.d.s.p. lists. Siemens 
were aware of the pending change to 64-bit serials and were prepared to 
implement them.  

I note that at the same time planning was underway to move from the in-house CA 
to an OSS CA – precisely for the reason of easing compliance with the 
increasing pace of change in technical aspects of the BR and other standards, 
such as CT, CAA and serial entropy.  It appears that by oversight, the update 
to bring the inhouse CA to 64-bits was not deployed, and our expectation was 
that the check would be made in the external audit.  The long transition to the 
OSS CA is close to completion.

2)  QuoVadis has a dedicated head of compliance and risk management who, in 
addition to overseeing QuoVadis’ own measures, supervises its external sub-CAs 
including detailed discussions on evolving standards, checks on 
implementations, as well as ongoing monitoring of certificate issuance.  There 
is frequent communication with Siemens and our other root-signed customers.

Siemens has a significant and mature internal audit and external audit regime.  
QuoVadis placed too much reliance on the external ETSI TS 102042 V2.4.1 NCP+ 
DVCP/OVCP audit report for what should have been textbook issues like the 
serial number entropy.  Going forward, QuoVadis will increase the formality of 
notifications regarding BR approved ballots, requiring documented evidence of 
compliance by the effective date, and notification to auditors for scope.

Like many CAs, QuoVadis uses crt.sh/certlint to check certificate issuance 
including for external sub-CAs.  This perhaps led to a false sense of security, 
as certlint does not highlight issues with serial number entropy.  Moreover, 
the fleeting window of visibility in some crt.sh reports may not reveal older 
issues or certificates that have not appeared in CT. QuoVadis is introducing 
routine use of certlint in its own certificate management system, and will 
build an expanded view for our external subCAs (the new Siemens CA will log all 
SSL in CT, and we intend our other external sub-CAs to do so before the Google 
deadline).  

3)  I do not have sufficient information yet to answer your questions 
regarding the auditor’s practices, and cannot comment on Digicert’s (nor 
Verizon’s) previous practices.

4)  The list of affected certificates is attached in spreadsheet form;  
they will be uploaded to CT as well.  You will note that the number has 
declined – Siemens' previous report did not take into account that some of the 
certificates had already previously been revoked for other reasons.   The 
spreadsheet also includes certificates issued during the Digicert/Verizon root 
signing period.

Regards, Stephen

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

TBSCertificate / Certificate Linting APIs

[Rob Stradling via dev-security-policy]

In response to the many BR compliance issues [1] that have been reported 
here this month, there's been renewed interest in certificate linting. 
Various CAs have said that they're considering plugging one or more 
certificate linters into their certificate issuance processes.


Some CAs, such as those with high certificate issuance rates, will 
probably prefer to run their own local installations of their chosen 
linter(s).  However, other CAs may prefer to use an external linting 
service.


One current problem is that neither certlint/cablint nor x509lint is 
suitable for use prior to certificate issuance - that is, they're only 
currently capable of operating on certificates, not TBSCertificates.


With all of the above in mind, I've created a new crt.sh API that can be 
used to lint TBSCertificates.  It uses crt.sh's existing linting 
capabilities, which are provided by cablint and x509lint.  To workaround 
the limitation described in the previous paragraph, it wraps the 
TBSCertificate into a certificate structure by appending a dummy signature.


I'm planning to integrate this crt.sh API into Comodo's issuance 
processes ASAP.  Other CAs are also welcome to use it (although please 
chat to me first if you're a high-volume issuer!)


API URL: https://crt.sh/linttbscert

To use it, either (1) browse to that URL, paste a base64-encoded 
TBSCertificate, then click "Lint TBSCertificate", or (2) simulate that 
button click by POSTing a URL-encoded "b64tbscert" parameter to the same 
URL.


The API response is tab-separated text, with one line per "issue".  Each 
line contains three items:

  LinterSeverityDescription


P.S. I've also created an equivalent linting API for certificates: 
https://crt.sh/lintcert



[1] https://wiki.mozilla.org/CA/Incident_Dashboard#Open_CA_Compliance_Bugs

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

BR compliance of legacy certs at root inclusion time

[Nick Lamb via dev-security-policy]

I'll speak up for transparency again. In terms of policy the most vital thing 
is that a CA tells us about such certs during application. One way to do that 
would be to CT log them, but especially for small sets there might be other 
sensible ways. If we can't be shown the certs in question (or much worse the CA 
didn't keep records) it's tough to be sure the risk is tolerable, we're back to 
taking the CA's word for it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: BR compliance of legacy certs at root inclusion time

[Kristian Fiskerstrand via dev-security-policy]

[Intro; long time lurker but I rarely post, but given this is an open
question not directly tied to any CA or official capacity my opinions are..]

On 08/18/2017 05:02 PM, Gervase Markham via dev-security-policy wrote:
> Sometimes, CAs apply for inclusion with new, clean roots. Other times,
> CAs apply to include roots which already have a history of issuance. The
> previous certs issued by that CA aren't always all BR-compliant. Which
> is in one sense understandable, because up to this point the CA has not
> been bound by the BRs. Heck, the CA may never even have heard of the BRs
> until they come to apply - although this seems less likely than it would
> once have been.
> 
> What should our policy be regarding BR compliance for certificates
> issued by a root requesting inclusion, which were issued before the date
> of their request? Do we:
> 

Iff the CA has known non-BR compliant certs issued I would be in favor
of the CA setting up a new, clean root certificate for the inclusion in
the root program at this point, and require all the certificates issued
by the approved root to be BR compliant.

> A) Require all certs be BR-compliant going forward, but grandfather in
>the old ones; or
> B) Require that any non-BR-compliant old certs be revoked; or
> C) Require that any seriously (TBD) non-BR-compliant old certs be
>revoked; or
>

If new root required for non-BR compliant history, the issues above
seems mitigated

 D) something else?

Yes please


-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Nil satis nisi optimum
Nothing but the best is good enough



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: BR compliance of legacy certs at root inclusion time

[Ryan Sleevi via dev-security-policy]

On Fri, Aug 18, 2017 at 11:02 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Sometimes, CAs apply for inclusion with new, clean roots. Other times,
> CAs apply to include roots which already have a history of issuance. The
> previous certs issued by that CA aren't always all BR-compliant. Which
> is in one sense understandable, because up to this point the CA has not
> been bound by the BRs. Heck, the CA may never even have heard of the BRs
> until they come to apply - although this seems less likely than it would
> once have been.
>
> What should our policy be regarding BR compliance for certificates
> issued by a root requesting inclusion, which were issued before the date
> of their request? Do we:
>
> A) Require all certs be BR-compliant going forward, but grandfather in
>the old ones; or
> B) Require that any non-BR-compliant old certs be revoked; or
> C) Require that any seriously (TBD) non-BR-compliant old certs be
>revoked; or
> D) something else?
>

D) Require that the CA create a new root certificate to be included within
Mozilla products, and which all future BR-compliant certificates will be
issued from this new root. In the event this CA has an existing root
included within one or more software products, this CA may cross-certify
their new root with their old root, thus ensuring their newly-issued
certificates (which are BR compliant) work with such legacy software.

This ensures that all included CAs operate from a 'clean slate' with no
baggage or risk. It also ensures that the slate always starts from "BR
compliant" and continues forward.

However, some (new) CAs may rightfully point out that existing, 'legacy'
CAs have not had this standard applied to them, and have operated in a
manner that is not BR compliant in the past.

To reduce and/or eliminate the risk from existing CAs, particularly those
with long and storied histories of misissuance, which similar present
unknowns to the community (roots that may have been included for >5 years,
thus prior to the BR effective date), require the same of existing roots
who cannot demonstrate that they have had BR audits from the moment of
their inclusion. That is, require 'legacy' CAs to create and stand up new
roots, which will be certified by their existing roots, and transition all
new certificate issuance to these new 'roots' (which will appear to be
cross-signed/intermediates, at first). Within 39 months, Mozilla will be
able to remove all 'legacy' roots for purposes of website authentication,
adding these 'clean' roots in their stead, without any disruption to the
community. Note that this is separable from D, and represents an effort to
holistically clean up and reduce risk.

The transition period at present cannot be less than 39 months (the maximum
validity of a newly issued certificate), plus whatever time is afforded to
CAs to transition (presumably, on the order of 6 months should be
sufficient). In the future, it would also be worth considering reducing the
maximum validity of certificates, such that such rollovers can be completed
in a more timely fashion, thus keeping the ecosystem in a constant 'clean'
state.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

BR compliance of legacy certs at root inclusion time

[Gervase Markham via dev-security-policy]

Sometimes, CAs apply for inclusion with new, clean roots. Other times,
CAs apply to include roots which already have a history of issuance. The
previous certs issued by that CA aren't always all BR-compliant. Which
is in one sense understandable, because up to this point the CA has not
been bound by the BRs. Heck, the CA may never even have heard of the BRs
until they come to apply - although this seems less likely than it would
once have been.

What should our policy be regarding BR compliance for certificates
issued by a root requesting inclusion, which were issued before the date
of their request? Do we:

A) Require all certs be BR-compliant going forward, but grandfather in
   the old ones; or
B) Require that any non-BR-compliant old certs be revoked; or
C) Require that any seriously (TBD) non-BR-compliant old certs be
   revoked; or
D) something else?

Gerv


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

Re: O=U.S. Government for non-USG entity (IdenTrust)

[Ryan Sleevi via dev-security-policy]

Doesn't RFC 5280 clearly indicate that already, through its normative
description of the EKU?

That is, I can understand there being confusion or misinterpretation, but
I'm not sure that the problem itself is rooted in the documents, and thus,
may not be something the documents need to address. :)

On Fri, Aug 18, 2017 at 10:49 AM, Jeremy Rowley 
wrote:

> I don't (as these are the exact type of cert I've been trying to kill for
> years), but Identrust did based on their response. Looking at it from their
> POV, the language could probably be clarified to state thar any cert with
> no equipment, sever Auth,  or anyEKU is considered a BR cert regardless of
> other content.
>
> On Aug 18, 2017, at 8:26 AM, Ryan Sleevi vb wrote:
>
> Do you believe https://github.com/mozilla/pkipolicy/blob/master/
> rootstore/policy.md#11-scope is ambiguous in this context? That is what
> is referenced in the text.
>
> It sounds as if you're suggesting they're in scope, via 1.1, but that
> they're out of scope, because the policy does not state that (id-kp-anyEKU
> || id-kp-serverAuth) are SSL certificates and (id-kp-anyEKU ||
> id-kp-emailProtection) are email certificates, even though this would
> logically flow (from RFC 5280 https://tools.ietf.org/
> html/rfc5280#section-4.2.1.12) stating that anyEKU places no restrictions
> on the subject key as to its purpose. Is that correct?
>
> On Fri, Aug 18, 2017 at 9:53 AM, Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Right, but can you call these SSL certs without an FQDN?
>>
>>
>>   *   Insofar as the Baseline Requirements attempt to define their own
>> scope, the scope of this policy (section 1.1) overrides that. Mozilla thus
>> requires CA operations relating to issuance of all SSL certificates in the
>> scope of this policy to conform to the Baseline Requirements.
>>
>> Is SSL certificate defined?
>>
>> On Aug 18, 2017, at 7:33 AM, Gervase Markham  g...@mozilla.org>> wrote:
>>
>> On 17/08/17 20:31, Jeremy Rowley wrote:
>> Without an FQDN, I doubt they are in scope for the baseline requirements.
>>
>> Not according to the BRs themselves. However, the Mozilla Policy 2.5
>> specifically says:
>>
>> "Insofar as the Baseline Requirements attempt to define their own scope,
>> the scope of this policy (section 1.1) overrides that. Mozilla thus
>> requires CA operations relating to issuance of all SSL certificates in
>> the scope of this policy to conform to the Baseline Requirements."
>>
>> Now, whether we are right to include anyEKU in scope, given that it
>> pulls in certs such as those in question, is still something I am unsure
>> about :-) But the current policy says what it says.
>>
>> They are in scope for the Mozilla policy. The BRs require the cert to
>> be intended for web tls. These are not.
>>
>> But the Mozilla Policy re-scopes the BRs to remove the ambiguous
>> language about "intent".
>>
>> The Mozilla policy covers client certs as well as tls.
>>
>> Er, no it doesn't (except insofar as we make anyEKU in scope)? Our
>> policy covers server certs and email certs.
>>
>> Gerv
>> ___
>> 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-security-policy

Re: O=U.S. Government for non-USG entity (IdenTrust)

[Jeremy Rowley via dev-security-policy]

I don't (as these are the exact type of cert I've been trying to kill for 
years), but Identrust did based on their response. Looking at it from their 
POV, the language could probably be clarified to state thar any cert with no 
equipment, sever Auth,  or anyEKU is considered a BR cert regardless of other 
content.

On Aug 18, 2017, at 8:26 AM, Ryan Sleevi 
vb> wrote:

Do you believe 
https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md#11-scope 
is ambiguous in this context? That is what is referenced in the text.

It sounds as if you're suggesting they're in scope, via 1.1, but that they're 
out of scope, because the policy does not state that (id-kp-anyEKU || 
id-kp-serverAuth) are SSL certificates and (id-kp-anyEKU || 
id-kp-emailProtection) are email certificates, even though this would logically 
flow (from RFC 5280 https://tools.ietf.org/html/rfc5280#section-4.2.1.12) 
stating that anyEKU places no restrictions on the subject key as to its 
purpose. Is that correct?

On Fri, Aug 18, 2017 at 9:53 AM, Jeremy Rowley via dev-security-policy 
>
 wrote:
Right, but can you call these SSL certs without an FQDN?


  *   Insofar as the Baseline Requirements attempt to define their own scope, 
the scope of this policy (section 1.1) overrides that. Mozilla thus requires CA 
operations relating to issuance of all SSL certificates in the scope of this 
policy to conform to the Baseline Requirements.

Is SSL certificate defined?

On Aug 18, 2017, at 7:33 AM, Gervase Markham 
>>
 wrote:

On 17/08/17 20:31, Jeremy Rowley wrote:
Without an FQDN, I doubt they are in scope for the baseline requirements.

Not according to the BRs themselves. However, the Mozilla Policy 2.5
specifically says:

"Insofar as the Baseline Requirements attempt to define their own scope,
the scope of this policy (section 1.1) overrides that. Mozilla thus
requires CA operations relating to issuance of all SSL certificates in
the scope of this policy to conform to the Baseline Requirements."

Now, whether we are right to include anyEKU in scope, given that it
pulls in certs such as those in question, is still something I am unsure
about :-) But the current policy says what it says.

They are in scope for the Mozilla policy. The BRs require the cert to
be intended for web tls. These are not.

But the Mozilla Policy re-scopes the BRs to remove the ambiguous
language about "intent".

The Mozilla policy covers client certs as well as tls.

Er, no it doesn't (except insofar as we make anyEKU in scope)? Our
policy covers server certs and email certs.

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

Re: O=U.S. Government for non-USG entity (IdenTrust)

[Ryan Sleevi via dev-security-policy]

Do you believe
https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md#11-scope
is ambiguous in this context? That is what is referenced in the text.

It sounds as if you're suggesting they're in scope, via 1.1, but that
they're out of scope, because the policy does not state that (id-kp-anyEKU
|| id-kp-serverAuth) are SSL certificates and (id-kp-anyEKU ||
id-kp-emailProtection) are email certificates, even though this would
logically flow (from RFC 5280
https://tools.ietf.org/html/rfc5280#section-4.2.1.12) stating that anyEKU
places no restrictions on the subject key as to its purpose. Is that
correct?

On Fri, Aug 18, 2017 at 9:53 AM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Right, but can you call these SSL certs without an FQDN?
>
>
>   *   Insofar as the Baseline Requirements attempt to define their own
> scope, the scope of this policy (section 1.1) overrides that. Mozilla thus
> requires CA operations relating to issuance of all SSL certificates in the
> scope of this policy to conform to the Baseline Requirements.
>
> Is SSL certificate defined?
>
> On Aug 18, 2017, at 7:33 AM, Gervase Markham > wrote:
>
> On 17/08/17 20:31, Jeremy Rowley wrote:
> Without an FQDN, I doubt they are in scope for the baseline requirements.
>
> Not according to the BRs themselves. However, the Mozilla Policy 2.5
> specifically says:
>
> "Insofar as the Baseline Requirements attempt to define their own scope,
> the scope of this policy (section 1.1) overrides that. Mozilla thus
> requires CA operations relating to issuance of all SSL certificates in
> the scope of this policy to conform to the Baseline Requirements."
>
> Now, whether we are right to include anyEKU in scope, given that it
> pulls in certs such as those in question, is still something I am unsure
> about :-) But the current policy says what it says.
>
> They are in scope for the Mozilla policy. The BRs require the cert to
> be intended for web tls. These are not.
>
> But the Mozilla Policy re-scopes the BRs to remove the ambiguous
> language about "intent".
>
> The Mozilla policy covers client certs as well as tls.
>
> Er, no it doesn't (except insofar as we make anyEKU in scope)? Our
> policy covers server certs and email certs.
>
> Gerv
> ___
> 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-security-policy

Re: AC FNMT Usuarios and anyExtendedKeyUsage

[Eric Mill via dev-security-policy]

Hi Jose,

Apologies, on looking back through m.d.s.p, it's clear attachments aren't
processed by the list configuration. Would you be able to post it to a URL,
or attach it to a bugzilla bug?

-- Eric

On Fri, Aug 18, 2017 at 10:01 AM, Eric Mill  wrote:

> Hi Jose,
>
> There was no attachment to your email. Would you mind re-sending with an
> attachment?
>
> On Fri, Aug 18, 2017 at 8:17 AM, Jose Manuel Torres via
> dev-security-policy  wrote:
>
>> Hello everyone,
>>
>> In response to the questions raised:
>>
>> AC FNMT Usuarios do not issue TLS / SSL certificates, as evidenced by the
>> attached document: Audit Attestation - ETSI Assestment 2017, FNMT CA's and
>> TSU's.
>>
>> Regarding anyExtendedKeyUsage EKU, since January 2017 it is no longer
>> incorporated into the certificates issued by AC FNMT Usuarios so it should
>> not be possible
>> to use it for TLS server authentication.
>>
>> In this sense the certificate indicated in this incident was issued prior
>> to the change indicated.
>>
>> Taking these considerations into account, FNMT considers that a revocation
>> of the intermediate CA by OneCRL is not necessary.
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
>
> --
> konklone.com | @konklone 
>



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

Re: AC FNMT Usuarios and anyExtendedKeyUsage

[Kurt Roeckx via dev-security-policy]

On 2017-08-18 16:01, Eric Mill wrote:

Hi Jose,

There was no attachment to your email. Would you mind re-sending with an
attachment?


Attachments never make it to the list.


Kurt

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

Re: AC FNMT Usuarios and anyExtendedKeyUsage

[Eric Mill via dev-security-policy]

Hi Jose,

There was no attachment to your email. Would you mind re-sending with an
attachment?

On Fri, Aug 18, 2017 at 8:17 AM, Jose Manuel Torres via dev-security-policy
 wrote:

> Hello everyone,
>
> In response to the questions raised:
>
> AC FNMT Usuarios do not issue TLS / SSL certificates, as evidenced by the
> attached document: Audit Attestation - ETSI Assestment 2017, FNMT CA's and
> TSU's.
>
> Regarding anyExtendedKeyUsage EKU, since January 2017 it is no longer
> incorporated into the certificates issued by AC FNMT Usuarios so it should
> not be possible
> to use it for TLS server authentication.
>
> In this sense the certificate indicated in this incident was issued prior
> to the change indicated.
>
> Taking these considerations into account, FNMT considers that a revocation
> of the intermediate CA by OneCRL is not necessary.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



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

Re: O=U.S. Government for non-USG entity (IdenTrust)

[Jeremy Rowley via dev-security-policy]

Right, but can you call these SSL certs without an FQDN?


  *   Insofar as the Baseline Requirements attempt to define their own scope, 
the scope of this policy (section 1.1) overrides that. Mozilla thus requires CA 
operations relating to issuance of all SSL certificates in the scope of this 
policy to conform to the Baseline Requirements.

Is SSL certificate defined?

On Aug 18, 2017, at 7:33 AM, Gervase Markham 
> wrote:

On 17/08/17 20:31, Jeremy Rowley wrote:
Without an FQDN, I doubt they are in scope for the baseline requirements.

Not according to the BRs themselves. However, the Mozilla Policy 2.5
specifically says:

"Insofar as the Baseline Requirements attempt to define their own scope,
the scope of this policy (section 1.1) overrides that. Mozilla thus
requires CA operations relating to issuance of all SSL certificates in
the scope of this policy to conform to the Baseline Requirements."

Now, whether we are right to include anyEKU in scope, given that it
pulls in certs such as those in question, is still something I am unsure
about :-) But the current policy says what it says.

They are in scope for the Mozilla policy. The BRs require the cert to
be intended for web tls. These are not.

But the Mozilla Policy re-scopes the BRs to remove the ambiguous
language about "intent".

The Mozilla policy covers client certs as well as tls.

Er, no it doesn't (except insofar as we make anyEKU in scope)? Our
policy covers server certs and email certs.

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

Re: Responding to a misissuance

[Gervase Markham via dev-security-policy]

On 18/08/17 13:03, Doug Beattie wrote:
> And if there is any guidance on processing misissuance reports for
> Name constrained sub-CA vs. not name constrained, that would be
> helpful also.

What parts of a response do you think might be different for
name-constrained sub-CAs?

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

Re: Responding to a misissuance

[Gervase Markham via dev-security-policy]

Hi Rich,

On 18/08/17 12:51, richmoor...@gmail.com wrote:
> Perhaps some explicit statements about sub-CAs would be helpful -
> detailing where responsibility lies and how a CA is required to deal
> with a sub-CA who is found to have misissued.

Do you specifically mean sub-CAs which are run by someone other than the
CA (and so have their own audits etc.)?

Good idea. What do you think we should say? :-)

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

Re: Bugzilla Bugs re CA issuance of non-compliant certs

[Gervase Markham via dev-security-policy]

On 17/08/17 00:18, Kathleen Wilson wrote:
> == Let’s Encrypt == 
> RESOLVED (no bug needed)

> == Staat der Nederlandend / PKIoverheid ==
> RESOLVED (no bug needed)

While the timely responses and performance of these CAs is commendable,
it may be worth opening a bug and recording the events and the outcome,
so that our bug database remains the canonical source of information
regarding misissuances that Mozilla knows about.

Kathleen: If your bug-filing fingers are not yet entirely worn out,
could they stretch to two more? :-)

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

Re: O=U.S. Government for non-USG entity (IdenTrust)

[Gervase Markham via dev-security-policy]

On 17/08/17 20:31, Jeremy Rowley wrote:
> Without an FQDN, I doubt they are in scope for the baseline requirements. 

Not according to the BRs themselves. However, the Mozilla Policy 2.5
specifically says:

"Insofar as the Baseline Requirements attempt to define their own scope,
the scope of this policy (section 1.1) overrides that. Mozilla thus
requires CA operations relating to issuance of all SSL certificates in
the scope of this policy to conform to the Baseline Requirements."

Now, whether we are right to include anyEKU in scope, given that it
pulls in certs such as those in question, is still something I am unsure
about :-) But the current policy says what it says.

> They are in scope for the Mozilla policy. The BRs require the cert to 
> be intended for web tls. These are not. 

But the Mozilla Policy re-scopes the BRs to remove the ambiguous
language about "intent".

> The Mozilla policy covers client certs as well as tls.

Er, no it doesn't (except insofar as we make anyEKU in scope)? Our
policy covers server certs and email certs.

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

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Gervase Markham via dev-security-policy]

On 15/08/17 16:53, Ben Wilson wrote:
> Attached is an audit from 2016.  They are due for another one for 2017.

Attachments don't appear on this list, but I have the docs. Please email
me if you'd like them. I've asked Ben to update CCADB to point to them,
and to also update any other entries where it is written "available on
request". That is not a valid value for that field.

Gerv

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

Re: Mensaje privado sobre: Miss-issuance: URI in dNSName SAN

[Jonathan Rudenberg via dev-security-policy]

+mdsp

> On Aug 18, 2017, at 05:56, ramirommu...@gmail.com wrote:
> 
> Hi Jonathan
> You are right, we are going to look into this, taken into account that the 
> same serial number should be in the real certificate.
> 
> Regards
> 
> El jueves, 17 de agosto de 2017, 19:54:31 (UTC+2), Jonathan Rudenberg 
> escribió:
>> 
>> 
>> > On Aug 17, 2017, at 07:19, ramirommunoz--- via dev-security-policy 
>> >  wrote: 
>> > 
>> > https://crt.sh/?id=112929021=cablint 
>> > is a precertificate. You can see the CT Precertificate Poison critical 
>> > extention. 
>> 
>> The serial number of this certificate should still be added to the relevant 
>> CRL, as it is not possible to prove the non-existance of a corresponding 
>> certificate without the CT Poison extension. 
>> 
>> Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: AC FNMT Usuarios and anyExtendedKeyUsage

[Jose Manuel Torres via dev-security-policy]

Hello everyone,

In response to the questions raised:

AC FNMT Usuarios do not issue TLS / SSL certificates, as evidenced by the
attached document: Audit Attestation - ETSI Assestment 2017, FNMT CA's and
TSU's.

Regarding anyExtendedKeyUsage EKU, since January 2017 it is no longer
incorporated into the certificates issued by AC FNMT Usuarios so it should
not be possible
to use it for TLS server authentication.

In this sense the certificate indicated in this incident was issued prior
to the change indicated.

Taking these considerations into account, FNMT considers that a revocation
of the intermediate CA by OneCRL is not necessary.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Responding to a misissuance

[Doug Beattie via dev-security-policy]

And if there is any guidance on processing misissuance reports for Name 
constrained sub-CA vs. not name constrained, that would be helpful also.

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> richmoore44--- via dev-security-policy
> Sent: Friday, August 18, 2017 7:51 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Responding to a misissuance
> 
> Perhaps some explicit statements about sub-CAs would be helpful - detailing
> where responsibility lies and how a CA is required to deal with a sub-CA who
> is found to have misissued.
> ___
> 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-security-policy

Re: Responding to a misissuance

[richmoore44--- via dev-security-policy]

Perhaps some explicit statements about sub-CAs would be helpful - detailing 
where responsibility lies and how a CA is required to deal with a sub-CA who is 
found to have misissued.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Responding to a misissuance

[Gervase Markham via dev-security-policy]

I've started a wiki page giving Mozilla expectations and best practices
for CAs responding to a misissuance report. (No idea why I decided to
write that now...)

https://wiki.mozilla.org/CA/Responding_To_A_Misissuance

Comments on whether the content is correct, and what might be missing,
are most welcome.

The idea might be for us (or anyone else, for that matter) to send a
link to this document to CAs along with any misissuance reports.

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

Re: Certificates with less than 64 bits of entropy

[Ryan Sleevi via dev-security-policy]

On Fri, Aug 18, 2017 at 1:34 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Since QuoVadis has not yet responded, let me point to a few (partial)
> answers already known from previous messages from QuoVadis or others:


I believe it would be far more productive for this community if you allow
CAs to respond rather than attempting to speak for them. While I recognize
your desire to help, your replies unfortunately tend to introduce more
confusion and new issues. While not wanting to discourage participation on
this list, some discussions on this list are transparent and public
discussions between CAs and Root Stores, and thus your involvement is
neither beneficial nor necessary. Please allow CAs to answer for themselves.

In this case, for example, you do not actually reference any answers, as
you suggest you have, because these matters have not been answered.

I appreciate your enthusiasm on this topic, and for participation, but as
your replies attempt to speak for either CAs or root stores, they
unfortunately introduce significant harm and confusion. As I am sure you
intend to make productive contributions, it may be best in such cases to
simply observe and ask questions to better understand things, rather than
attempt to provide answers on behalf of others. This applies both on-list
and in bugs.

Thank you for your interest in learning more about these topics, and
hopefully these requests will lead to more productive discussions. As this
transparency is a valuable benefit to the community, it would be truly
unfortunate if such attempts to assist were to undermine and harm such
discussions and result in removing that transparency in order to ensure
that only the authorized representatives were responding.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy