Re: TURKTRUST Non-compliance

2018-03-16 Thread Eric Mill via dev-security-policy 
In TurkTrust's 2016 email noting that they were suspending their TLS
certificate business, they noted it stemmed mainly from not being accepted
to all major root stores (Apple did not accept them).

Therefore, the sites using these certificates are not trusted by some major
client bases, which is likely why some of the few existing sites that have
TurkTrust certificates, such as http://www.enpos.com.tr and
http://www.turktrust.com.tr/tr/, do not redirect clients to HTTPS. This
lack of reliance on using the certificates for HTTPS reduces the impact to
Mozilla's users of suspending trust in the remaining certificates.

Even if this were not the case, I would agree and recommend prompt removal
of this explicitly unmaintained, unaudited hierarchy to protect Mozilla's
users. The above only makes it even more obviously the right decision.

-- Eric

On Fri, Mar 16, 2018 at 8:23 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> TURKTRUST has the "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5"
> root included in the Mozilla program with the 'websites' trust bit enabled
> (not EV). Crt.sh identifies one unexpired and unrevoked subordinate CA [1],
> and 13 unexpired end-entity certificates signed by this root [2]. The
> audits for this root are either already expired (based on audit date) or
> nearly expired (based on the ETSI certificate expiration date) [3] [4].
>
> TURKTRUST announced the suspension of their SSL business in 2016 [5].
>
> TURKTRUST failed to respond to the January 2018 CA Communication. After
> repeated attempts, they did respond to my emails and posted a statement in
> the bug [6] including the following:
>
> The strategic decision mentioned above is actually suspending all SSL
> > business supporting activities that incur direct costs for TURKTRUST,
> > including suspending the ETSI and BR audits or OV and EV SSL related
> > insurance policies. We have also ceased our investment and studies on CT
> > and CAA requirements for the time being that are actually mandatory
> > criteria set by the CA/Browser Forum.
> >
>
> TURKTRUST has chosen not to request removal of the root, but I believe this
> is a clear case in which prompt removal of the root is necessary.
>
> I would appreciate everyone's constructive input on what action should be
> taken.
>
> - Wayne
>
> [1] https://crt.sh/?Identity=%25=5766=expired
> [2] https://crt.sh/?Identity=%25=5767=expired
> 
> [3] https://bug1332435.bmoattachments.org/attachment.cgi?id=8828490
> [4]
> https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/6749UE_s.pdf
> 
> [5] https://cabforum.org/pipermail/public/2016-September/008475.html
> 
> [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1439127
> ___
> 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

TURKTRUST Non-compliance

2018-03-16 Thread Wayne Thayer via dev-security-policy 
TURKTRUST has the "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5"
root included in the Mozilla program with the 'websites' trust bit enabled
(not EV). Crt.sh identifies one unexpired and unrevoked subordinate CA [1],
and 13 unexpired end-entity certificates signed by this root [2]. The
audits for this root are either already expired (based on audit date) or
nearly expired (based on the ETSI certificate expiration date) [3] [4].

TURKTRUST announced the suspension of their SSL business in 2016 [5].

TURKTRUST failed to respond to the January 2018 CA Communication. After
repeated attempts, they did respond to my emails and posted a statement in
the bug [6] including the following:

The strategic decision mentioned above is actually suspending all SSL
> business supporting activities that incur direct costs for TURKTRUST,
> including suspending the ETSI and BR audits or OV and EV SSL related
> insurance policies. We have also ceased our investment and studies on CT
> and CAA requirements for the time being that are actually mandatory
> criteria set by the CA/Browser Forum.
>

TURKTRUST has chosen not to request removal of the root, but I believe this
is a clear case in which prompt removal of the root is necessary.

I would appreciate everyone's constructive input on what action should be
taken.

- Wayne

[1] https://crt.sh/?Identity=%25=5766=expired
[2] https://crt.sh/?Identity=%25=5767=expired

[3] https://bug1332435.bmoattachments.org/attachment.cgi?id=8828490
[4]
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/6749UE_s.pdf

[5] https://cabforum.org/pipermail/public/2016-September/008475.html

[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1439127
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

2018-03-16 Thread József Szilágyi via dev-security-policy 
Please put also this certificate on that list:
https://crt.sh/?id=181538497=cablint,x509lint

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

Logius PKIoverheid response to Action #2 in the January 2018 CA Communication

2018-03-16 Thread Berge, J. van den (Jochem) - Logius via dev-security-policy 
Dear MSDP community,

As requested by Mozilla in the CA Communication survey we've reviewed our 
implementation of BR 3.2.2.4.1 and 3.2.2.4.5. PKIoverheid only issues OV/EV 
certificates to subscribers for which the applicant representative has to have 
had a face-to-face check to confirm the identity of the representative 
(regardless of which method from 3.2.2.4 is used). The applicant 
representatives are defined beforehand by the applicant (authority is granted 
by a managing director, who's authority is checked against the national trade 
register). The issuing TSPs all use a secured environment in which the 
subscriber can order certificates. PKIoverheid certificates are mainly issued 
to Dutch subscribers. The Dutch Chamber of Commerce (de facto the national 
agency as referred in BR 3.2.2.1) only allows unique organization names, and as 
mentioned before, the TSP has a complete file of the applicant and it 
representative(s). In case that there is doubt about the authority of the 
applicant (whether us
 ing method 3.2.2.4.1 or 3.2.2.4.5), another method from 3.2.2.4 is used 
instead. Therefore, the scenario as described earlier on the web (for instance, 
the Stripe, Inc. case) is, in our eyes, very unlikely. However, the PKIoverheid 
TSPs are now moving away from these methods per ballot 218.

Please let me know if you have any questions.


Kind regards,

Jochem van den Berge

Logius PKIoverheid
Public Key Infrastructure for the Dutch government

Logius
Ministry of the Interior and Kingdom Relations (BZK)
Wilhelmina van Pruisenweg 52 | 2595 AN | The Hague
PO Box 96810 | 2509 JE | The Hague

jochem.vanden.be...@logius.nl
http://www.logius.nl

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet 
de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u 
verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat 
aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband 
houdt met risico's verbonden aan het elektronisch verzenden van berichten.
This message may contain information that is not intended for you. If you are 
not the addressee or if this message was sent to you by mistake, you are 
requested to inform the sender and delete the message. The State accepts no 
liability for damage of any kind resulting from the risks inherent in the 
electronic transmission of messages.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mis-issuance of certificate with https in CN/SAN

2018-03-16 Thread Rob Stradling via dev-security-policy 

On 16/03/18 05:17, Jakob Bohm via dev-security-policy wrote:


Please see https://crt.sh/?id=353098570=cablint



Note: This is the CT precertificate.

Note 2: According to crt.sh, the OCSP response for this precertificate
is not correct.  (error message: "OCSP response contains bad number of
certificates").


The crt.sh feature relies on Go's crypto/ocsp library, which currently 
"is just a bit limited and doesn't have support for more complex 
responses" [1].


It's not "incorrect" for an OCSP response to contain superfluous CA 
certificates.  However, it is suboptimal (in terms of bytes on the wire).



[1] https://github.com/golang/go/issues/21527

--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com

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