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.
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo
