date:20190308

Re: A modest proposal for a better BR 7.1

2019-03-08 Thread okaphone.elektronika--- via dev-security-policy

On Saturday, 9 March 2019 03:44:12 UTC+1, Matthew Hardeman  wrote:
> I know this isn't the place to bring a BR ballot, but I'm not presently a
> participant there.
> 
> I present alternative language along with notes and rationale which, I put
> forth, would have resulted in a far better outcome for the ecosystem than
> the issues which have arisen from the present BR 7.1 subsequent to ballot
> 164.
> 
> I humbly propose that this would have been a far better starting point, for
> reasons I discuss in notes below.
> 
> Effective as of Month Day, Year, CAs shall generate a certificate serial
> numbers as herein specified:
> 
> 
>1. The ASN.1 signed integer encoded form of the certificate serial
>number value must be represented as not less than 9 bytes and not more than
>20 bytes.  [Note 1]
>2. The hexadecimal value of the first byte of the certificate serial
>number shall be 0x75.  [Note 2]
>3. The consecutive 64 bits immediately following the first byte of the
>encoded serial number shall be the first 64 bits of output of an AES-128
>random session key generation operation, said operation having been seeded
>within random data to within its design requirements. [Note 3]
>4. The remaining bytes of the encoded serial number (the 10th through
>20th bytes of the encoded serial number), to the extent any are desired,
>may be populated with any values. [Note 4]

Is it still important that the random bits are not all zero? Because that seems 
to be omitted here.

And if it is then the next question is: is it still important that the entropy 
of the whole thing is at least 64 bits? For if that is the case then you will 
need at least one more bit in the random part because of the exclusion of the 
all zeroes value, which reduces entropy to slightly below 64 bits.

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

Re: EJBCA defaulting to 63 bit serial numbers

2019-03-08 Thread Peter Gutmann via dev-security-policy

Dimitris Zacharopoulos via dev-security-policy 
 writes:

>If we have to count every CA that had this interpretation, then I suppose all
>CAs that were using EJBCA with the default configuration have the same
>interpretation.

There's also an unknown number of CAs not using EJBCA that may have even
further interpretations.  For example my code, which I'll point out in advance
has nothing to do with the BR and predates the existence of the CAB Forum
itself, may or may not be compliant with whatever Mozilla's interpretation of
7.1 is.  I literally have no idea whether it meets Mozilla's expectations.  It
doesn't do what EJBCA does, so at least it's OK there, but beyond that I have
no idea whether it does what Mozilla wants or not.  

I assume any number of other CAs are in the same position, and given that if
they guessed wrong they have to revoke an arbitrarily large number of certs,
it's in their best interests to keep their heads down and wait for this to
blow over.

So perhaps instead of trying to find out which of the hundreds of CAs in the
program aren't compliant, we can check which ones are.  Would any CA that
thinks it's compliant let us know, and indicate why they think they're
compliant?  For example "we take 64 bits of CSPRNG output, pad it with a
leading , and use that as the serial number", in other words what
Matthew Hardeman suggested, would seem to be OK.

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

Re: EJBCA defaulting to 63 bit serial numbers

2019-03-08 Thread Dimitris Zacharopoulos via dev-security-policy

Adding to this discussion, and to support that there were -in fact-
different interpretations (all in good faith) please check the issue I
had created in Dec 2017 https://github.com/awslabs/certlint/issues/56.

My simple interpretation of the updated requirement in 7.1 at the time
was that "no matter what, the resulting serial number should be at least
64 bits long". However, experts like Peter Bowen, Rob Stradling and Matt
Palmer, paying attention to details of the new requirement, gave a
different interpretation. According to their explanation, if you take
64-bits from a CSPRNG, there is a small but existing probability that
the resulting serialNumber will be something smaller. So, "shorter"
serial numbers were not considered a violation of the BRs as long as the
64-bits came out of a CSPRNG.

I am personally shocked that a large part of this community considers
that now is the time for CAs to demonstrate "agility to replace
certificates", as lightly as that, without considering the significant
pain that Subscribers will experience having to replace hundreds of
thousands of certificates around the globe. It is very possible that
Relying parties will also suffer availability issues.

As discussed before, automation is one of the goals (other opinions had
been raised, noting security concerns to this automation). Centralized
systems like large web hosting providers or single large Subscribers
like the ones already mentioned in current incident reports, can build
automation easier. However, simple/ordinary Subscribers that don't have
the technical skills to automate the certificate replacement, that
struggled to even install certificates in their TLS servers in the first
place, will create huge burden for no good reason.

I don't know if others share the same view about the interpretation of
7.1 but it seems that some highly respected members of this community
did. If we have to count every CA that had this interpretation, then I
suppose all CAs that were using EJBCA with the default configuration
have the same interpretation.

BTW, the configuration in EJBCA that we are talking about, as the
default number of bytes, had the number "8" in the setting, resulting in
64-bits, not 63. So, as far as the CA administrator was concerned, this
setting resulted in using 64 random bits from a CSPRNG. One would have
to see the internal code to determine that the first bit was replaced by
a zero.

IMO, Mozilla should also treat this as an incident and evaluate the
specific parameters (strict interpretation of section 7.1, CAs did not
deliberately violate the requirement, a globally-respected software
vendor and other experts had a different allowable interpretation of a
requirement, the security impact on Subscribers and Relying Parties for
1 bit of entropy is negligible), and consider treating this incident at
least as the underscore issue. In the underscore case, there was a SCWG
ballot with an effective date where CAs had to ultimately revoke all
certificates that included an underscore.

Thanks,
Dimitris.

On 9/3/2019 6:32 π.μ., Peter Bowen via dev-security-policy wrote:

On Fri, Mar 8, 2019 at 7:55 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

On Fri, Mar 8, 2019 at 9:49 PM Ryan Sleevi wrote:

I consider that only a single CA has represented any ambiguity as being
their explanation as to why the non-compliance existed, and even then,
clarifications to resolve that ambiguity already existed, had they simply
been sought.

Please contemplate this question, which is intended as rhetorical, in the
most generous and non-judgmental light possible. Have you contemplated the
possibility that only one CA attempted to do so because you've stated your
interpretation and because they're subject to your judgement and mercy,
rather than because the text as written reflects a single objective
mechanism which matches your own position?

Matthew,

I honestly doubt so. It seems that one CA software vendor had a buggy
implementation but we know this is not universal. For example, see
https://github.com/r509/r509/blob/05aaeb1b0314d68d2fcfd2a0502f31659f0de906/lib/r509/certificate_authority/signer.rb#L132
and https://github.com/letsencrypt/boulder/blob/master/ca/ca.go#L511 are
open source CA software packages that clearly do not have the issue.
Further at least one CA has publicly stated their in-house written CA
software does not have the issue.

I know, as the author of cablint, that the main reason I didn't have any
confusion. I didn't add more checks because of the false positive rate
issue; if I checked for 64 or more bits, it would be wrong 50% of the
time. The rate is still unacceptable with even looser rules; in 1/256
cases the top 8 bits will all be zero, leading to a whole the serial being
a whole byte shorter.

47 matches

Mail list logo