Certificates with invalidly long serial numbers

[Jonathan Rudenberg]

RFC 5280 section 4.1.2.2 says:

> Conforming CAs MUST NOT use serialNumber values longer than 20 octets.

There are two CAs that appear to misissue certificates with serial numbers that are longer than 20 octets on an ongoing basis:

- Certinomis
- TI Trust Technologies (chains up to a Baltimore/DigiCert root)

Here is a list of 40 certificates with this error: https://misissued.com/batch/2/

Jonathan

[Franck Leroy]

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 {
8 3: [0] {
10 1: 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

[Peter Bowen]

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

[Peter Bowen]

(inserted missed word; off to get coffee now)

On Mon, Aug 7, 2017 at 7:54 AM, Peter Bowen <pzb...@gmail.com> wrote:
> On Mon, Aug 7, 2017 at 12:53 AM, Franck Leroy via dev-security-policy
> <dev-secur...@lists.mozilla.org> 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 {
>> 8 3: [0] {
>> 10 1: 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

[Matthew Hardeman]

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?

[Ben Wilson]

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.

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

[Hanno Böck]

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

<dev-secur...@lists.mozilla.org> 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

[Jakob Bohm]

On 07/08/2017 18:07, Hanno Böck wrote:
> On Mon, 7 Aug 2017 15:59:07 +0000
> Ben Wilson via dev-security-policy
> <dev-secur...@lists.mozilla.org> 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

[Alex Gaynor]

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-secur...@lists.mozilla.org> wrote:

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

>> On Mon, 7 Aug 2017 15:59:07 +0000
>> Ben Wilson via dev-security-policy
>> <dev-secur...@lists.mozilla.org> 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
>

[Jakob Bohm]

(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.

[Jakob Bohm]

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.

[Ryan Sleevi]

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.

[Matthew Hardeman]

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.

[Ryan Sleevi]

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.

[Ryan Sleevi]

Yes. NSS does. Because NSS properly implements 5280.

[Peter Gutmann]

Matthew Hardeman via dev-security-policy <dev-secur...@lists.mozilla.org> 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.

[Peter Gutmann]

Ryan Sleevi via dev-security-policy <dev-secur...@lists.mozilla.org> 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.

[Alex Gaynor]

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-secur...@lists.mozilla.org> wrote:

> Ryan Sleevi via dev-security-policy <dev-secur...@lists.mozilla.org>
> writes:
>

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

[Jakob Bohm]

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.

[Ryan Sleevi]

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.

[Jakob Bohm]

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 the
proper party (example: 20 byte serial withe extra leading 0 byte, if
NSS revocation didn't fail on that): Clarify rule, but only revoke if
it has more than 9 months left before expiry.

Comparison with some recent cases:

Symantec's Korean RA replaced O with test (a minor thing, since no real
organization was impersonated), but also failed to keep proper vetting
records (a major thing, requiring urgent revocation).

The interpretation of the 20 byte serial rule as being "160 arbitrary
bits, sometimes encoded as a 23 byte DER structure (1 byte tag, 1 byte
length, 1 leading 0, 20 significant bytes) would have been a lack of
clarity and a future requirement, had it not been for the apparent fact
(I haven't tested this) that NSS would be unable to detect revocation of
such certs, but would accept them regardless of actual revocation, which
escalates it to urgent revocation and a security bug filed against NSS
to either block all such certs or implement revocation checking for
them.

Certificates issued with the IDNA in a SAN, but the equivalent unicode
in CN: Falls in the 14 day bucket or perhaps the 9 month bucket
(depending on clarity of old rules). This is if NSS will only look
at the SANs anyway when there is at least one SAN, as is required by
once of the RFCs. Ditto if NSS would not successfully match any network
name to the UNICODE CN, because no pure ASCII string would compare equal
to a string with at least one significant non-ASCII char.

[Alex Gaynor]

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-secur...@lists.mozilla.org> wrote:

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

[Matthew Hardeman]

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.

[Jakob Bohm]

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

[Alex Gaynor]

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-secur...@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:
>

[Ryan Sleevi]

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 off-with-
> their-heads (revoke all affected certificates in 24 hours) whenever any
> formal rule was broken without actually harming security.

That is what the Baseline Requirements say, and which both CAs and browsers agreed was an appropriate and responsible remediation. You are barking up the wrong tree, and in the wrong Forum, to suggest in the abstract that more lenient is required, and you've also failed to grasp the risk presented to clients in several cases, so such arguments will have a high burden to bear.

> Symantec's Korean RA replaced O with test (a minor thing, since no real
> organization was impersonated), but also failed to keep proper vetting
> records (a major thing, requiring urgent revocation).

Your analysis does not match the facts of the situation.

>
> The interpretation of the 20 byte serial rule as being "160 arbitrary
> bits, sometimes encoded as a 23 byte DER structure (1 byte tag, 1 byte
> length, 1 leading 0, 20 significant bytes) would have been a lack of
> clarity and a future requirement, had it not been for the apparent fact
> (I haven't tested this) that NSS would be unable to detect revocation of
> such certs, but would accept them regardless of actual revocation, which
> escalates it to urgent revocation and a security bug filed against NSS
> to either block all such certs or implement revocation checking for
> them.

You have also misunderstood the risk to interoperability or compatibility here. Such certs actively don't work in Mozilla clients, creating interoperability issues in the Web Platform due to nonadherance to the standards.

>
> Certificates issued with the IDNA in a SAN, but the equivalent unicode
> in CN: Falls in the 14 day bucket or perhaps the 9 month bucket
> (depending on clarity of old rules). This is if NSS will only look
> at the SANs anyway when there is at least one SAN, as is required by
> once of the RFCs. Ditto if NSS would not successfully match any network
> name to the UNICODE CN, because no pure ASCII string would compare equal
> to a string with at least one significant non-ASCII char.

This equally fails to understand the risk, but perhaps more importantly, the Mozilla Manifesto and its goals for interoperability and security.

[Jeremy Rowley]

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.

> On Aug 8, 2017, at 1:02 PM, Jakob Bohm via dev-security-policy <dev-secur...@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:

[Jeremy Rowley]

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=digice...@lists.mozilla.org] On Behalf Of Alex Gaynor via dev-security-policy
Sent: Tuesday, August 8, 2017 12:46 PM
To: Jakob Bohm <jb-mo...@wisemo.com>
Cc: mozilla-dev-s...@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-secur...@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:
>

[Peter Gutmann]

Matthew Hardeman via dev-security-policy <dev-secur...@lists.mozilla.org> 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.

[paul.l...@gmail.com]

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

[Jeremy Rowley]

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-secur...@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

[Jakob Bohm]

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 Gaynor]

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-secur...@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-secur...@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

[Jakob Bohm]

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.

[Jeremy Rowley]

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 <aga...@mozilla.com<mailto:aga...@mozilla.com>> 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-secur...@lists.mozilla.org<mailto:dev-secur...@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-secur...@lists.mozilla.org<mailto:dev-secur...@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-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>

> https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list

dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Jakob Bohm]

(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....@lists.mozilla.org
(Part of this thread).

This only received a meaningless reply from a VIP bureaucrat.

[Ryan Sleevi]

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.

[paul.l...@gmail.com]

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

[Jeremy Rowley]

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=digice...@lists.mozilla
.org] On Behalf Of Paul Kehrer via dev-security-policy
Sent: Wednesday, August 9, 2017 4:57 PM
To: mozilla-dev-s...@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.

[Matt Palmer]

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

[okaphone.e...@gmail.com]

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

[Jakob Bohm]

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.

[Ryan Sleevi]

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-secur...@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:
>

> 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

[Jeremy Rowley]

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=digice...@lists.mozilla
.org] On Behalf Of Jakob Bohm via dev-security-policy
Sent: Thursday, August 10, 2017 3:40 PM
To: mozilla-dev-s...@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:

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

[Jeremy Rowley]

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=digice...@lists.mozilla.org] On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, August 10, 2017 4:13 PM
To: Jakob Bohm <jb-mo...@wisemo.com>

Cc: mozilla-dev-security-policy <mozilla-dev-s...@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-secur...@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:
>

> 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

[Jakob Bohm]

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.

[Alex Gaynor]

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-secur...@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=
> digice...@lists.mozilla
> .org] On Behalf Of Jakob Bohm via dev-security-policy
> Sent: Thursday, August 10, 2017 3:40 PM
> To: mozilla-dev-s...@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:

> 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

[Jakob Bohm]

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).