Re: CA Problem Reporting Mechanisms

[Jonathan Rudenberg via dev-security-policy]

> On May 17, 2017, at 07:24, Gervase Markham via dev-security-policy 
>  wrote:
> 
> On 16/05/17 02:26, userwithuid wrote:
>> After skimming the responses and checking a few CAs, I'm starting to
>> wonder: Wouldn't it be easier to just add another mandatory field to
>> the CCADB (e..g. "revocation contact"), requiring $URL or $EMAIL via
>> policy and just use that to provide a public list?
> 
> Well, such contacts are normally per CA rather than per root. I guess we
> could add it on the CA's entry.

I’ve been reporting a fair amount of misissuance this week, and the responses 
to the Problem Reporting question in the April CA communication leave a lot to 
be desired. Several CAs do not have any contact details at all, and others 
require filling forms with captchas.

I think it’d be very useful if CAs were required maintain a problem reporting 
email address and keep it current in the CCADB, this requirement could go in 
the Mozilla Root Store policy or the CCADB policy. If they want to also 
maintain other modes of contact, they can but no matter what an email address 
should be required.

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

RE: StartCom cross-signs disclosed by Certinomis

[Richard Wang via dev-security-policy]

For adding Richard Wang back to StartCom UK director is for the completion 
separation, this is a temporally adding as director for signing bank document 
to change the bank signer person from Richard Wang to New CEO Inigo. It will be 
removed soon once the bank signer change is done.

Mr. Jon Luk (Alliotts) is the accountant of StartCom UK that he processed this 
change, anyone can contact him to verify this change intention.

For StartCom, Richard Wang is 100% no any relationship after the separation, 
Qihoo 360 100% get rid of Richard Wang in StartCom case.

BTW, StartCom UK is the 100% shareholder of StartCom Spain.

Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Itzhak Daniel via dev-security-policy
Sent: Tuesday, August 8, 2017 5:36 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom cross-signs disclosed by Certinomis

On Monday, August 7, 2017 at 11:03:27 PM UTC+3, Jakob Bohm wrote: 
> 7. At Quihoo: Actually get rid of Richard Wang, not just change his
>title from CEO to COO.

I didn't map the new hierarchy of the "Spanish" StartCom CA ("StartCom CA Spain 
Sociedad Limitada"), having trouble registering to the Spanish company house 
and pull documents (I pulled from 3rd party, but they're garbage [1] [2]). I 
did mange to see that Mr. Barreira is the Directory but nothing on the share 
holders or parent company.

I took a quick look at StartCom UK (as the information there is free) and 
noticed Mr. Wang became a director again [3]... I wonder who is "StartCom CA 
Spain Sociedad Limitada" parent/share holder, maybe a disclosure?

___
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: StartCom cross-signs disclosed by Certinomis

[Percy via dev-security-policy]

On Monday, August 7, 2017 at 2:36:10 PM UTC-7, Itzhak Daniel wrote:
> On Monday, August 7, 2017 at 11:03:27 PM UTC+3, Jakob Bohm wrote: 
> > 7. At Quihoo: Actually get rid of Richard Wang, not just change his
> >title from CEO to COO.
> 
> I didn't map the new hierarchy of the "Spanish" StartCom CA ("StartCom CA 
> Spain Sociedad Limitada"), having trouble registering to the Spanish company 
> house and pull documents (I pulled from 3rd party, but they're garbage [1] 
> [2]). I did mange to see that Mr. Barreira is the Directory but nothing on 
> the share holders or parent company.
> 
> I took a quick look at StartCom UK (as the information there is free) and 
> noticed Mr. Wang became a director again [3]... I wonder who is "StartCom CA 
> Spain Sociedad Limitada" parent/share holder, maybe a disclosure?
> 
> Links:
> 1. https://www.letsphish.org/files/StartCom-CA-SPA-Appointment.pdf
> 2. https://www.letsphish.org/files/StartCom-CA-SPA-Profile.pdf
> 3. https://beta.companieshouse.gov.uk/company/09744347

StartCom CA Spain Sociedad Limitada was not in the original hierarchy [1] or 
the proposed hierarchy [2] . I request that StartCom makes a full disclosure of 
the ownership information. 

In addition, in the WoSign remediation plan, WoSign Stated[3] that 

Due to the severity of issues noted within, the decision has been made to 
address the above three areas as they fall under the areas of 1) 
leadership/authority in WoSign and StartCom, 2) operational/business process 
and 3) technology. 

If WoSign/Startcom has determined leadership/authority is the No.1 cause of 
issues, why is Richard Wang appointed as a director of StartCom merely 6 month 
after his removal? This doesn't even mention his COO role at WoSign. 

[1] 
https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/startcom%7Csort:relevance/mozilla.dev.security.policy/0pqpLJ_lCJQ/z69lmZ88DwAJ
[2]https://en.wikipedia.org/wiki/StartCom#cite_note-structure201612-9
[3]https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Ryan Sleevi via dev-security-policy]

On Tuesday, August 8, 2017 at 6:31:34 AM UTC+9, Jakob Bohm wrote:
> On 07/08/2017 23:05, Vincent Lynch wrote:
> > Jakob,
> > 
> > I don't see what is wrong with Jonathan reporting these issues. The authors
> > and ratifiers of the BRs made the choice to specify these small details.
> > While a minor encoding error is certainly not as alarming as say, issuing
> > an md5 signed certificate, it is still an error and is worth reporting.
> > 
> > I believe it is decidedly off-topic to debate what BR violations are worth
> > reporting.
> > 
> > If you think certain BR rules are outdated or sub-par, I am sure the
> > community would welcome that discussion but it should be its own thread.
> > 
> 
> Since the CT made it possible, I have seen an increasing obsession with
> enforcing every little detail of the BRs, things that would not only
> have gone unnoticed, but also been considered unremarkable before CT.
> 
> Do we really want the CA community to be filled with bureaucratic
> enforcement of harsh punishments for every slight misstep?  This is the
> important question that any organization (in this case this community)
> needs to ask itself whenever new surveillance abilities make it possible
> to catch microscopic infractions.
> 
> Do we want to be the kind of place where people are punished for not
> polishing their boots perfectly or having a picture of their wife on
> their desk?  (To mention other rules that some organizations have
> overzealously enforced a long time ago).
> 
> 
> 
> 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

As mentioned earlier, you would be best to start your own thread.

As a peer for the module, I greatly appreciate the work Jonathan is doing, and 
encourage him to do more. If you feel otherwise, it may be best if you simply 
don't participate in those discussions, since the contrariness or explanations 
are not providing significant value to these discussions.

As others suspected, the use of an HTTPS URI for OCSP effectively prevents 
clients from being able to check, as clients including NSS, CryptoAPI, Chrome, 
and SecureTransport all refuse to check OCSP via HTTPS due to circular 
dependencies. This means that the inclusion of such a URL does not provide 
revocation services, and as those are presently required by the BRs, fails to 
meet those objectives.

Your proposed approach - of dividing things you feel are serious or minor - are 
actively harmful to the efforts of this community, in part due to seeming to 
lack sufficient context to assess the seriousness or minorness of the impact 
(as shown in this week's threads). Issues you have felt were minor are, in 
fact, serious, and the prevalence of a myriad of minor issues has historically 
been and continues to be a reasonable signal for more serious issues in either 
policy or practice. Perhaps it may be worth holding back on sharing opinions at 
first, so that these technical details can be shared and a better sense of 
serious and minor developed.
___
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 issued with HTTPS OCSP responder URL (IdenTrust)

[Matthew Hardeman via dev-security-policy]

> Do we really want the CA community to be filled with bureaucratic
> enforcement of harsh punishments for every slight misstep?  This is the
> important question that any organization (in this case this community)
> needs to ask itself whenever new surveillance abilities make it possible
> to catch microscopic infractions.

I can certainly see both sides.

The discovery of these matters is a natural consequence of the increasing 
prevalence (and ultimately mandatory nature) of CT.

I do think strong approach of identifying issues and potential issues 
accompanied with as forgiving a perspective as possible is important moving 
forward:

It is important that issues or potential issues (I would regard variance from 
the accepted norm in areas where there is ambiguity as to the propriety of a 
given encoding / parameter / etc in the standards as a "potential issue") be 
identified so that conclusions can be made as to what is or is not correct and 
proper and so that any unintended (or worse, precisely intended) consequences 
can be determined.

It is also important, however, that where there is no direct security risk, 
that there be a great deal of leeway and time to resolve the issues moving 
forward.  If this is not the case, the easy answer for any commercial CA would 
be to use the exact same software stack as every other CA.  There is already, 
in fact, a lot of concentration in that area.  If using same config X on 
software version Y of package A is the formula that every CA implements in 
order to not get caught out on these issues, this will create a significant 
monoculture as to key pieces of the PKI infrastructure which might easily 
create a greater ecosystem risk than some of these technical noncompliances.

Harsh punishments or consequences should be reserved for real security 
problems, real intentional deception, actual harms, etc.

The one gray area that must be watched for is constant issues of one form or 
another from a broad array of problem areas.  The community is NOT the basic 
compliance test bed.  A CA can not expect to just have the community do their 
QA and compliance testing.  Frequent issues on well resolved matters of a broad 
array all arising from a single CA would bring a question of whether the CA is 
exercising due care in their operations.

___
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: StartCom cross-signs disclosed by Certinomis

[Itzhak Daniel via dev-security-policy]

On Monday, August 7, 2017 at 11:03:27 PM UTC+3, Jakob Bohm wrote: 
> 7. At Quihoo: Actually get rid of Richard Wang, not just change his
>title from CEO to COO.

I didn't map the new hierarchy of the "Spanish" StartCom CA ("StartCom CA Spain 
Sociedad Limitada"), having trouble registering to the Spanish company house 
and pull documents (I pulled from 3rd party, but they're garbage [1] [2]). I 
did mange to see that Mr. Barreira is the Directory but nothing on the share 
holders or parent company.

I took a quick look at StartCom UK (as the information there is free) and 
noticed Mr. Wang became a director again [3]... I wonder who is "StartCom CA 
Spain Sociedad Limitada" parent/share holder, maybe a disclosure?

Links:
1. https://www.letsphish.org/files/StartCom-CA-SPA-Appointment.pdf
2. https://www.letsphish.org/files/StartCom-CA-SPA-Profile.pdf
3. https://beta.companieshouse.gov.uk/company/09744347
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Jakob Bohm via dev-security-policy]

On 07/08/2017 23:05, Vincent Lynch wrote:

Jakob,

I don't see what is wrong with Jonathan reporting these issues. The authors
and ratifiers of the BRs made the choice to specify these small details.
While a minor encoding error is certainly not as alarming as say, issuing
an md5 signed certificate, it is still an error and is worth reporting.

I believe it is decidedly off-topic to debate what BR violations are worth
reporting.

If you think certain BR rules are outdated or sub-par, I am sure the
community would welcome that discussion but it should be its own thread.



Since the CT made it possible, I have seen an increasing obsession with
enforcing every little detail of the BRs, things that would not only
have gone unnoticed, but also been considered unremarkable before CT.

Do we really want the CA community to be filled with bureaucratic
enforcement of harsh punishments for every slight misstep?  This is the
important question that any organization (in this case this community)
needs to ask itself whenever new surveillance abilities make it possible
to catch microscopic infractions.

Do we want to be the kind of place where people are punished for not
polishing their boots perfectly or having a picture of their wife on
their desk?  (To mention other rules that some organizations have
overzealously enforced a long time ago).



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 issued with HTTPS OCSP responder URL (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

> On Aug 7, 2017, at 16:57, Jakob Bohm via dev-security-policy 
>  wrote:
> 
> On 07/08/2017 22:47, Jonathan Rudenberg wrote:
>> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder 
>> URL that has a HTTPS URI scheme. This is not valid, the OCSP responder URI 
>> is required to have the plaintext HTTP scheme according to Baseline 
>> Requirements section 7.1.2.2(c).
>> Here’s the list of certificates: https://misissued.com/batch/4/
>> Jonathan
> 
> Why are you so obsessed with the least significant BR requirements?

I’m not convinced this is insignificant. NSS only supports http:// URLs for 
OCSP, and I suspect the majority of OCSP clients do the same.

https://hg.mozilla.org/projects/nss/file/3c4f0e9f6e45/lib/certhigh/ocsp.c#l2844
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Vincent Lynch via dev-security-policy]

Jakob,

I don't see what is wrong with Jonathan reporting these issues. The authors
and ratifiers of the BRs made the choice to specify these small details.
While a minor encoding error is certainly not as alarming as say, issuing
an md5 signed certificate, it is still an error and is worth reporting.

I believe it is decidedly off-topic to debate what BR violations are worth
reporting.

If you think certain BR rules are outdated or sub-par, I am sure the
community would welcome that discussion but it should be its own thread.

-Vincent

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

> On 07/08/2017 22:47, Jonathan Rudenberg wrote:
>
>> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder
>> URL that has a HTTPS URI scheme. This is not valid, the OCSP responder URI
>> is required to have the plaintext HTTP scheme according to Baseline
>> Requirements section 7.1.2.2(c).
>>
>> Here’s the list of certificates: https://misissued.com/batch/4/
>>
>> Jonathan
>>
>>
> Why are you so obsessed with the least significant BR requirements?
>
> The original prohibition on https revocation URLs was based on the risk
> that CAs might misconfigure this in a way that causes infinite recursion
> in clients checking that particular https certificate for revocation.
>
> This was before mass-surveillance became such a big issue, and might
> have been decided otherwise today.
>
> 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
>



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

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Jakob Bohm via dev-security-policy]

On 07/08/2017 22:47, Jonathan Rudenberg wrote:

“IdenTrust ACES CA 2” has issued five certificates with an OCSP responder URL 
that has a HTTPS URI scheme. This is not valid, the OCSP responder URI is 
required to have the plaintext HTTP scheme according to Baseline Requirements 
section 7.1.2.2(c).

Here’s the list of certificates: https://misissued.com/batch/4/

Jonathan



Why are you so obsessed with the least significant BR requirements?

The original prohibition on https revocation URLs was based on the risk
that CAs might misconfigure this in a way that causes infinite recursion
in clients checking that particular https certificate for revocation.

This was before mass-surveillance became such a big issue, and might
have been decided otherwise today.

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 issued with HTTPS OCSP responder URL (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

> On Aug 7, 2017, at 16:47, Jonathan Rudenberg via dev-security-policy 
>  wrote:
> 
> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder URL 
> that has a HTTPS URI scheme. This is not valid, the OCSP responder URI is 
> required to have the plaintext HTTP scheme according to Baseline Requirements 
> section 7.1.2.2(c).
> 
> Here’s the list of certificates: https://misissued.com/batch/4/

I also note that these certificates all have an organizationName of "U.S. 
Government”, but the rest of the subject details indicate organizations that 
are not components of the US Government.

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

Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

“IdenTrust ACES CA 2” has issued five certificates with an OCSP responder URL 
that has a HTTPS URI scheme. This is not valid, the OCSP responder URI is 
required to have the plaintext HTTP scheme according to Baseline Requirements 
section 7.1.2.2(c).

Here’s the list of certificates: https://misissued.com/batch/4/

Jonathan
___
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: StartCom cross-signs disclosed by Certinomis

[Jakob Bohm via dev-security-policy]

On 07/08/2017 11:21, Franck Leroy wrote:

Hello
I see many reactions that are not in line with the reality because you don’t 
have all the history on the subject.
I’ll try to summarize.
Approximately one year ago Inigo was CTO of Izenpe (CA of the Basque Country) 
and he left this company in order to join StartCom.
Not long after he arrives at StartCom (days? Weeks? I don’t know) we discover 
the deal that has been made by the previous CEO (Eddy Nigg) with the Chinese’s 
guys and the relations with WoSign.
Inigo could have resign in regard to the trap the hiring was, but he decided to 
face, and to setup the remediation plan defined by Mozilla community.
As said Jon Snow in S07E01: “I will not punish a son for this father’s sins”.
So instead of denigrate Inigo’s work, as a community we should encourage and 
support him.
Setting up a new company, with a new datacentre, new pki software, NO client, 
NO revenue, with Chinese employees far away speaking not fluent English and 
with the pressure of the market, it is definitely not an easy task! Personally 
I would not have tried this, so bravo for Inigo’s bravery…
One of the major thing to solve in addition of the remediation plan was to be 
back in the business as soon as possible, because without any incomes a company 
cannot survive.
So Inigo contacted me to know if Certinomis could help him to be back in the 
business. As you can imagine we did not said yes immediately.
But Inigo is not an anonymous guy coming from a strange area of Spain. He has 
been for many years an active CABForum member. He is also an active expert at 
ESTI, where he was editing the CA policy for web authentication certificates. 
Inigo is known for his expertise, trustworthiness, honesty and not the least 
his sympathy. So when he said that he will build a new StartCom and engage the 
remediation plan, we could trust him.
We are a community, not only in order to do the “police” but also to support 
each other’s. So my answer was “yes, we will see how we can help you in respect 
with community expectations”.
There was different possibilities to be back in the business while waiting for 
a brand new CA root included in the browsers; reselling Certinomis 
certificates, becoming a Certinomis RA, creation a StartCom subCA under our 
root using our technology or a cross-signing operation on new StartCom sub 
certificates.
The cross signing was not the very first option we studied because it requires 
that the new StartCom infrastructure be ready. But the other options were not 
so trivial, in a technical point of view but also in the context of restoring 
StartCom trust.
Then in November 2016 I contacted Kathleen and Gerv to know if there was some 
stoppers to work with Inigo to help StartCom to be back in the business.
There was no opposition as long as we follow the requirements of the 
remediation plan. Gerv also answered that our plan was good to him.
So with Inigo we studied the different possibilities and finally, taking into 
account cost and delay, the more efficient solution was cross signing new sub 
certificates from a StartCom full new pki with CT log and get this audited.
On April 2017 the new StartCom datacentre with EJBCA pki software were ready, 
and StartCom was able to create a new root and some sub CAs.
Then Inigo work on the CT log activation in the EJBCA software, not an easy 
task, and the bugs to solve. He also engaged the webtrust audit with PwC.
On April it was also the mouth when Certinomis had planned to use its offline 
root in order to sign the authority revocation list (ARL, the root CRL). So 
there was an opportunity to save money by also cross signing StartCom CAs 
during this operation. But it was strictly clear with Inigo that we will not 
give him the certificates as long as the remediation plan is not completed.
By the end of June the audit was completed and so Inigo send me the report on 
July 3rd.
I sent it to Kathleen to be sure that the auditor company was an acceptable one 
and that the editor’s opinion was in line with the Mozilla policy. Kathleen 
pointed out some minor issues, so I asked Inigo to correct them.
By mid July Inigo had corrected the remaining minor issues, he published the 
updated policies and audit assessment report on StartCom web site (July 14/07) 
and updated the remediation bug (1311832) stating that all remediation steps 
where achieved (17/07).
Back from vacation on August first, I read Inigo’s emails, checked the StartCom 
policies, audit report, remediation bug progress, and it appears that every 
steps was done. So I asked a confirmation to my management to let StartCom 
having the cross signing certificates.
The day after I received the go from my management, so I filled the CCADB with 
all the corresponding information: policies, practices, audit dates, audit 
report, certificates fingerprints… And then sent to Inigo the cross signed 
certificates.

It appeared that some people think that there is a policy violation 

Re: StartCom cross-signs disclosed by Certinomis

[Matthew Hardeman via dev-security-policy]

To play the devil's advocate...

If everything is as Mr. Leroy of Certinomis points out, I don't see the problem 
with the cross-sign.

In that version of events, the vast majority of the issues in the new PKI (test 
certs, etc) had already been revoked and measures put in place to prevent that 
sort of issuance prior to Startcom being provided the cross-sign certificates.

They've committed to logging everything in CT and I can not recall any 
suggestion that any issuances have occurred which evaded CT.

At this point, why not let them sink or swim?  Allow the cross-signs to stand.  
If Inigo has prior CA management experience and is running the technical 
picture at Startcom now, why not allow them to proceed under this new PKI 
infrastructure with past issues set aside and take a serious stance to any 
issues going forward.

As far as I know, the current manager of Startcom has not been previously 
accused of deception or bad action.  Far more than has been problematic in this 
early testing phase of their new PKI has been forgiven by the root programs 
before.

Is it not possible that they're getting increased animus just for being called 
Startcom?  I say "being called" because they have clearly undertaken a great 
deal of work to bring up an entirely new PKI infrastructure and have new and 
experienced management, according to Mr. Leroy's assertions.

Nothing disastrous or intentionally dishonest has been done in their new PKI.  
Why not grant them a gentleman's chance to proceed and address any further 
issues with great scrutiny?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom cross-signs disclosed by Certinomis

[Itzhak Daniel via dev-security-policy]

Trust is something you *gain*.

I want to believe the internet has come a long way from PGP signing parties.
___
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 common names not present in their SANs

[Alex Gaynor via dev-security-policy]

Sorry, you're right -- I'd misunderstood the issue with Python. (FWIW, I'm
one of the maintainers of the Python ssl module, and I anticipate us having
a fix for IDNs by the next release).

Alex

On Sun, Aug 6, 2017 at 8:38 PM, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> "simply" how?
>
> If it's your belief that the Python code actually does work for IDN SANs I
> think you're going to need to do better than just asserting that it's
> "simply" so in the face of subject experts saying it's broken.
> ___
> 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: StartCom cross-signs disclosed by Certinomis

[Franck Leroy via dev-security-policy]

Hello
I see many reactions that are not in line with the reality because you don’t 
have all the history on the subject.
I’ll try to summarize.
Approximately one year ago Inigo was CTO of Izenpe (CA of the Basque Country) 
and he left this company in order to join StartCom.
Not long after he arrives at StartCom (days? Weeks? I don’t know) we discover 
the deal that has been made by the previous CEO (Eddy Nigg) with the Chinese’s 
guys and the relations with WoSign.
Inigo could have resign in regard to the trap the hiring was, but he decided to 
face, and to setup the remediation plan defined by Mozilla community.
As said Jon Snow in S07E01: “I will not punish a son for this father’s sins”.
So instead of denigrate Inigo’s work, as a community we should encourage and 
support him.
Setting up a new company, with a new datacentre, new pki software, NO client, 
NO revenue, with Chinese employees far away speaking not fluent English and 
with the pressure of the market, it is definitely not an easy task! Personally 
I would not have tried this, so bravo for Inigo’s bravery…
One of the major thing to solve in addition of the remediation plan was to be 
back in the business as soon as possible, because without any incomes a company 
cannot survive.
So Inigo contacted me to know if Certinomis could help him to be back in the 
business. As you can imagine we did not said yes immediately.
But Inigo is not an anonymous guy coming from a strange area of Spain. He has 
been for many years an active CABForum member. He is also an active expert at 
ESTI, where he was editing the CA policy for web authentication certificates. 
Inigo is known for his expertise, trustworthiness, honesty and not the least 
his sympathy. So when he said that he will build a new StartCom and engage the 
remediation plan, we could trust him.
We are a community, not only in order to do the “police” but also to support 
each other’s. So my answer was “yes, we will see how we can help you in respect 
with community expectations”.
There was different possibilities to be back in the business while waiting for 
a brand new CA root included in the browsers; reselling Certinomis 
certificates, becoming a Certinomis RA, creation a StartCom subCA under our 
root using our technology or a cross-signing operation on new StartCom sub 
certificates.
The cross signing was not the very first option we studied because it requires 
that the new StartCom infrastructure be ready. But the other options were not 
so trivial, in a technical point of view but also in the context of restoring 
StartCom trust.
Then in November 2016 I contacted Kathleen and Gerv to know if there was some 
stoppers to work with Inigo to help StartCom to be back in the business.
There was no opposition as long as we follow the requirements of the 
remediation plan. Gerv also answered that our plan was good to him.
So with Inigo we studied the different possibilities and finally, taking into 
account cost and delay, the more efficient solution was cross signing new sub 
certificates from a StartCom full new pki with CT log and get this audited.
On April 2017 the new StartCom datacentre with EJBCA pki software were ready, 
and StartCom was able to create a new root and some sub CAs.
Then Inigo work on the CT log activation in the EJBCA software, not an easy 
task, and the bugs to solve. He also engaged the webtrust audit with PwC.
On April it was also the mouth when Certinomis had planned to use its offline 
root in order to sign the authority revocation list (ARL, the root CRL). So 
there was an opportunity to save money by also cross signing StartCom CAs 
during this operation. But it was strictly clear with Inigo that we will not 
give him the certificates as long as the remediation plan is not completed.
By the end of June the audit was completed and so Inigo send me the report on 
July 3rd.
I sent it to Kathleen to be sure that the auditor company was an acceptable one 
and that the editor’s opinion was in line with the Mozilla policy. Kathleen 
pointed out some minor issues, so I asked Inigo to correct them.
By mid July Inigo had corrected the remaining minor issues, he published the 
updated policies and audit assessment report on StartCom web site (July 14/07) 
and updated the remediation bug (1311832) stating that all remediation steps 
where achieved (17/07).
Back from vacation on August first, I read Inigo’s emails, checked the StartCom 
policies, audit report, remediation bug progress, and it appears that every 
steps was done. So I asked a confirmation to my management to let StartCom 
having the cross signing certificates.
The day after I received the go from my management, so I filled the CCADB with 
all the corresponding information: policies, practices, audit dates, audit 
report, certificates fingerprints… And then sent to Inigo the cross signed 
certificates.

It appeared that some people think that there is a policy violation about the 
delay for CCADB disclosure.
Maybe I 

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