Re: Technically Constrained Sub-CAs

[Brian Smith]

Gervase Markham  wrote:

> RFC 6962bis (the new CT RFC) allows certs below technically-constrained
> sub-CAs (TCSCs) to be exempt from CT. This is to allow name privacy.
> TCSCs themselves are also currently exempt from disclosure to Mozilla in
> the Common CA Database.
>
> If this is the only privacy mechanism available for 6962bis,


First, here's the RFC 6969-bis draft:
https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-20#section-4.2.

Please see my other messages in this thread, where I pointed out that
Mozilla's own definition of externally-operated name-constrained sub-CAs
should be improved because name constraints don't mitigate every serious
concern one might have regarding technically-constrained sub-CAs. I think
that's clearly true for what RFC 6962-bis is trying to do with name
constraints too.

I think there might be ways to fix the name-constrained sub-CA stuff for
RFC 6962-bis, but those kinds of improvements are unlikely to happen in RFC
6962-bis itself, it seems. They will have to happen in an update to RFC
6962-bis.

I also disagree with Google's position that it is OK to leave bad stuff in
the spec and then ignore it. The WGLC has passed, but that doesn't mean
that the spec can't be changed. Google's already proposed a hugely
significant change to the spec in the last few days (which I support),
which demonstrates this.

Accordingly, I think the exception mechanism for name-constrained sub-CAs
(section 4.2) should be removed from the spec. This is especially the case
if there are no browsers who want to implement it. If the draft contains
things that clients won't implement, then that's an issue that's relevant
for the IETF last call, as that's against the general IETF philosophy of
requiring running code.

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

Re: Technically Constrained Sub-CAs

[Brian Smith]

Gervase Markham  wrote:

> On 18/11/16 01:43, Brian Smith wrote:
> > The fundamental problem is that web browsers accept certificates with
> > validity periods that are years long. If you want to have the agility to
> > fix things with an N month turnaround, reject certificates that are valid
> > for more than N months.
>
> That's all very well to say. The CAB Forum is deadlocked over a proposal
> to reduce the max validity of everything to 2 years + 3 months; some
> people like it because it removes a disadvantage of EV (which already
> has this limit), other's don't like it because people like not having to
> change their cert and are willing to pay for longer. Mozilla is in
> support, but without agreement, we can hardly implement unilaterally -
> the breakage would be vast.
>

Regardless, the main point of that message of mine was left out: You could
limit, in policy and in code, the acceptable lifetime of name-constrained
externally-operated sub-CAs and/or the end-entity certificates they issue
strictly, independently of whether it can be done for all certificates, and
doing so would be at least part of the solution to making name-constrained
externally-operated sub-CAs actually a viable alternative in the market.

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

Re: Technically Constrained Sub-CAs

[Gervase Markham]

On 18/11/16 14:28, Jeremy Rowley wrote:
> So much  has changed since the last time we discussed shorter
> validity periods at CAB forum that it'd be worth bringing up again. I
> think the vocal minority opposed the change last time and they may
> have switched positions by now.

I like your optimism :-) We can add it to the long list of issues to
discuss when we've at least established a timeline for fixing the IPR mess.

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

Re: Upcoming removals report

[Kathleen Wilson]

On Monday, November 14, 2016 at 10:00:31 AM UTC-8, Peter Bowen wrote:
> Is there a CSV version of the upcoming root removals report?
> https://mozillacaprogram.secure.force.com/CA/UpcomingRootRemovalsReport
> 
> Thanks,
> Peter


https://wiki.mozilla.org/CA:RemovedCAcerts
has these links:
Upcoming Root Cert Removals
CSV Format of Upcoming Root Cert Removals
CSV Format of Upcoming Root Cert Removals with PEM


Cheers,
Kathleen


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

Re: Technically Constrained Sub-CAs

[Jeremy Rowley]

So much  has changed since the last time we discussed shorter validity periods 
at CAB forum that it'd be worth bringing up again. I think the vocal minority 
opposed the change last time and they may have switched positions by now.

> On Nov 18, 2016, at 7:12 AM, Gervase Markham  wrote:
> 
>> On 18/11/16 01:43, Brian Smith wrote:
>> The fundamental problem is that web browsers accept certificates with
>> validity periods that are years long. If you want to have the agility to
>> fix things with an N month turnaround, reject certificates that are valid
>> for more than N months.
> 
> That's all very well to say. The CAB Forum is deadlocked over a proposal
> to reduce the max validity of everything to 2 years + 3 months; some
> people like it because it removes a disadvantage of EV (which already
> has this limit), other's don't like it because people like not having to
> change their cert and are willing to pay for longer. Mozilla is in
> support, but without agreement, we can hardly implement unilaterally -
> the breakage would be vast.
> 
> Gerv
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


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

Re: Technically Constrained Sub-CAs

[Gervase Markham]

On 18/11/16 01:43, Brian Smith wrote:
> The fundamental problem is that web browsers accept certificates with
> validity periods that are years long. If you want to have the agility to
> fix things with an N month turnaround, reject certificates that are valid
> for more than N months.

That's all very well to say. The CAB Forum is deadlocked over a proposal
to reduce the max validity of everything to 2 years + 3 months; some
people like it because it removes a disadvantage of EV (which already
has this limit), other's don't like it because people like not having to
change their cert and are willing to pay for longer. Mozilla is in
support, but without agreement, we can hardly implement unilaterally -
the breakage would be vast.

Gerv

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

Re: Technically Constrained Sub-CAs

[Gervase Markham]

On 18/11/16 00:28, Andrew Ayer wrote:
> I see the appeal of this.  However, I'm concerned that allowing
> leniency with name-constrained TCSCs will make it hard for Mozilla to
> make security improvements to its certificate validation in the
> future.  Improvements like rejecting SHA-1, 1024-bit RSA keys, and
> certificates valid for more than 39 months were only possible because
> CAs were first made to stop issuing these types of certificates.  If
> policies are not enforced on the issuance of certificates from TCSCs,
> how will Mozilla make these types of changes in the future without
> causing massive breakage?

Mozilla's policy certainly needs some sections to apply to every cert
issued under the roots in the store, and some sections which apply only
to server certs (BR-compliant; recognised by Firefox) or email certs. I
hope, before too long, to rearrange it in this way. It could then also
have requirements which only apply to non-TCSC-issued certs. The
question is, which rules which should in which category.

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

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Gervase Markham]

On 18/11/16 11:38, wangsn1...@gmail.com wrote:
> GDCA takes security and governance seriously and we have a strict
> control for Chinese version CP/CPS, all the contents are disclosed.
> And The Chinese versions for CPS 4.1, 4.2, 4.3 are published on the
> official website, so we cannot cover-up anything. There are three
> reasons for the confusion in the English versions: 


Thank you for this information. I accept these explanations. Once the
fully-translated documents are available, I think the inclusion request
should continue.

Gerv

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

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

在 2016年11月17日星期四 UTC+8下午7:20:05，Gervase Markham写道：
> Hi Kathleen,
> 
> On 15/11/16 00:51, Kathleen Wilson wrote:
> > There were some recommendations to deny this request due to the
> > versioning problems between the English documents and the original
> > documents.
> > 
> > Do you all still feel that is the proper answer to this root
> > inclusion request?
> 
> As I understand it, what happened was as follows:
> 
> * As part of their application, GDCA provided both Chinese and English
> versions of their CP/CPS, posted to m.d.s.policy on 3rd August:
> 
> Chinese CP: http://www.gdca.com.cn/cp/cp
> Chinese CPS: http://www.gdca.com.cn/cps/cps
> English CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
> English CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749
> 
> (I don't immediately have URLs for their EV CP and CPS in Chinese or
> English from the original submission.)
> 
> * On 26th September, it was pointed out by Andrew Whalley that the
> English versions had lower version numbers than the Chinese versions
> (CP: 1.2 vs. 1.4; CPS: 4.1 vs 4.3)
> 
> * On 27th September, one day later, GDCA provided new English versions
> with the same version numbers as the Chinese versions:
> 
> CP V1.4: https://bugzilla.mozilla.org/attachment.cgi?id=8795090
> CPS V4.3: https://bugzilla.mozilla.org/attachment.cgi?id=8795091
> EV CP V1.2: https://bugzilla.mozilla.org/attachment.cgi?id=8795093
> EV CPS V1.3: https://bugzilla.mozilla.org/attachment.cgi?id=8795094
> 
> * It was pointed out by more than one person that there were significant
> content differences between the English and Chinese versions which were
> both labelled with the same version number
> 
> * GDCA said this was due to a "poor CP/CPS English translation" and on
> 28th October, provided new English versions (again) with the same
> version numbers
> 
> CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
> CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8805545
> EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
> EV CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8805547
> 
> What Mozilla has to decide is whether this was incompetence or malice.
> Were GDCA trying to hide something? If so, their inclusion must be in
> doubt. If they were not trying to hide something and just need a lesson
> in version control, that is not necessarily something which
> disqualifies, although it does give one concern.
> 
> Looking at the CPS (using pdf2txt and diff), the differences between the
> originally-submitted v4.1 and the first 4.3 are very minor. One
> intermediate certificate changes name throughout, as does the name of
> GDCA. Three certs in an appendix are replaced with others. Other than
> that, the only changes are these:
> 
> https://gist.github.com/gerv/fc311785c49c7fdfdfba78d6d5ad4aa9
> 
> This seems like an odd change, removing specificity about how domain
> validation is done. This change was _added_ to the Chinese version of
> 3.2.5 between 4.1 and 4.2, and moved to section 3.2.7 in version 4.3. So
> how does going from 4.1 to 4.3 in the English version lead to it being
> removed?

On 2015.8.20, we uploaded the English Version 4.1 to bugzilla for the first 
time, and section 3.2.5 was translated from the Chinese version CPS 4.1. 
On 2015.10.22, Kathleen pointed out that section 3.2.5 " Domain name 
recognition and identification" could not meet the requirements of Mozilla. 
Therefore, on 2015.11.17, we submitted a new English Version 4.1 with modified 
section 3.2.5. 
However, due to the negligence of our employee, the submitted English Version 
4.3 on 2016.9.26 was revised based on the English version 4.1 of 2015.8.20. 
In the submitted English Version 4.3 on 2016.10.28, this mistake was found and 
solved.
For the question that "the Chinese version of 3.2.5 between 4.1 and 4.2 moved 
to section 3.2.7 in version 4.3", this is because we added section 3.2.5 " 
Authentication of SSL Server Identity" and section 3.2.6 " Authentication of 
CodeSigning Identity". Accordingly, the former 3.2.5 changes into 3.2.7.

> 
> The differences between the first 4.3 and the second one are much more
> extensive.
> 
> So I'd say the questions for GDCA are these:
> 
> * When you were asked to produce a version of your CPS matching Chinese
> version 4.3, within a day you came up with:
> https://bugzilla.mozilla.org/attachment.cgi?id=8795091
> That clearly doesn't match Chinese version 4.3, and yet it has "version
> 4.3" written in it. And the effective date marked within it is one month
> _earlier_ than the effective date of the Chinese 4.3. How did this
> happen? How did such a document come to exist with such a version number
> and date attached, when it is so massively different from the real 4.3,
> and so similar to the previous 4.1?
> 
> * You say you only translated the relevant bits rather than all of it,
> which is why there is a discrepancy, but the diff between 4.1 and the
> first version of 4.3 reveals no additions,