CN not in SAN in CT certificate

[Varga Viktor via dev-security-policy]

Dear Dev.Sec.Policy,



Following you can find our report about the problem reported about the Bug 
1462423.



  1.  How your CA first became aware of the problem (e.g. via a problem report 
submitted to your Problem Reporting Mechanism, a discussion in 
mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the 
time and date.



On 2018-05-17 Andrew Ayer reported the problem through the standard email 
channel: visszavo...@netlock.hu used for 
revoking certificates. Unfortunately we missed the Mozilla bug ticked reminder 
at this time.



  1.  A timeline of the actions your CA took in response. A timeline is a 
date-and-time-stamped sequence of all relevant events. This may include events 
before the incident was reported, such as when a particular requirement became 
applicable, or a document changed, or a bug was introduced, or an audit was 
done.



After we got Andrews mail, we immediately stopped the issuance until the 
investigation. We identified 7 certificates with this problem (which have 
problematic CT certificates) and communicated with the end user about the 
problem. It was a configuration error in the production system on these 
certificates, which was the root cause.



  1.  Whether your CA has stopped, or has not yet stopped, issuing certificates 
with the problem. A statement that you have will be considered a pledge to the 
community; a statement that you have not requires an explanation.



Upon receiving Andrew's email, we stopped the issuing certificates until the 
conclusion of the investigation. After the identification of affected 
certificates and cause, we made the necessary corrections, double checked, and 
then restarted the issuing.



4. A summary of the problematic certificates. For each problem: number of 
certs, and the date the first and last certs with that problem were issued.

7 incorrect CT certificates were issued between 2018-05-10 and 2018-05-17 
connected to issuing 7 standard certificates.



  1.  The complete certificate data for the problematic certificates. The 
recommended way to provide this is to ensure each certificate is logged to CT 
and then list the fingerprints or crt.sh IDs, either in the report or as an 
attached spreadsheet, with one list per distinct problem.



The problematic CT certificates have the following ids:

https://crt.sh/?id=453465677

https://crt.sh/?id=453471736

https://crt.sh/?id=454888650

https://crt.sh/?id=455334246

https://crt.sh/?id=463346340

https://crt.sh/?id=463665252

https://crt.sh/?id=465748957



6. Explanation about how and why the mistakes were made or bugs introduced, 
and how they avoided detection until now.



It was a misconfiguration in the production system. A placeholder config entry 
was left in a specific cert type. We have new test cases and protocol in place 
to avoid this problem in the future.

7. List of steps your CA is taking to resolve the situation and ensure such 
issuance will not be repeated in the future, accompanied with a timeline of 
when your CA expects to accomplish these things.



We already modified the configuration and also added extra validation to block 
these types of errors.


sincerely yours,

Viktor Varga

Netlock

chief architect






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

usareally.com and OFAC lists

[Doug Beattie via dev-security-policy]

A few of us have been discussing the usareally.com "issue" recently.  In
case you didn't know, the US Treasure put out a notice that US companies
must not do business with USA Really:

https://home.treasury.gov/news/press-releases/sm577

 

Let's Encrypt mapped that release to certificates they had issued to the
domain and revoked them:

https://www.mcclatchydc.com/news/policy/technology/cyber-security/article223
832790.html 

 

They came to the GlobalSign Russia organization then to WoTrus:

https://crt.sh/?q=usareally.com

US CAs should take notice and put the proper controls in place.

 

This site never appeared on Google Safe Browsing as it's not a malware "bad
site", and it's safe to visit.  You can even issue them a certificate or do
business with them if you're not a US company.  It's likely that there are
governmental notices like this in other regions which would be useful to
share and factor into the CA's High Risk checks.

 

Does this group have any recommendations for how/where such "claims" or
announcements could be posted? Is the this list off-limits for such
communication?

 

 



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: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)

[Ryan Sleevi via dev-security-policy]

I don't think it's reasonable to push the problem to your CA software
vendor.

If Verizon does not provide this support, what steps will your CA take? If
you know what those steps are, is there reason not to take them now? If you
do not know what those steps are, when will you know?

Your software is producing invalid and improper certificates. The
responsibility for that ultimately falls on the CA, and understanding what
steps the CA is taking to prevent that is critical. It appears that the
steps, today, rely on human factors. As the past year of incident reports
have shown, relying solely on human factors is not a reasonable practice.

On Fri, Jan 11, 2019 at 3:50 AM Grabowski Piotr 
wrote:

> Hello Wayne,
>
> Thank you for your email.
>
> I think it is still the same incident. In my opinion there is no need to 
> create another thread. Let me explain how it happened.
>
>
>
> As I said in previous emails we have requested urgent need for pre-linting 
> feature from Verizon just after the incident was reported. I have sent a few 
> reminders
>
> and finally on 18th of December 2018 got a response :
>
> "The feature request of implementing pre-issuance linting was discussed with 
> PM and development today. Our feeling is that UniCERT is policy-centric 
> software and therefore the burden of ensuring that “misissuance” does not 
> happen is on the implementer of the policies.  To help with this, we provide 
> registration policy templates in the Registration Policy Wizard and they 
> ensure most of x509lint test. ", but the keyword here is *most.*
>
>  We can not for example restrict the length of the field like 
> organizationName to have no more than 64 characters. We can set it as 
> mandatory or not.
>
>  It is the only gap we have now in our policy templates.  We tried to 
> mitigate this risk putting the informational text on operators website and in 
> the dedicated
>
> procedure to double check the orgranizationName text size when operator is 
> filling up the form of certificate request but but this time he did not 
> perform this check.  The post-linting procedure officially came into a force 
> on the 1st of January 2019 as a procedural step to check the certificate that 
> was just issued so unfortunately this certificate was not encompassed by the 
> procedure. The OCSP status is 'unknown' because the customer have not  picked 
> up the certificate yet.
>
>
>
> Anyway, I sent another email to Verizon that we need specific x509lint or 
> zlint feature with fileld length validation so the case is in progress.
>
> Please belive me, we try to practice due care as much as we can but we are 
> just one among many clients of Verizon and we don't have such a clout to
>
> force them to implement new feature in the timeline we propose. I have 
> described in details our need and belive they will deliver the feature as 
> soon as they can.
>
>
>
> We have already reinforced and made live our post-linting procedure to check 
> not only certificate that was just issued but check wider range like this
>
> https://crt.sh/?caid=15985&opt=cablint,zlint,x509lint&minNotBefore=2019-01-01
>
>
>
> TODO:
>
> -   Keep exerting pressure on Verizon to deliver:
>
> o   Policy field size validation – in our opinion it is simple change request 
> and should be delivered ASAP.
>
> o   native x509lint or zlint feature
>
>
>
>
>
> Piotr Grabowski
> Linia biznesowa podpis elektroniczny
> Krajowa Izba Rozliczeniowa S.A.
> ul. rtm. W. Pileckiego 65
> 02-781 Warszawa
>
> Tel. +48 22 545 56 76
>
> Tel. +48 507 024 083
>
>
>
> *From:* Wayne Thayer 
> *Sent:* Wednesday, January 09, 2019 9:52 PM
> *To:* Grabowski Piotr 
> *Cc:* r...@sleevi.com; mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> *Subject:* Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR
> violations (KIR)
>
>
>
> KIR recently misissued another (pre-)certificate with an organizationName
> field containing too many characters [1]. This is despite being given
> specific guidance earlier in this thread on the organizationName attribute
> [2]. I have requested a new incident report in the bug [3].
>
>
>
> A pre-certificate was logged but the OCSP status is reported as "unknown",
> so I assume that KIR detected this prior to signing the certificate. If so,
> I find it particularly troubling that KIR decided not to report this, and
> that after 3 months they still have no commitment from their vendor to
> implement pre-issuance linting [4].
>
>
>
> - Wayne
>
>
>
> [1] https://crt.sh/?id=1036631881&opt=zlint
>
> [2]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/IRLlR1AJ0vA/daHgd-IXBAAJ
>
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1495497
>
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1495497#c5
>
>
>
> On Fri, Oct 12, 2018 at 8:16 AM Grabowski Piotr 
> wrote:
>
> Hello,
>
> My comments in blue.
>
>
> --
>
> *Od:* Ryan Sleevi 
> *Wysłane:* czwartek, 11 października 2018 04:53
> *

Re: P-521 Certificates

[Peter Gutmann via dev-security-policy]

Jakob Bohm via dev-security-policy  
writes:

>On 11/01/2019 13:04, Peter Gutmann wrote:
>> Jason via dev-security-policy  writes:
>> 
>>> I would say that the problem here would be that a child certificate can't 
>>> use
>>> a higher cryptography level than the issuer
>> 
>>Why not?  If the issuer uses strong-enough crypto, what difference does it
>>make what the child uses?
>
>Really?  If the CA key is weaker than the child key, an attacker can break
>the CA key and sign a fake certificate with less effort than breaking the
>child key directly

You've apparently missed the fact that I said "strong-enough crypto".  The
attacker can't break either the issuer key or the child key, no matter how
much stronger the child key may be than the issuer.

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

Re: P-521 Certificates

[Jakob Bohm via dev-security-policy]

On 11/01/2019 13:04, Peter Gutmann wrote:
> Jason via dev-security-policy  writes:
> 
>> I would say that the problem here would be that a child certificate can't use
>> a higher cryptography level than the issuer
> 
> Why not?  If the issuer uses strong-enough crypto, what difference does it
> make what the child uses?
> 
> Peter.
> 

Really?  If the CA key is weaker than the child key, an attacker can 
break the CA key and sign a fake certificate with less effort than 
breaking the child key directly (for modern crypto that "easier" is 
the difference between degrees of resistance to future cryptanalytic 
attacks, thus often involving some guesswork).

This obviously is less effective for encryption public keys than 
signature public keys, as faking a new certificate doesn't provide 
access to data encrypted to the real certificate.  It is also ineffective 
if the certificate is checked against additional criteria than the CA 
signatures, such as a strong Merkle hash tree or non-cryptographic proof 
of the certificate contents.

Thus signing stronger child keys from weaker CA keys is often allowed 
as a transition mechanism when a trusted root with strength n has been 
widely distributed, yet there is a desire to introduce new keys with 
strength m > n .

The typical way (at least in the past) is for the strength n CA key to 
cross sign a strength m CA key, which is also made available as its 
own root cert for future deployment, thus eventually removing the 
reliance on the strength n key to validate the strength m keys.

This was seen a lot during the long transition from RSA-SHA1 to 
RSA-SHA256, and some CAs may wish to prepare early for future 
transitions from RSA-SHA256 and ECDSA-SHA256 to stronger algorithms.

Similarly, some users obtained end certificates based on 2048 bit RSA 
back when 1024 bit RSA was the norm.  Similarly situated users today 
may wish to get ECDSA-P-521 or EdDSA-488 keys at a time when half as 
long keys are the norm.  While getting such certificates from a weaker 
CA is obviously vulnerable to future attacks on the CA key, at least 
this provides a safety margin where the mitigations mentioned above 
are likely to be available.


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: P-521 Certificates

[Peter Gutmann via dev-security-policy]

Jason via dev-security-policy  writes:

>I would say that the problem here would be that a child certificate can't use
>a higher cryptography level than the issuer

Why not?  If the issuer uses strong-enough crypto, what difference does it
make what the child uses?

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

RE: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)

[Grabowski Piotr via dev-security-policy]

Hello Wayne,

Thank you for your email.

I think it is still the same incident. In my opinion there is no need to create 
another thread. Let me explain how it happened.



As I said in previous emails we have requested urgent need for pre-linting 
feature from Verizon just after the incident was reported. I have sent a few 
reminders

and finally on 18th of December 2018 got a response :

"The feature request of implementing pre-issuance linting was discussed with PM 
and development today. Our feeling is that UniCERT is policy-centric software 
and therefore the burden of ensuring that “misissuance” does not happen is on 
the implementer of the policies.  To help with this, we provide registration 
policy templates in the Registration Policy Wizard and they ensure most of 
x509lint test. ", but the keyword here is most.



We can not for example restrict the length of the field like organizationName 
to have no more than 64 characters. We can set it as mandatory or not.



It is the only gap we have now in our policy templates.  We tried to mitigate 
this risk putting the informational text on operators website and in the 
dedicated

procedure to double check the orgranizationName text size when operator is 
filling up the form of certificate request but but this time he did not perform 
this check.  The post-linting procedure officially came into a force on the 1st 
of January 2019 as a procedural step to check the certificate that was just 
issued so unfortunately this certificate was not encompassed by the procedure. 
The OCSP status is 'unknown' because the customer have not  picked up the 
certificate yet.



Anyway, I sent another email to Verizon that we need specific x509lint or zlint 
feature with fileld length validation so the case is in progress.

Please belive me, we try to practice due care as much as we can but we are just 
one among many clients of Verizon and we don't have such a clout to

force them to implement new feature in the timeline we propose. I have 
described in details our need and belive they will deliver the feature as soon 
as they can.



We have already reinforced and made live our post-linting procedure to check 
not only certificate that was just issued but check wider range like this

https://crt.sh/?caid=15985&opt=cablint,zlint,x509lint&minNotBefore=2019-01-01



TODO:

-   Keep exerting pressure on Verizon to deliver:

o   Policy field size validation – in our opinion it is simple change request 
and should be delivered ASAP.

o   native x509lint or zlint feature


Piotr Grabowski
Linia biznesowa podpis elektroniczny
Krajowa Izba Rozliczeniowa S.A.
ul. rtm. W. Pileckiego 65
02-781 Warszawa
Tel. +48 22 545 56 76
Tel. +48 507 024 083

From: Wayne Thayer 
Sent: Wednesday, January 09, 2019 9:52 PM
To: Grabowski Piotr 
Cc: r...@sleevi.com; mozilla-dev-security-policy 

Subject: Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)

KIR recently misissued another (pre-)certificate with an organizationName field 
containing too many characters [1]. This is despite being given specific 
guidance earlier in this thread on the organizationName attribute [2]. I have 
requested a new incident report in the bug [3].

A pre-certificate was logged but the OCSP status is reported as "unknown", so I 
assume that KIR detected this prior to signing the certificate. If so, I find 
it particularly troubling that KIR decided not to report this, and that after 3 
months they still have no commitment from their vendor to implement 
pre-issuance linting [4].

- Wayne

[1] https://crt.sh/?id=1036631881&opt=zlint
[2] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/IRLlR1AJ0vA/daHgd-IXBAAJ
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1495497
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1495497#c5

On Fri, Oct 12, 2018 at 8:16 AM Grabowski Piotr 
mailto:piotr.grabow...@kir.pl>> wrote:

Hello,

My comments in blue.


Od: Ryan Sleevi mailto:r...@sleevi.com>>
Wysłane: czwartek, 11 października 2018 04:53
Do: Grabowski Piotr
DW: Wayne Thayer; mozilla-dev-security-policy
Temat: Re: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)


On Wed, Oct 10, 2018 at 4:33 PM Grabowski Piotr via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Hello Wayne,

- Is the new dual control process documented in a manner that will be auditable 
by your external auditors?

  Yes, the new dual control process is already included in the document called 
instruction of the security of system Szafir (internal name of the PKI system)  
 and it is one of the document that is presented to internal and external 
auditors.

Has this been added to your CP/CPS? If not, why not?
-in our CP/CPS we have already the statement that key functions require dual 
control

Can you please detail the additional controls that were specified?

- Despite the review, is it possible for one malicious employee to modify a 
policy templa