Policy 2.8: MRSP Issue #178: Sunset SHA1

788 views
Skip to first unread message

Ben Wilson

unread,
Jan 21, 2022, 2:54:49 PM1/21/22
to dev-secur...@mozilla.org
All,

This email launches a new discussion related to sunsetting the future use of SHA1 in the Mozilla Root Store Policy (MRSP). 

It is related to GitHub Issue #178 (as well as Issue #201).

SHA1 is still allowed to be used in signing SMIME certificates, Authority Revocation Lists (ARLs), and CRLs, and OCSP responses (but see CABF Ballot

SC53: Sunset for SHA-1 OCSP Signing).

Can the future use of SHA1 signing be eliminated from the MRSP altogether, and if so, on what timeframes?

Currently, SHA1 is mentioned in the MRSP as follows:
-----------

When a root or intermediate certificate's RSA key is used to produce a signature, only the following algorithms may be used, and with the following encoding requirements:

  • RSASSA-PKCS1-v1_5 with SHA-1.

    The encoded AlgorithmIdentifier MUST match the following hex-encoded bytes: 300d06092a864886f70d0101050500.

See section 5.1.3 for further restrictions on the use of SHA-1.

Section 5.1.3 SHA-1

CAs MAY sign SHA-1 hashes over end-entity certificates which chain up to roots in Mozilla's program only if all the following are true:

  1. The end-entity certificate:

    • is not within the scope of the Baseline Requirements;
    • contains an EKU extension which does not contain either of the id-kp-serverAuth or anyExtendedKeyUsage key purposes;
    • has at least 64 bits of entropy from a CSPRNG in the serial number.

  2. The issuing certificate:

    • contains an EKU extension which does not contain either of the id-kp-serverAuth or anyExtendedKeyUsage key purposes;
    • has a pathlen:0 constraint.

Point 2 does not apply if the certificate is an OCSP signing certificate manually issued directly from a root.

CAs MAY sign SHA-1 hashes over intermediate certificates which chain up to roots in Mozilla's program only if the certificate to be signed is a duplicate of an existing SHA-1 intermediate certificate with the only changes being all of:

  • a new key (of the same size);
  • a new serial number (of the same length);
  • the addition of an EKU and/or a pathlen constraint to meet the requirements outlined above.

CAs MAY sign SHA-1 hashes over OCSP responses only if the signing certificate contains an EKU extension which contains only the id-kp-ocspSigning EKU.

CAs MAY sign SHA-1 hashes over CRLs for roots and intermediates only if they have issued SHA-1 certificates.

CAs MUST NOT sign SHA-1 hashes over other data, including CT pre-certificates.

-----------

I am thinking that we could amend MSRP sections 5.1.1 and 5.1.3 to have sunset dates and to also say something to the effect that:

"CAs MUST NOT sign SHA-1 hashes over any data."

Thoughts?

Thanks,

Ben





Ben Wilson

unread,
Jan 25, 2022, 10:29:46 PM1/25/22
to dev-secur...@mozilla.org
My previous email asked, "Can the future use of SHA1 signing be eliminated from the MRSP altogether, and if so, on what timeframes?" 

Rather than attempt to determine SHA1 deprecation timeframes here, I am going to create a CA Communication and Survey. The survey will go out to all CAs in the Mozilla program, and it will ask the relevant questions that will help us determine appropriate sunset dates for SHA1.

Thanks,

Ben

Ryan Sleevi

unread,
Jan 26, 2022, 1:12:06 AM1/26/22
to Ben Wilson, dev-secur...@mozilla.org
It’s not clear: what situations make it appropriate for a CA communication, versus discussion here?

Given Mozilla requires CA program participants monitor this list, and given the discussion gives a chance to gather feedback directly, it’s not entirely clear the benefit? Do we expect that some CAs are out of compliance with that part of the program?

If CAs don’t respond, but are otherwise aware, isn’t it reasonable to conclude “Yes” and “immediately”? Isn’t that part of the point of the policy in the first place - for CAs to engage when questions are raised, while also being able to be aware of discussions relevant to there operations, whether it be new policies, incidents, or other matters of interest?

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaa9f1Oi6bNSkHfu4Cnd%3DgNUnbF_6DuKgYGULSOWb3myog%40mail.gmail.com.

Ben Wilson

unread,
Jan 26, 2022, 2:00:33 PM1/26/22
to Ryan Sleevi, dev-secur...@mozilla.org
See responses inline below.

On Tue, Jan 25, 2022 at 11:12 PM Ryan Sleevi <ry...@sleevi.com> wrote:
It’s not clear: what situations make it appropriate for a CA communication, versus discussion here?

Yes.  It is preferable that discussion take place here. However, a survey would still be public, as they have been in the past, and the CCADB would collect all of the responses in a table format.
 
Given Mozilla requires CA program participants monitor this list, and given the discussion gives a chance to gather feedback directly, it’s not entirely clear the benefit? Do we expect that some CAs are out of compliance with that part of the program?

Section 4.2 of the MRSP says, "Mozilla may conduct a survey of CAs from time to time using the CCADB. CAs are required to respond to the surveys with accurate information, within the timescale defined in the survey." I thought it might be an opportunity that would ensure we canvas CAs for a response, rather than sit back and wait for responses, if any, to trickle in.

If CAs don’t respond, but are otherwise aware, isn’t it reasonable to conclude “Yes” and “immediately”? Isn’t that part of the point of the policy in the first place - for CAs to engage when questions are raised, while also being able to be aware of discussions relevant to there operations, whether it be new policies, incidents, or other matters of interest?

While silence should constitute consent, I think experience has shown that not all CAs are aware of requirements that change the way their services are performed. That being said, here are some questions that could be asked here in an email format:

Do any of your Mozilla-trusted CAs still sign SMIME certificates using the SHA1 algorithm?  (Y/N)
When should CAs be prohibited from signing SMIME certificates using the SHA1 algorithm? (Date)

Do any of your Mozilla-trusted CAs still sign CRLs for SMIME certificates using the SHA1 algorithm?  (Y/N)
When should CAs be prohibited from signing CRLs for SMIME certificates using the SHA1 algorithm? (Date)

Do you still sign OCSP responses for SMIME certificates using the SHA1 algorithm?  (Y/N)
When should CAs be prohibited from signing OCSP responses for SMIME certificates using the SHA1 algorithm? (Date)

Thanks,
Ben

Ryan Sleevi

unread,
Jan 26, 2022, 2:41:05 PM1/26/22
to Ben Wilson, Ryan Sleevi, dev-secur...@mozilla.org
On Wed, Jan 26, 2022 at 2:00 PM Ben Wilson <bwi...@mozilla.com> wrote:
See responses inline below.

On Tue, Jan 25, 2022 at 11:12 PM Ryan Sleevi <ry...@sleevi.com> wrote:
It’s not clear: what situations make it appropriate for a CA communication, versus discussion here?

Yes.  It is preferable that discussion take place here. However, a survey would still be public, as they have been in the past, and the CCADB would collect all of the responses in a table format.

Oh, for sure :) I just know that the surveys have historically had delays or had confusion by CAs in interpreting questions, and the survey approach somewhat predates the m.d.s.p. participation requirement. I totally realize that it has benefits for bringing direct awareness, but I raise it to try and understand if the expectation is to always have the two parallel paths for soliciting feedback, or if it might just be sufficient to email blast CAs to say "Hey, here's the discussion, to send feedback, please participate here". That, I think, might achieve the goal of highlighting the importance, while still centralizing some of the conversation :) Just a thought

Ben Wilson

unread,
Feb 1, 2022, 10:59:37 PM2/1/22
to Ryan Sleevi, dev-secur...@mozilla.org
I have emailed CAs in the Mozilla program asking them to respond here.

Aaron Gable

unread,
Feb 2, 2022, 12:35:58 PM2/2/22
to dev-secur...@mozilla.org, bwi...@mozilla.com, dev-secur...@mozilla.org
For the sake of completeness: Let's Encrypt / ISRG does not sign SHA-1 hashes for any purpose, and would be amenable to any sunset date.

We do accept signatures over SHA-1 hashes of CSRs provided by subscribers, and of course accept SHA-1 hashes for the issuerKeyHash and issuerNameHash in OCSP requests, but those are not relevant to this proposal.

Aaron

Mohamed Abdelshahid

unread,
Feb 3, 2022, 1:10:40 AM2/3/22
to Ben Wilson, dev-secur...@mozilla.org, Policy Authority

Dear All,


DESC is already using sha256 for signing CRLs, OCSP responses, and EE Certificates. 


Kind Regards,



Mohamed Abdelshahid

محمد عبدالشهيد
Principal PKI Consultant
T: +97144150400 P.O. Box 36996
M: +971566824278 Dubai, UAE
E: mohamed.a...@desc.gov.ae www.desc.gov.ae
DXB-GOV-LOGO DESC-LOGO
YOUTUBE_LOGO LINKEDIN_LOGO TWITTER_LOGO FB_LOGO INSTA_LOGO

 

 

Disclaimer:
This email and any files transmitted with it may be confidential and contain privileged or copyright information. If you are not the intended recipient you must not copy, distribute or use this email or the information contained in it for any purpose other than to notify us of the receipt thereof, if you have received this message in error, please notify the sender immediately, and delete this email from your system. Please note that e-mails are susceptible to change, the sender shall not be liable for the improper or incomplete transmission of the information contained in this communication, nor for any delay in its receipt or damage to your system. The sender does not guarantee that this material is free from viruses or any other defects although due care has been taken to minimize the risk.

Please consider your environmental responsibility before printing this e-mail.

إخلاء المسؤولية:
إن المعلومات الواردة في هذا البريد الإلكتروني وأي ملفات مرفقة به هي معلومات خاصة بالمرسل إليه أو المتعامل، وقد تحتوي على معلومات سرية أو مواد محمية. إن لم تكن أحد المعنيين باستلام هذا البريد الإكتروني، فيمنع منعاً باتاً نسخ أو توزيع أو اتخاذ إجراء بالاعتماد على المعلومات الواردة فيه، وإن كان قد وصلك عن طريق الخطأ، فالرجاء المبادرة فوراً بإشعار المرسل بذلك، وحذف البريد من جهازك. يرجى العلم بأن البريد الإلكتروني هو عنصر قابل للتغيير؛ ولذا لن يكون المُرسل خاضعاً للمساءلة حال انتقال المعلومات في هذا البريد بصورة غير ملائمة أو منتقصة، ولا تجاه أي تأخير في وصوله، أو تجاه أي عطل في جهازك. إن مركز دبي للأمن الإلكتروني لا يتحمل مسؤولية أي أضرار ناتجة عن أي فيروس أو برنامج قد يرسل بواسطة هذا البريد الإلكتروني.

 

من فضلك خذ بعين الاعتبار مسؤوليتك تجاه البيئة قبل طباعة هذا البريد الإلكتروني.

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Ben Wilson <bwi...@mozilla.com>
Sent: Wednesday, February 2, 2022 7:59 AM
To: Ryan Sleevi
Cc: dev-secur...@mozilla.org
Subject: Re: Policy 2.8: MRSP Issue #178: Sunset SHA1
 
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

Masaru Sakamoto

unread,
Feb 3, 2022, 11:28:33 AM2/3/22
to dev-secur...@mozilla.org, bwi...@mozilla.com, dev-secur...@mozilla.org
Hello,

This is Cybertrust Japan. One of our root CAs uses SHA-1 for CRL signing.
But we would like to sunset the use of SHA1.  In fact, our plan is to retire this SHA-1 Root of SecureSign Root11 and replace it with its successors. So we are preparing root inclusion requests.


Best,
Mo

2022年2月3日木曜日 2:35:58 UTC+9 aa...@letsencrypt.org:

Bruce Morton

unread,
Feb 3, 2022, 4:12:39 PM2/3/22
to dev-secur...@mozilla.org, mo.masar...@gmail.com, bwi...@mozilla.com, dev-secur...@mozilla.org
Entrust has already sunset SHA-1 for S/MIME certificates. Entrust will respond to ballot SC53 and will stop using SHA-1 with OCSP responses and will push this requirement to CRLs as well. We have also reached out to our subordinate CAs to advise of the pending change and confirm their current SHA-1 status.

加毛 寿

unread,
Feb 4, 2022, 5:57:24 AM2/4/22
to Ben Wilson, dev-secur...@mozilla.org

Ben-san,

 

Regarding Policy 2.8: MRSP Issue #178: Sunset SHA1, we agree with the response with a view to improving the reliability of network security.

 

On the other hand, the CRL signed with SHA-1 of a Root CA Certificate (Security Communication Root CA1) (* 1) is used for the verification of the already issued client-auth certificate, and suppose if we try replace the verification logic to SHA-2, the serious impact on the PKI of client-auth may be expected, which makes difficulty doing it.  For that reason, we are planning to use the SHA-1 CRL until September 2023, which is the expiration date of Security Communication Root CA1. Therefore, in order to comply sunset of the SHA-1 CRL before that date, we believe that it is necessary to erase the security bit of server-auth and revoke the Cross root certificate.

We are currently working on the timeline planning for these procedures. We also understand that this validation path is used by the feature phones (old cell phones) with a hard-coded trust store.  (As reported in # 8.d of April 2021 CA Communication (* 2), NTT DoCoMo, a Japanese mobile phone top carrier, plans to continue providing services to those feature phones until March 2026). We suppose that users who still use these feature phones include a significant proportion of elderly people, and that they will pay greater switching costs than ordinary consumers would do. In such a situation, we also had received requests from some stakeholders to let them have a certain period of informing time before revoking the Cross-Root Certificate, so that we are trying to decide timeline bit more carefully compare to other cases.

 

(*1)  SHA1 Root CA Certificate (Security Communication RootCA1)

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

Sep 30 04:20:49 2023 GMT

 

(*2)  #8.d of April 2021 CA Communication

https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00156,Q00151,Q00158

 

Thank you for your consideration.

 

Best regards,

Hisashi Kamo

 

 

From: 'Bruce Morton' via dev-secur...@mozilla.org [mailto:dev-secur...@mozilla.org]
Sent: Friday, February 4, 2022 6:13 AM
To: dev-secur...@mozilla.org
Cc: mo.masar...@gmail.com <mo.masar...@gmail.com>; bwi...@mozilla.com <bwi...@mozilla.com>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: Policy 2.8: MRSP Issue #178: Sunset SHA1

 

Entrust has already sunset SHA-1 for S/MIME certificates. Entrust will respond to ballot SC53 and will stop using SHA-1 with OCSP responses and will push this requirement to CRLs as well. We have also reached out to our subordinate CAs to advise of the pending change and confirm their current SHA-1 status.

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

Ben Wilson

unread,
Feb 4, 2022, 12:50:38 PM2/4/22
to dev-secur...@mozilla.org
All,

Do we know of any CA claiming a need to sign with SHA1 past September 2023?

Also, two other concepts that I don't believe have been fully expressed yet are:

1 - Mozilla curates the trust store for TLS server authentication and for SMIME and not for other uses - see https://blog.mozilla.org/security/2021/05/10/beware-of-applications-misusing-root-stores/, and

2 - while switching from SHA1 to SHA2 might be costly and time-consuming for some CAs, isn't it something that they need to do sooner rather than later?

Thanks,

Ben

Rob Stradling

unread,
Feb 4, 2022, 4:08:13 PM2/4/22
to Ben Wilson, Ryan Sleevi, dev-secur...@mozilla.org
Sectigo currently still "sign[s] SHA-1 hashes over CRLs for roots and intermediates only if they have issued SHA-1 certificates", as permitted by https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#513-sha-1.

It would require very little effort for us to reconfigure these roots and intermediates so that they use SHA-256 instead.

We expect that switching to SHA-256 will bring minimal, perhaps even zero, disruption to relying parties.  Therefore, we'll be happy with whatever sunset date Mozilla chooses.

Sent: 02 February 2022 03:59
To: Ryan Sleevi <ry...@sleevi.com>
Cc: dev-secur...@mozilla.org <dev-secur...@mozilla.org>

Subject: Re: Policy 2.8: MRSP Issue #178: Sunset SHA1
 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

Ben Wilson

unread,
Feb 7, 2022, 11:43:27 AM2/7/22
to dev-secur...@mozilla.org
I feel we need additional input here from Certification Authorities who have not yet responded.

Jeremy Rowley

unread,
Feb 7, 2022, 11:59:47 AM2/7/22
to Ben Wilson, dev-secur...@mozilla.org

DigiCert supports banning SHA1 across the board. We are no longer supporting SHA1 signatures for services related to certs trusted by Mozilla.

 

Jeremy

Joanna Fox

unread,
Feb 7, 2022, 12:12:13 PM2/7/22
to dev-secur...@mozilla.org, bwi...@mozilla.com

TrustCor Systems does not use SHA1 for signing of SMIME certificates, ARLs/CRLs, and OCSP responses and would be open to any sunset date. We do support SHA1 hash-types in our OCSP responses.

Joanna Fox
Head of Digital Certificate Compliance

Peter Miškovič

unread,
Feb 8, 2022, 1:08:28 AM2/8/22
to dev-secur...@mozilla.org, Ben Wilson

Disig currently uses SHA-256 signing exclusively, so there is no problem with sunset of SHA-1.

 

Regards

Peter

Doug Beattie

unread,
Feb 8, 2022, 6:53:11 AM2/8/22
to Ben Wilson, dev-secur...@mozilla.org

Hi Ben,

 

GlobalSign supports banning SHA-1 across the board. We no longer supporting SHA-1 signatures for services related to certs trusted by Mozilla except for the "GlobalSign Root CA" CRL and we plan to change that over prior to September. 

 

We use SHA-1 for other purposes such as accepting SHA-1 hashes in CSRs, for the issuerKeyHash and issuerNameHash in OCSP requests, and in computing and validating subjectkeyidentifer and issuerkeyidentifier values.

 

Doug

 

 

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Ben Wilson

Fernandez Ruperez, David Alvaro

unread,
Feb 8, 2022, 7:45:01 AM2/8/22
to Ben Wilson, dev-secur...@mozilla.org

Hi,

Izenpe doesn’t perform any SHA-1 signatures. As other mentioned, we also accept SHA-1 for CSRs and OCSP/TSA requests, but that’s all. The proposed change wouldn’t have any impact on us.

Regards,

Message has been deleted

Fotis Loukos

unread,
Feb 8, 2022, 12:25:19 PM2/8/22
to dev-secur...@mozilla.org, bwi...@mozilla.com
Hello all,

Google Trust Services does not sign SHA-1 hashes over any data. We are fine with any sunset date as it will not affect our practices.

Google Trust Services

Ben Wilson

unread,
Feb 8, 2022, 3:50:18 PM2/8/22
to 加毛 寿, dev-secur...@mozilla.org
Kamo-san and others,

If SHA1 were prohibited sometime during the first half of 2023, could a technically constrained CA (with an EKU that is not serverAuth or emailProtection) be used after then for NTT DoCoMo?

Thanks,

Ben

On Fri, Feb 4, 2022 at 3:57 AM 加毛 寿 <h-k...@secom.co.jp> wrote:

Michael Guenther

unread,
Feb 9, 2022, 3:51:29 AM2/9/22
to dev-secur...@mozilla.org, bwi...@mozilla.com
SwissSign is currently using SHA1 on our CRLs. We are currently looking into the necessary changes to remove SHA1 signing. If the sunset date is anytime in 2023 we do not see any time issues.

Mike

Adriano Santoni

unread,
Feb 10, 2022, 9:16:26 AM2/10/22
to dev-secur...@mozilla.org

Actalis uses SHA-256 all over the place, therefore sunsetting of SHA-1 is okay with us.

Regards

Adriano

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

Mads Egil Henriksveen

unread,
Feb 11, 2022, 10:18:40 AM2/11/22
to Ben Wilson, dev-secur...@mozilla.org

Hi


Buypass does only use SHA256 when signing certificates, CRLs and OCSP responses and we are supportive of sunsetting SHA-1.

 

Regards

Mads

--

Dustin Hollenback

unread,
Feb 11, 2022, 3:02:22 PM2/11/22
to dev-secur...@mozilla.org, bwi...@mozilla.com
Microsoft is not using SHA-1 for signing of CRLs or end entity certificates. However, we are currently using SHA-1 to sign some OCSP responses and will stop using it by 2022-06-01.

Pekka Lahtiharju

unread,
Feb 16, 2022, 8:25:54 AM2/16/22
to dev-secur...@mozilla.org, Dustin Hollenback, bwi...@mozilla.com
Telia is not anymore using SHA-1 for signing CRL, OCSP or certificates within scope of publicly trusted certificates.

Ben Wilson

unread,
Feb 17, 2022, 1:09:17 PM2/17/22
to dev-secur...@mozilla.org
Everyone,

Here is what I'd like to propose:

Effective July 1, 2022, S/MIME certificates cannot be signed using SHA1 (Apple’s deadline is April 1, 2022).

Effective July 1, 2023, all certificates (including OCSP responders), CRLs (including ARLs), and OCSP responses cannot be signed using SHA1.

Thoughts?

Ben


Ben Wilson

unread,
Feb 17, 2022, 4:17:31 PM2/17/22
to dev-secur...@mozilla.org
Here is proposed language to include at the top of MRSP section 5.3.1:

Effective July 1, 2022, CAs SHALL NOT sign SHA-1 hashes over end-entity certificates with an EKU extension containing the id-kp-emailProtection key purpose.
Effective July 1, 2023, CAs SHALL NOT sign SHA-1 hashes over:
* certificates with an EKU extension containing the id-kp-ocspSigning key purpose;
* intermediate certificates that chain up to roots in Mozilla's program;
* OCSP responses; or
* CRLs.

See https://github.com/BenWilson-Mozilla/pkipolicy/commit/0c215bb32e9ab556808cc4fb704eb633c3cb4581

I'm open to suggestions. For example, should the above language be placed at the bottom of Section 5.1.3 instead?  (I already tried placing the language after every relevant case in section 5.1.3, but that was unnecessarily repetitive.)

Thanks,

Ben

Eddie Ho

unread,
Feb 18, 2022, 5:07:06 PM2/18/22
to dev-secur...@mozilla.org, bwi...@mozilla.com, dev-secur...@mozilla.org, Ryan Sleevi
Hongkong Post CA no longer signs any certificates using the SHA1 algorithm, but still signs SHA1 hashes over ARLs/CRLs for un-expired SHA1 SMIME certificates. Since the root certificate (Root CA 1) will expire on 15 May 2023, we wish that the sunset date be no earlier than that expiry date.

Eddie

Francesc Ferrer

unread,
Mar 11, 2022, 7:56:13 PM3/11/22
to Ben Wilson, dev-secur...@mozilla.org

Hi Ben and dev-security-policy group,

 

Consorci AOC supports banning SHA-1 across the board.

 

We no longer support SHA-1 signatures for services related to CAs trusted by Mozilla, in our situation OCSP and CRL, and we have met the deadline to change in February 2022.

 

We use SHA-1 for other purposes such as accepting SHA-1 hashes in CSRs, for the issuerKeyHash and issuerNameHash in OCSP requests, and in computing and validating subjectkeyidentifer and issuerkeyidentifier values.

 

Thank you,

 

_

 



_
_

Francesc Ferrer i Grevolosa
Àrea de Tecnologia
Consorci Administració Oberta de Catalunya
Tànger, 98 (planta baixa) 08018 Barcelona
tel: 93 272 40 00
www.aoc.cat - @consorciaoc

"Impulsem la transformació digital de les Administracions Catalanes, per promoure Governs Àgils, Lògics i Col·laboratius "

 
Aquest correu electrònic, així com qualsevol fitxer annex, conté informació classificada. Queda prohibida la seva divulgació, còpia o distribució a persones diferents del seu destinatari exclusiu sense autorització prèvia per escrit del Consorci Administració Oberta de Catalunya. Si vostè ha rebut aquest correu electrònic per error, si us plau notifiqui-ho immediatament al remitent reenviant-lo.

--

Reply all
Reply to author
Forward
0 new messages