Re: ComSign Root Renewal Request

[Peter Bowen]

Peter,

I obviously do not represent ComSign, but several of the items in your list
are not really specific to the CPS and instead are more comments on the
Mozilla policies.

On Fri, Jan 29, 2016 at 4:24 PM, Peter Kurrasch  wrote:

> * There is a BR from CABF that covers code signing. I must admit I don't
> know the status of it but this CPS should at least acknowledge it and say
> if ComSign will adhere to it.
>

There is not a BR from the CA/Browser Forum.  A subset of the members of
the CABF drafted a BR, but it failed to be adopted as a Forum Guideline
when brought to a vote of the whole Forum.  Concerns were raised on several
fronts, including some specific requirements.  Therefore I don't think it
is necessary or appropriate for a CA to commit to adhere (or not adhere) to
a document that is still under development.

Additionally, Mozilla has determined that Code Signing is out of scope for
the Mozilla CA program.  Therefore, as I understand it, whether a CA issues
certificates for code signing or not, and the terms under which is does so,
should not be in scope for review of their CPS in this forum.


> * Section 3.2.8.1.1. is provably insecure and should not be used to verify
> ownership or control of a domain. A WHOIS record might contain an email
> address of a proxy and is, therefore, unreliable. The "magic" email address
> names might be directed to an unauthorized person and, therefore, also
> unreliable.
>

The process described in 3.2.8.1.1 is the process that was included in the
Mozilla CA policy (https://wiki.mozilla.org/CA:CertInclusionPolicyV2.0) and
is now included in the CABF BRs.  It is an approved process to verify
ownership or control of a domain.


> * Section 3.2.8.1.3. is also provably insecure and should not be used.
> Changing a website proves nothing and if I'm trying to exploit an existing
> domain for nefarious purposes I probably have control over the website
> anyway.
>

The process described in 3.2,8.1.3 is an implementation of section 3.2.2.4
(6) of the CABF BRs.  It appears to be an approved process to verify
ownership or control.

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

Re: SHA1 certs issued this year chaining to included roots

[Richard Barnes]

On Fri, Jan 29, 2016 at 4:43 PM, Kathleen Wilson 
wrote:

> On 1/25/16 12:22 AM, Charles Reiss wrote:
>
>> On 01/19/16 01:49, Charles Reiss wrote:
>>
>>> Via censys.io, I found a couple SHA-1 certs with notBefore dates from
>>> this year
>>> which chain to root CAs in Mozilla's program:
>>>
>> [snip]
>>
>> And here are a couple more, from different subCAs:
>>
>> - https://crt.sh/?id=12131821 -- chaining to Deutsche Telekom Root CA 2
>> [T-Systems] via subCA "Shared Business CA 3"
>>
>>
>
> I received email from Bernd of T-Systems saying that from 1 January 2016,
> 8 SHA‐1 subscriber certificates (SSL) were issued via sub-CA "Shared
> Business CA 3" (chaining to “Deutsche Telekom Root CA 2”) – because of
> converging use cases. Other T-Systems CAs were not affected.
> The problem has been fixed, so SHA-1 certs can no longer be issued.
> The 8 certs will be revoked on February 5 and the corresponding CRL will
> be updated/published.
>


February 5th?  Allow me to quote the BRs:

"""
4.9.1.1 Reasons for Revoking a Subscriber Certificate

The CA SHALL revoke a Certificate within 24 hours if one or more of the
following occurs: ...

The CA is made aware that the Certificate was not issued in accordance with
these Requirements
"""



>
> Thanks,
> Kathleen
>
>
> ___
> 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: ComSign Root Renewal Request

[Peter Kurrasch]

  I've reviewed the ComSign CPS and while it has a lot of legal language in it, it lacks a certain legal and technical precision that is needed in this case. For example, there is frequent use of the term "electronic certificate" which I think this document means "certificate used for electronic signatures of individual people" even though one might naturally include SSL/TLS and code signing certs as‎ such. Similarly, the use of "SSL" in this doc might also mean "code signing" but that is less clear. I was actually surprised to find code signing in section 3.2.9 given the lack of its even being mentioned elsewhere in the doc.I can appreciate ComSign wanting to take a shortcut by adding on the SSL and code signing stuff to their already detailed doc but my recommendation is for ComSign to rework the document anyway. It's difficult for me to assess the security risk that this root might introduce to the wider Internet population. Based on my current understanding of this document I'd say the attack surface is "large", meaning there seem to be many gaps through which I might fraudulently obtain a ComSign certificate. Further, I would say the potential for harm that I can cause with that ill-gotten cert is probably "unlimited".My hope is that by reworking the CPS document ComSign can more clearly articulate what is and is not possible when it comes to issuing and using their certs and, consequently, ‎my concerns about risk and damage are lessened. That said, I offer some specific comments:* Section 1 should stipulate that The Law was enacted by the State of Israel and has jurisdiction in the relevant Israeli territories. I'm assuming that to be the case, anyway.‎* I assume The Law does not apply to SSL/TLS certs. What about code signing? * There is a BR from CABF that covers code signing. I must admit I don't know the status of it but this CPS should at least acknowledge it and say if ComSign will adhere to it.* In Section 1 where it says "some procedures dealing with SSL...are not part of the Hebrew version", this statement is insufficient. For example what about code signing? Which SSL procedures are actually in the Hebrew version? This has an important implication when it comes to statements like "only the Hebrew version is binding".* I wasn't sure if a Registration Agent (Section 1.3.2) represents a business entity which is separate and apart from the ComSign company? Will ComSign bear any responsibility for the hiring of people at an RA, for example? This has a significant impact into my evaluation of the attack surface.‎ The greater the "space" between ComSign and the RA, the greater the chance for mistakes or bad acts to happen.* Section 1.4., what are the usage terms for SSL/TLS and code signing certs? Is key sharing allowed for any of the certs issued by ComSign? If key sharing is not allowed, how is that enforced (and who does the enforcing)?* Section 3.2.8.1.1. is provably insecure and should not be used to verify ownership or control of a domain. A WHOIS record might contain an email address of a proxy and is, therefore, unreliable. The "magic" email address names might be directed to an unauthorized person and, therefore, also unreliable. * Section 3.2.8.1.3. is also provably insecure and should not be used. Changing a website proves nothing and if I'm trying to exploit an existing domain for nefarious purposes I probably have control over the website anyway.* Throughout the CPS I found some uses of the term "signature" to be ambiguous. Where possible it would be good to distinguish between a pen-and-paper signature and one that's in some electronic form. I do like that the issuance process is not completely electronic.I do have concerns with other sections in this CPS but I would like to give ComSign a chance to respond or do rework before I get overly detailed. As I stated above, my hope is that a revised CPS will demonstrate that the attack surface is more "medium" and that the potential for damage is less than "unlimited"--that it is constrained in some way.   From: Kathleen WilsonSent: Wednesday, January 20, 2016 5:46 PM‎On 12/10/15 12:01 PM, Kathleen Wilson wrote:> This request is to include the "ComSign Global Root CA" root> certificate, and enable the Websites and Email trust bits. This root> will eventually replace the "ComSign CA" root certificate that is> currently included in NSS, and was approved in bug #420705.>> ComSign is owned by Comda, Ltd., and was appointed by the Justice> Ministry as a CA in Israel in 

Re: SHA1 certs issued this year chaining to included roots

[Kathleen Wilson]

On 1/25/16 12:22 AM, Charles Reiss wrote:

On 01/19/16 01:49, Charles Reiss wrote:

Via censys.io, I found a couple SHA-1 certs with notBefore dates from this year
which chain to root CAs in Mozilla's program:

[snip]

And here are a couple more, from different subCAs:

- https://crt.sh/?id=12131821 -- chaining to Deutsche Telekom Root CA 2
[T-Systems] via subCA "Shared Business CA 3"




I received email from Bernd of T-Systems saying that from 1 January 
2016, 8 SHA‐1 subscriber certificates (SSL) were issued via sub-CA 
"Shared Business CA 3" (chaining to “Deutsche Telekom Root CA 2”) – 
because of converging use cases. Other T-Systems CAs were not affected.

The problem has been fixed, so SHA-1 certs can no longer be issued.
The 8 certs will be revoked on February 5 and the corresponding CRL will 
be updated/published.


Thanks,
Kathleen

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