RE: [EXT] Re: DigiCert-Symantec Announcement

[Steve Medin via dev-security-policy]

We are not making any changes at this time.

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Adrian R. via dev-security-policy
> Sent: Friday, September 01, 2017 4:09 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Re: DigiCert-Symantec Announcement
>
> a small question:
> what's going to happen with [freessl.com]
>
> under Symantec's leadership it was intended for the site to become a free
> alternative to StartCom and LetsEncrypt, but it was not quite opened for
> issuance except for non-profits.
>
> Now with the transition of the CA activities to DigiCert i haven't seen
> anything about it, not even the site blog over there says anything about it.
> https://www.freessl.com/freessl/blog/
>
> Any news about it?
>
> Thanks,
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
___
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 31, 2017 at 11:31:48 PM UTC-4, Eric Mill wrote:
> Thank you for the continued updates, and for relaying the deadline by which
> these will be revoked.
> 
> On Thu, Aug 31, 2017 at 9:35 PM, identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On Monday, August 28, 2017 at 3:28:01 PM UTC-4, iden...@gmail.com wrote:
> > > On Friday, August 18, 2017 at 7:22:06 PM UTC-4, iden...@gmail.com wrote:
> > > > 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 <
> > dev-security-policy@lists.mozilla.org> 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.
> > >
> > > Effective August 28, 2017, IdenTrust has discontinued new issuance or
> > reissuance of human certificates with the anyExtendedKeyUsage extension
> > from all IdenTrust ACES CAs.
> >
> >
> > IdenTrust continues to work our customers in revoking/replacing ACES SSL
> > certificates with these reported issues:
> > - https for OCSP validation instead of http in AIA extension;
> > - Invalid “US Government” as o= in the SDN;
> > - Invalid OtherName in the SAN extension.
> > For those customers that have not replaced their certificates by September
> > 15, 2017, we will revoke their them.
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> 
> 
> 
> -- 
> konklone.com | @konklone 

Effective Aug-31-2017 at 7:00PM MT, IdenTrust have revoked the remaining ACES 
SSL certificates with the issues reported. As of today September 1st. 2017, the 
remediation process is completed.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Idea for a stricter name constraint interpretation

[Ryan Sleevi via dev-security-policy]

On Fri, Sep 1, 2017 at 2:07 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> RFC2818 postdates real world https by several years.  The original de
> facto standard by Netscape/Mozilla used the commonName semantics, which
> survived for more than a decade in commonly used software (GNU wget
> added SAN support sometime in 2011 for example).


Respectfully, you're conflating two different things.

You're suggesting support for _only_ common names versus support for
subjectAltNames.

You are correct to highlight the publication of 2818 happened in 2000, with
work beginning in 98. However, you're not correct to suggest the SAN wasn't
supported in the original implementations.

You are also correct to highlight some implementations ignored 2818 and/or
didn't implement support for SAN. However, I don't believe that distinction
is relevant to your underlying discussion of nameConstraints or their
applicability, no more than a discussion of macOS's lack of support until
macOS 10.9 (if memory serves correctly)

I realize we're ratholing on trivia here, and perhaps that was a goal, but
I think it's important to note that your original statement of fact was
inaccurate, and has remained inaccurate, and to the extent that mistatement
affects the subsequent design, bears highlighting. The application of
nameConstraints to subjectAltName has been aligned, and the use of
subjectAltName in preference to commonName has been documented for a
considerable amount of time. The application of dNSName nameConstraints to
commonNames is, while a note of historical practice for a small number of
(widely deployed) clients, is equally not necessary as same clients move
towards the deprecation or removal of commonName support.

That is, put differently, if we're talking about how systems will/should
change, I would argue that it's not relevant to argue how systems
previously changed, because the only thing that matters is what _new_
changes will be implemented. You can see this in my explanation about why
changing the semantics of nameConstraints (without any other signal) is a
fundamentally flawed and problematic idea, and you can see this in a
discussion about why constraining commonNames (when new clients don't,
won't, or shouldn't support commonNames) is equally a flawed and
problematic idea.


> So, from the get-go with the standards, it was possible to name constrain
>> DNS. Unless you were referencing certificates prior to them being bound to
>> domain names, but I can't see how that would be relevant, since the
>> context
>> is about DNS names.
>>
>>
> Point was that RFC2818 (and RFC2459 which it references for SAN usage)
> changed the established interpretation of WebPKI certificates from the
> established Mozilla standard.  And that this is an obvious precedent to
> making such changes.
>

I'm sorry, this is simply factually false.


> The primary problem is the need to not weaken security for code that
> starts looking at new (or previously unused) name types after existing
> PKI restricted CAs have (obviously) not mentioned the "new" type(s) as
> "deny all" entries in their name restrictions.
>
> The secondary problem is not to burden such restricted CAs with
> additional audit or other compliance requirements when such "new" name
> types are added to standards such as the CAB/F BRs and the Mozilla root
> program polices.


I gave multiple suggestions on how to avoid both of those.


> Indeed, I am just trying to see those very requirements from the
> perspective of the already deployed PKI and its subscribers being the
> "existing users" for which interop needs to be ensured.


Unfortunately, I do not believe you are succeeding in doing so through
proposing semantic changes.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violations of Baseline Requirements 4.9.10

[Policy Authority PKIoverheid via dev-security-policy]

> Government of The Netherlands, PKIoverheid (Logius)
> 
> DN: C=NL, O=KPN Corporate Market BV, CN=KPN Corporate Market CSP
> Organisatie CA - G2
> Example cert:
> https://crt.sh/?q=f821a600af00d2fa23f569e00fdf2379bc182920205a6b9b0276733cb2857c15
> OCSP URI: http://ocsp2.managedpki.com

Dear community,

My apologies for the delayed response. The last few days we’ve been in close 
contact with our TSP KPN to identify and remedy this issue. I can confirm that 
a fix for this issue has been deployed yesterday and that the OCSP responder 
(OCSP2) in question now responds as expected to these kind of requests. 

As to Nick’s question about how we and the auditor missed this: KPN switched to 
another OCSP responder (OCSP3) when BR requirement 4.9.10 became effective. 
Around that time KPN deployed a software update regarding OCSP2 which was 
necessary so this responder would also comply with BR requirement 4.9.10. 
Although the software upgrade took place, the configuration change to the OCSP2 
responder was somehow never executed. Nevertheless, all TLS certificates issued 
after 10/25/2013 should be directing users to OCSP3. That responder was and is 
compliant with BR 4.9.10 from the effective date. 

Today we have published a new requirement for our PKIoverheid TSPs regarding 
audit criteria and scoping. See bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1391864 Result of this new 
requirement should be that ALL BR requirements are in scope of the audit 
including a technical requirement like BR 4.9.10.

Furthermore, we have formulated a plan to prevent future issues like these, 
which involves active monitoring of the OCSP responses. Not only because of 
uptime requirements (that was already monitored), but also input/output 
validation to confirm OCSP responders are behaving like it should. Said 
mechanism would probably take the form of a fixed interval query which results 
would be reported by email to us and (possibly) the sub CA from the PKIoverheid 
TSP in question. This new measure will be effective no later than 10/1/2017.  

Please let me know if you have any questions. 

Best regards,
Mark Janssen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violations of Baseline Requirements 4.9.10

[Policy Authority PKIoverheid via dev-security-policy]

> Government of The Netherlands, PKIoverheid (Logius)
 
> DN: C=NL, O=KPN Corporate Market BV, CN=KPN Corporate Market CSP
> Organisatie CA - G2
> Example cert:
> https://crt.sh/?q=f821a600af00d2fa23f569e00fdf2379bc182920205a6b9b0276733cb2857c15
> OCSP URI: http://ocsp2.managedpki.com

Dear community,

My apologies for the delayed response. The last few days we’ve been in close 
contact with our TSP KPN to identify and remedy this issue. I can confirm that 
a fix for this issue has been deployed yesterday and that the OCSP responder 
(OCSP2) in question now responds as expected to these kind of requests. 

As to Nick’s question about how we and the auditor missed this: KPN switched to 
another OCSP responder (OCSP3) when BR requirement 4.9.10 became effective. 
Around that time KPN deployed a software update regarding OCSP2 which was 
necessary so this responder would also comply with BR requirement 4.9.10. 
Although the software upgrade took place, the configuration change to the OCSP2 
responder was somehow never executed. Nevertheless, all TLS certificates issued 
after 10/25/2013 should be directing users to OCSP3. That responder was and is 
compliant with BR 4.9.10 from the effective date. 

Today we have published a new requirement for PKIoverheid TSPs regarding audit 
criteria and scoping. See bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1391864 Result of this new 
requirement should be that ALL BR requirements are in scope of the audit 
including a technical requirement like BR 4.9.10.

Furthermore, we have formulated a plan to prevent future issues like these, 
which involves active monitoring of the OCSP responses. Not only because of 
uptime requirements (that was already monitored), but also input/output 
validation to confirm OCSP responders are behaving like it should. Said 
mechanism would probably take the form of a fixed interval query which results 
would be reported by email to us. This new measure will be effective no later 
than 10/1/2017.  

Please let me know if you have any questions. 

Best regards,
Mark Janssen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Per-intermediate CAA/problem reporting info

[Gervase Markham via dev-security-policy]

On 28/08/17 18:40, Andrew Ayer wrote:
> However, externally-operated sub-CAs generally have their own CAA
> identifiers and problem reporting information, and this information
> is not currently collected.  Would it be possible to collect this
> information on a per-intermediate basis and to publish it in
> the intermediate CA report[2]?  There could also be "same as parent"
> option, as with CPS/audit information.

This seems to make sense to me. I will investigate whether this might be
possible. It seems like having this information centrally collected is
proving useful to people.

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

Re: Remove old WoSign root certs from NSS

[Gervase Markham via dev-security-policy]

On 30/08/17 18:50, Kathleen Wilson wrote:
> https://blog.mozilla.org/security/2017/08/30/removing-disabled-wosign-startcom-certificates-firefox-58/
> 
> I will look into getting this translated and published in China.

Here are the links to the post in Chinese, kindly supplied by our
colleagues:

http://mozilla.com.cn/thread-389981-1-1.html

http://www.toutiao.com/i6460694823383876110/

http://weibo.com/1663337394/FjOcBkk6e?type=repost#_rnd1504260080825

https://mp.weixin.qq.com/s?__biz=MTc0MDM5MjUwMQ===2651082547=1=ca6759cd7a0a035028579e7705b59e6f=547350696304d97fad4eaab40cf1d933f794525e358afc6ae40bcc1c47ff6e3007c407e0ccf0#rd

Gerv


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

Re: Adding a subCA to OneCRL when email-signing users may be impacted

[Gervase Markham via dev-security-policy]

On 01/09/17 04:47, Víctor wrote:
> But I find an issue here. The root has both websites and email trust
> bits. The subCA cert is not constrained. The representative of the CA
> want to add the subCA to OneCRL because this subCA doesn't issue TLS
> certificates. OneCRL and the CA program acts on both Firefox (if
> websites trust bit enabled) and Thunderbird (if email trust bit
> enabled). 

I don't believe Thunderbird checks OneCRL, although someone may wish to
contradict me.

> - Should CAs that ONLY have the websites trust bit get all its subCAs
> -that do not issue TLS certificates and the intermediate certificate
> is not technologically constrained- added to OneCRL just for
> prevention? Should this become mandatory?

SubCAs which are technically capable of issuing TLS certificates,
whether the CA intends for them to do so or not, need to either be
name-constrained or need to be publicly disclosed and audited. If
neither of those things is possible, we might add it to OneCRL, but this
should not be seen as a simple and first-choice solution. Better is to
make subCAs which are not intended for TLS certificates, not technically
capable of issuing them in the first place.

Gerv

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

RE: Violations of Baseline Requirements 4.9.10

[加毛 寿 via dev-security-policy]

※個人情報保護のため、宛先を非表示（ＢＣＣ）にて送信しています。
-

Paul-san,

Thank you for the notice.
We are going to investigate on this matter.

Best regards,
Hisashi Kamo
Secom Trust Systems

> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+h-kamo=secom.co...@lists.mozilla.org] On 
> Behalf Of Paul Kehrer
> via dev-security-policy
> Sent: Thursday, August 31, 2017 10:02 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Violations of Baseline Requirements 4.9.10
> 
> I have updated the list below to try to capture all the information provided 
> in this thread about which responders have been
> fixed (and verified using another random serial number), which ones have a 
> date, and removed the ones that are actually under
> technical constraint that I missed.
> 
> I have received several responses from CAs that were CC'd informing me that 
> they are investigating but until the issues are
> resolved or I have a date for resolution I have not noted those 
> communications below.
> 
> 
> AS Sertifitseerimiskeskuse (SK)
> 
> CCADB does not list an email address. Not CC'd.
> 
> DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, 
> emailAddress=p...@sk.ee Example cert:
> https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f
> OCSP URI: http://ocsp.sk.ee/CA
> 
> Autoridad de Certificacion Firmaprofesional
> 
> Email sent to i...@firmaprofesional.com
> 
> DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068 
> Example cert:
> https://crt.sh/?q=cd74198d4c23e4701dea579892321b9e4f47a08bd8374710b899aad1495a4b35
> OCSP URI: http://ocsp.firmaprofesional.com
> 
> DN: C=ES, emailAddress=c...@firmaprofesional.com, L=C/ Muntaner 244 
> Barcelona, OU=Consulte http://www.firmaprofesional.com,
> OU=Jerarquia de Certificacion Firmaprofesional, O=Firmaprofesional S.A. NIF 
> A-62634068, CN=AC Firmaprofesional - CA1 Example
> cert:
> https://crt.sh/?q=649d5190f9fff58de60313c2f0598393f9dba05368b1dbfe93ec806015fb8796
> OCSP URI: http://ocsp.firmaprofesional.com
> 
> DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la 
> Administracion Publica, serialNumber=A62634068, CN=AC
> Firmaprofesional - AAPP Example cert:
> https://crt.sh/?q=d4ef928ee32c3838d40e5756b523829b1dafcd46fd84428ba03d59330a4ae5e7
> OCSP URI: http://ocsp.firmaprofesional.com
> 
> CA Disig a.s.
> 
> Email sent to tspnot...@disig.sk
> 
> DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service 
> Example cert:
> https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2
> OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1
> 
> DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service 
> Example cert:
> https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417
> OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2
> 
> DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1 Example cert:
> https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947
> OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1
> 
> DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2 Example cert:
> https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341
> OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2
> 
> certSIGN
> 
> Email sent to off...@certsign.ro
> 
> DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN 
> Enterprise CA Class 3 G2 Example cert:
> https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1b0bf266fa205a140b1bc1d340ff4ff6355
> OCSP URI: http://ocsp.certsign.ro
> Notes: This is fixed as of 2017-08-31
> 
> DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA Example cert:
> https://crt.sh/?q=3003bf8853427c7b91023f7539853d987c58dc4e11bbe047d2a9305c01a6152c
> OCSP URI: http://ocsp.certsign.ro
> Notes: Per Cristian Garabet this will be resolved 2017-09-15
> 
> Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert)
> 
> CCADB does not list an email address. Not CC'd.
> 
> DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de 
> la Concepcio 11 08008 Barcelona, OU=Serveis Publics
> de Certificacio ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2  (c)03, 
> OU=Administracions Locals de Catalunya, CN=EC-AL
> Example cert:
> https://crt.sh/?q=88f6298c5a8cc66cefb8ea214a528c3efce36a26213fe4fd260613967d39e7d4
> OCSP URI: http://ocsp.catcert.net
> 
> DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de 
> la Concepcio 11 08008 Barcelona, OU=Serveis Publics
> de Certificacio ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2  (c)03, 
> OU=Administracions Locals de Catalunya, CN=EC-AL
> Example cert:
> https://crt.sh/?q=1869a83f83b8f034336ab09fe52563c00c80c4b45897b3ea15e658fd14306208
> OCSP URI: http://ocsp.catcert.net
> 
> DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de 

Adding a subCA to OneCRL when email-signing users may be impacted

[Víctor via dev-security-policy]

Hello everyone,

This is the first time I am writing here. I've been reading for a time (part) 
of this list and the Bugzilla section of the CA Program. I hope I can 
cooperate. I am specially interested on the technical aspects and legal 
implications that electronic certificates have on the EU, as laws are appearing 
and the public opinion are unaware of that.

Well, back to the issue, I've seen Bug 1394595 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1394595) where Firmaprofesional 
requests the addition of a subCA to OneCRL because the subCA is not technically 
constrained and, for prevention, wants to avoid any misissuance of TLS 
certificates. I congratulate Firmaprofesional for making this move in favor of 
transparency and tech security. This becomes after that FNMT got one subCA 
added to OneCRL because of the addition of anyExtendedKeyUsage to its personal 
certs 
(https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/Qo1ZNwlYKnY/UrAodnoQBwAJ).
 And a similar subCA is on the way of being added to OneCRL for prevention.

But I find an issue here. The root has both websites and email trust bits. The 
subCA cert is not constrained. The representative of the CA want to add the 
subCA to OneCRL because this subCA doesn't issue TLS certificates. OneCRL and 
the CA program acts on both Firefox (if websites trust bit enabled) and 
Thunderbird (if email trust bit enabled). If a subCA is added to OneCRL, all 
certs that chain up to it get untrusted -for both bits.

I am not quite sure how many people receive on their Thunderbird client emails 
signed with a personal electronic certificate, but I think we can agree that 
they are fewer than all Firefox users.

So, my questions are,

- Should CAs that ONLY have the websites trust bit get all its subCAs -that do 
not issue TLS certificates and the intermediate certificate is not 
technologically constrained- added to OneCRL just for prevention? Should this 
become mandatory?

- Should CAs that have BOTH trust bits get all its subCAs -that issue personal 
certificates but email-signing is not advertised to their consumers (e.g. the 
consumer gets the certificate to be able to do some bureaucratic procedures 
with the Government) and the intermediate certificate is not technologically 
constrained- added to OneCRL just for prevention? Should this become mandatory?

- Should CAs that have BOTH trust bits get all its subCAs -that issue 
certificates that are not TLS neither related to email signing and the 
intermediate certificate is not technologically constrained- added to OneCRL 
just for prevention? Should this become mandatory?

Greetings,
Víctor
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert-Symantec Announcement

[Adrian R. via dev-security-policy]

a small question:
what's going to happen with https://www.freessl.com/ ?

under Symantec's leadership it was intended for the site to become a free 
alternative to StartCom and LetsEncrypt, but it was not quite opened for 
issuance except for non-profits.

Now with the transition of the CA activities to DigiCert i haven't seen 
anything about it, not even the site blog over there says anything about it. 
https://www.freessl.com/freessl/blog/

Any news about it?

Thanks,

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

Re: Idea for a stricter name constraint interpretation

[Jakob Bohm via dev-security-policy]

On 01/09/2017 02:14, Ryan Sleevi wrote:

On Thu, Aug 31, 2017 at 5:21 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 31/08/2017 22:26, Ryan Sleevi wrote:


Agreed. But in general, in order to maintain interoperability, there's a
process for building consensus, and repurposing extensions as you propose
is generally detrimental to that :)



But sometimes necessary.



There is a tremendous burden of proof to demonstrate this, and it's the
path of last resort, not first.



Moving the information to a new extension would basically just bloat

certificates with more redundant data to be sent in every certificate
based protocol exchange.  But changing the original decision in a
backwards compatible manner may still be a good idea, either as a
"stricter security policy" or (better, if it works well in controlled
tests) as part of an update RFC for the IETF standard that specified the
original semantics.




I can understand your perspective, but I must disagree with you that it's
"backwards compatible". It isn't - it's a meaningful semantic change that
breaks interoperability.



I meant backwards compatible and interoperable with the actual real
world CAs (as opposed to all the CAs that could be built under the old
standard).  Compare to how the standard was changed from DNS name in the
CN element to DNS name exclusively in the SAN extension, but hopefully
with less transition time needed.



I believe this may be operating on an incomplete knowledge of history. RFC
2818 (aka the HTTPS RFC) always indicated commonName was deprecated (and
SAN was preferred), and nameConstraints have similarly always expressed a
path for constraining the nameConstraints.



RFC2818 postdates real world https by several years.  The original de
facto standard by Netscape/Mozilla used the commonName semantics, which
survived for more than a decade in commonly used software (GNU wget
added SAN support sometime in 2011 for example).


So, from the get-go with the standards, it was possible to name constrain
DNS. Unless you were referencing certificates prior to them being bound to
domain names, but I can't see how that would be relevant, since the context
is about DNS names.



Point was that RFC2818 (and RFC2459 which it references for SAN usage)
changed the established interpretation of WebPKI certificates from the
established Mozilla standard.  And that this is an obvious precedent to
making such changes.




Yes, it means that technically constrained sub-CA certificates may be

'bloated' in order to ensure the desired degree of security. That's a
trade-off for the compromises necessary to avoid audits. That's not,
however, an intrinsic argument against the process, or a suggestion it
cannot be deployed.



Avoiding audit failures is a legal, not a technical need.  Anything that
would only fail audits could be fixed by changing audit requirements, if
the organizations setting those (such a Mozilla and CAB/F) desires.



I didn't suggest avoiding audit failures, but rather, avoiding audits. That
is, the material difference between a TCSC and a CA is not one of technical
requirements (they're the same, effectively), but one of whether or not a
self-audit is seen as acceptable versus an independent third-party audit.

I highlight this because it makes the tradeoff something more concrete: An
organization that wishes to avoid the administrative hassle of an
independent audit could opt for a technically constrained sub-CA, which
would be "bloated" in your view. If they didn't want the bloat, they could
accept the administrative hassle of an independent third-party audit.

That is, there are options to satisfy an organizations needs, and allows
them to prioritize whether it's more important to have the size reduction
or to have organizational flexibility. There's no innate requirement to
allow both - and while that may be an optimization, is one that comes with
the compatibility and interoperability risks I highlighted, so it may not
actually be achievable in the world we have. But that's OK - organizations
and individuals routinely have to operate in the world we have and make
choices based on priorities, and we've made it so far :)






The interaction between a nameConstraints extension not specifying

directorynames and the directoryname in the Subject field would be an
area
needing careful specification, based on compatibility and historic
concerns.



Yes. Which would not be appropriate for m.d.s.p (for reasons of both
consensus and intellectual property). That is a concern for some members,
and is why organizations like W3C and groups such as WICG exist :)



Ok, I was simply hoping informal discussion in a place like m.d.s.p.
would be a better place to initial evaluate such an idea before starting
up the whole standardization process.



Fair enough. This makes a great venue for that, but certainly, as it shifts
to technical details, working through a process like WICG - in which