Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

[Roland Shoemaker via dev-security-policy]

(Posting in a personal capacity)

I think everyone so far has made valid points about why this is unexpected, and 
a dangerous precedent to set going forward. That said I'd like to reiterate 
that this feels like rewarding undesirable behavior. The CAs that will benefit 
from an exemption, especially one that allows them to take advantage of it 
silently, are those that have chosen to drag their heels until the last 
possible moment.

This behavior should not be encouraged and Mozilla policy should not be 
dictated by the minority of CAs that are holding it back via inaction.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

SHA256 for OCSP response issuer hashing

[Roland Shoemaker]

Let's Encrypt is currently considering moving away from using SHA1 as
the issuer subject/public key hashing function in OCSP responses and
using SHA256 instead. Given a little investigation this seems like a
safe move to make but we wanted to check with the community to see if
anyone was aware of legacy (or contemporary) software issues that may
cause us any trouble.

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

Re: SSL Certs for Malicious Websites

[Roland Shoemaker]

In the case of a DV certificate it's exactly what it says, validating
the ownership of a domain, and nothing more. While users _may believe_
that TLS is supposed to protect them from malware, hackers, or
'untrustworthy' sites in general _it is not_. TLS exists to encrypt the
connection between a client and a server.

What users expect, because of poor wording by people conveying the use
of TLS in the past (I think we are all probably a bit guilty of
perpetuating this error), should not dictate how CAs actually operate.

On 05/17/2016 12:36 PM, Peter Gutmann wrote:
> Hubert Kario  writes:
> 
>> then users expect impossible
> 
> Users expect CAs to be something other than certificate vending machines. The
> fact that CAs fail to do this is a problem with browser PKI and CAs, not with
> users.
> 
> (There have been numerous cases of security people reporting CA-certified
> phishing and malware sites to the CAs that did it.  The general response has
> been "not our problem, they paid their money and we gave them a cert".  So
> even if you tell the CA, they're likely not going to fix it).
> 
> Peter.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> 

-- 
Roland Bracewell Shoemaker
Software Engineer
Linux Foundation / Internet Security Research Group
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Undisclosed CA certificates

[Roland Shoemaker]

Ah yes, that is true. It is still the case though that a CA could be
calling out to some third party library or such they are not at liberty
to disclose.

Another thing to point out is that defining the structure that strictly
(i.e. MUST be a HMAC of something) would prevent a number of CAs from
storing various other structure within the serial (including Let's
Encrypt, in the code you linked we append our '8-bit instance id prefix'
to define from which instance a certificate was issued).

It seems the best solution to this problem is to simply remove the use
of entropy and require that N number of bits in the serial were
generated using a CSPRNG. The term is relatively well defined such that
an auditor (or other party) should be able to determine if a CA is
complying given the process by which they generate the required bits.

On 04/30/2016 03:12 PM, Eric Mill wrote:
> I understand that, but I would assume that the choice of what to ask the
> HSM to do would be in the CA's own software. This was the question I was
> responding to:
> 
> 
>> What if the serial number is HMAC-MD5(SecretStaticKey, MMDDHHmmss)?
> Or AES encryption of the timestamp?
> 
> That seems like CA-land code. In Let's Encrypt's boulder, it looks like the
> answer is here:
> 
> https://github.com/letsencrypt/boulder/blob/b7cf618f5d228ba2699e09cc4a65888d61654b19/ca/certificate-authority.go#L499-L512
> 
> -- Eric
> 
> On Sat, Apr 30, 2016 at 5:34 PM, Roland Shoemaker <rol...@letsencrypt.org>
> wrote:
> 
>> This assumes the use of a software RNG that can be open sourced. Many
>> CAs may be using a hardware source of randomness, such as a HSM, which
>> runs proprietary code they do not hold the license to.
>>
>> On 04/30/2016 06:45 AM, Eric Mill wrote:
>>> On Fri, Apr 29, 2016 at 8:12 PM, Peter Bowen <pzbo...@gmail.com> wrote:
>>>
>>>> On Fri, Apr 29, 2016 at 5:03 PM, Matt Palmer <mpal...@hezmatt.org>
>> wrote:
>>>>> On Fri, Apr 29, 2016 at 12:42:28AM -0700, Nick Lamb wrote:
>>>>>> There is an absolutely objective test, but it is negative. If anyone
>> can
>>>>>> predict N-bits of your next serial number then those N-bits were by
>>>>>> definition predictable.  To give a concrete example if you issued with
>>>> 16
>>>>>> digit serial numbers, but the first 8 are MMDD from the actual
>> date,
>>>>>> any bad guy can predict those numbers in the next certificate, thus
>> they
>>>>>> don't constitute entropy / unpredictable bits, so your serial numbers
>>>> have
>>>>>> no more than 8 digits of entropy in this scenario.
>>>>>
>>>>> Even more fun: what if the serial number is MD5(MMDDHHmmss)?  In
>> that
>>>>> case, comparing two serial numbers makes them all *look* awesomely
>>>> random,
>>>>> until someone figures out "the secret", at which point pretty much all
>>>> the
>>>>> bits are predictable, even though there's no "obvious" pattern from
>>>>> examining the serials themselves.
>>>>
>>>> What if the serial number is HMAC-MD5(SecretStaticKey,
>>>> MMDDHHmmss)? Or AES encryption of the timestamp?
>>>>
>>>> This is why there are human auditors.  They can ask the CA how they
>>>> are generating the serial numbers.  That is the only way that this can
>>>> every be verified.
>>>>
>>>
>>> Or a CA could release this part of their infrastructure as open source
>> (or
>>> at least publicly disclosed), and have the auditor attest that the code
>>> used in production is the code in public version control. That would make
>>> it so the community, not just the auditor, could evaluate of the strength
>>> of the methods the CA uses to manage entropy while being assured that
>>> they're evaluating the actual production code.
>>>
>>> -- Eric
>>>
>>>
>>>>
>>>> Thanks,
>>>> Peter
>>>> ___
>>>> 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
>>
> 
> 
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Undisclosed CA certificates

[Roland Shoemaker]

This assumes the use of a software RNG that can be open sourced. Many
CAs may be using a hardware source of randomness, such as a HSM, which
runs proprietary code they do not hold the license to.

On 04/30/2016 06:45 AM, Eric Mill wrote:
> On Fri, Apr 29, 2016 at 8:12 PM, Peter Bowen  wrote:
> 
>> On Fri, Apr 29, 2016 at 5:03 PM, Matt Palmer  wrote:
>>> On Fri, Apr 29, 2016 at 12:42:28AM -0700, Nick Lamb wrote:
 There is an absolutely objective test, but it is negative. If anyone can
 predict N-bits of your next serial number then those N-bits were by
 definition predictable.  To give a concrete example if you issued with
>> 16
 digit serial numbers, but the first 8 are MMDD from the actual date,
 any bad guy can predict those numbers in the next certificate, thus they
 don't constitute entropy / unpredictable bits, so your serial numbers
>> have
 no more than 8 digits of entropy in this scenario.
>>>
>>> Even more fun: what if the serial number is MD5(MMDDHHmmss)?  In that
>>> case, comparing two serial numbers makes them all *look* awesomely
>> random,
>>> until someone figures out "the secret", at which point pretty much all
>> the
>>> bits are predictable, even though there's no "obvious" pattern from
>>> examining the serials themselves.
>>
>> What if the serial number is HMAC-MD5(SecretStaticKey,
>> MMDDHHmmss)? Or AES encryption of the timestamp?
>>
>> This is why there are human auditors.  They can ask the CA how they
>> are generating the serial numbers.  That is the only way that this can
>> every be verified.
>>
> 
> Or a CA could release this part of their infrastructure as open source (or
> at least publicly disclosed), and have the auditor attest that the code
> used in production is the code in public version control. That would make
> it so the community, not just the auditor, could evaluate of the strength
> of the methods the CA uses to manage entropy while being assured that
> they're evaluating the actual production code.
> 
> -- Eric
> 
> 
>>
>> Thanks,
>> Peter
>> ___
>> 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