Re: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

Given the rarity of such events, it will be hard for subscribers to
ensure they properly handle automated "renew prematurely" messages,
so other contact methods designed to reach human operators would often
be preferable.

But for fully automated "fire-and-forget" servers, I think the most
efficient way to do this would be as an Extended attribute in OCSP
responses, since at least some servers (and hopefully more in the
future) will be doing OCSP-stapling anyway.  The warning attribute would
contain a standard date field indicating a premature revocation
date/time in the future, and the (positive) OCSP response would also
expire at that time.  If no appropriate extended attribute exists, one
would be assigned out of the Enterprise OID-tree belonging to Let's
Encrypt, with a public statement that other CAs are free to use it with
the same documented semantics.

With a little ingenuity on the part of the CA, this can be readily
incorporated into pre-calculated OCSP responses (for single certificate
queries without a nonce).  The CA would need the general ability to roll
out a few updated OCSP responses outside its usual batch schedule, which
is also useful for speeding up regular revocations (for clients that
check OCSP).

On 11/08/2017 15:17, Alex Gaynor wrote:

This is a great point, re:automated issuance systems like ACME. I've
suggested to the Let's Encrypt folks the idea of a "should I re-issue"
endpoint that clients can poll. This would give CAs a programatic ability
to broadcast to subscribers that they should reissue now because the cert
is about to be revoked (or because they want to shift which SCTs are
embedded, or to indicate an appropriate renewal period for short lived
certs, or... turns out there are a lot of use case!) and then automatically
revoke at the end of the defined period.

Hopefully something useful comes out of that :-)

Alex

On Thu, Aug 10, 2017 at 7:11 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Not really - most CAs reuse validation information for the time period
specified under the BRs, which is currently 825 days under section 4.2.1.
The hardest part of the whole process is typically contacting the customer
to start the replacement process. The problem is probably worse for fully
automated CAs who don't necessarily have a close relationship with the
customer, perhaps only an email address that can be used to let them know
their website is about to go down.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=
digicert.com@lists.mozilla
.org] On Behalf Of Jakob Bohm via dev-security-policy
Sent: Thursday, August 10, 2017 3:40 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with invalidly long serial numbers

But that would require the issuer of the replacement cert (which might not
be a fast-issue DV cert) to complete validation in something like 36 hours,
which is much shorter than the normal time taken to do proper OV and/or EV
validation.

I have previously suggested 14 days for live certificates that don't cause
actual security issues.  This would be enough for most subscribers to
either
get a reissued certificate (for free) from the original CA or set up an
account with a competing CA and get at least a basic OV cert.

On 10/08/2017 03:02, Jeremy Rowley wrote:

No objection to 72 hours v. 1 business day.  I agree it should be
short and
72 hours seems perfectly reasonable .

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.m
ozilla .org] On Behalf Of Paul Kehrer via dev-security-policy
Sent: Wednesday, August 9, 2017 4:57 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with invalidly long serial numbers

On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:

All CAS are required to maintain the capability to process and
receive

revocation requests 24x7 under the baseline requirements. The headache
is not with the CA. Rather, it's notifying the customer that their
certificate will be revoked before the start of the next business day.
Having a one to two business day rule  instead of 24 hours for non
compromise issues gives the end entity time to receive the
notification and replace their certificate with a compliant version.

I'm sure many customers would absolutely prefer that and on the
surface it does sound like a good solution. However, I think it's
another example of the general difference of opinion between people on
this list around whether we should be holding CAs to the highest
standards or not. These mis-issued certificates are typically not a
security concern, but they speak to either ignorance on the part of CA
operators or a pattern of lackadaisical controls within the issuance
systems. Neither of these is acceptable behavior at this juncture.

Conformance with the BRs has

Re: Certificates with invalidly long serial numbers

[Alex Gaynor via dev-security-policy]

This is a great point, re:automated issuance systems like ACME. I've
suggested to the Let's Encrypt folks the idea of a "should I re-issue"
endpoint that clients can poll. This would give CAs a programatic ability
to broadcast to subscribers that they should reissue now because the cert
is about to be revoked (or because they want to shift which SCTs are
embedded, or to indicate an appropriate renewal period for short lived
certs, or... turns out there are a lot of use case!) and then automatically
revoke at the end of the defined period.

Hopefully something useful comes out of that :-)

Alex

On Thu, Aug 10, 2017 at 7:11 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Not really - most CAs reuse validation information for the time period
> specified under the BRs, which is currently 825 days under section 4.2.1.
> The hardest part of the whole process is typically contacting the customer
> to start the replacement process. The problem is probably worse for fully
> automated CAs who don't necessarily have a close relationship with the
> customer, perhaps only an email address that can be used to let them know
> their website is about to go down.
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=
> digicert.com@lists.mozilla
> .org] On Behalf Of Jakob Bohm via dev-security-policy
> Sent: Thursday, August 10, 2017 3:40 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Certificates with invalidly long serial numbers
>
> But that would require the issuer of the replacement cert (which might not
> be a fast-issue DV cert) to complete validation in something like 36 hours,
> which is much shorter than the normal time taken to do proper OV and/or EV
> validation.
>
> I have previously suggested 14 days for live certificates that don't cause
> actual security issues.  This would be enough for most subscribers to
> either
> get a reissued certificate (for free) from the original CA or set up an
> account with a competing CA and get at least a basic OV cert.
>
> On 10/08/2017 03:02, Jeremy Rowley wrote:
> > No objection to 72 hours v. 1 business day.  I agree it should be
> > short and
> > 72 hours seems perfectly reasonable .
> >
> > -Original Message-
> > From: dev-security-policy
> > [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.m
> > ozilla .org] On Behalf Of Paul Kehrer via dev-security-policy
> > Sent: Wednesday, August 9, 2017 4:57 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Re: Certificates with invalidly long serial numbers
> >
> > On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:
> >> All CAS are required to maintain the capability to process and
> >> receive
> > revocation requests 24x7 under the baseline requirements. The headache
> > is not with the CA. Rather, it's notifying the customer that their
> > certificate will be revoked before the start of the next business day.
> > Having a one to two business day rule  instead of 24 hours for non
> > compromise issues gives the end entity time to receive the
> > notification and replace their certificate with a compliant version.
> >
> > I'm sure many customers would absolutely prefer that and on the
> > surface it does sound like a good solution. However, I think it's
> > another example of the general difference of opinion between people on
> > this list around whether we should be holding CAs to the highest
> > standards or not. These mis-issued certificates are typically not a
> > security concern, but they speak to either ignorance on the part of CA
> > operators or a pattern of lackadaisical controls within the issuance
> > systems. Neither of these is acceptable behavior at this juncture.
> Conformance with the BRs has been mandatory for over 5 years now.
> > Customers need to be made aware of the failures of their chosen
> > providers and the responsibilities incumbent upon them as subscribers,
> > and if their own certificate installation/replacement processes are
> > sufficiently archaic as to make it difficult to replace a certificate
> > in an automated fashion then they should rectify that immediately.
> >
> > That said, to continue the thought experiment, what does "1-2 business
> days"
> > really mean?Does the CA get 1-2 business days followed by 1-2 for the
> > customer? What if there's a holiday in the CA's country of operations
> > followed by a holiday in the customer's home country? How quickly does
> > this window extend to 2+ weeks? If you were to go down this path I'

Re: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

On 11/08/2017 00:12, Ryan Sleevi wrote:

Could you explain how it benefits Mozilla users to optimize for OV or EV,
given that it does not provide any additional security value?



Of all the browsers I have tried, Firefox is the one that most
aggressively promotes EV certificates, going to the extent of displaying
unhelpful status messages ("This website does not supply ownership
information") for OV and DV certificates.


It seems far better for the security of users, and the ecosystem, to have
such certificates revoked in 24 hours. If the subscriber's selection of
certificate type (e.g. OV or EV) makes it difficult to replace, then that's
a market choice they've made, given that it offers no objective security
value over DV, and it being possible to replace that certificate with a DV
certificate in a timely fashion.


Note that I was considering the desirability of the subscriber switching
CAs in response to such events (others have argued for that in this
thread).  If the subscriber switches to a different CA, that CA has no
validation data on file.

Also, the way the BRs specify the validation data reuse period and the
maximum certificate validity period, they encourage the creation of
situations where certificates expire long after the validation data
reuse limit.  Some CAs go out of their way to avoid that, but it is not
a BR requirement.



24 hours is enough for most subscribers to get a reissued certificate. I
don't think we should speculate about what cost it is (that's between them
and the CA) or their selection of validation type (of which, for objective
security value, only the domain name matters).



The only cost consideration I mentioned was a strong suggestion that if
the original CA issues the replacement certificate, the CA should bear
the cost.



On Thu, Aug 10, 2017 at 5:39 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


But that would require the issuer of the replacement cert (which might
not be a fast-issue DV cert) to complete validation in something like 36
hours, which is much shorter than the normal time taken to do proper OV
and/or EV validation.

I have previously suggested 14 days for live certificates that don't
cause actual security issues.  This would be enough for most subscribers
to either get a reissued certificate (for free) from the original CA or
set up an account with a competing CA and get at least a basic OV cert.

On 10/08/2017 03:02, Jeremy Rowley wrote:


No objection to 72 hours v. 1 business day.  I agree it should be short
and
72 hours seems perfectly reasonable .

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.
com@lists.mozilla
.org] On Behalf Of Paul Kehrer via dev-security-policy
Sent: Wednesday, August 9, 2017 4:57 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with invalidly long serial numbers

On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:


All CAS are required to maintain the capability to process and receive


revocation requests 24x7 under the baseline requirements. The headache is
not with the CA. Rather, it's notifying the customer that their
certificate
will be revoked before the start of the next business day. Having a one to
two business day rule  instead of 24 hours for non compromise issues gives
the end entity time to receive the notification and replace their
certificate with a compliant version.

I'm sure many customers would absolutely prefer that and on the surface it
does sound like a good solution. However, I think it's another example of
the general difference of opinion between people on this list around
whether
we should be holding CAs to the highest standards or not. These mis-issued
certificates are typically not a security concern, but they speak to
either
ignorance on the part of CA operators or a pattern of lackadaisical
controls
within the issuance systems. Neither of these is acceptable behavior at
this
juncture. Conformance with the BRs has been mandatory for over 5 years
now.
Customers need to be made aware of the failures of their chosen providers
and the responsibilities incumbent upon them as subscribers, and if their
own certificate installation/replacement processes are sufficiently
archaic
as to make it difficult to replace a certificate in an automated fashion
then they should rectify that immediately.

That said, to continue the thought experiment, what does "1-2 business
days"
really mean?Does the CA get 1-2 business days followed by 1-2 for the
customer? What if there's a holiday in the CA's country of operations
followed by a holiday in the customer's home country? How quickly does
this
window extend to 2+ weeks? If you were to go down this path I'd strongly
prefer it to be a hard deadline (e.g. 72 hours) and not anything related
to
business days.





Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wi

RE: Certificates with invalidly long serial numbers

[Jeremy Rowley via dev-security-policy]

I disagree - 24 hours is enough to reissue the certificate, but  24 hours 
usually isn't enough to contact the subscriber, regardless of cert type. 

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, August 10, 2017 4:13 PM
To: Jakob Bohm <jb-mozi...@wisemo.com>
Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: Certificates with invalidly long serial numbers

Could you explain how it benefits Mozilla users to optimize for OV or EV, given 
that it does not provide any additional security value?

It seems far better for the security of users, and the ecosystem, to have such 
certificates revoked in 24 hours. If the subscriber's selection of certificate 
type (e.g. OV or EV) makes it difficult to replace, then that's a market choice 
they've made, given that it offers no objective security value over DV, and it 
being possible to replace that certificate with a DV certificate in a timely 
fashion.

24 hours is enough for most subscribers to get a reissued certificate. I don't 
think we should speculate about what cost it is (that's between them and the 
CA) or their selection of validation type (of which, for objective security 
value, only the domain name matters).

On Thu, Aug 10, 2017 at 5:39 PM, Jakob Bohm via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> But that would require the issuer of the replacement cert (which might 
> not be a fast-issue DV cert) to complete validation in something like 
> 36 hours, which is much shorter than the normal time taken to do 
> proper OV and/or EV validation.
>
> I have previously suggested 14 days for live certificates that don't 
> cause actual security issues.  This would be enough for most 
> subscribers to either get a reissued certificate (for free) from the 
> original CA or set up an account with a competing CA and get at least a basic 
> OV cert.
>
> On 10/08/2017 03:02, Jeremy Rowley wrote:
>
>> No objection to 72 hours v. 1 business day.  I agree it should be 
>> short and
>> 72 hours seems perfectly reasonable .
>>
>> -Original Message-
>> From: dev-security-policy
>> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.
>> com@lists.mozilla
>> .org] On Behalf Of Paul Kehrer via dev-security-policy
>> Sent: Wednesday, August 9, 2017 4:57 PM
>> To: mozilla-dev-security-pol...@lists.mozilla.org
>> Subject: Re: Certificates with invalidly long serial numbers
>>
>> On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:
>>
>>> All CAS are required to maintain the capability to process and 
>>> receive
>>>
>> revocation requests 24x7 under the baseline requirements. The 
>> headache is not with the CA. Rather, it's notifying the customer that 
>> their certificate will be revoked before the start of the next 
>> business day. Having a one to two business day rule  instead of 24 
>> hours for non compromise issues gives the end entity time to receive 
>> the notification and replace their certificate with a compliant 
>> version.
>>
>> I'm sure many customers would absolutely prefer that and on the 
>> surface it does sound like a good solution. However, I think it's 
>> another example of the general difference of opinion between people 
>> on this list around whether we should be holding CAs to the highest 
>> standards or not. These mis-issued certificates are typically not a 
>> security concern, but they speak to either ignorance on the part of 
>> CA operators or a pattern of lackadaisical controls within the 
>> issuance systems. Neither of these is acceptable behavior at this 
>> juncture. Conformance with the BRs has been mandatory for over 5 
>> years now.
>> Customers need to be made aware of the failures of their chosen 
>> providers and the responsibilities incumbent upon them as 
>> subscribers, and if their own certificate installation/replacement 
>> processes are sufficiently archaic as to make it difficult to replace 
>> a certificate in an automated fashion then they should rectify that 
>> immediately.
>>
>> That said, to continue the thought experiment, what does "1-2 
>> business days"
>> really mean?Does the CA get 1-2 business days followed by 1-2 for the 
>> customer? What if there's a holiday in the CA's country of operations 
>> followed by a holiday in the customer's home country? How quickly 
>> does this window extend to 2+ weeks? If you were to go down this path 
>> I'd strongly prefer it to be a ha

RE: Certificates with invalidly long serial numbers

[Jeremy Rowley via dev-security-policy]

Not really - most CAs reuse validation information for the time period
specified under the BRs, which is currently 825 days under section 4.2.1.
The hardest part of the whole process is typically contacting the customer
to start the replacement process. The problem is probably worse for fully
automated CAs who don't necessarily have a close relationship with the
customer, perhaps only an email address that can be used to let them know
their website is about to go down.   

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Jakob Bohm via dev-security-policy
Sent: Thursday, August 10, 2017 3:40 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with invalidly long serial numbers

But that would require the issuer of the replacement cert (which might not
be a fast-issue DV cert) to complete validation in something like 36 hours,
which is much shorter than the normal time taken to do proper OV and/or EV
validation.

I have previously suggested 14 days for live certificates that don't cause
actual security issues.  This would be enough for most subscribers to either
get a reissued certificate (for free) from the original CA or set up an
account with a competing CA and get at least a basic OV cert.

On 10/08/2017 03:02, Jeremy Rowley wrote:
> No objection to 72 hours v. 1 business day.  I agree it should be 
> short and
> 72 hours seems perfectly reasonable .
> 
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.m
> ozilla .org] On Behalf Of Paul Kehrer via dev-security-policy
> Sent: Wednesday, August 9, 2017 4:57 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Certificates with invalidly long serial numbers
> 
> On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:
>> All CAS are required to maintain the capability to process and 
>> receive
> revocation requests 24x7 under the baseline requirements. The headache 
> is not with the CA. Rather, it's notifying the customer that their 
> certificate will be revoked before the start of the next business day. 
> Having a one to two business day rule  instead of 24 hours for non 
> compromise issues gives the end entity time to receive the 
> notification and replace their certificate with a compliant version.
> 
> I'm sure many customers would absolutely prefer that and on the 
> surface it does sound like a good solution. However, I think it's 
> another example of the general difference of opinion between people on 
> this list around whether we should be holding CAs to the highest 
> standards or not. These mis-issued certificates are typically not a 
> security concern, but they speak to either ignorance on the part of CA 
> operators or a pattern of lackadaisical controls within the issuance 
> systems. Neither of these is acceptable behavior at this juncture.
Conformance with the BRs has been mandatory for over 5 years now.
> Customers need to be made aware of the failures of their chosen 
> providers and the responsibilities incumbent upon them as subscribers, 
> and if their own certificate installation/replacement processes are 
> sufficiently archaic as to make it difficult to replace a certificate 
> in an automated fashion then they should rectify that immediately.
> 
> That said, to continue the thought experiment, what does "1-2 business
days"
> really mean?Does the CA get 1-2 business days followed by 1-2 for the 
> customer? What if there's a holiday in the CA's country of operations 
> followed by a holiday in the customer's home country? How quickly does 
> this window extend to 2+ weeks? If you were to go down this path I'd 
> strongly prefer it to be a hard deadline (e.g. 72 hours) and not 
> anything related to business days.
> 


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com Transformervej
29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10 This public discussion
message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Ryan Sleevi via dev-security-policy]

Could you explain how it benefits Mozilla users to optimize for OV or EV,
given that it does not provide any additional security value?

It seems far better for the security of users, and the ecosystem, to have
such certificates revoked in 24 hours. If the subscriber's selection of
certificate type (e.g. OV or EV) makes it difficult to replace, then that's
a market choice they've made, given that it offers no objective security
value over DV, and it being possible to replace that certificate with a DV
certificate in a timely fashion.

24 hours is enough for most subscribers to get a reissued certificate. I
don't think we should speculate about what cost it is (that's between them
and the CA) or their selection of validation type (of which, for objective
security value, only the domain name matters).

On Thu, Aug 10, 2017 at 5:39 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> But that would require the issuer of the replacement cert (which might
> not be a fast-issue DV cert) to complete validation in something like 36
> hours, which is much shorter than the normal time taken to do proper OV
> and/or EV validation.
>
> I have previously suggested 14 days for live certificates that don't
> cause actual security issues.  This would be enough for most subscribers
> to either get a reissued certificate (for free) from the original CA or
> set up an account with a competing CA and get at least a basic OV cert.
>
> On 10/08/2017 03:02, Jeremy Rowley wrote:
>
>> No objection to 72 hours v. 1 business day.  I agree it should be short
>> and
>> 72 hours seems perfectly reasonable .
>>
>> -Original Message-
>> From: dev-security-policy
>> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.
>> com@lists.mozilla
>> .org] On Behalf Of Paul Kehrer via dev-security-policy
>> Sent: Wednesday, August 9, 2017 4:57 PM
>> To: mozilla-dev-security-pol...@lists.mozilla.org
>> Subject: Re: Certificates with invalidly long serial numbers
>>
>> On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:
>>
>>> All CAS are required to maintain the capability to process and receive
>>>
>> revocation requests 24x7 under the baseline requirements. The headache is
>> not with the CA. Rather, it's notifying the customer that their
>> certificate
>> will be revoked before the start of the next business day. Having a one to
>> two business day rule  instead of 24 hours for non compromise issues gives
>> the end entity time to receive the notification and replace their
>> certificate with a compliant version.
>>
>> I'm sure many customers would absolutely prefer that and on the surface it
>> does sound like a good solution. However, I think it's another example of
>> the general difference of opinion between people on this list around
>> whether
>> we should be holding CAs to the highest standards or not. These mis-issued
>> certificates are typically not a security concern, but they speak to
>> either
>> ignorance on the part of CA operators or a pattern of lackadaisical
>> controls
>> within the issuance systems. Neither of these is acceptable behavior at
>> this
>> juncture. Conformance with the BRs has been mandatory for over 5 years
>> now.
>> Customers need to be made aware of the failures of their chosen providers
>> and the responsibilities incumbent upon them as subscribers, and if their
>> own certificate installation/replacement processes are sufficiently
>> archaic
>> as to make it difficult to replace a certificate in an automated fashion
>> then they should rectify that immediately.
>>
>> That said, to continue the thought experiment, what does "1-2 business
>> days"
>> really mean?Does the CA get 1-2 business days followed by 1-2 for the
>> customer? What if there's a holiday in the CA's country of operations
>> followed by a holiday in the customer's home country? How quickly does
>> this
>> window extend to 2+ weeks? If you were to go down this path I'd strongly
>> prefer it to be a hard deadline (e.g. 72 hours) and not anything related
>> to
>> business days.
>>
>>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ___
> 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: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

But that would require the issuer of the replacement cert (which might
not be a fast-issue DV cert) to complete validation in something like 36
hours, which is much shorter than the normal time taken to do proper OV
and/or EV validation.

I have previously suggested 14 days for live certificates that don't
cause actual security issues.  This would be enough for most subscribers
to either get a reissued certificate (for free) from the original CA or
set up an account with a competing CA and get at least a basic OV cert.

On 10/08/2017 03:02, Jeremy Rowley wrote:

No objection to 72 hours v. 1 business day.  I agree it should be short and
72 hours seems perfectly reasonable .

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Paul Kehrer via dev-security-policy
Sent: Wednesday, August 9, 2017 4:57 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with invalidly long serial numbers

On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:

All CAS are required to maintain the capability to process and receive

revocation requests 24x7 under the baseline requirements. The headache is
not with the CA. Rather, it's notifying the customer that their certificate
will be revoked before the start of the next business day. Having a one to
two business day rule  instead of 24 hours for non compromise issues gives
the end entity time to receive the notification and replace their
certificate with a compliant version.

I'm sure many customers would absolutely prefer that and on the surface it
does sound like a good solution. However, I think it's another example of
the general difference of opinion between people on this list around whether
we should be holding CAs to the highest standards or not. These mis-issued
certificates are typically not a security concern, but they speak to either
ignorance on the part of CA operators or a pattern of lackadaisical controls
within the issuance systems. Neither of these is acceptable behavior at this
juncture. Conformance with the BRs has been mandatory for over 5 years now.
Customers need to be made aware of the failures of their chosen providers
and the responsibilities incumbent upon them as subscribers, and if their
own certificate installation/replacement processes are sufficiently archaic
as to make it difficult to replace a certificate in an automated fashion
then they should rectify that immediately.

That said, to continue the thought experiment, what does "1-2 business days"
really mean?Does the CA get 1-2 business days followed by 1-2 for the
customer? What if there's a holiday in the CA's country of operations
followed by a holiday in the customer's home country? How quickly does this
window extend to 2+ weeks? If you were to go down this path I'd strongly
prefer it to be a hard deadline (e.g. 72 hours) and not anything related to
business days.




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[okaphone.elektronika--- via dev-security-policy]

The answers from CAs we typically see in this group are more along the lines of 
not thinking it necessary to revoke at all than needing more time, I'd say. So 
I don't really see what this idea that 24 hours would be too short is based on. 
I think relaxing the revocation time limit may in fact be a solution for a 
problem that doesn't exist (much). After all quite a few of these misissued 
certificates will not even work properly.

What I don't like is that the answers of CAs hardly ever explain what happened, 
how it was possible that it happened and what has/will be done to prevent is 
from happening again. It looks like they have no real incentive to do things 
right.

Yes, in some cases the bad certificates will be in use and the revocation may 
cause problems (not too much I understand as revocation mostly does not work 
;-) for CA-customers and their website visitors. But having to deal with that 
when they are doing it wrong is the only motivation a CA has for doing things 
right. As things are this doesn't seem to motivate them very much. ;-)

And customers will have to learn to choose CAs that don't cause this kind of 
problems. Or suffer them... that is up to them.

On to other hand customers also have little motivation to do things right. To 
most of them HTTPS is something they are forced into by the recent HTTPS-only 
drive by the browsers.

All in all I appreciate how CT is pulling all this garbage into broad daylight. 
We should be simply aiming to get it cleared away. And if there is stuff in 
there that is not worth revoking promptly then it would be better to remove 
theses issuance requirements than to relax the revocation requirement.

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

Re: Certificates with invalidly long serial numbers

[Matt Palmer via dev-security-policy]

On Wed, Aug 09, 2017 at 04:21:19PM +0200, Jakob Bohm via dev-security-policy 
wrote:
> On 08/08/2017 20:46, Alex Gaynor wrote:
> > It's from the BRs 4.9.1.1:
> > 
> >   The CA SHALL revoke a Certificate within 24 hours if one or more of
> > the following occurs:
> > 
> > It's also not a penalty on the CA, it's a remediation step for them to
> > undertake.
> > 
> 
> It is a disruption and penalty to the 3rd party certificate holder to
> have their certificate suddenly revoked due to a bureaucratic mistake at
> the CA.

If a certificate holder feels that they have been materially damaged as a
result of their CA's negligence, they should take that up with the CA.

- Matt

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

RE: Certificates with invalidly long serial numbers

[Jeremy Rowley via dev-security-policy]

No objection to 72 hours v. 1 business day.  I agree it should be short and
72 hours seems perfectly reasonable . 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Paul Kehrer via dev-security-policy
Sent: Wednesday, August 9, 2017 4:57 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with invalidly long serial numbers

On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:
> All CAS are required to maintain the capability to process and receive
revocation requests 24x7 under the baseline requirements. The headache is
not with the CA. Rather, it's notifying the customer that their certificate
will be revoked before the start of the next business day. Having a one to
two business day rule  instead of 24 hours for non compromise issues gives
the end entity time to receive the notification and replace their
certificate with a compliant version.

I'm sure many customers would absolutely prefer that and on the surface it
does sound like a good solution. However, I think it's another example of
the general difference of opinion between people on this list around whether
we should be holding CAs to the highest standards or not. These mis-issued
certificates are typically not a security concern, but they speak to either
ignorance on the part of CA operators or a pattern of lackadaisical controls
within the issuance systems. Neither of these is acceptable behavior at this
juncture. Conformance with the BRs has been mandatory for over 5 years now.
Customers need to be made aware of the failures of their chosen providers
and the responsibilities incumbent upon them as subscribers, and if their
own certificate installation/replacement processes are sufficiently archaic
as to make it difficult to replace a certificate in an automated fashion
then they should rectify that immediately.

That said, to continue the thought experiment, what does "1-2 business days"
really mean?Does the CA get 1-2 business days followed by 1-2 for the
customer? What if there's a holiday in the CA's country of operations
followed by a holiday in the customer's home country? How quickly does this
window extend to 2+ weeks? If you were to go down this path I'd strongly
prefer it to be a hard deadline (e.g. 72 hours) and not anything related to
business days.

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Paul Kehrer via dev-security-policy]

On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:
> All CAS are required to maintain the capability to process and receive 
> revocation requests 24x7 under the baseline requirements. The headache is not 
> with the CA. Rather, it's notifying the customer that their certificate will 
> be revoked before the start of the next business day. Having a one to two 
> business day rule  instead of 24 hours for non compromise issues gives the 
> end entity time to receive the notification and replace their certificate 
> with a compliant version.

I'm sure many customers would absolutely prefer that and on the surface it does 
sound like a good solution. However, I think it's another example of the 
general difference of opinion between people on this list around whether we 
should be holding CAs to the highest standards or not. These mis-issued 
certificates are typically not a security concern, but they speak to either 
ignorance on the part of CA operators or a pattern of lackadaisical controls 
within the issuance systems. Neither of these is acceptable behavior at this 
juncture. Conformance with the BRs has been mandatory for over 5 years now. 
Customers need to be made aware of the failures of their chosen providers and 
the responsibilities incumbent upon them as subscribers, and if their own 
certificate installation/replacement processes are sufficiently archaic as to 
make it difficult to replace a certificate in an automated fashion then they 
should rectify that immediately.

That said, to continue the thought experiment, what does "1-2 business days" 
really mean?Does the CA get 1-2 business days followed by 1-2 for the customer? 
What if there's a holiday in the CA's country of operations followed by a 
holiday in the customer's home country? How quickly does this window extend to 
2+ weeks? If you were to go down this path I'd strongly prefer it to be a hard 
deadline (e.g. 72 hours) and not anything related to business days.

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

Re: Certificates with invalidly long serial numbers

[Ryan Sleevi via dev-security-policy]

On Wednesday, August 9, 2017 at 12:05:32 AM UTC-4, Peter Gutmann wrote:
> Matthew Hardeman via dev-security-policy 
>  writes:
> 
> >I merely raise the point that IF the framers of the 20 bytes rule did, in
> >fact, simultaneously intend that arbitrary SHA-1 hash results should be able
> >to be stuffed into the serial number field AND SIMULTANEOUSLY that the DER
> >encoded integer field value must be a positive integer and that insertion of
> >a leading 0x00 byte to ensure that the high order bit would be 0 (thus
> >regarded as a positive value per the coding), THEN it must follow that at
> >least in the minds of those who engineered the rule, that the inserted 0x00
> >byte must not be part of the 20 byte maximum size of the value AS legitimate
> >SHA-1 values of 20 bytes do include values where the high order bit would be
> >1 and without pre-padding the proper interpretation of such a value would be
> >as a negative integer.
> 
> That sounds like sensible reasoning.  So you need to accept at least 20 + 1
> bytes, or better yet just set it to 32 or 64 bytes and be done with it because
> there are bound to be implementations out there that don't respect the 20-byte
> limit.  At the very least though you'd need to be able to handle 20 + 1.
> 
> Peter.

I see. So the solution to standards non-compliance that creates compatibility 
issues is to invent arbitrary standards (32 or 64 bytes)? How does that align 
with https://www.mozilla.org/en-US/about/manifesto/#principle-06 ?

The original language in RFC 2459 restricted it to INTEGER, and in 2459 had no 
length limit (thus, unbounded). This was reformed in RFC 3280, which introduced 
the language limiting the upper bound to 20 octets - which clearly intends to 
be the encoded value, by virtue of X.690. Similarly, when coupled with the 
'positive integer', this would hopefully have clearly limited the length to 20 
octets - there's no "20 plus padding" because the guarantee of a positive 
integer is a transformation that happens  before the conversion to octets, and 
the result is limited to 20 octets, and those octets are the result of encoding 
to the appropriate rules (BER or DER).

So no, this attempt at retro-analyzing 'large enough to fit SHA-1' does not fit 
the historic context, does not fit the text, and the argument for arbitrary 
bytes (e.g. actively ignoring 3280) is equally silly.

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

Re: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

(Note: Top posting because Alex did so)

FYI: Last night, I posted a proposed very very rough draft overall
graduation of revocation periods for various kinds of issues in
mailman.1730.1502216764.14894.dev-security-pol...@lists.mozilla.org
(Part of this thread).

This only received a meaningless reply from a VIP bureaucrat.

On 09/08/2017 16:22, Alex Gaynor wrote:

I'm not really sure I agree that there should be multiple tiers of
revocation, but just to go along with the thought experiment..

If there were, "key compromise" is definitely not the only case I'd want on
the more aggressive schedule, I'd also want to include cases where there
was a failure in DV and the rightful owner of a domain wanted the cert
revoked.

Alex

On Wed, Aug 9, 2017 at 10:19 AM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


All CAS are required to maintain the capability to process and receive
revocation requests 24x7 under the baseline requirements. The headache is
not with the CA. Rather, it's notifying the customer that their certificate
will be revoked before the start of the next business day. Having a one to
two business day rule  instead of 24 hours for non compromise issues gives
the end entity time to receive the notification and replace their
certificate with a compliant version.


On Aug 9, 2017, at 1:10 AM, Paul Kehrer via dev-security-policy <

dev-security-policy@lists.mozilla.org> wrote:



On Tuesday, August 8, 2017 at 7:03:19 PM UTC-5, Jeremy Rowley wrote:
24 hours is super short when it's a Saturday morning at 4 am and it’s a

European government entity. I agree that is what the policy says now, but,
for lower risk items, the policy should change, preferably to at least one
business day.




It is short, but any CA possessing global trust should already have

procedures in place for handling revocation in a prompt manner. It seems
odd that it would be onerous for them to revoke a non-compliant
certificate. The only difference is a need to confirm to the CA's
satisfaction that the given certificate is in violation of the BRs, which I
would expect any competent CA to be eminently capable of doing.





Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Jeremy Rowley via dev-security-policy]

Totally agree Alex. The tiers I'm proposing are 1) subscriber requests 
revocation, cert was issued to the wrong entity, or the key was compromised and 
2) everything else

On Aug 9, 2017, at 8:22 AM, Alex Gaynor 
> wrote:

I'm not really sure I agree that there should be multiple tiers of revocation, 
but just to go along with the thought experiment..

If there were, "key compromise" is definitely not the only case I'd want on the 
more aggressive schedule, I'd also want to include cases where there was a 
failure in DV and the rightful owner of a domain wanted the cert revoked.

Alex

On Wed, Aug 9, 2017 at 10:19 AM, Jeremy Rowley via dev-security-policy 
>
 wrote:
All CAS are required to maintain the capability to process and receive 
revocation requests 24x7 under the baseline requirements. The headache is not 
with the CA. Rather, it's notifying the customer that their certificate will be 
revoked before the start of the next business day. Having a one to two business 
day rule  instead of 24 hours for non compromise issues gives the end entity 
time to receive the notification and replace their certificate with a compliant 
version.

> On Aug 9, 2017, at 1:10 AM, Paul Kehrer via dev-security-policy 
> >
>  wrote:
>
>> On Tuesday, August 8, 2017 at 7:03:19 PM UTC-5, Jeremy Rowley wrote:
>> 24 hours is super short when it's a Saturday morning at 4 am and it’s a 
>> European government entity. I agree that is what the policy says now, but, 
>> for lower risk items, the policy should change, preferably to at least one 
>> business day.
>>
>
> It is short, but any CA possessing global trust should already have 
> procedures in place for handling revocation in a prompt manner. It seems odd 
> that it would be onerous for them to revoke a non-compliant certificate. The 
> only difference is a need to confirm to the CA's satisfaction that the given 
> certificate is in violation of the BRs, which I would expect any competent CA 
> to be eminently capable of doing.
>
> -Paul
> ___
> 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: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

On 08/08/2017 21:24, Jeremy Rowley wrote:

I agree that the 24 hours seems excessive for some of these. Ive proposed at 
the cab forum we bifuracte the revocation periods to key compromise vs non key 
compromise. I'd love support there on the proposal. However, I think that until 
the rules change formally, CAs should be required to meet that strict period. 
It's not hard to make a change once general agreement is reached.



And I would suggest that until that has been resolved (one way or
another), we should have a moratorium on mass-filing revocation demands
for the kinds of violations which are expected to get a longer deadline
if the proposed changes go through.

For such, maybe post public descriptions, but delay on the formal filing 
that would start the 24 hour clock.



On Aug 8, 2017, at 1:02 PM, Jakob Bohm via dev-security-policy 
 wrote:

Some people seemed to require 24-hour revocation of these, which I also
find possibly excessive.


On 08/08/2017 20:28, Alex Gaynor wrote:
I think you're largely objecting to a strawman, no one is proposing
revoking trust in any of these threads.
The only CAs that have ever had _any_ penalty applied to them have been for
grotesque abuse of the trust vested in them.
Alex
On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

On 08/08/2017 18:43, Ryan Sleevi wrote:


On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:

I was not advocating "letting everyone decide".  I was advocating that
Mozilla show some restraint, intelligence and common sense in wielding
the new weapons that certlint and crt.sh have given us.

This shouldn't be race as to who wields the weapon first, forgiving CAs
only if they happen to report faster than some other newsgroup
participant.

This is similar to if a store boss gets a new surveillance camera in the
shop and sees that some employees are taking extra breaks when there are
few customers in the store.  It would be unreasonable for such a store
boss to discipline this with similar zeal as seeing some employees
genuinely steeling cash out of the register or selling stolen items out
of the back door.  Instead the fact that they work less when there is
less work to do should inspire reevaluation of any old rule that they
are not allowed to have a watercooler chat during work hours.

Now such a reevaluation might result in requiring them to use such
occasions to clean the floors or do some other chores (Mozilla equiv:
Deciding that the rule is important for good reason and needs to be
followed in the future) or it could result in relaxing the rule as
long as they stand ready the moment a customer arrives (Mozilla equiv:
Relaxing the requirement, initially just for Mozilla, later perhaps as a
BR change).

Dogmatically insisting on enforcing rules that were previously not
enforced due to lack of detection, just because "rules are rules" or
other such arguments seems overzealous.



Such tools have been available for over a year. CAs have been aware of
this, the ability to run it over their own corpus and self-detect and
self-report. These tools, notably, were created by one of the newest CA
applicants - Amazon - based on a methodical study of what is required of a
CA.

Your attempts to characterize it as overzealous ignore this entirely. At
this point, it's gross negligence, and attempts to argue otherwise merely
suggest a lack of understanding or concern for standards compliance and
interoperability.

Mozilla has already communicated to CAs these tools exist and their
relevance to CAs.

Perhaps we can move on from misguided apologetics and instead focus on
how to make things better. Suggestions we ignore these, at this point, are
neither productive nor relevant. Attempts to suggest tortured metaphors are
like attempting to suggest rich people deserve to be robbed, or poor people
just need to work harder - arguments that are both hollow and borderline
offensive in their reductionism. A pattern of easily preventable
misissuance has been happening,CAs have been repeatedly told to
self-detect, and clearly, some CAs, like presumably some businesses, aren't
taking security seriously. That needs to stop.



I am questioning the fairness of applying these tools, which did not
exist when the rules were written, to enforce every rule with the same
high weight.  I am not apologizing for bad behavior, I am saying if
everybody gets scrutinized this hard, we will eventually have to
distrust pretty much all the CAs, because there is no such thing as a
perfect CA organization.

So we need to prioritize the rules instead of just saying off-with-
their-heads (revoke all affected certificates in 24 hours) whenever any
formal rule was broken without actually harming security.

An example of a graduated response:

- Deliberately issued super-interception certificate: Instant revocation
  of CA trust.
- SubCA that does no vetting at all: Instant 

Re: Certificates with invalidly long serial numbers

[Alex Gaynor via dev-security-policy]

I'm not really sure I agree that there should be multiple tiers of
revocation, but just to go along with the thought experiment..

If there were, "key compromise" is definitely not the only case I'd want on
the more aggressive schedule, I'd also want to include cases where there
was a failure in DV and the rightful owner of a domain wanted the cert
revoked.

Alex

On Wed, Aug 9, 2017 at 10:19 AM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> All CAS are required to maintain the capability to process and receive
> revocation requests 24x7 under the baseline requirements. The headache is
> not with the CA. Rather, it's notifying the customer that their certificate
> will be revoked before the start of the next business day. Having a one to
> two business day rule  instead of 24 hours for non compromise issues gives
> the end entity time to receive the notification and replace their
> certificate with a compliant version.
>
> > On Aug 9, 2017, at 1:10 AM, Paul Kehrer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> >> On Tuesday, August 8, 2017 at 7:03:19 PM UTC-5, Jeremy Rowley wrote:
> >> 24 hours is super short when it's a Saturday morning at 4 am and it’s a
> European government entity. I agree that is what the policy says now, but,
> for lower risk items, the policy should change, preferably to at least one
> business day.
> >>
> >
> > It is short, but any CA possessing global trust should already have
> procedures in place for handling revocation in a prompt manner. It seems
> odd that it would be onerous for them to revoke a non-compliant
> certificate. The only difference is a need to confirm to the CA's
> satisfaction that the given certificate is in violation of the BRs, which I
> would expect any competent CA to be eminently capable of doing.
> >
> > -Paul
> > ___
> > 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: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

On 08/08/2017 20:46, Alex Gaynor wrote:

It's from the BRs 4.9.1.1:

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

It's also not a penalty on the CA, it's a remediation step for them to
undertake.



It is a disruption and penalty to the 3rd party certificate holder to
have their certificate suddenly revoked due to a bureaucratic mistake at
the CA.

It is a disruption and penalty to relying parties encountering the
certificate to suddenly receive error messages or loose connectivity due
to a bureaucratic mistake at the CA.

It is generally bad for interoperability to have certificates randomly
disappear due to someone filing mass-bugs for violations of formalities.


Alex

On Tue, Aug 8, 2017 at 2:43 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Some people seemed to require 24-hour revocation of these, which I also
find possibly excessive.

On 08/08/2017 20:28, Alex Gaynor wrote:


I think you're largely objecting to a strawman, no one is proposing
revoking trust in any of these threads.

The only CAs that have ever had _any_ penalty applied to them have been
for
grotesque abuse of the trust vested in them.

Alex

On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

On 08/08/2017 18:43, Ryan Sleevi wrote:


On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:


I was not advocating "letting everyone decide".  I was advocating that

Mozilla show some restraint, intelligence and common sense in wielding
the new weapons that certlint and crt.sh have given us.

This shouldn't be race as to who wields the weapon first, forgiving CAs
only if they happen to report faster than some other newsgroup
participant.

This is similar to if a store boss gets a new surveillance camera in
the
shop and sees that some employees are taking extra breaks when there
are
few customers in the store.  It would be unreasonable for such a store
boss to discipline this with similar zeal as seeing some employees
genuinely steeling cash out of the register or selling stolen items out
of the back door.  Instead the fact that they work less when there is
less work to do should inspire reevaluation of any old rule that they
are not allowed to have a watercooler chat during work hours.

Now such a reevaluation might result in requiring them to use such
occasions to clean the floors or do some other chores (Mozilla equiv:
Deciding that the rule is important for good reason and needs to be
followed in the future) or it could result in relaxing the rule as
long as they stand ready the moment a customer arrives (Mozilla equiv:
Relaxing the requirement, initially just for Mozilla, later perhaps as
a
BR change).

Dogmatically insisting on enforcing rules that were previously not
enforced due to lack of detection, just because "rules are rules" or
other such arguments seems overzealous.


Such tools have been available for over a year. CAs have been aware of

this, the ability to run it over their own corpus and self-detect and
self-report. These tools, notably, were created by one of the newest CA
applicants - Amazon - based on a methodical study of what is required
of a
CA.

Your attempts to characterize it as overzealous ignore this entirely. At
this point, it's gross negligence, and attempts to argue otherwise
merely
suggest a lack of understanding or concern for standards compliance and
interoperability.

Mozilla has already communicated to CAs these tools exist and their
relevance to CAs.

Perhaps we can move on from misguided apologetics and instead focus on
how to make things better. Suggestions we ignore these, at this point,
are
neither productive nor relevant. Attempts to suggest tortured metaphors
are
like attempting to suggest rich people deserve to be robbed, or poor
people
just need to work harder - arguments that are both hollow and borderline
offensive in their reductionism. A pattern of easily preventable
misissuance has been happening,CAs have been repeatedly told to
self-detect, and clearly, some CAs, like presumably some businesses,
aren't
taking security seriously. That needs to stop.


I am questioning the fairness of applying these tools, which did not

exist when the rules were written, to enforce every rule with the same
high weight.  I am not apologizing for bad behavior, I am saying if
everybody gets scrutinized this hard, we will eventually have to
distrust pretty much all the CAs, because there is no such thing as a
perfect CA organization.

So we need to prioritize the rules instead of just saying off-with-
their-heads (revoke all affected certificates in 24 hours) whenever any
formal rule was broken without actually harming security.

An example of a graduated response:

- Deliberately issued super-interception certificate: Instant revocation
   of CA trust.
- SubCA that does no vetting at all: Instant revocation and adding to
   OneCRL.
- 

Re: Certificates with invalidly long serial numbers

[Jeremy Rowley via dev-security-policy]

All CAS are required to maintain the capability to process and receive 
revocation requests 24x7 under the baseline requirements. The headache is not 
with the CA. Rather, it's notifying the customer that their certificate will be 
revoked before the start of the next business day. Having a one to two business 
day rule  instead of 24 hours for non compromise issues gives the end entity 
time to receive the notification and replace their certificate with a compliant 
version.

> On Aug 9, 2017, at 1:10 AM, Paul Kehrer via dev-security-policy 
>  wrote:
> 
>> On Tuesday, August 8, 2017 at 7:03:19 PM UTC-5, Jeremy Rowley wrote:
>> 24 hours is super short when it's a Saturday morning at 4 am and it’s a 
>> European government entity. I agree that is what the policy says now, but, 
>> for lower risk items, the policy should change, preferably to at least one 
>> business day. 
>> 
> 
> It is short, but any CA possessing global trust should already have 
> procedures in place for handling revocation in a prompt manner. It seems odd 
> that it would be onerous for them to revoke a non-compliant certificate. The 
> only difference is a need to confirm to the CA's satisfaction that the given 
> certificate is in violation of the BRs, which I would expect any competent CA 
> to be eminently capable of doing.
> 
> -Paul
> ___
> 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: Certificates with invalidly long serial numbers

[Paul Kehrer via dev-security-policy]

On Tuesday, August 8, 2017 at 7:03:19 PM UTC-5, Jeremy Rowley wrote:
> 24 hours is super short when it's a Saturday morning at 4 am and it’s a 
> European government entity. I agree that is what the policy says now, but, 
> for lower risk items, the policy should change, preferably to at least one 
> business day. 
> 

It is short, but any CA possessing global trust should already have procedures 
in place for handling revocation in a prompt manner. It seems odd that it would 
be onerous for them to revoke a non-compliant certificate. The only difference 
is a need to confirm to the CA's satisfaction that the given certificate is in 
violation of the BRs, which I would expect any competent CA to be eminently 
capable of doing.

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

Re: Certificates with invalidly long serial numbers

[Peter Gutmann via dev-security-policy]

Matthew Hardeman via dev-security-policy 
 writes:

>I merely raise the point that IF the framers of the 20 bytes rule did, in
>fact, simultaneously intend that arbitrary SHA-1 hash results should be able
>to be stuffed into the serial number field AND SIMULTANEOUSLY that the DER
>encoded integer field value must be a positive integer and that insertion of
>a leading 0x00 byte to ensure that the high order bit would be 0 (thus
>regarded as a positive value per the coding), THEN it must follow that at
>least in the minds of those who engineered the rule, that the inserted 0x00
>byte must not be part of the 20 byte maximum size of the value AS legitimate
>SHA-1 values of 20 bytes do include values where the high order bit would be
>1 and without pre-padding the proper interpretation of such a value would be
>as a negative integer.

That sounds like sensible reasoning.  So you need to accept at least 20 + 1
bytes, or better yet just set it to 32 or 64 bytes and be done with it because
there are bound to be implementations out there that don't respect the 20-byte
limit.  At the very least though you'd need to be able to handle 20 + 1.

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

RE: Certificates with invalidly long serial numbers

[Jeremy Rowley via dev-security-policy]

24 hours is super short when it's a Saturday morning at 4 am and it’s a 
European government entity. I agree that is what the policy says now, but, for 
lower risk items, the policy should change, preferably to at least one business 
day. 

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Alex Gaynor via dev-security-policy
Sent: Tuesday, August 8, 2017 12:46 PM
To: Jakob Bohm <jb-mozi...@wisemo.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with invalidly long serial numbers

It's from the BRs 4.9.1.1:

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

It's also not a penalty on the CA, it's a remediation step for them to 
undertake.

Alex

On Tue, Aug 8, 2017 at 2:43 PM, Jakob Bohm via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> Some people seemed to require 24-hour revocation of these, which I 
> also find possibly excessive.
>
> On 08/08/2017 20:28, Alex Gaynor wrote:
>
>> I think you're largely objecting to a strawman, no one is proposing 
>> revoking trust in any of these threads.
>>
>> The only CAs that have ever had _any_ penalty applied to them have 
>> been for grotesque abuse of the trust vested in them.
>>
>> Alex
>>
>> On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via dev-security-policy < 
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> On 08/08/2017 18:43, Ryan Sleevi wrote:
>>>
>>> On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:
>>>>
>>>> I was not advocating "letting everyone decide".  I was advocating 
>>>> that
>>>>> Mozilla show some restraint, intelligence and common sense in 
>>>>> wielding the new weapons that certlint and crt.sh have given us.
>>>>>
>>>>> This shouldn't be race as to who wields the weapon first, 
>>>>> forgiving CAs only if they happen to report faster than some other 
>>>>> newsgroup participant.
>>>>>
>>>>> This is similar to if a store boss gets a new surveillance camera 
>>>>> in the shop and sees that some employees are taking extra breaks 
>>>>> when there are few customers in the store.  It would be 
>>>>> unreasonable for such a store boss to discipline this with similar 
>>>>> zeal as seeing some employees genuinely steeling cash out of the 
>>>>> register or selling stolen items out of the back door.  Instead 
>>>>> the fact that they work less when there is less work to do should 
>>>>> inspire reevaluation of any old rule that they are not allowed to 
>>>>> have a watercooler chat during work hours.
>>>>>
>>>>> Now such a reevaluation might result in requiring them to use such 
>>>>> occasions to clean the floors or do some other chores (Mozilla equiv:
>>>>> Deciding that the rule is important for good reason and needs to 
>>>>> be followed in the future) or it could result in relaxing the rule 
>>>>> as long as they stand ready the moment a customer arrives (Mozilla equiv:
>>>>> Relaxing the requirement, initially just for Mozilla, later 
>>>>> perhaps as a BR change).
>>>>>
>>>>> Dogmatically insisting on enforcing rules that were previously not 
>>>>> enforced due to lack of detection, just because "rules are rules" 
>>>>> or other such arguments seems overzealous.
>>>>>
>>>>>
>>>>> Such tools have been available for over a year. CAs have been 
>>>>> aware of
>>>> this, the ability to run it over their own corpus and self-detect 
>>>> and self-report. These tools, notably, were created by one of the 
>>>> newest CA applicants - Amazon - based on a methodical study of what 
>>>> is required of a CA.
>>>>
>>>> Your attempts to characterize it as overzealous ignore this 
>>>> entirely. At this point, it's gross negligence, and attempts to 
>>>> argue otherwise merely suggest a lack of understanding or concern 
>>>> for standards compliance and interoperability.
>>>>
>>>> Mozilla has already communicated to CAs these tools exist and their 
>>>> relevance to CAs.
>>>>
>>>> Perhaps we can move on from misguided apologetics and instead focus 
>>>> on how to make things better. Suggestions we ig

Re: Certificates with invalidly long serial numbers

[Ryan Sleevi via dev-security-policy]

On Tuesday, August 8, 2017 at 11:26:11 AM UTC-7, Jakob Bohm wrote:
> On 08/08/2017 18:43, Ryan Sleevi wrote:
> > On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:
> >> I was not advocating "letting everyone decide".  I was advocating that
> >> Mozilla show some restraint, intelligence and common sense in wielding
> >> the new weapons that certlint and crt.sh have given us.
> >>
> >> This shouldn't be race as to who wields the weapon first, forgiving CAs
> >> only if they happen to report faster than some other newsgroup
> >> participant.
> >>
> >> This is similar to if a store boss gets a new surveillance camera in the
> >> shop and sees that some employees are taking extra breaks when there are
> >> few customers in the store.  It would be unreasonable for such a store
> >> boss to discipline this with similar zeal as seeing some employees
> >> genuinely steeling cash out of the register or selling stolen items out
> >> of the back door.  Instead the fact that they work less when there is
> >> less work to do should inspire reevaluation of any old rule that they
> >> are not allowed to have a watercooler chat during work hours.
> >>
> >> Now such a reevaluation might result in requiring them to use such
> >> occasions to clean the floors or do some other chores (Mozilla equiv:
> >> Deciding that the rule is important for good reason and needs to be
> >> followed in the future) or it could result in relaxing the rule as
> >> long as they stand ready the moment a customer arrives (Mozilla equiv:
> >> Relaxing the requirement, initially just for Mozilla, later perhaps as a
> >> BR change).
> >>
> >> Dogmatically insisting on enforcing rules that were previously not
> >> enforced due to lack of detection, just because "rules are rules" or
> >> other such arguments seems overzealous.
> >>
> > 
> > Such tools have been available for over a year. CAs have been aware of 
> > this, the ability to run it over their own corpus and self-detect and 
> > self-report. These tools, notably, were created by one of the newest CA 
> > applicants - Amazon - based on a methodical study of what is required of a 
> > CA.
> > 
> > Your attempts to characterize it as overzealous ignore this entirely. At 
> > this point, it's gross negligence, and attempts to argue otherwise merely 
> > suggest a lack of understanding or concern for standards compliance and 
> > interoperability.
> > 
> > Mozilla has already communicated to CAs these tools exist and their 
> > relevance to CAs.
> > 
> > Perhaps we can move on from misguided apologetics and instead focus on how 
> > to make things better. Suggestions we ignore these, at this point, are 
> > neither productive nor relevant. Attempts to suggest tortured metaphors are 
> > like attempting to suggest rich people deserve to be robbed, or poor people 
> > just need to work harder - arguments that are both hollow and borderline 
> > offensive in their reductionism. A pattern of easily preventable 
> > misissuance has been happening,CAs have been repeatedly told to 
> > self-detect, and clearly, some CAs, like presumably some businesses, aren't 
> > taking security seriously. That needs to stop.
> > 
> 
> I am questioning the fairness of applying these tools, which did not
> exist when the rules were written, to enforce every rule with the same
> high weight. 

Did anything prevent the CAs responsible from writing these tools?

Do you believe there is any excuse for issuance in 2017 that violates these 
rules?

Is your view that until someone else does the CA's work for them (reading and 
understanding the rules), the CA should not be responsible for reading or 
understanding themselves?

You're arguing against a strawman. It's 2017 - it's both time to stop making 
excuses and time to recognize that the ability of CAs to adhere to the rules is 
core to their trustworthiness. Technical rules are but a proxy for procedure 
rules.

> I am not apologizing for bad behavior, I am saying if
> everybody gets scrutinized this hard, we will eventually have to
> distrust pretty much all the CAs, because there is no such thing as a
> perfect CA organization.

No, you are apologizing for their bad behaviour by suggesting they shouldn't be 
held to an objective standard, because someone else hadn't done the work for 
them. The compliance or noncompliance is extremely relevant to the CAs ability 
to react and respond to changes, and you continue to offer a view that suggests 
CAs shouldn't have to respond consistently or should not be expected to 
consistently follow the rules, which undermine the very trust.

If these are violations, and they are, we should expect each CA to take action 
and explain to the community why they failed to detect these issues, as well as 
what changes they are making in the future to stay on top. Prioritization is 
both a misdirect to responsibility and an attempt to undermine trustworthiness.

> 
> So we need to prioritize the rules instead of just saying 

Re: Certificates with invalidly long serial numbers

[Alex Gaynor via dev-security-policy]

It's from the BRs 4.9.1.1:

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

It's also not a penalty on the CA, it's a remediation step for them to
undertake.

Alex

On Tue, Aug 8, 2017 at 2:43 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Some people seemed to require 24-hour revocation of these, which I also
> find possibly excessive.
>
> On 08/08/2017 20:28, Alex Gaynor wrote:
>
>> I think you're largely objecting to a strawman, no one is proposing
>> revoking trust in any of these threads.
>>
>> The only CAs that have ever had _any_ penalty applied to them have been
>> for
>> grotesque abuse of the trust vested in them.
>>
>> Alex
>>
>> On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> On 08/08/2017 18:43, Ryan Sleevi wrote:
>>>
>>> On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:

 I was not advocating "letting everyone decide".  I was advocating that
> Mozilla show some restraint, intelligence and common sense in wielding
> the new weapons that certlint and crt.sh have given us.
>
> This shouldn't be race as to who wields the weapon first, forgiving CAs
> only if they happen to report faster than some other newsgroup
> participant.
>
> This is similar to if a store boss gets a new surveillance camera in
> the
> shop and sees that some employees are taking extra breaks when there
> are
> few customers in the store.  It would be unreasonable for such a store
> boss to discipline this with similar zeal as seeing some employees
> genuinely steeling cash out of the register or selling stolen items out
> of the back door.  Instead the fact that they work less when there is
> less work to do should inspire reevaluation of any old rule that they
> are not allowed to have a watercooler chat during work hours.
>
> Now such a reevaluation might result in requiring them to use such
> occasions to clean the floors or do some other chores (Mozilla equiv:
> Deciding that the rule is important for good reason and needs to be
> followed in the future) or it could result in relaxing the rule as
> long as they stand ready the moment a customer arrives (Mozilla equiv:
> Relaxing the requirement, initially just for Mozilla, later perhaps as
> a
> BR change).
>
> Dogmatically insisting on enforcing rules that were previously not
> enforced due to lack of detection, just because "rules are rules" or
> other such arguments seems overzealous.
>
>
> Such tools have been available for over a year. CAs have been aware of
 this, the ability to run it over their own corpus and self-detect and
 self-report. These tools, notably, were created by one of the newest CA
 applicants - Amazon - based on a methodical study of what is required
 of a
 CA.

 Your attempts to characterize it as overzealous ignore this entirely. At
 this point, it's gross negligence, and attempts to argue otherwise
 merely
 suggest a lack of understanding or concern for standards compliance and
 interoperability.

 Mozilla has already communicated to CAs these tools exist and their
 relevance to CAs.

 Perhaps we can move on from misguided apologetics and instead focus on
 how to make things better. Suggestions we ignore these, at this point,
 are
 neither productive nor relevant. Attempts to suggest tortured metaphors
 are
 like attempting to suggest rich people deserve to be robbed, or poor
 people
 just need to work harder - arguments that are both hollow and borderline
 offensive in their reductionism. A pattern of easily preventable
 misissuance has been happening,CAs have been repeatedly told to
 self-detect, and clearly, some CAs, like presumably some businesses,
 aren't
 taking security seriously. That needs to stop.


 I am questioning the fairness of applying these tools, which did not
>>> exist when the rules were written, to enforce every rule with the same
>>> high weight.  I am not apologizing for bad behavior, I am saying if
>>> everybody gets scrutinized this hard, we will eventually have to
>>> distrust pretty much all the CAs, because there is no such thing as a
>>> perfect CA organization.
>>>
>>> So we need to prioritize the rules instead of just saying off-with-
>>> their-heads (revoke all affected certificates in 24 hours) whenever any
>>> formal rule was broken without actually harming security.
>>>
>>> An example of a graduated response:
>>>
>>> - Deliberately issued super-interception certificate: Instant revocation
>>>   of CA trust.
>>> - SubCA that does no vetting at all: Instant revocation and adding to
>>>   OneCRL.
>>> - Certificate issued to someone who should not have it (like the github

Re: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

Some people seemed to require 24-hour revocation of these, which I also
find possibly excessive.

On 08/08/2017 20:28, Alex Gaynor wrote:

I think you're largely objecting to a strawman, no one is proposing
revoking trust in any of these threads.

The only CAs that have ever had _any_ penalty applied to them have been for
grotesque abuse of the trust vested in them.

Alex

On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 08/08/2017 18:43, Ryan Sleevi wrote:


On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:


I was not advocating "letting everyone decide".  I was advocating that
Mozilla show some restraint, intelligence and common sense in wielding
the new weapons that certlint and crt.sh have given us.

This shouldn't be race as to who wields the weapon first, forgiving CAs
only if they happen to report faster than some other newsgroup
participant.

This is similar to if a store boss gets a new surveillance camera in the
shop and sees that some employees are taking extra breaks when there are
few customers in the store.  It would be unreasonable for such a store
boss to discipline this with similar zeal as seeing some employees
genuinely steeling cash out of the register or selling stolen items out
of the back door.  Instead the fact that they work less when there is
less work to do should inspire reevaluation of any old rule that they
are not allowed to have a watercooler chat during work hours.

Now such a reevaluation might result in requiring them to use such
occasions to clean the floors or do some other chores (Mozilla equiv:
Deciding that the rule is important for good reason and needs to be
followed in the future) or it could result in relaxing the rule as
long as they stand ready the moment a customer arrives (Mozilla equiv:
Relaxing the requirement, initially just for Mozilla, later perhaps as a
BR change).

Dogmatically insisting on enforcing rules that were previously not
enforced due to lack of detection, just because "rules are rules" or
other such arguments seems overzealous.



Such tools have been available for over a year. CAs have been aware of
this, the ability to run it over their own corpus and self-detect and
self-report. These tools, notably, were created by one of the newest CA
applicants - Amazon - based on a methodical study of what is required of a
CA.

Your attempts to characterize it as overzealous ignore this entirely. At
this point, it's gross negligence, and attempts to argue otherwise merely
suggest a lack of understanding or concern for standards compliance and
interoperability.

Mozilla has already communicated to CAs these tools exist and their
relevance to CAs.

Perhaps we can move on from misguided apologetics and instead focus on
how to make things better. Suggestions we ignore these, at this point, are
neither productive nor relevant. Attempts to suggest tortured metaphors are
like attempting to suggest rich people deserve to be robbed, or poor people
just need to work harder - arguments that are both hollow and borderline
offensive in their reductionism. A pattern of easily preventable
misissuance has been happening,CAs have been repeatedly told to
self-detect, and clearly, some CAs, like presumably some businesses, aren't
taking security seriously. That needs to stop.



I am questioning the fairness of applying these tools, which did not
exist when the rules were written, to enforce every rule with the same
high weight.  I am not apologizing for bad behavior, I am saying if
everybody gets scrutinized this hard, we will eventually have to
distrust pretty much all the CAs, because there is no such thing as a
perfect CA organization.

So we need to prioritize the rules instead of just saying off-with-
their-heads (revoke all affected certificates in 24 hours) whenever any
formal rule was broken without actually harming security.

An example of a graduated response:

- Deliberately issued super-interception certificate: Instant revocation
  of CA trust.
- SubCA that does no vetting at all: Instant revocation and adding to
  OneCRL.
- Certificate issued to someone who should not have it (like the github
  certs issued by WoSign): 24 hour revocation, faster if possible.
- Certificate that violates rules and triggers a bug preventing Mozilla
  NSS from detecting if it is revoked: 24 hour revocation and adding
  special case code to NSS to treat this form of certificate as not valid
  instead of non-revocable.
- Certificate issued in such a way as to increase the risk of
  post-issuance attacks (such as SHA-1 cert issued in 2016 or later with
  insufficient random bits near the start of the TBSCertificate): 24 hour
  revocation of cert itself, issuing SubCA revoked with 2 month delay to
  replace affected good certificates from a new clean SubCA.
- Single Certificate that violates rules, but works with revocation
  checking in NSS and was issued to the proper party (possesses 

Re: Certificates with invalidly long serial numbers

[Matthew Hardeman via dev-security-policy]

It seems this thread has diverged a bit from its stated purpose, the 
determination of the question of mis-issuance of a set of certificates which 
have (possibly) longer than allowed serial numbers.

I raised a question as to the history of the selection of the 20 bytes limit 
for serial numbers and it was pointed out that this is the size of an SHA-1 
hash.

As the principal use of serial these days is double-duty as both unique 
identifier within an issuer DN as well as an early-in-the-certificate-document 
insertion of unpredictable entropy for mitigation of pre-image collision 
attacks, the continued merits of the notion of serial number as needing to 
store an SHA-1 value are certainly questionable.

I merely raise the point that IF the framers of the 20 bytes rule did, in fact, 
simultaneously intend that arbitrary SHA-1 hash results should be able to be 
stuffed into the serial number field AND SIMULTANEOUSLY that the DER encoded 
integer field value must be a positive integer and that insertion of a leading 
0x00 byte to ensure that the high order bit would be 0 (thus regarded as a 
positive value per the coding), THEN it must follow that at least in the minds 
of those who engineered the rule, that the inserted 0x00 byte must not be part 
of the 20 byte maximum size of the value AS legitimate SHA-1 values of 20 bytes 
do include values where the high order bit would be 1 and without pre-padding 
the proper interpretation of such a value would be as a negative integer.

The language of the 20 bytes rule is actually ambiguous.  If that ambiguity is 
coupled with a possible (prior) intent that it be possible to store a SHA-1 
output as the serial number, it's more than just ambiguous.   If it is 
essential that the total encoded representation within the certificate 
structure not exceed 20 bytes, I would think that a clarification in line with 
Peter Bowen's proposal in this thread might be appropriate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Alex Gaynor via dev-security-policy]

I think you're largely objecting to a strawman, no one is proposing
revoking trust in any of these threads.

The only CAs that have ever had _any_ penalty applied to them have been for
grotesque abuse of the trust vested in them.

Alex

On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 08/08/2017 18:43, Ryan Sleevi wrote:
>
>> On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:
>>
>>> I was not advocating "letting everyone decide".  I was advocating that
>>> Mozilla show some restraint, intelligence and common sense in wielding
>>> the new weapons that certlint and crt.sh have given us.
>>>
>>> This shouldn't be race as to who wields the weapon first, forgiving CAs
>>> only if they happen to report faster than some other newsgroup
>>> participant.
>>>
>>> This is similar to if a store boss gets a new surveillance camera in the
>>> shop and sees that some employees are taking extra breaks when there are
>>> few customers in the store.  It would be unreasonable for such a store
>>> boss to discipline this with similar zeal as seeing some employees
>>> genuinely steeling cash out of the register or selling stolen items out
>>> of the back door.  Instead the fact that they work less when there is
>>> less work to do should inspire reevaluation of any old rule that they
>>> are not allowed to have a watercooler chat during work hours.
>>>
>>> Now such a reevaluation might result in requiring them to use such
>>> occasions to clean the floors or do some other chores (Mozilla equiv:
>>> Deciding that the rule is important for good reason and needs to be
>>> followed in the future) or it could result in relaxing the rule as
>>> long as they stand ready the moment a customer arrives (Mozilla equiv:
>>> Relaxing the requirement, initially just for Mozilla, later perhaps as a
>>> BR change).
>>>
>>> Dogmatically insisting on enforcing rules that were previously not
>>> enforced due to lack of detection, just because "rules are rules" or
>>> other such arguments seems overzealous.
>>>
>>>
>> Such tools have been available for over a year. CAs have been aware of
>> this, the ability to run it over their own corpus and self-detect and
>> self-report. These tools, notably, were created by one of the newest CA
>> applicants - Amazon - based on a methodical study of what is required of a
>> CA.
>>
>> Your attempts to characterize it as overzealous ignore this entirely. At
>> this point, it's gross negligence, and attempts to argue otherwise merely
>> suggest a lack of understanding or concern for standards compliance and
>> interoperability.
>>
>> Mozilla has already communicated to CAs these tools exist and their
>> relevance to CAs.
>>
>> Perhaps we can move on from misguided apologetics and instead focus on
>> how to make things better. Suggestions we ignore these, at this point, are
>> neither productive nor relevant. Attempts to suggest tortured metaphors are
>> like attempting to suggest rich people deserve to be robbed, or poor people
>> just need to work harder - arguments that are both hollow and borderline
>> offensive in their reductionism. A pattern of easily preventable
>> misissuance has been happening,CAs have been repeatedly told to
>> self-detect, and clearly, some CAs, like presumably some businesses, aren't
>> taking security seriously. That needs to stop.
>>
>>
> I am questioning the fairness of applying these tools, which did not
> exist when the rules were written, to enforce every rule with the same
> high weight.  I am not apologizing for bad behavior, I am saying if
> everybody gets scrutinized this hard, we will eventually have to
> distrust pretty much all the CAs, because there is no such thing as a
> perfect CA organization.
>
> So we need to prioritize the rules instead of just saying off-with-
> their-heads (revoke all affected certificates in 24 hours) whenever any
> formal rule was broken without actually harming security.
>
> An example of a graduated response:
>
> - Deliberately issued super-interception certificate: Instant revocation
>  of CA trust.
> - SubCA that does no vetting at all: Instant revocation and adding to
>  OneCRL.
> - Certificate issued to someone who should not have it (like the github
>  certs issued by WoSign): 24 hour revocation, faster if possible.
> - Certificate that violates rules and triggers a bug preventing Mozilla
>  NSS from detecting if it is revoked: 24 hour revocation and adding
>  special case code to NSS to treat this form of certificate as not valid
>  instead of non-revocable.
> - Certificate issued in such a way as to increase the risk of
>  post-issuance attacks (such as SHA-1 cert issued in 2016 or later with
>  insufficient random bits near the start of the TBSCertificate): 24 hour
>  revocation of cert itself, issuing SubCA revoked with 2 month delay to
>  replace affected good certificates from a new clean SubCA.
> - Single Certificate that violates rules, 

Re: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

On 08/08/2017 18:43, Ryan Sleevi wrote:

On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:

I was not advocating "letting everyone decide".  I was advocating that
Mozilla show some restraint, intelligence and common sense in wielding
the new weapons that certlint and crt.sh have given us.

This shouldn't be race as to who wields the weapon first, forgiving CAs
only if they happen to report faster than some other newsgroup
participant.

This is similar to if a store boss gets a new surveillance camera in the
shop and sees that some employees are taking extra breaks when there are
few customers in the store.  It would be unreasonable for such a store
boss to discipline this with similar zeal as seeing some employees
genuinely steeling cash out of the register or selling stolen items out
of the back door.  Instead the fact that they work less when there is
less work to do should inspire reevaluation of any old rule that they
are not allowed to have a watercooler chat during work hours.

Now such a reevaluation might result in requiring them to use such
occasions to clean the floors or do some other chores (Mozilla equiv:
Deciding that the rule is important for good reason and needs to be
followed in the future) or it could result in relaxing the rule as
long as they stand ready the moment a customer arrives (Mozilla equiv:
Relaxing the requirement, initially just for Mozilla, later perhaps as a
BR change).

Dogmatically insisting on enforcing rules that were previously not
enforced due to lack of detection, just because "rules are rules" or
other such arguments seems overzealous.



Such tools have been available for over a year. CAs have been aware of this, 
the ability to run it over their own corpus and self-detect and self-report. 
These tools, notably, were created by one of the newest CA applicants - Amazon 
- based on a methodical study of what is required of a CA.

Your attempts to characterize it as overzealous ignore this entirely. At this 
point, it's gross negligence, and attempts to argue otherwise merely suggest a 
lack of understanding or concern for standards compliance and interoperability.

Mozilla has already communicated to CAs these tools exist and their relevance 
to CAs.

Perhaps we can move on from misguided apologetics and instead focus on how to 
make things better. Suggestions we ignore these, at this point, are neither 
productive nor relevant. Attempts to suggest tortured metaphors are like 
attempting to suggest rich people deserve to be robbed, or poor people just 
need to work harder - arguments that are both hollow and borderline offensive 
in their reductionism. A pattern of easily preventable misissuance has been 
happening,CAs have been repeatedly told to self-detect, and clearly, some CAs, 
like presumably some businesses, aren't taking security seriously. That needs 
to stop.



I am questioning the fairness of applying these tools, which did not
exist when the rules were written, to enforce every rule with the same
high weight.  I am not apologizing for bad behavior, I am saying if
everybody gets scrutinized this hard, we will eventually have to
distrust pretty much all the CAs, because there is no such thing as a
perfect CA organization.

So we need to prioritize the rules instead of just saying off-with-
their-heads (revoke all affected certificates in 24 hours) whenever any
formal rule was broken without actually harming security.

An example of a graduated response:

- Deliberately issued super-interception certificate: Instant revocation
 of CA trust.
- SubCA that does no vetting at all: Instant revocation and adding to
 OneCRL.
- Certificate issued to someone who should not have it (like the github
 certs issued by WoSign): 24 hour revocation, faster if possible.
- Certificate that violates rules and triggers a bug preventing Mozilla
 NSS from detecting if it is revoked: 24 hour revocation and adding
 special case code to NSS to treat this form of certificate as not valid
 instead of non-revocable.
- Certificate issued in such a way as to increase the risk of
 post-issuance attacks (such as SHA-1 cert issued in 2016 or later with
 insufficient random bits near the start of the TBSCertificate): 24 hour
 revocation of cert itself, issuing SubCA revoked with 2 month delay to
 replace affected good certificates from a new clean SubCA.
- Single Certificate that violates rules, but works with revocation
 checking in NSS and was issued to the proper party (possesses domains,
 matches any real world identity in DN etc.): Revoke after 14 days, try
 to replace before that.
- Thousands of certificates that violate rules, but work with revocation
 checking in NSS and were issued to the proper parties (example: O=
 field replaced by "test" after full vetting of actual name): Revoke
 after 2 months, try to replace before that.
- Certificate that violates a previously unclear interpretation of a
 rule, but works with revocation checking in NSS and was issued to 

Re: Certificates with invalidly long serial numbers

[Ryan Sleevi via dev-security-policy]

On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:
> I was not advocating "letting everyone decide".  I was advocating that
> Mozilla show some restraint, intelligence and common sense in wielding
> the new weapons that certlint and crt.sh have given us.
> 
> This shouldn't be race as to who wields the weapon first, forgiving CAs
> only if they happen to report faster than some other newsgroup
> participant.
> 
> This is similar to if a store boss gets a new surveillance camera in the
> shop and sees that some employees are taking extra breaks when there are
> few customers in the store.  It would be unreasonable for such a store
> boss to discipline this with similar zeal as seeing some employees
> genuinely steeling cash out of the register or selling stolen items out
> of the back door.  Instead the fact that they work less when there is
> less work to do should inspire reevaluation of any old rule that they
> are not allowed to have a watercooler chat during work hours.
> 
> Now such a reevaluation might result in requiring them to use such
> occasions to clean the floors or do some other chores (Mozilla equiv:
> Deciding that the rule is important for good reason and needs to be
> followed in the future) or it could result in relaxing the rule as
> long as they stand ready the moment a customer arrives (Mozilla equiv:
> Relaxing the requirement, initially just for Mozilla, later perhaps as a
> BR change).
> 
> Dogmatically insisting on enforcing rules that were previously not
> enforced due to lack of detection, just because "rules are rules" or
> other such arguments seems overzealous.
> 

Such tools have been available for over a year. CAs have been aware of this, 
the ability to run it over their own corpus and self-detect and self-report. 
These tools, notably, were created by one of the newest CA applicants - Amazon 
- based on a methodical study of what is required of a CA.

Your attempts to characterize it as overzealous ignore this entirely. At this 
point, it's gross negligence, and attempts to argue otherwise merely suggest a 
lack of understanding or concern for standards compliance and interoperability.

Mozilla has already communicated to CAs these tools exist and their relevance 
to CAs.

Perhaps we can move on from misguided apologetics and instead focus on how to 
make things better. Suggestions we ignore these, at this point, are neither 
productive nor relevant. Attempts to suggest tortured metaphors are like 
attempting to suggest rich people deserve to be robbed, or poor people just 
need to work harder - arguments that are both hollow and borderline offensive 
in their reductionism. A pattern of easily preventable misissuance has been 
happening,CAs have been repeatedly told to self-detect, and clearly, some CAs, 
like presumably some businesses, aren't taking security seriously. That needs 
to stop.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

I was not advocating "letting everyone decide".  I was advocating that
Mozilla show some restraint, intelligence and common sense in wielding
the new weapons that certlint and crt.sh have given us.

This shouldn't be race as to who wields the weapon first, forgiving CAs
only if they happen to report faster than some other newsgroup
participant.

This is similar to if a store boss gets a new surveillance camera in the
shop and sees that some employees are taking extra breaks when there are
few customers in the store.  It would be unreasonable for such a store
boss to discipline this with similar zeal as seeing some employees
genuinely steeling cash out of the register or selling stolen items out
of the back door.  Instead the fact that they work less when there is
less work to do should inspire reevaluation of any old rule that they
are not allowed to have a watercooler chat during work hours.

Now such a reevaluation might result in requiring them to use such
occasions to clean the floors or do some other chores (Mozilla equiv:
Deciding that the rule is important for good reason and needs to be
followed in the future) or it could result in relaxing the rule as
long as they stand ready the moment a customer arrives (Mozilla equiv:
Relaxing the requirement, initially just for Mozilla, later perhaps as a
BR change).

Dogmatically insisting on enforcing rules that were previously not
enforced due to lack of detection, just because "rules are rules" or
other such arguments seems overzealous.

On 08/08/2017 15:16, Alex Gaynor wrote:

This methodology of "letting everyone decide which parts of the spec/BRs
aren't important" doesn't make sense. If there's something wrong with the
spec, let's fix it! (Perhaps X.509 validation needs its own equivalent of
the "fetch" specification). Giving each CA unilateral authority to ignore
what they want is not how we get to a cleaner, better, more secure, spec or
PKI. BTW, the reason you know they were unilaterally ignoring things is
that this thread was started by an independent security researcher, and not
by the CAs in question!

If the CAs had noticed themselves, they could have sent an email to
m.d.s.p, "Hey, we noticed some of our certs were triggering warnings on
crt.sh, we looked into and it's because of an encoding issue with large
serials. We're revoking those certs, and looking into the bug in our
issuance code, but we're pretty sure this happened because the text in RFC
5280 is a bit vague, can we do something to make this more clear?"

Alex

On Mon, Aug 7, 2017 at 9:25 PM, Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Ryan Sleevi via dev-security-policy 
writes:


Pragmatically, does anything known break on the extra byte there?


Yes. NSS does. Because NSS properly implements 5280.


I would say that's probably more a flaw in NSS then.  Does anyone's
implementation seriously expect things to work, and by extension break if
they
don't, as 5280 says it should?  What happens to NSS if it sees a policy
explicitText longer than 200 bytes?  If it sees a CRL with an unknown
critical
extension?  If it sees a CRL with one of the extensions where you ignore
the
actual contents of the CRL and instead use revocation information hidden
in a
sub-extension (sorry, can't remember the name of that one at the moment).

That's just the first few things that came to mind, there are a million
(well,
thousands.  OK, maybe hundreds.  At least a dozen) bizarre, arbitrary, and
often illogical requirements (for example with the critical extension thing
the only sensible action is to do the opposite of what the RFC says) in
5280
that I'm pretty sure NSS, and probably most other implementations as well,
don't conform to, or are even aware of.  So saying "it happens to break our
code" is a perfectly valid response, but claiming better standards
conformance
than everyone else is venturing onto thin ice.

More generally, I don't think there's any PKI implementation that can
claim to
"properly implement 5280" because there's just too much weird stuff in
there
for anyone to fully comprehend and be conformant to.  As a corollary, since
there are also things in there that are illogical, a hypothetical
implementation that really was fully conformant could be regarded as broken
when it does things that the spec requires but that no-one would expect an
implementation to do.

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




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list

Re: Certificates with invalidly long serial numbers

[Alex Gaynor via dev-security-policy]

This methodology of "letting everyone decide which parts of the spec/BRs
aren't important" doesn't make sense. If there's something wrong with the
spec, let's fix it! (Perhaps X.509 validation needs its own equivalent of
the "fetch" specification). Giving each CA unilateral authority to ignore
what they want is not how we get to a cleaner, better, more secure, spec or
PKI. BTW, the reason you know they were unilaterally ignoring things is
that this thread was started by an independent security researcher, and not
by the CAs in question!

If the CAs had noticed themselves, they could have sent an email to
m.d.s.p, "Hey, we noticed some of our certs were triggering warnings on
crt.sh, we looked into and it's because of an encoding issue with large
serials. We're revoking those certs, and looking into the bug in our
issuance code, but we're pretty sure this happened because the text in RFC
5280 is a bit vague, can we do something to make this more clear?"

Alex

On Mon, Aug 7, 2017 at 9:25 PM, Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Ryan Sleevi via dev-security-policy 
> writes:
>
> >>Pragmatically, does anything known break on the extra byte there?
> >
> >Yes. NSS does. Because NSS properly implements 5280.
>
> I would say that's probably more a flaw in NSS then.  Does anyone's
> implementation seriously expect things to work, and by extension break if
> they
> don't, as 5280 says it should?  What happens to NSS if it sees a policy
> explicitText longer than 200 bytes?  If it sees a CRL with an unknown
> critical
> extension?  If it sees a CRL with one of the extensions where you ignore
> the
> actual contents of the CRL and instead use revocation information hidden
> in a
> sub-extension (sorry, can't remember the name of that one at the moment).
>
> That's just the first few things that came to mind, there are a million
> (well,
> thousands.  OK, maybe hundreds.  At least a dozen) bizarre, arbitrary, and
> often illogical requirements (for example with the critical extension thing
> the only sensible action is to do the opposite of what the RFC says) in
> 5280
> that I'm pretty sure NSS, and probably most other implementations as well,
> don't conform to, or are even aware of.  So saying "it happens to break our
> code" is a perfectly valid response, but claiming better standards
> conformance
> than everyone else is venturing onto thin ice.
>
> More generally, I don't think there's any PKI implementation that can
> claim to
> "properly implement 5280" because there's just too much weird stuff in
> there
> for anyone to fully comprehend and be conformant to.  As a corollary, since
> there are also things in there that are illogical, a hypothetical
> implementation that really was fully conformant could be regarded as broken
> when it does things that the spec requires but that no-one would expect an
> implementation to do.
>
> 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

Re: Certificates with invalidly long serial numbers

[Peter Gutmann via dev-security-policy]

Ryan Sleevi via dev-security-policy  
writes:

>>Pragmatically, does anything known break on the extra byte there?
>
>Yes. NSS does. Because NSS properly implements 5280.

I would say that's probably more a flaw in NSS then.  Does anyone's
implementation seriously expect things to work, and by extension break if they
don't, as 5280 says it should?  What happens to NSS if it sees a policy
explicitText longer than 200 bytes?  If it sees a CRL with an unknown critical
extension?  If it sees a CRL with one of the extensions where you ignore the
actual contents of the CRL and instead use revocation information hidden in a
sub-extension (sorry, can't remember the name of that one at the moment).

That's just the first few things that came to mind, there are a million (well,
thousands.  OK, maybe hundreds.  At least a dozen) bizarre, arbitrary, and
often illogical requirements (for example with the critical extension thing
the only sensible action is to do the opposite of what the RFC says) in 5280
that I'm pretty sure NSS, and probably most other implementations as well,
don't conform to, or are even aware of.  So saying "it happens to break our
code" is a perfectly valid response, but claiming better standards conformance
than everyone else is venturing onto thin ice.

More generally, I don't think there's any PKI implementation that can claim to
"properly implement 5280" because there's just too much weird stuff in there
for anyone to fully comprehend and be conformant to.  As a corollary, since
there are also things in there that are illogical, a hypothetical
implementation that really was fully conformant could be regarded as broken
when it does things that the spec requires but that no-one would expect an
implementation to do.

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

Re: Certificates with invalidly long serial numbers

[Peter Gutmann via dev-security-policy]

Matthew Hardeman via dev-security-policy 
 writes:

>One question: the choice of 20 bytes of serial number is an unusual length
>for an integer type.  It's not a nice clean power of 2.  It doesn't align to
>any native integer data type length on any platform I'm aware of.

It exactly matches the SHA-1 hash size.  SHA-1 was the universal go-to hash
function when 2459 and its successors were created, and is implicitly
hardcoded into various parts of the spec.  See for example the suggestions for
generating the keyIdentifier.

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

Re: Certificates with invalidly long serial numbers

[Ryan Sleevi via dev-security-policy]

On Tuesday, August 8, 2017 at 12:51:40 AM UTC+9, Matthew Hardeman wrote:
> It is what it is, I'm sure, but that definition in RFC5280 is rather tortured 
> and leads to ambiguity as to whether or not the leading 0x00 is.  In fact, I 
> would say that it is not part of the integer value but rather an explicit 
> sign flag required by the encoding mechanism.
> 
> Wouldn't it have been easier just to say that despite what the ASN.1 INTEGER 
> type says, serial number shall be regarded as an explicitly unsigned integer 
> of up to 20 bytes length, to be represented as a positive integral value?
> 
> Pragmatically, does anything known break on the extra byte there?

Yes. NSS does. Because NSS properly implements 5280.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Ryan Sleevi via dev-security-policy]

On Tuesday, August 8, 2017 at 5:27:13 AM UTC+9, Jakob Bohm wrote:
> On 07/08/2017 22:12, Alex Gaynor wrote:
> > You seem to be suggesting that the thoroughness of testing is somehow
> > related to how long it takes.
> > 
> > I'd expect any serious (or even not particularly serious...) to have a
> > comprehensive automated test suite that can verify that the software is
> > regression free and correct in minutes or hours. If you can't deploy
> > changes of any size with confidence in less than several months, I think
> > you have some serious process problems.
> > 
> 
> For non-essential changes, 

I think this may be the first, and most serious, flaw in your argument. 
Compliance with Mozilla policy and standards that are, at this point, over 
twenty years old, are essential Ganges. Full stop, they need to be made, made 
quickly, and should never have reached production.

> it may be a good idea to supplement the fast
> automated tests by tests that take a lot longer.  This could be manual
> tests, or it could be tests that verify expiry procedures in real time
> (e.g. issue a cert at the start of the test and verify that the OCSP
> component acts as intended near the end of the test).

Your examples are things you can and should write automated tests for.

> 
> The need to deploy some changes quickly inevitably represents a
> compromise between speed and quality, both in testing and coding.  So
> not using the rushed procedures for non-urgent changes is good general
> practice.

Creating a taxonomy between such is otherwise attempting to legitimize poor 
software development practices and poor business practices. It is a perspective 
that is no doubt shared by legacy software development firms, but much has been 
done in the past 20 years to support models of continuous development and 
continuous deployment. This is aided by rigorous test driven development, which 
is the corner stone of having the objective confidence, rather than the 
subjective unease.

> 
> Consider that most end-users are not encouraged to run Firefox nightlies
> and that enterprise users tend to use special ESR releases with longer
> release cycles than end users.  These practices represent the same
> fundamental speed/quality trade-off.
> 

While is may sound like compelling support for your argument, it does represent 
several unsupported or inaccurate claims. For example, Firefox users are 
encouraged to run other channels (like Aurora or Beta) precisely because the 
thorough esss of the automated testing represents a higher degree of confidence 
- which enables such updated versions to ship every six weeks. Similarly, 
Enterprise users who run ESR generally hold back the Web Platform and face 
greater risks, despite the considerable effort to support ESR, by virtue of 
running perpetually outdated software. Again, this is an area where the past 
twenty years have shown notions such as shipping "long term stable" software - 
whether it be a browser, an OS, or CA software - is actively detrimental to the 
ecosystem.

I realize much of your message is expressing a philosophy on software 
development, and while I've responded to point out that alternative 
philosophies exist - and with more catcher in modern software development - it 
is likely that our entire philosophical musings are moot. Whatever the approach 
to development, participants in the Mozilla Root CA Program have an obligation 
to comply with the program requirements, and for the safety and security of 
Mozilla users, that compliance needs to be timely. If certain, outdated and 
insecure approaches to that development may be used, then that is the CAs fault 
and risk, and not something the community should be asked to bear.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Matthew Hardeman via dev-security-policy]

On Monday, August 7, 2017 at 5:20:13 PM UTC-5, Ryan Sleevi wrote:

> This is entirely unnecessary and would present serious stability issues due 
> to backwards compatibility.
> 
> It may not be appropriate for this thread - discussing specific misissuances 
> - but there is zero benefit from extending the serial number, and obvious 
> serious detriment to the wide variety of applications - including, of course, 
> NSS and CryptoAPI - that specifically expect serial numbers to be less than 
> or equal to 20 bytes, when encoded.
> 
> I appreciate your multiyear perspective, but given that it provides no 
> articulated value, and of which significant discussion around the limits of 
> other fields, such as commonName, are both relevant and informative, it would 
> merely be change for change sake.

One question: the choice of 20 bytes of serial number is an unusual length for 
an integer type.  It's not a nice clean power of 2.  It doesn't align to any 
native integer data type length on any platform I'm aware of.

Does the history of the choice of the 20 byte length actual owe to an attempt 
to make the serial size capable of encompassing an SHA-1 hash output?

The reason that I ask is that IF the intent in the choice of the length of 20 
bytes was intentional for purpose of facilitating the output of an SHA-1 hash 
operation, this would speak FOR the argument that the leading 0x00 byte prepend 
(in cases of a leading 1 bit in the serial number value) would NOT be counted 
in the length.  There are certainly plenty of SHA-1 hash values which would 
have a leading 1 bit.

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

Re: Certificates with invalidly long serial numbers

[Ryan Sleevi via dev-security-policy]

On Tuesday, August 8, 2017 at 5:18:21 AM UTC+9, Jakob Bohm wrote:
> On 07/08/2017 16:54, Peter Bowen wrote:
> > On Mon, Aug 7, 2017 at 12:53 AM, Franck Leroy via dev-security-policy
> >  wrote:
> >> Hello
> >>
> >> I checked only one but I think they are all the same.
> >>
> >> The integer value of the serial number is 20 octets, but when encoded into 
> >> DER a starting 00 may be necessary to mark the integer as a positive value 
> >> :
> >>
> >> 0 1606: SEQUENCE {
> >> 4 1070:   SEQUENCE {
> >> 83: [0] {
> >>101:   INTEGER 2
> >>   :   }
> >>13   21: INTEGER
> >>   :   00 A5 45 35 99 1C E2 8B 6D D9 BC 1E 94 48 CC 86
> >>   :   7C 6B 59 9E B3
> >>
> >> So the serialNumber (integer) value is 20 octets long but lenght can be 
> >> more depending on the encoding representation.
> >>
> >> Here is ASCII (common representation when stored into a database: 
> >> "A54535991CE28B6DD9BC1E9448CC867C6B599EB3" it is 40 octets long, 
> >> VARCHAR(40) is needed.
> > 
> > The text from 5280 says:
> > 
> > " CAs MUST force the serialNumber to be a non-negative integer, that
> > is, the sign bit in the DER encoding of the INTEGER value MUST be
> > zero.  This can be done by adding a leading (leftmost) `00'H octet if
> > necessary.  This removes a potential ambiguity in mapping between a
> > string of octets and an integer value.
> > 
> > As noted in Section 4.1.2.2, serial numbers can be expected to
> > contain long integers.  Certificate users MUST be able to handle
> > serialNumber values up to 20 octets in length.  Conforming CAs MUST
> > NOT use serialNumber values longer than 20 octets."
> > 
> > This makes it somewhat whether the `00'H octet is to be included in
> > the 20 octet limit or not. While I can see how one might view it
> > differently, I think the correct interpretation is to include the
> > leading `00'H octet in the count.  This is because
> > CertificateSerialNumber is defined as being an INTEGER, which means
> > "octet" is not applicable.  If it was defined as OCTET STRING, similar
> > to how KeyIdentifier is defined, then octet could be seen as applying
> > to the unencoded value.  However, given this is an INTEGER, the only
> > way to get octets is to encode and this requires the leading bit to be
> > zero for non-negative values.
> > 
> > That being said, I think that it is reasonable to add "DER encoding of
> > Serial must be 20 octets or less including any leading 00 octets" to
> > the list of ambiguities that CAs must fix by date X, rather than
> > something that requires revocation.
> > 
> 
> (Thinking in a multi-year future perspective):
> 
> Given the age of RFC5280 and the (suspicious) fact that 20 is also the
> length of SHA-1 hashes, maybe there should be work in CAB/F and
> implementations to actually raise this maximum (and one day perhaps the
> minimum) to a larger value, such as 64 plus optional zero.
> 
> Doing so would allow future requirements to increase the minimum serial
> entropy to more than 160 bits, should a relevant attack scenario emerge.

This is entirely unnecessary and would present serious stability issues due to 
backwards compatibility.

It may not be appropriate for this thread - discussing specific misissuances - 
but there is zero benefit from extending the serial number, and obvious serious 
detriment to the wide variety of applications - including, of course, NSS and 
CryptoAPI - that specifically expect serial numbers to be less than or equal to 
20 bytes, when encoded.

I appreciate your multiyear perspective, but given that it provides no 
articulated value, and of which significant discussion around the limits of 
other fields, such as commonName, are both relevant and informative, it would 
merely be change for change sake.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

On 07/08/2017 22:12, Alex Gaynor wrote:

You seem to be suggesting that the thoroughness of testing is somehow
related to how long it takes.

I'd expect any serious (or even not particularly serious...) to have a
comprehensive automated test suite that can verify that the software is
regression free and correct in minutes or hours. If you can't deploy
changes of any size with confidence in less than several months, I think
you have some serious process problems.



For non-essential changes, it may be a good idea to supplement the fast
automated tests by tests that take a lot longer.  This could be manual
tests, or it could be tests that verify expiry procedures in real time
(e.g. issue a cert at the start of the test and verify that the OCSP
component acts as intended near the end of the test).

The need to deploy some changes quickly inevitably represents a
compromise between speed and quality, both in testing and coding.  So
not using the rushed procedures for non-urgent changes is good general
practice.

Consider that most end-users are not encouraged to run Firefox nightlies
and that enterprise users tend to use special ESR releases with longer
release cycles than end users.  These practices represent the same
fundamental speed/quality trade-off.




On Mon, Aug 7, 2017 at 4:09 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 07/08/2017 18:07, Hanno Böck wrote:


On Mon, 7 Aug 2017 15:59:07 +
Ben Wilson via dev-security-policy
 wrote:

FWIW - In the case of Telecom Italia, they have a commercial CA

product has a bug in it that occasionally causes this issue.  They
may need some time for the software to be fixed/replaced.



I'm more worried by this statement than by the actual bug.

If you're a CA and are not able to fix a bug in your product in a timely
manner then you probably shouldn't be a CA.



If you are a CA or serious CA software vendor, you should not install
non-essential patches without a very long and thorough testing process.

Since this is (at most) a formal violation and not a security problem,
it is better for the fix to go through many month of careful testing
than to rush it through.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

On 07/08/2017 16:54, Peter Bowen wrote:

On Mon, Aug 7, 2017 at 12:53 AM, Franck Leroy via dev-security-policy
 wrote:

Hello

I checked only one but I think they are all the same.

The integer value of the serial number is 20 octets, but when encoded into DER 
a starting 00 may be necessary to mark the integer as a positive value :

0 1606: SEQUENCE {
4 1070:   SEQUENCE {
83: [0] {
   101:   INTEGER 2
  :   }
   13   21: INTEGER
  :   00 A5 45 35 99 1C E2 8B 6D D9 BC 1E 94 48 CC 86
  :   7C 6B 59 9E B3

So the serialNumber (integer) value is 20 octets long but lenght can be more 
depending on the encoding representation.

Here is ASCII (common representation when stored into a database: 
"A54535991CE28B6DD9BC1E9448CC867C6B599EB3" it is 40 octets long, VARCHAR(40) is 
needed.


The text from 5280 says:

" CAs MUST force the serialNumber to be a non-negative integer, that
is, the sign bit in the DER encoding of the INTEGER value MUST be
zero.  This can be done by adding a leading (leftmost) `00'H octet if
necessary.  This removes a potential ambiguity in mapping between a
string of octets and an integer value.

As noted in Section 4.1.2.2, serial numbers can be expected to
contain long integers.  Certificate users MUST be able to handle
serialNumber values up to 20 octets in length.  Conforming CAs MUST
NOT use serialNumber values longer than 20 octets."

This makes it somewhat whether the `00'H octet is to be included in
the 20 octet limit or not. While I can see how one might view it
differently, I think the correct interpretation is to include the
leading `00'H octet in the count.  This is because
CertificateSerialNumber is defined as being an INTEGER, which means
"octet" is not applicable.  If it was defined as OCTET STRING, similar
to how KeyIdentifier is defined, then octet could be seen as applying
to the unencoded value.  However, given this is an INTEGER, the only
way to get octets is to encode and this requires the leading bit to be
zero for non-negative values.

That being said, I think that it is reasonable to add "DER encoding of
Serial must be 20 octets or less including any leading 00 octets" to
the list of ambiguities that CAs must fix by date X, rather than
something that requires revocation.



(Thinking in a multi-year future perspective):

Given the age of RFC5280 and the (suspicious) fact that 20 is also the
length of SHA-1 hashes, maybe there should be work in CAB/F and
implementations to actually raise this maximum (and one day perhaps the
minimum) to a larger value, such as 64 plus optional zero.

Doing so would allow future requirements to increase the minimum serial
entropy to more than 160 bits, should a relevant attack scenario emerge.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Alex Gaynor via dev-security-policy]

You seem to be suggesting that the thoroughness of testing is somehow
related to how long it takes.

I'd expect any serious (or even not particularly serious...) to have a
comprehensive automated test suite that can verify that the software is
regression free and correct in minutes or hours. If you can't deploy
changes of any size with confidence in less than several months, I think
you have some serious process problems.

Alex

On Mon, Aug 7, 2017 at 4:09 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 07/08/2017 18:07, Hanno Böck wrote:
>
>> On Mon, 7 Aug 2017 15:59:07 +
>> Ben Wilson via dev-security-policy
>>  wrote:
>>
>> FWIW - In the case of Telecom Italia, they have a commercial CA
>>> product has a bug in it that occasionally causes this issue.  They
>>> may need some time for the software to be fixed/replaced.
>>>
>>
>> I'm more worried by this statement than by the actual bug.
>>
>> If you're a CA and are not able to fix a bug in your product in a timely
>> manner then you probably shouldn't be a CA.
>>
>>
> If you are a CA or serious CA software vendor, you should not install
> non-essential patches without a very long and thorough testing process.
>
> Since this is (at most) a formal violation and not a security problem,
> it is better for the fix to go through many month of careful testing
> than to rush it through.
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> ___
> 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: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

On 07/08/2017 18:07, Hanno Böck wrote:

On Mon, 7 Aug 2017 15:59:07 +
Ben Wilson via dev-security-policy
 wrote:


FWIW - In the case of Telecom Italia, they have a commercial CA
product has a bug in it that occasionally causes this issue.  They
may need some time for the software to be fixed/replaced.


I'm more worried by this statement than by the actual bug.

If you're a CA and are not able to fix a bug in your product in a timely
manner then you probably shouldn't be a CA.



If you are a CA or serious CA software vendor, you should not install
non-essential patches without a very long and thorough testing process.

Since this is (at most) a formal violation and not a security problem,
it is better for the fix to go through many month of careful testing
than to rush it through.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Hanno Böck via dev-security-policy]

On Mon, 7 Aug 2017 15:59:07 +
Ben Wilson via dev-security-policy
 wrote:

> FWIW - In the case of Telecom Italia, they have a commercial CA
> product has a bug in it that occasionally causes this issue.  They
> may need some time for the software to be fixed/replaced. 

I'm more worried by this statement than by the actual bug.

If you're a CA and are not able to fix a bug in your product in a timely
manner then you probably shouldn't be a CA.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificates with invalidly long serial numbers

[Ben Wilson via dev-security-policy]

FWIW - In the case of Telecom Italia, they have a commercial CA product has
a bug in it that occasionally causes this issue.  They may need some time
for the software to be fixed/replaced. 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Matthew Hardeman via dev-security-policy
Sent: Monday, August 7, 2017 9:52 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with invalidly long serial numbers

It is what it is, I'm sure, but that definition in RFC5280 is rather
tortured and leads to ambiguity as to whether or not the leading 0x00 is.
In fact, I would say that it is not part of the integer value but rather an
explicit sign flag required by the encoding mechanism.

Wouldn't it have been easier just to say that despite what the ASN.1 INTEGER
type says, serial number shall be regarded as an explicitly unsigned integer
of up to 20 bytes length, to be represented as a positive integral value?

Pragmatically, does anything known break on the extra byte there?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Matthew Hardeman via dev-security-policy]

It is what it is, I'm sure, but that definition in RFC5280 is rather tortured 
and leads to ambiguity as to whether or not the leading 0x00 is.  In fact, I 
would say that it is not part of the integer value but rather an explicit sign 
flag required by the encoding mechanism.

Wouldn't it have been easier just to say that despite what the ASN.1 INTEGER 
type says, serial number shall be regarded as an explicitly unsigned integer of 
up to 20 bytes length, to be represented as a positive integral value?

Pragmatically, does anything known break on the extra byte there?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Peter Bowen via dev-security-policy]

(inserted missed word; off to get coffee now)

On Mon, Aug 7, 2017 at 7:54 AM, Peter Bowen  wrote:
> On Mon, Aug 7, 2017 at 12:53 AM, Franck Leroy via dev-security-policy
>  wrote:
>> Hello
>>
>> I checked only one but I think they are all the same.
>>
>> The integer value of the serial number is 20 octets, but when encoded into 
>> DER a starting 00 may be necessary to mark the integer as a positive value :
>>
>>0 1606: SEQUENCE {
>>4 1070:   SEQUENCE {
>>83: [0] {
>>   101:   INTEGER 2
>>  :   }
>>   13   21: INTEGER
>>  :   00 A5 45 35 99 1C E2 8B 6D D9 BC 1E 94 48 CC 86
>>  :   7C 6B 59 9E B3
>>
>> So the serialNumber (integer) value is 20 octets long but lenght can be more 
>> depending on the encoding representation.
>>
>> Here is ASCII (common representation when stored into a database: 
>> "A54535991CE28B6DD9BC1E9448CC867C6B599EB3" it is 40 octets long, VARCHAR(40) 
>> is needed.
>
> The text from 5280 says:
>
> " CAs MUST force the serialNumber to be a non-negative integer, that
>is, the sign bit in the DER encoding of the INTEGER value MUST be
>zero.  This can be done by adding a leading (leftmost) `00'H octet if
>necessary.  This removes a potential ambiguity in mapping between a
>string of octets and an integer value.
>
>As noted in Section 4.1.2.2, serial numbers can be expected to
>contain long integers.  Certificate users MUST be able to handle
>serialNumber values up to 20 octets in length.  Conforming CAs MUST
>NOT use serialNumber values longer than 20 octets."
>
> This makes it somewhat unclear whether the `00'H octet is to be included in
> the 20 octet limit or not. While I can see how one might view it
> differently, I think the correct interpretation is to include the
> leading `00'H octet in the count.  This is because
> CertificateSerialNumber is defined as being an INTEGER, which means
> "octet" is not applicable.  If it was defined as OCTET STRING, similar
> to how KeyIdentifier is defined, then octet could be seen as applying
> to the unencoded value.  However, given this is an INTEGER, the only
> way to get octets is to encode and this requires the leading bit to be
> zero for non-negative values.
>
> That being said, I think that it is reasonable to add "DER encoding of
> Serial must be 20 octets or less including any leading 00 octets" to
> the list of ambiguities that CAs must fix by date X, rather than
> something that requires revocation.
>
> Thanks,
> Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Peter Bowen via dev-security-policy]

On Mon, Aug 7, 2017 at 12:53 AM, Franck Leroy via dev-security-policy
 wrote:
> Hello
>
> I checked only one but I think they are all the same.
>
> The integer value of the serial number is 20 octets, but when encoded into 
> DER a starting 00 may be necessary to mark the integer as a positive value :
>
>0 1606: SEQUENCE {
>4 1070:   SEQUENCE {
>83: [0] {
>   101:   INTEGER 2
>  :   }
>   13   21: INTEGER
>  :   00 A5 45 35 99 1C E2 8B 6D D9 BC 1E 94 48 CC 86
>  :   7C 6B 59 9E B3
>
> So the serialNumber (integer) value is 20 octets long but lenght can be more 
> depending on the encoding representation.
>
> Here is ASCII (common representation when stored into a database: 
> "A54535991CE28B6DD9BC1E9448CC867C6B599EB3" it is 40 octets long, VARCHAR(40) 
> is needed.

The text from 5280 says:

" CAs MUST force the serialNumber to be a non-negative integer, that
   is, the sign bit in the DER encoding of the INTEGER value MUST be
   zero.  This can be done by adding a leading (leftmost) `00'H octet if
   necessary.  This removes a potential ambiguity in mapping between a
   string of octets and an integer value.

   As noted in Section 4.1.2.2, serial numbers can be expected to
   contain long integers.  Certificate users MUST be able to handle
   serialNumber values up to 20 octets in length.  Conforming CAs MUST
   NOT use serialNumber values longer than 20 octets."

This makes it somewhat whether the `00'H octet is to be included in
the 20 octet limit or not. While I can see how one might view it
differently, I think the correct interpretation is to include the
leading `00'H octet in the count.  This is because
CertificateSerialNumber is defined as being an INTEGER, which means
"octet" is not applicable.  If it was defined as OCTET STRING, similar
to how KeyIdentifier is defined, then octet could be seen as applying
to the unencoded value.  However, given this is an INTEGER, the only
way to get octets is to encode and this requires the leading bit to be
zero for non-negative values.

That being said, I think that it is reasonable to add "DER encoding of
Serial must be 20 octets or less including any leading 00 octets" to
the list of ambiguities that CAs must fix by date X, rather than
something that requires revocation.

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

Re: Certificates with invalidly long serial numbers

[Franck Leroy via dev-security-policy]

Hello

I checked only one but I think they are all the same.

The integer value of the serial number is 20 octets, but when encoded into DER 
a starting 00 may be necessary to mark the integer as a positive value :

   0 1606: SEQUENCE {
   4 1070:   SEQUENCE {
   83: [0] {
  101:   INTEGER 2
 :   }
  13   21: INTEGER
 :   00 A5 45 35 99 1C E2 8B 6D D9 BC 1E 94 48 CC 86
 :   7C 6B 59 9E B3

So the serialNumber (integer) value is 20 octets long but lenght can be more 
depending on the encoding representation.

Here is ASCII (common representation when stored into a database: 
"A54535991CE28B6DD9BC1E9448CC867C6B599EB3" it is 40 octets long, VARCHAR(40) is 
needed.

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