Re: Serial Number Origin Transparency proposal (was Re: A modest proposal for a better BR 7.1)

2019-03-13 Thread Rob Stradling via dev-security-policy 
On 13/03/2019 03:04, Peter Gutmann wrote:
> Rob Stradling via dev-security-policy  
> writes:
> 
>> I've been working on an alternative proposal for a serial number generation
>> scheme, for which I intend to write an I-D and propose to the LAMPS WG.
> 
> This seems really, really complicated.

Yes, SNOT adds complexity, but this was necessary to achieve the 
security/transparency properties that I set out to achieve.

Whether or not all of those security/transparency properties are 
desirable enough to warrant (some or all) CAs taking on the burden of 
this added complexity is of course worthy of discussion.

CT, for example, is complicated, and yet the security/transparency 
properties have been deemed desirable enough to warrant burdening the 
ecosystem with the added complexity.

> In all of the endless debate over this, the one thing that hasn't actually 
> come > under question is how to generate the random values themselves. What 
has come up over> and over is how to encapsulate those values as an 
ASN.1 integer.

I'm not sure I agree that dropping 1-bit of entropy falls entirely into 
the "encapsulating those values as an ASN.1 integer" part.

> So I really prefer the
> Modest Proposal version, which directly addresses the bit-bagging problems
> that are the real issue with 7.1.
> 
> Peter.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: Serial Number Origin Transparency proposal (was Re: A modest proposal for a better BR 7.1)

2019-03-13 Thread Rob Stradling via dev-security-policy 
On 13/03/2019 03:18, Matthew Hardeman wrote:
> Overall I think it's a neat scheme.
> 
> It does impose some trade-offs beyond the mechanism that I proposed:
> 
> 1.  It leaves the implementing CA with no space within the serial number 
> field to include a CA significant sequence number, timestamp, or other 
> value.  That may not be a bad thing, but it's other than capabilities 
> that they have today.

To comply with today's BRs, SNOT requires that R MUST be 64-bits of 
(fresh and unfiltered!) output from a CSPRNG.

However, if using SNOT in any environment where today's BRs don't apply, 
the purpose of R is simply to act as a disambiguator; so it could be any 
string of 64-bits chosen by the CA (because the TRUNCATE_TO_64BITS(D) 
part of the algorithm is, I believe, sufficient by itself to thwart 
chosen-prefix attacks).

(For clarity: Whilst I can imagine a possible future in which the BRs 
are updated to relax the CSPRNG requirement when SNOT is used, I am *not 
proposing that here* because m.d.s.p is the wrong venue to discuss 
updating the BRs).

> 2.  It necessarily requires that the TBS certificate data be available 
> to the serial number generation routine.  This would seem to lock in 
> some architectural changes  as the system element producing the serial 
> number necessarily has to have all the TBSCertificate data), which may 
> not necessarily be the case today.

Good point.  I think this can be addressed by changing steps 7 and 8 to...

7. Perform a binary search for the first occurrence of H || A || R || D 
in the DER(TBSCertificate) that was produced in step 6, and replace that 
first occurrence with H || A || R || TRUNCATE_TO_64BITS(D).

8. Sign the (modified by step 7) DER(TBSCertificate).

> On Tue, Mar 12, 2019 at 12:10 PM Rob Stradling via dev-security-policy 
>  > wrote:
> 
> Hi all.  I've been working on an alternative proposal for a serial
> number generation scheme, for which I intend to write an I-D and
> propose
> to the LAMPS WG.  However, since other folks' proposals are already
> flowing, I will share the gist of mine here.  Comments welcome!
> 
> - Serial Number Origin Transparency (SNOT ;-) ): Generation -
> 1. Let H (meaning "Header"; uint24) be: 0x00DE7E.  The 0x00 is the byte
> that makes the ASN.1 INTEGER a positive value.  0xDE7E signifies
> "DE7Erministic".
> 
> 2. Let A (meaning "Algorithm"; uint8) be a hash algorithm ID from the
> TLS HashAlgorithm registry
> 
> (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18).
> 
> 3. Let R (meaning "Random"; uint64) be 64-bits of (fresh and
> unfiltered!) output from a CSPRNG.
> 
> 4. Let M (meaning "Magic"; uint64) be the magic constant:
>     0x0102030405060708
> 
> 5. Generate the TBSCertificate template with the serial number value
> set to:
>     H || A || R || M
> 
> 6. Let D (meaning "Digest") be the thumbprint of the DER-encoded
> TBSCertificate, calculated using the hash algorithm denoted by A.
>     e.g., D = SHA-256(DER(TBSCertificate))
> 
> 7. Change the serial number value in the TBSCertificate template to:
>     H || A || R || TRUNCATE_TO_64BITS(D).
> 
> 8. Calculate DER(TBSCertificate), then sign it.
> --
> 
> Since this mechanism includes 64-bits of (fresh and unfiltered!) output
> from a CSPRNG, it is compatible with today's BRs.  The randomness also
> ensures that this mechanism doesn't yield multiple certs with the same
> serial number (contrary to RFC5280 §4.1.2.2) if the CA signs the exact
> same TBSCertificate multiple times using a nondeterministic signature
> algorithm.
> 
> In terms of preventing certificate forgery (see [1]), which is the
> thing
> that unpredictable serial numbers are designed to prevent, this
> mechanism gives CAs two chances to not screw up:
>     1) if the CA implements this mechanism wrongly but nonetheless does
> successfully include 64-bits of (fresh and unfiltered!) output from a
> CSPRNG, then the desired level of security is still achieved.
>     2) or, if the CA correctly implements the deterministic parts of
> this
> mechanism but mishandles the output from their CSPRNG, then the desired
> level of security is still achieved (although let me stress that this
> would of course not be compliant with today's BRs).
> 
> Whilst this mechanism does add complexity for the CA (compared to only
> using a CSPRNG to generate serial numbers), I think that the additional
> operations on the TBSCertificate are less complicated than most CAs
> have
> already had to deal with to issue CT precertificates and embed SCTs in
> certificates.
> 
> *** ADVANTAGES OF THIS MECHANISM ***
> When implemented correctly by the CA, this mecha

Re: A modest proposal for a better BR 7.1

2019-03-13 Thread Piotr Kucharski via dev-security-policy 
On Wed, Mar 13, 2019 at 5:52 AM Ryan Sleevi  wrote:

>
>
> On Tue, Mar 12, 2019 at 11:18 PM bif via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> FWIW, the easiest would've been to remove "positive" aspect of serials.
>> Who really cares? A random number is a random number.
>>
>
> RFC 5280 cares, as it's been a long-standing source of compat issues,
> which is why RFC 5280 itself made the 'positive' requirement.
>
> https://tools.ietf.org/html/rfc5280#section-4.1.2.2
>

Oh, I know RFC is the source of this requirement (and even in that, it says
"should handle").
All I was saying, a number is a number, and making this exception only
solidified wrong implementations (said compat issues), instead of healing
the ecosystem (forcing wrong implementations to be fixed).

But I understand that's not the battle to be won or even fought here. :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: A modest proposal for a better BR 7.1

2019-03-12 Thread Ryan Sleevi via dev-security-policy 
On Tue, Mar 12, 2019 at 11:18 PM bif via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> FWIW, the easiest would've been to remove "positive" aspect of serials.
> Who really cares? A random number is a random number.
>

RFC 5280 cares, as it's been a long-standing source of compat issues, which
is why RFC 5280 itself made the 'positive' requirement.

https://tools.ietf.org/html/rfc5280#section-4.1.2.2
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Serial Number Origin Transparency proposal (was Re: A modest proposal for a better BR 7.1)

2019-03-12 Thread Matthew Hardeman via dev-security-policy 
Overall I think it's a neat scheme.

It does impose some trade-offs beyond the mechanism that I proposed:

1.  It leaves the implementing CA with no space within the serial number
field to include a CA significant sequence number, timestamp, or other
value.  That may not be a bad thing, but it's other than capabilities that
they have today.

2.  It necessarily requires that the TBS certificate data be available to
the serial number generation routine.  This would seem to lock in some
architectural changes  as the system element producing the serial number
necessarily has to have all the TBSCertificate data), which may not
necessarily be the case today.

On Tue, Mar 12, 2019 at 12:10 PM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi all.  I've been working on an alternative proposal for a serial
> number generation scheme, for which I intend to write an I-D and propose
> to the LAMPS WG.  However, since other folks' proposals are already
> flowing, I will share the gist of mine here.  Comments welcome!
>
> - Serial Number Origin Transparency (SNOT ;-) ): Generation -
> 1. Let H (meaning "Header"; uint24) be: 0x00DE7E.  The 0x00 is the byte
> that makes the ASN.1 INTEGER a positive value.  0xDE7E signifies
> "DE7Erministic".
>
> 2. Let A (meaning "Algorithm"; uint8) be a hash algorithm ID from the
> TLS HashAlgorithm registry
> (
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18
> ).
>
> 3. Let R (meaning "Random"; uint64) be 64-bits of (fresh and
> unfiltered!) output from a CSPRNG.
>
> 4. Let M (meaning "Magic"; uint64) be the magic constant:
>0x0102030405060708
>
> 5. Generate the TBSCertificate template with the serial number value set
> to:
>H || A || R || M
>
> 6. Let D (meaning "Digest") be the thumbprint of the DER-encoded
> TBSCertificate, calculated using the hash algorithm denoted by A.
>e.g., D = SHA-256(DER(TBSCertificate))
>
> 7. Change the serial number value in the TBSCertificate template to:
>H || A || R || TRUNCATE_TO_64BITS(D).
>
> 8. Calculate DER(TBSCertificate), then sign it.
> --
>
> Since this mechanism includes 64-bits of (fresh and unfiltered!) output
> from a CSPRNG, it is compatible with today's BRs.  The randomness also
> ensures that this mechanism doesn't yield multiple certs with the same
> serial number (contrary to RFC5280 §4.1.2.2) if the CA signs the exact
> same TBSCertificate multiple times using a nondeterministic signature
> algorithm.
>
> In terms of preventing certificate forgery (see [1]), which is the thing
> that unpredictable serial numbers are designed to prevent, this
> mechanism gives CAs two chances to not screw up:
>1) if the CA implements this mechanism wrongly but nonetheless does
> successfully include 64-bits of (fresh and unfiltered!) output from a
> CSPRNG, then the desired level of security is still achieved.
>2) or, if the CA correctly implements the deterministic parts of this
> mechanism but mishandles the output from their CSPRNG, then the desired
> level of security is still achieved (although let me stress that this
> would of course not be compliant with today's BRs).
>
> Whilst this mechanism does add complexity for the CA (compared to only
> using a CSPRNG to generate serial numbers), I think that the additional
> operations on the TBSCertificate are less complicated than most CAs have
> already had to deal with to issue CT precertificates and embed SCTs in
> certificates.
>
> *** ADVANTAGES OF THIS MECHANISM ***
> When implemented correctly by the CA, this mechanism enables the
> community to programmatically verify(*) that a certificate is not a
> forgery, without having to...
> 1. trust the CA (to have handled their CSPRNG correctly), or
> 2. trust the CA's WebTrust/ETSI auditors (to have correctly verified
> that the CA has handled their CSPRNG correctly), or
> 3. trust the CSPRNG algorithm to actually be unpredictable
> (Dual_EC_DRBG, anyone?)
>
> This mechanism builds on PHB's earlier proposal [2].
>
>
> [1] https://www.win.tue.nl/hashclash/rogue-ca/
>
> [2] https://cabforum.org/pipermail/public/2016-July/008053.html
>
> (*)
> - Serial Number Origin Transparency (SNOT): Verification -
> 1. Check that the first 3 bytes of the certificate's serial number value
> (including the leading sign byte) are 0x00DE7E.
>
> 2. Check that the certificate's serial number value is exactly 20 bytes
> long (including the leading 0x00 sign byte).
>
> 3. Let A be the 4th byte of the serial number value (considering the
> leading 0x00 sign byte to be the 1st byte).  Check that A denotes a
> supported hash algorithm.
>
> 4. Let D1 be a copy of the last 8 bytes of the certificate's serial number.
>
> 5. Let T be a copy of the DER-encoded TBSCertificate component of the
> certificate.
>
> 6. Change the last 8 bytes of T's serial number to the magic constant:
>0x010203

Re: A modest proposal for a better BR 7.1

2019-03-12 Thread bif via dev-security-policy 
On Saturday, March 9, 2019 at 3:44:12 AM 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]
> 
> Notes / Rationale:
> 
> Note 1.  The first bullet point sets out a structure which necessarily
> requires that the encoded form of the serial number for all cases be at
> least 9 bytes in length.  As many CAs would have been able to immediately
> see that their values, while random, don't reach 9 bytes, each CA in that
> case would have had an easy hint that further work to assess compliance
> with this BR change would be necessary and would definitely result in
> changes.  I believe that would have triggered the necessary investigations
> and remediations.  To the extent that it did not do so, the CAs which
> ignored the change would be quickly identifiable as a certificate with an 8
> byte serial number encoding would not have been valid after the effective
> date.
> 
> Note 2.  A fixed value was chosen for the first byte for a couple of
> reasons.  First, by virtue of not having a value of 1 in the highest order
> bit, it means that ASN.1 integer encoding issues pertaining to sign are
> mooted.  Secondarily, with each certificate issuance subsequent to the
> effective date of the proposal, a CA which has not updated their systems to
> accommodate this ballot but does use random number generation to populate
> the certificate serial has a probability of 127/128 of revealing that they
> have not implemented the changes specified in this ballot.
> 
> Note 3.  CAs and their software vendors are quite familiar with
> cryptographic primitives, cryptographic keys, key generation, etc.  Rather
> than using ambiguous definitions of randomness or bits of entropy or output
> of a CSPRNG, the administration of a CA and their software vendors should
> be able to be relied upon to understand the demands of symmetric key
> generation in actual practice.  By choosing to specify a symmetric block
> cipher type and key size in common use, the odds of an appropriate
> algorithm being selected from among the large body of appropriate
> implementations of such algorithms greatly reduces odds of low quality
> "random" data for the serial number.
> 
> Note 4.  Note 4 makes clear that plenty of space remains for the CA to
> populate other information, be it further random data or particular data of
> interest to the CA, such as sequence numbers, date/time, etc.
> 
> Further notes / rationale:
> 
> In supporting systems whose databases may support only a 64 bit serial
> number in database storage, etc, it is noteworthy that the serial number
> rules I specified here only refer to the encoded form which occurs in the
> certificate itself, not any internal representation in an issuance
> database.  Because the first byte is hard coded to 0x75 in my proposal,
> this doesn't need to be reflected in a legacy system database, it can just
> be implemented as part of the certificate encoding process.
> 
> Strategically, certificates which would conform to the proposal I've laid
> out here would obviously and facially be different from any previously
> deployed system which routinely utilized 8 byte encodings, meaning that
> every CA previously generating 8 byte serials would have an obvious signal
> that they needed to dig into their serial number generation methodologies.
> 
> By tying the generation of high quality random data to fill the serial
> number to algorithms and procedures already well known to CAs and to their
> vendors, auditors, etc, my proposal enhances the odds that the required
> amount of random unpredictable bits actually be backed by a mechanism
> appropriate for the use of cryptography.
> 
> If anyone thi

Re: Serial Number Origin Transparency proposal (was Re: A modest proposal for a better BR 7.1)

2019-03-12 Thread Peter Gutmann via dev-security-policy 
Rob Stradling via dev-security-policy  
writes:

>I've been working on an alternative proposal for a serial number generation
>scheme, for which I intend to write an I-D and propose to the LAMPS WG.

This seems really, really complicated.  In all of the endless debate over
this, the one thing that hasn't actually come under question is how to
generate the random values themselves.  What has come up over and over is how
to encapsulate those values as an ASN.1 integer.  So I really prefer the
Modest Proposal version, which directly addresses the bit-bagging problems
that are the real issue with 7.1.

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

Serial Number Origin Transparency proposal (was Re: A modest proposal for a better BR 7.1)

2019-03-12 Thread Rob Stradling via dev-security-policy 
Hi all.  I've been working on an alternative proposal for a serial 
number generation scheme, for which I intend to write an I-D and propose 
to the LAMPS WG.  However, since other folks' proposals are already 
flowing, I will share the gist of mine here.  Comments welcome!

- Serial Number Origin Transparency (SNOT ;-) ): Generation -
1. Let H (meaning "Header"; uint24) be: 0x00DE7E.  The 0x00 is the byte 
that makes the ASN.1 INTEGER a positive value.  0xDE7E signifies 
"DE7Erministic".

2. Let A (meaning "Algorithm"; uint8) be a hash algorithm ID from the 
TLS HashAlgorithm registry 
(https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18).

3. Let R (meaning "Random"; uint64) be 64-bits of (fresh and 
unfiltered!) output from a CSPRNG.

4. Let M (meaning "Magic"; uint64) be the magic constant:
   0x0102030405060708

5. Generate the TBSCertificate template with the serial number value set to:
   H || A || R || M

6. Let D (meaning "Digest") be the thumbprint of the DER-encoded 
TBSCertificate, calculated using the hash algorithm denoted by A.
   e.g., D = SHA-256(DER(TBSCertificate))

7. Change the serial number value in the TBSCertificate template to:
   H || A || R || TRUNCATE_TO_64BITS(D).

8. Calculate DER(TBSCertificate), then sign it.
--

Since this mechanism includes 64-bits of (fresh and unfiltered!) output 
from a CSPRNG, it is compatible with today's BRs.  The randomness also 
ensures that this mechanism doesn't yield multiple certs with the same 
serial number (contrary to RFC5280 §4.1.2.2) if the CA signs the exact 
same TBSCertificate multiple times using a nondeterministic signature 
algorithm.

In terms of preventing certificate forgery (see [1]), which is the thing 
that unpredictable serial numbers are designed to prevent, this 
mechanism gives CAs two chances to not screw up:
   1) if the CA implements this mechanism wrongly but nonetheless does 
successfully include 64-bits of (fresh and unfiltered!) output from a 
CSPRNG, then the desired level of security is still achieved.
   2) or, if the CA correctly implements the deterministic parts of this 
mechanism but mishandles the output from their CSPRNG, then the desired 
level of security is still achieved (although let me stress that this 
would of course not be compliant with today's BRs).

Whilst this mechanism does add complexity for the CA (compared to only 
using a CSPRNG to generate serial numbers), I think that the additional 
operations on the TBSCertificate are less complicated than most CAs have 
already had to deal with to issue CT precertificates and embed SCTs in 
certificates.

*** ADVANTAGES OF THIS MECHANISM ***
When implemented correctly by the CA, this mechanism enables the 
community to programmatically verify(*) that a certificate is not a 
forgery, without having to...
1. trust the CA (to have handled their CSPRNG correctly), or
2. trust the CA's WebTrust/ETSI auditors (to have correctly verified 
that the CA has handled their CSPRNG correctly), or
3. trust the CSPRNG algorithm to actually be unpredictable 
(Dual_EC_DRBG, anyone?)

This mechanism builds on PHB's earlier proposal [2].


[1] https://www.win.tue.nl/hashclash/rogue-ca/

[2] https://cabforum.org/pipermail/public/2016-July/008053.html

(*)
- Serial Number Origin Transparency (SNOT): Verification -
1. Check that the first 3 bytes of the certificate's serial number value 
(including the leading sign byte) are 0x00DE7E.

2. Check that the certificate's serial number value is exactly 20 bytes 
long (including the leading 0x00 sign byte).

3. Let A be the 4th byte of the serial number value (considering the 
leading 0x00 sign byte to be the 1st byte).  Check that A denotes a 
supported hash algorithm.

4. Let D1 be a copy of the last 8 bytes of the certificate's serial number.

5. Let T be a copy of the DER-encoded TBSCertificate component of the 
certificate.

6. Change the last 8 bytes of T's serial number to the magic constant:
   0x0102030405060708
(To avoid having to DER-decode and re-DER-encode T, this step should be 
performed using a binary search-and-replace directly on the first 
occurrence of D1 in T).

7. Let D2 be the thumbprint of T, calculated using the hash algorithm 
denoted by A.
   e.g., D2 = SHA-256(T)

8. Check that D1 exactly matches D2.
--

On 12/03/2019 14:14, Jakob Bohm via dev-security-policy wrote:
> On 09/03/2019 03:43, 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

Re: A modest proposal for a better BR 7.1

2019-03-12 Thread Ryan Sleevi via dev-security-policy 
On Tue, Mar 12, 2019 at 7:14 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>  5. As a special exception, systems that require signing certificates
>with the same serial-number more than once (such as CT and CA
>validity adjustments) are not required to change the serial number
>after initial selection).


While I am largely ignoring the rest of this message/thread, I feel
obligated to point out to any CAs that get distracted by this thread (e.g.
If they struggle to understand what “at least” means) that the reuse of
serials for “CA validity adjustments” is not, nor has it ever been,
compliant with RFC 5280 nor the Baseline Requirements. Serials that are
duplicated in such a manner are non-compliant and incidents, as has been
discussed repeatedly in the past [1] [2].

While I hope and expect CAs are well aware of these basic requirements, its
necessary to call out when participants are advocating for violating the
Baseline Requirements.

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/OJIhgypNvkc/c7_sHuCeFAAJ
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/SM3cUnENmUw/ZeNCpR2eBgAJ

 6. As a special exception due to widespread technical failures,
>certificates issued on or prior to 2019-03-31 UTC may instead use
>serial numbers consisting only of 63 random bits chosen as per #2,
>but checked to reject any value that would be encoded to 7 or fewer
>bytes or be the same as a previously issued serial number.


Again, it is worth reiterating that exceptions are not and cannot be
retroactively granted, even by the Baseline Requirements.


This thread will not be beneficial, either for Mozilla participants nor the
CA/Browser Forum. There are plenty of avenues one could take if one felt
they had a unique and valuable technical contribution to offer, such as
creating an IETF Internet-Draft that attempts to formalize a given
algorithm, while providing a degree of IP protection/disclosure to such a
contribution. However, this group is not that.

On a more fundamental level, suggestions such as this highlight the
confusion that some non-CA participants may have with respect to the
Baseline Requirements. In many ways, the BRs specify the expectations and
goals, while the technical means of achieving those goals are left for
other specifications. For example, the recently completed RFC 8555 provides
an algorithm for fulfilling the obligations of 3.2.2.4 of the Baseline
Requirements. FIPS 140 series provides methods for fulfilling the
obligations of key protection requirements.

Threads proposing changes to the BRs should be left to archive, as they do
not provide value to the community here, and create significant risks and
problems.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: A modest proposal for a better BR 7.1

2019-03-12 Thread Jakob Bohm via dev-security-policy 
On 09/03/2019 03:43, 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]
> 
> Notes / Rationale:
> 
> Note 1.  The first bullet point sets out a structure which necessarily
> requires that the encoded form of the serial number for all cases be at
> least 9 bytes in length.  As many CAs would have been able to immediately
> see that their values, while random, don't reach 9 bytes, each CA in that
> case would have had an easy hint that further work to assess compliance
> with this BR change would be necessary and would definitely result in
> changes.  I believe that would have triggered the necessary investigations
> and remediations.  To the extent that it did not do so, the CAs which
> ignored the change would be quickly identifiable as a certificate with an 8
> byte serial number encoding would not have been valid after the effective
> date.
> 
> Note 2.  A fixed value was chosen for the first byte for a couple of
> reasons.  First, by virtue of not having a value of 1 in the highest order
> bit, it means that ASN.1 integer encoding issues pertaining to sign are
> mooted.  Secondarily, with each certificate issuance subsequent to the
> effective date of the proposal, a CA which has not updated their systems to
> accommodate this ballot but does use random number generation to populate
> the certificate serial has a probability of 127/128 of revealing that they
> have not implemented the changes specified in this ballot.
> 
> Note 3.  CAs and their software vendors are quite familiar with
> cryptographic primitives, cryptographic keys, key generation, etc.  Rather
> than using ambiguous definitions of randomness or bits of entropy or output
> of a CSPRNG, the administration of a CA and their software vendors should
> be able to be relied upon to understand the demands of symmetric key
> generation in actual practice.  By choosing to specify a symmetric block
> cipher type and key size in common use, the odds of an appropriate
> algorithm being selected from among the large body of appropriate
> implementations of such algorithms greatly reduces odds of low quality
> "random" data for the serial number.
> 
> Note 4.  Note 4 makes clear that plenty of space remains for the CA to
> populate other information, be it further random data or particular data of
> interest to the CA, such as sequence numbers, date/time, etc.
> 
> Further notes / rationale:
> 
> In supporting systems whose databases may support only a 64 bit serial
> number in database storage, etc, it is noteworthy that the serial number
> rules I specified here only refer to the encoded form which occurs in the
> certificate itself, not any internal representation in an issuance
> database.  Because the first byte is hard coded to 0x75 in my proposal,
> this doesn't need to be reflected in a legacy system database, it can just
> be implemented as part of the certificate encoding process.
> 
> Strategically, certificates which would conform to the proposal I've laid
> out here would obviously and facially be different from any previously
> deployed system which routinely utilized 8 byte encodings, meaning that
> every CA previously generating 8 byte serials would have an obvious signal
> that they needed to dig into their serial number generation methodologies.
> 
> By tying the generation of high quality random data to fill the serial
> number to algorithms and procedures already well known to CAs and to their
> vendors, auditors, etc, my proposal enhances the odds that the required
> amount of random unpredictable bits actually be backed by a mechanism
> appropriate for the use of cryptography.
> 
> If anyone thinks any of t

Re: A modest proposal for a better BR 7.1

2019-03-09 Thread James Burton via dev-security-policy 
Matt's right, you need to discussion this on the CAB Forum.

Burton

On Sat, Mar 9, 2019 at 9:10 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Fri, Mar 08, 2019 at 08:43:49PM -0600, Matthew Hardeman via
> dev-security-policy wrote:
> > I know this isn't the place to bring a BR ballot, but I'm not presently a
> > participant there.
>
> My understanding is that discussing potential BR changes here is actively
> counter-productive, because of intellectual property concerns around the
> BRs.  Basically, if you want to propose a change in the BRs, you really
> *have* to sign up as an interested party and do the IPR agreement dance,
> otherwise... problems.  And no, disclaiming copyrights, etc probably isn't
> enough, because it's far more complicated than that.
>
> - Matt
>
> ___
> 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: A modest proposal for a better BR 7.1

2019-03-09 Thread Matt Palmer via dev-security-policy 
On Fri, Mar 08, 2019 at 08:43:49PM -0600, Matthew Hardeman via 
dev-security-policy wrote:
> I know this isn't the place to bring a BR ballot, but I'm not presently a
> participant there.

My understanding is that discussing potential BR changes here is actively
counter-productive, because of intellectual property concerns around the
BRs.  Basically, if you want to propose a change in the BRs, you really
*have* to sign up as an interested party and do the IPR agreement dance,
otherwise... problems.  And no, disclaiming copyrights, etc probably isn't
enough, because it's far more complicated than that.

- Matt

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

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: A modest proposal for a better BR 7.1

2019-03-08 Thread Matthew Hardeman via dev-security-policy 
On Fri, Mar 8, 2019 at 8:57 PM Peter Gutmann 
wrote:

> Matthew Hardeman via dev-security-policy <
> dev-security-policy@lists.mozilla.org> writes:
>
> >shall be 0x75
>
> Not 0x71?
>

:-)  In truth, I think any particular chosen single value for the first
byte which has the high order bit set to 0 and is not 0x00, 0x01, or 0x7F
is probably fine.  0x00 is avoided for obvious encoding reasons.  0x01 and
0x7F should be avoided as they seem likely to be the most common values
people would utilize in that position when they have the goal of avoiding
variable length.  One of the benefits of choosing a particular fixed value
for the entire first byte is that it creates a significant probability
(127/128) that a random value (save for a fixed high order bit set to 0) in
the first byte by a CA who hasn't updated their behavior to conform will be
rapidly and obviously revealed.


> Sounds good, and saves me having to come up with something (the
> bitsort(CSPRNG64()) nonsense took enough time to type up).  The only thing
> I
> somewhat disagree with is #3, since this is now very concise and requires
> "the
> first 64 bits of output" you can just make it a CSPRNG, which is well-
> understood and presumably available to any CA, since it's a standard
> feature
> of all HSMs.


I don't necessarily have strong opinions about it, but I did consider it
and still came to the conclusion that it should be specified as a symmetric
key generation operation.  My reason for this change arises from my own
experiences in a variety of languages and platforms on various hardware
over the years.  CSPRNG ought to be enough, but sometimes some environments
will spoil a developer with choice.  And if the developer isn't necessarily
a cryptographer, they could easily choose the wrong type or initialize it
incorrectly.  Conversely, through the years various programming languages
and runtime environments have gotten better and better about the default or
most prevalent routines for key generation on those platforms.  It is
therefore belief that specifying the entropy source as a standardized
symmetric key generation operation improves the odds that a less than
expert developer will accidentally get it right.  I kind of cringe at that
idea, but I still think it deserves a look.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: A modest proposal for a better BR 7.1

2019-03-08 Thread Peter Gutmann via dev-security-policy 
Matthew Hardeman via dev-security-policy 
 writes:

>shall be 0x75

Not 0x71?

>If anyone thinks any of this has merit, by all means run with it.

Sounds good, and saves me having to come up with something (the
bitsort(CSPRNG64()) nonsense took enough time to type up).  The only thing I
somewhat disagree with is #3, since this is now very concise and requires "the
first 64 bits of output" you can just make it a CSPRNG, which is well-
understood and presumably available to any CA, since it's a standard feature
of all HSMs.

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

A modest proposal for a better BR 7.1

2019-03-08 Thread Matthew Hardeman via dev-security-policy 
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]

Notes / Rationale:

Note 1.  The first bullet point sets out a structure which necessarily
requires that the encoded form of the serial number for all cases be at
least 9 bytes in length.  As many CAs would have been able to immediately
see that their values, while random, don't reach 9 bytes, each CA in that
case would have had an easy hint that further work to assess compliance
with this BR change would be necessary and would definitely result in
changes.  I believe that would have triggered the necessary investigations
and remediations.  To the extent that it did not do so, the CAs which
ignored the change would be quickly identifiable as a certificate with an 8
byte serial number encoding would not have been valid after the effective
date.

Note 2.  A fixed value was chosen for the first byte for a couple of
reasons.  First, by virtue of not having a value of 1 in the highest order
bit, it means that ASN.1 integer encoding issues pertaining to sign are
mooted.  Secondarily, with each certificate issuance subsequent to the
effective date of the proposal, a CA which has not updated their systems to
accommodate this ballot but does use random number generation to populate
the certificate serial has a probability of 127/128 of revealing that they
have not implemented the changes specified in this ballot.

Note 3.  CAs and their software vendors are quite familiar with
cryptographic primitives, cryptographic keys, key generation, etc.  Rather
than using ambiguous definitions of randomness or bits of entropy or output
of a CSPRNG, the administration of a CA and their software vendors should
be able to be relied upon to understand the demands of symmetric key
generation in actual practice.  By choosing to specify a symmetric block
cipher type and key size in common use, the odds of an appropriate
algorithm being selected from among the large body of appropriate
implementations of such algorithms greatly reduces odds of low quality
"random" data for the serial number.

Note 4.  Note 4 makes clear that plenty of space remains for the CA to
populate other information, be it further random data or particular data of
interest to the CA, such as sequence numbers, date/time, etc.

Further notes / rationale:

In supporting systems whose databases may support only a 64 bit serial
number in database storage, etc, it is noteworthy that the serial number
rules I specified here only refer to the encoded form which occurs in the
certificate itself, not any internal representation in an issuance
database.  Because the first byte is hard coded to 0x75 in my proposal,
this doesn't need to be reflected in a legacy system database, it can just
be implemented as part of the certificate encoding process.

Strategically, certificates which would conform to the proposal I've laid
out here would obviously and facially be different from any previously
deployed system which routinely utilized 8 byte encodings, meaning that
every CA previously generating 8 byte serials would have an obvious signal
that they needed to dig into their serial number generation methodologies.

By tying the generation of high quality random data to fill the serial
number to algorithms and procedures already well known to CAs and to their
vendors, auditors, etc, my proposal enhances the odds that the required
amount of random unpredictable bits actually be backed by a mechanism
appropriate for the use of cryptography.

If anyone thinks any of this has merit, by all means run with it.  I
disclaim any proprietary interest (copyright, etc) that I might otherwise
have had by statute and declare that I'm releasing this to the public
domain.

Thanks,

Matt
___