<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.2.3) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-automation-keyusages-08" number="9809" updates="" obsoletes="" category="std" consensus="true" submissionType="IETF" xml:lang="en" tocDepth="3" tocInclude="true" sortRefs="false" symRefs="true" version="3"><!-- xml2rfc v2v3 conversion 3.28.1 --><front> <title abbrev="EKU forconfig, update,Configuration, Updates, andsafety">X.509Safety">X.509 Certificate Extended Key Usage (EKU) forconfiguration, updatesConfiguration, Updates, andsafety-communication</title>Safety-Critical Communication</title> <seriesInfoname="Internet-Draft" value="draft-ietf-lamps-automation-keyusages-08"/>name="RFC" value="9809"/> <author initials="H." surname="Brockhaus" fullname="Hendrik Brockhaus"> <organization abbrev="Siemens">Siemens</organization> <address> <postal> <street>Werner-von-Siemens-Strasse 1</street> <city>Munich</city> <code>80333</code> <country>Germany</country> </postal> <email>hendrik.brockhaus@siemens.com</email> <uri>https://www.siemens.com</uri> </address> </author> <author initials="D." surname="Goltzsche" fullname="David Goltzsche"> <organization>Siemens Mobility</organization> <address> <postal> <street>Ackerstrasse 22</street> <city>Braunschweig</city> <code>38126</code> <country>Germany</country> </postal> <email>david.goltzsche@siemens.com</email> <uri>https://www.mobility.siemens.com</uri> </address> </author> <dateyear="2025"/> <area>sec</area> <workgroup>LAMPS Working Group</workgroup>year="2025" month="June"/> <area>SEC</area> <workgroup>lamps</workgroup> <keyword>Industrial Automation</keyword> <keyword>ERJU</keyword> <keyword>extended key usage</keyword> <keyword>extension</keyword> <keyword>PKI</keyword> <abstract><?line 179?><t>RFC 5280 defines the Extended Key Usage (EKU) extension and specifies several extended keypurposespurpose identifiers (KeyPurposeIds) for use with that extension in X.509 certificates. This document defines KeyPurposeIds for general-purpose and trust anchor configuration files, for software and firmware update packages, and for safety-critical communication to be included in the EKU extension of X.509 v3 public key certificates.</t> </abstract> </front> <middle><?line 184?><section anchor="Intro"> <name>Introduction</name> <t>Keypurposespurpose identifiers (KeyPurposeIds) added to the certificate'sextended key usageEKU extensionas defined in<xref target="RFC5280"/> are meant to express intent as to the purpose of the named usage, for humans andforcomplying libraries. A full list of KeyPurposeIds is maintained in the IANA registry "SMI Security for PKIX Extended Key Purpose" <xref target="SMI-PKIX-PURPOSE"/>. The use of the anyExtendedKeyUsage KeyPurposeId, as defined in <xref section="4.2.1.12" sectionFormat="of" target="RFC5280"/>, is generally considered a poor practice.</t> <t>This document defines KeyPurposeIds for certificates that are used for the following purposes, among others:</t> <ul spacing="normal"> <li> <t>Validating signatures of general-purpose software configuration files.</t> </li> <li> <t>Validating signatures of trust anchor configuration files.</t> </li> <li> <t>Validating signatures of software and firmware update packages.</t> </li> <li> <t>Authenticating communication endpoints authorized for safety-critical communication.</t> </li> </ul> <t>If the purpose of an issued certificate is notrestricted, i.e.,restricted (i.e., thetype ofoperationsfor which aof the public key contained in the certificate can be used in unintendedways,ways), the risk of cross-application attacks is increased. Failure to ensure adequate segregation of duties means that an application or system that generates the public/private keys and applies for a certificate to the operator Certification Authority (CA) could obtain a certificate that can be misused for tasks that this application or system is not entitled to perform. For example, management of trust anchors is a particularly critical task. A device could potentially accept a trust anchor configuration file signed by a service that uses a certificate with noExtended Key Usage (EKU)EKU or with theKeyPurposeIdKeyPurposeIds id-kp-codeSigning (<xref section="4.2.1.12" sectionFormat="of" target="RFC5280"/>) or id-kp-documentSigning <xref target="RFC9336"/>. A device should only accept trust anchor configuration files if the file is verified with a certificate that has been explicitly issued for this purpose.</t> <t>The KeyPurposeId id-kp-serverAuth (<xref section="4.2.1.12" sectionFormat="of" target="RFC5280"/>) can be used to identify that the certificate is for a TLS WWW server, and the KeyPurposeId id-kp-clientAuth (<xref section="4.2.1.12" sectionFormat="of" target="RFC5280"/>) can be used to identify that the certificate is for a TLS WWW client. However, there are currently no KeyPurposeIds for usage with X.509 certificates for safety-critical communication.</t> <t>This document addresses the above problems by definingkeyPurposeIdsKeyPurposeIds for the EKU extension of X.509 public key certificates. These certificates areeitherused either for signing files (general-purpose configurationandfiles, trust anchor configuration files, and software and firmware update packages) orare usedfor safety-critical communication.</t> <t>Vendor-defined KeyPurposeIds used within a PKI governed by vendors typically do not pose interoperability concerns, as non-critical extensions can be safely ignored if unrecognized. However, using KeyPurposeIds outside of their intended vendor-controlled environment or in ExtendedKeyUsage extensions that have been marked critical can lead to interoperability issues. Therefore, it is advisable not to rely on vendor-defined KeyPurposeIds. Instead, this specification defines standard KeyPurposeIds to ensure interoperability across various vendors and industries.</t> <t>The definitions ofthesesthese KeyPurposeIds are intentionally broad to allow their use in different deployments even though they were initially motivated by industrial automation and railautomation, seeautomation (see <xreftarget="UseCases"/>.target="UseCases"/>). The details for each deploymentneedsneed to be described in the relevant technical standards and certificate policies.</t> </section> <section anchor="conventions"> <name>Conventions and Definitions</name><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> <t>This document uses terms defined in <xref target="RFC5280"/>. X.509 certificate extensions are defined using ASN.1 <xref target="X.680"/>and<xref target="X.690"/>.</t> <t>The term'safety-critical communication'"safety-critical communication" refers to communication that could, under certain conditions, lead to a state in which human life, health, property, or the environment is endangered. For the definition of'safety'"safety", see <xreftarget="NIST_Glossary"/>target="NIST.SP.800-160"/> and <xref target="ISO.IEC.IEEE_12207"/>.</t> </section> <section anchor="EKU"> <name>Extended Key Purpose forconfiguration files, update packagesConfiguration Files, Update Packages, andsafety-communication</name>Safety-Critical Communication</name> <t>This specification defines theKeyPurposeIds id-kp-configSigning, id-kp-trustAnchorConfigSigning, id-kp-updatePackageSigning, and id-kp-safetyCommunication. These KeyPurposeIds are used, respectively, for:following KeyPurposeIds:</t> <ul> <li>id-kp-configSigning: Used for signing general-purpose configurationfiles orfiles.</li> <li>id-kp-trustAnchorConfigSigning: Used for signing trust anchor configurationfiles,files.</li> <li>id-kp-updatePackageSigning: Used for signing software or firmware updatepackages, orpackages.</li> <li>id-kp-safetyCommunication: Used for authenticating communication peers for safety-criticalcommunication. Ascommunication.</li> </ul> <t>As described in <xref section="4.2.1.12" sectionFormat="of" target="RFC5280"/>, "[i]f the [extended key usage] extension is present, then the certificate <bcp14>MUST</bcp14> only be used for one of the purposesindicated"indicated", and "[i]f multiple [key] purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present".</t> <t>None of the KeyPurposeIds specified in this document are intrinsically mutually exclusive. Instead, the acceptable combinations of those KeyPurposeIds with others specified in this document and with other KeyPurposeIds specified elsewhere are left to the technical standards of the respective application and the certificate policy of the respective PKI. For example, a technical standard mayspecify: 'Differentspecify the following: "Different keys and certificates must be used forsafetysafety-critical communication and for trust anchor updates, and a relying party must ignore the KeyPurposeId id-kp-trustAnchorConfigSigning if id-kp-safetyCommunication is one of the specified key purposes in acertificate.' Thecertificate." For example, the certificate policyfor examplemayspecify: 'Thespecify the following: "The id-kp-safetyCommunication KeyPuposeId should not be included in an issued certificate together with the KeyPurposeIdid-kp-trustAnchorConfigSigning.'id-kp-trustAnchorConfigSigning." Technical standards and certificate policies of different applications may specify other rules. Further considerations on prohibiting combinations of KeyPurposeIds is described in <xref target="security"/>.</t> <t>Systems or applications that verify the signature of a general-purpose configuration file or trust anchor configuration file, the signature of a software or firmware update package, or the authentication of a communication peer for safety-critical communication <bcp14>SHOULD</bcp14> require that corresponding KeyPurposeIds be specified by the EKU extension. If the certificate requester knows the certificate users are mandated to use these KeyPurposeIds, it <bcp14>MUST</bcp14> enforce their inclusion. Additionally, such a certificate requester <bcp14>MUST</bcp14> ensure that the KeyUsage extension be set to digitalSignature for signature verification, to keyEncipherment for public key encryption, and keyAgreement for key agreement.</t> </section> <section anchor="include-EKU"> <name>Including the Extended Key Purpose in Certificates</name> <t><xref target="RFC5280"/> specifies the EKU X.509 certificate extension for use onend entityend-entity certificates. The extension indicates one or more purposes for which the certified public key is valid. The EKU extension can be used in conjunction with the Key Usage (KU) extension, which indicates the set of basic cryptographic operations for which the certified key may be used. The EKU extension syntax is repeated here for convenience:</t><artwork><![CDATA[<sourcecode type="asn.1"><![CDATA[ ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId KeyPurposeId ::= OBJECT IDENTIFIER]]></artwork>]]></sourcecode> <t>As described in <xref target="RFC5280"/>, the EKU extension may, at the option of the certificate issuer, be either critical or non-critical. The inclusion of KeyPurposeIds id-kp-configSigning, id-kp-trustAnchorConfigSigning, id-kp-updatePackageSigning, and id-kp-safetyCommunication in a certificate indicates that the public key encoded in the certificate has been certified for the following usages:</t> <ul spacing="normal"> <li> <t>id-kp-configSigning</t></li> </ul> <ul empty="true"> <li><t>A public key contained in a certificate containing the KeyPurposeId id-kp-configSigning may be used for verifying signatures of general-purpose configuration files of various formats (e.g., XML, YAML, or JSON). Configuration files are used to configure hardware or software.</t> </li></ul> <ul spacing="normal"><li> <t>id-kp-trustAnchorConfigSigning</t></li> </ul> <ul empty="true"> <li><t>A public key contained in a certificate containing the KeyPurposeId id-kp-trustAnchorConfigSigning may be used for verifying signatures of trust anchor configuration files of various formats (e.g., XML, YAML, or JSON). Trust anchor configuration files are used to add or remove trust anchors to the trust store of a device.</t> </li></ul> <ul spacing="normal"><li> <t>id-kp-updatePackageSigning</t></li> </ul> <ul empty="true"> <li><t>A public key contained in a certificate containing the KeyPurposeId id-kp-updatePackageSigning may be used for verifying signatures of software or firmware update packages. Update packages are used to install software (including bootloader, firmware, safety-related applications, and others) on systems.</t> </li></ul> <ul spacing="normal"><li> <t>id-kp-safetyCommunication</t></li> </ul> <ul empty="true"> <li><t>A public key contained in a certificate containing the KeyPurposeId id-kp-safetyCommunication may be used to authenticate a communication peer for safety-critical communication based on TLS or other protocols.</t> </li> </ul><artwork><![CDATA[<sourcecode type="asn.1"><![CDATA[ id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } id-kp-configSigning OBJECT IDENTIFIER ::= { id-kp 41 } id-kp-trustAnchorConfigSigning OBJECT IDENTIFIER ::= { id-kp 42 } id-kp-updatePackageSigning OBJECT IDENTIFIER ::= { id-kp 43 } id-kp-safetyCommunication OBJECT IDENTIFIER ::= { id-kp 44 }]]></artwork>]]></sourcecode> </section> <section anchor="ca-implication"> <name>Implications for a Certification Authority</name> <t>The procedures and practices employed by a certification authority must ensure that the correct values for the EKU extensionas well asand the KU extension are inserted in each certificate that is issued. The inclusion of the id-kp-configSigning, id-kp-trustAnchorConfigSigning, id-kp-updatePackageSigning, and id-kp-safetyCommunication KeyPurposeIds does not preclude the inclusion of other KeyPurposeIds.</t> </section> <section anchor="security"> <name>Security Considerations</name> <t>TheSecurity Considerationssecurity considerations of <xref target="RFC5280"/> are applicable to this document. Theseextended key usageEKU key purposes do not introduce new security risks but instead reduce existing security risks by providing the means to identify if a certificate is generated to verify the signature of a general-purpose or trust anchor configuration file, the signature of a software or firmware update package, or the authentication of a communication peer for safety-critical communication.</t> <t>To reduce the risk of specific cross-protocol attacks, the relying party may additionally prohibit use of specific combinations of KeyPurposeIds. The procedure for allowing or disallowing combinations of KeyPurposeIds using excluded KeyPurposeId and permitted KeyPurposeId, as carried out by a relying party, is defined in <xref section="4" sectionFormat="of" target="RFC9336"/>. The technical standards and certificate policies of the application should explicitly enumerate requirements for excluded or permitted KeyPurposeIds or their combinations. It is out of scope of this document to enumerate those, but an example of excluded KeyPurposeIds can be the presence of the anyExtendedKeyUsage KeyPurposeId. Examples of allowed KeyPurposeIds combinations can be the presence of id-kp-safetyCommunication together with id-kp-clientAuth or id-kp-serverAuth.</t> </section> <section anchor="privacy"> <name>Privacy Considerations</name> <t>In someprotocols, e.g.,protocols (e.g., TLS 1.2 <xreftarget="RFC5246">TLS 1.2</xref>,target="RFC5246"></xref>), certificates are exchanged in the clear. In otherprotocols, e.g.,protocols (e.g., TLS 1.3 <xreftarget="RFC8446">TLS 1.3</xref>, thetarget="RFC8446"></xref>), certificates are encrypted. The inclusion of the EKU extension can help an observer determine the purpose of the certificate. In addition, if the certificate is issued by a public certification authority, the inclusion of an EKU extension can help an attacker to monitor the Certificate Transparency logs <xref target="RFC9162"/> to identify the purpose of thecertificatecertificate, which may reveal private information of the certificate subject.</t> </section> <section anchor="iana"> <name>IANA Considerations</name> <t>IANAis requested to registerhas registered the following ASN.1 <xref target="X.680"/> module OID in the "SMI Security for PKIX Module Identifier" registry <xref target="SMI-PKIX-MOD"/>. This OID is defined in <xref target="asn1"/>.</t> <table> <thead> <tr> <th align="left">Decimal</th> <th align="left">Description</th> <thalign="left">References</th>align="left">Reference</th> </tr> </thead> <tbody> <tr> <tdalign="left">TBD1</td>align="left">117</td> <td align="left">id-mod-config-update-sc-eku</td> <tdalign="left">This-RFC</td>align="left">RFC 9809</td> </tr> </tbody> </table> <t>IANAishas alsorequested to registerregistered the following OIDs in the "SMI Security for PKIX Extended Key Purpose" registry <xref target="SMI-PKIX-PURPOSE"/>. These OIDs are defined in <xref target="include-EKU"/>.</t> <table> <thead> <tr> <th align="left">Decimal</th> <th align="left">Description</th> <thalign="left">References</th>align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">41</td> <td align="left">id-kp-configSigning</td> <tdalign="left">This-RFC</td>align="left">RFC 9809</td> </tr> <tr> <td align="left">42</td> <td align="left">id-kp-trustAnchorConfigSigning</td> <tdalign="left">This-RFC</td>align="left">RFC 9809</td> </tr> <tr> <td align="left">43</td> <td align="left">id-kp-updatePackageSigning</td> <tdalign="left">This-RFC</td>align="left">RFC 9809</td> </tr> <tr> <td align="left">44</td> <td align="left">id-kp-safetyCommunication</td> <tdalign="left">This-RFC</td>align="left">RFC 9809</td> </tr> </tbody> </table> </section><section anchor="acknow"> <name>Acknowledgments</name> <t>We would like to thank the authors of <xref target="RFC9336"/> and <xref target="RFC9509"/> for their excellent template.</t> <t>We also thank all reviewers of this document for their valuable feedback.</t> </section></middle> <back> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC5280"> <front> <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title> <author fullname="D. Cooper" initials="D." surname="Cooper"/> <author fullname="S. Santesson" initials="S." surname="Santesson"/> <author fullname="S. Farrell" initials="S." surname="Farrell"/> <author fullname="S. Boeyen" initials="S." surname="Boeyen"/> <author fullname="R. Housley" initials="R." surname="Housley"/> <author fullname="W. Polk" initials="W." surname="Polk"/> <date month="May" year="2008"/> <abstract> <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5280"/> <seriesInfo name="DOI" value="10.17487/RFC5280"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <reference anchor="X.680"target="https://www.itu.int/rec/T-REC.X.680">target="https://www.itu.int/rec/T-REC-X.680-202102-I/en"> <front> <title>Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation</title> <author> <organization>ITU-T</organization> </author> <date year="2021" month="February"/> </front> <seriesInfo name="ITU-TRecommendation X.680" value=""/>Recommendation" value="X.680"/> </reference> <reference anchor="X.690"target="https://www.itu.int/rec/T-REC.X.690">target="https://www.itu.int/rec/T-REC-X.690-202102-I/en"> <front> <title>Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <author> <organization>ITU-T</organization> </author> <date year="2021" month="February"/> </front> <seriesInfo name="ITU-TRecommendation X.690" value=""/>Recommendation" value="X.690"/> </reference> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9162.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9336.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9509.xml"/> <referenceanchor="RFC5246"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.2</title> <author fullname="T. Dierks" initials="T." surname="Dierks"/> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <date month="August" year="2008"/> <abstract> <t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5246"/> <seriesInfo name="DOI" value="10.17487/RFC5246"/> </reference> <reference anchor="RFC8446"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <date month="August" year="2018"/> <abstract> <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t> </abstract> </front> <seriesInfo name="RFC" value="8446"/> <seriesInfo name="DOI" value="10.17487/RFC8446"/> </reference> <reference anchor="RFC9162">anchor="Directive-2016_797" target="https://eur-lex.europa.eu/eli/dir/2016/797/2020-05-28"> <front><title>Certificate Transparency Version 2.0</title> <author fullname="B. Laurie" initials="B." surname="Laurie"/> <author fullname="E. Messeri" initials="E." surname="Messeri"/> <author fullname="R. Stradling" initials="R." surname="Stradling"/> <date month="December" year="2021"/> <abstract> <t>This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance<title>Directive (EU) 2016/797 ofsuspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates tothelogs.</t> <t>This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts.</t> <t>Logs are network services that implement the protocol operations for submissionsEuropean Parliament andqueries that are defined in this document.</t> </abstract> </front> <seriesInfo name="RFC" value="9162"/> <seriesInfo name="DOI" value="10.17487/RFC9162"/> </reference> <reference anchor="RFC9336"> <front> <title>X.509 Certificate General-Purpose Extended Key Usage (EKU) for Document Signing</title> <author fullname="T. Ito" initials="T." surname="Ito"/> <author fullname="T. Okubo" initials="T." surname="Okubo"/> <author fullname="S. Turner" initials="S." surname="Turner"/> <date month="December" year="2022"/> <abstract> <t>RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines a general-purpose Document-Signing KeyPurposeId for inclusion in the Extended Key Usage (EKU) extensionofX.509 public key certificates. Document-Signing applications may require that the EKU extension be present and that a Document-Signing KeyPurposeId be indicated in order forthecertificate to be acceptable to that Document-Signing application.</t> </abstract> </front> <seriesInfo name="RFC" value="9336"/> <seriesInfo name="DOI" value="10.17487/RFC9336"/> </reference> <reference anchor="RFC9509"> <front> <title>X.509 Certificate Extended Key Usage (EKU) for 5G Network Functions</title> <author fullname="T. Reddy.K" initials="T." surname="Reddy.K"/> <author fullname="J. Ekman" initials="J." surname="Ekman"/> <author fullname="D. Migault" initials="D." surname="Migault"/> <date month="March" year="2024"/> <abstract> <t>RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines encrypting JSON objects in HTTP messages, using JSON Web Tokens (JWTs), and signing the OAuth 2.0 access tokens KeyPurposeIds for inclusion in the Extended Key Usage (EKU) extensionCouncil ofX.509 v3 public key certificates used by Network Functions (NFs) for11 May 2016 on the5G System.</t> </abstract> </front> <seriesInfo name="RFC" value="9509"/> <seriesInfo name="DOI" value="10.17487/RFC9509"/> </reference> <reference anchor="Directive-2016_797" target="https://eur-lex.europa.eu/eli/dir/2016/797/2020-05-28"> <front> <title>Directive 2016/797 - Interoperabilityinteroperability of the rail system within theEU</title>European Union</title> <author> <organization>European Parliament, Council of the European Union</organization> </author> <date year="2020" month="May"/> </front> </reference> <reference anchor="ERJU" target="https://rail-research.europa.eu/wp-content/uploads/2025/03/ERJU-SP-Cybersecurity-Specifications-V1.0.zip"> <front> <title>Shared Cybersecurity Services Specification - SP-SEC-ServSpec - V1.0</title> <author> <organization>Europe's Rail Joint Undertaking</organization> </author> <date year="2025" month="February"/> </front> </reference> <reference anchor="ERJU-web" target="https://rail-research.europa.eu/system_pillar/"> <front><title>Europe’s<title>Europe's Rail Joint Undertaking - System Pillar</title> <author> <organization>Europe's Rail Joint Undertaking</organization> </author> <date/> </front> </reference> <reference anchor="EU-CRA"target="https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act">target="https://eur-lex.europa.eu/eli/reg/2024/2847/oj"> <front><title>Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUCIL<title>Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amendingRegulationRegulations (EU) No 168/2013 and (EU)2019/1020</title>2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act)</title> <author> <organization>European Commission</organization> </author> <dateyear="2022" month="September"/>year="2024" month="November"/> </front> </reference> <reference anchor="EU-STRATEGY" target="https://digital-strategy.ec.europa.eu/en/library/eus-cybersecurity-strategy-digital-decade-0"> <front> <title>The EU's Cybersecurity Strategy for the Digital Decade</title> <author> <organization>European Commission</organization> </author> <date year="2020" month="December"/> </front> </reference> <referenceanchor="NIST_Glossary" target="https://csrc.nist.gov/glossary/term/safety">anchor="NIST.SP.800-160" target=""> <front><title>Directive (EU) 2022/2555 of the European Parliament and of the Council</title> <author> <organization>NIST CSRC</organization> </author> <date>n.d.</date><title>Engineering Trustworthy Secure Systems</title> <author initials="R" surname="Ross" fullname="Ron Ross" /> <author initials="M" surname="Winstead" fullname="Mark Winstead" /> <author initials="M" surname="McEvilley" fullname="Michael McEvilley" /> <date year="2022" month="November"/> </front> <seriesInfo name="NIST SP" value="800-160v1r1"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-160v1r1"/> </reference> <reference anchor="ISO.IEC.IEEE_12207" target="https://www.iso.org/standard/63712.html"> <front> <title>Systems and software engineering–- Software life cycle processes</title> <author> <organization>ISO/IEC/IEEE</organization> </author> <dateyear="2024" month="December"/>year="2017" month="November"/> </front> <seriesInfo name="ISO/IEC/IEEE" value="12207:2017"/> </reference> <reference anchor="NIS2" target="https://digital-strategy.ec.europa.eu/en/policies/nis2-directive"> <front> <title>Directive (EU) 2022/2555 of the European Parliament and of the Council</title> <author> <organization>European Commission</organization> </author> <date year="2024" month="December"/> </front> </reference> <reference anchor="IEC.62443-4-2" target="https://webstore.iec.ch/publication/34421"> <front> <title>Security for industrial automation and control systems - Part 4-2: Technical security requirements for IACS components</title> <author> <organization>IEC</organization> </author> <date year="2019" month="February"/> </front> <seriesInfoname="IEC 62443-4-2:2019" value=""/>name="IEC" value="62443-4-2:2019"/> </reference> <reference anchor="IEC.62443-3-3" target="https://webstore.iec.ch/publication/7033"> <front> <title>Industrial communication networks - Network and system security - Part 3-3: System security requirements and security levels</title> <author> <organization>IEC</organization> </author> <date year="2013" month="August"/> </front> <seriesInfoname="IEC 62443-3-3:2013" value=""/>name="IEC" value="62443-3-3:2013"/> </reference> <reference anchor="CE-marking" target="https://single-market-economy.ec.europa.eu/single-market/ce-marking_en"> <front> <title>CE marking</title> <author> <organization>European Commission</organization> </author><date>n.d.</date></front> </reference> <reference anchor="SMI-PKIX-PURPOSE"target="https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.3">target="https://www.iana.org/assignments/smi-numbers"> <front> <title>SMI Security for PKIX Extended Key Purpose</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> <reference anchor="SMI-PKIX-MOD"target="https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0">target="https://www.iana.org/assignments/smi-numbers"> <front> <title>SMI Security for PKIX Module Identifier</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> </references> </references><?line 331?><section anchor="asn1"> <name>ASN.1 Module</name> <t>The following module adheres to ASN.1 specifications <xref target="X.680"/> and <xref target="X.690"/>.</t> <sourcecodetype="asn1"><![CDATA[type="asn.1"><![CDATA[ <CODE BEGINS> Automation-EKU { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-config-update-sc-eku(TBD1)(117) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- OID Arc id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) } -- Extended Key Usage Values id-kp-configSigning OBJECT IDENTIFIER ::= { id-kp 41 } id-kp-trustAnchorConfigSigning OBJECT IDENTIFIER ::= { id-kp 42 } id-kp-updatePackageSigning OBJECT IDENTIFIER ::= { id-kp 43 } id-kp-safetyCommunication OBJECT IDENTIFIER ::= { id-kp 44 } END <CODE ENDS> ]]></sourcecode> </section> <section anchor="UseCases"> <name>Use Cases</name> <t>These use cases are only for informational purposes.</t> <t>Automation hardware and software products strive to become more safe and secure by fulfilling mandatory, generic system requirements related tocyber security,cybersecurity, e.g., driven by federal offices like the<xref target="EU-CRA">EuropeanEuropean Union Cyber ResilienceAct</xref>Act <xref target="EU-CRA"></xref> governed by the European Commission and the High Representative of the Union for Foreign Affairs and Security Policy. Automation products connected to the Internetwouldand sold in the EU after 2027 must bear the so-called "CE marking" <xreftarget="CE-marking">CE marking</xref>target="CE-marking"></xref> to indicate that theycomply.comply with the EU-CRA. Such regulation was announced in the<xref target="EU-STRATEGY">20202020 EU CybersecurityStrategy</xref>,Strategy <xref target="EU-STRATEGY"></xref> and complements other legislation in this area, like theNIS2 Framework, <xref target="NIS2">Directivedirective on measures for a high common level of cybersecurity for network and information systems (NIS) across theUnion</xref>.</t> <t><xref target="EU-STRATEGY">2020European Union <xref target="NIS2"></xref>.</t> <t>The 2020 EU CybersecurityStrategy</xref>Strategy <xref target="EU-STRATEGY"></xref> suggeststo implementimplementing andextendextending international standards such asthe<xreftarget="IEC.62443-4-2">Security for industrial automation and control systems - Part 4-2: Technical security requirements for IACS components</xref> (IACS refers to industrial automationtarget="IEC.62443-4-2"></xref> andcontrol system) and the<xreftarget="IEC.62443-3-3">Industrial communication networks - Network and system security - Part 3-3: System security requirements and security levels</xref>.target="IEC.62443-3-3"></xref>. Automation hardware and software products of diverse vendors that are connected on automation networks and the Internet can be used to build common automation solutions. Standardized attributes would allow transparency of security properties and interoperability for vendors in the context of software and firmware updates, general-purpose configuration, trust anchor configuration, andsafetysafety-critical communication.</t> <t>A concrete example for automation is aRail Automationrail automation system. The<xref target="ERJU-web">Europe'sEurope's Rail webpage</xref> states: "Thepage <xreftarget="ERJU">System Pillar</xref>target="ERJU-web"></xref> states: </t> <blockquote>The System Pillar brings rail sector representatives under a single coordination body. To achieve this, the System Pillar will deliver a unified operational concept and a functional, safe and secure system architecture, with due consideration of cyber-security aspects, focused on the European railway network to which<xref target="Directive-2016_797">Directive 2016/797</xref>Directive 2016/797 applies (i.e. the heavy rail network) as well as associated specifications and/orstandards."</t>standards.</blockquote> <t>See <xref target="Directive-2016_797"/>. For details about the System Pillar, see <xref target="ERJU"/>.</t> </section> <sectionanchor="history"> <name>History of Changes</name> <t>[RFC Editor: Please remove this appendix in the release version of the document.]</t> <t>Changes from 07 -> 08:</t> <ul spacing="normal"> <li> <t>Updated Appendix B</t> </li> </ul> <t>Changes from 06 -> 07:</t> <ul spacing="normal"> <li> <t>Moved Section 1.1anchor="acknow" numbered="false"> <name>Acknowledgments</name> <t>We would like to thank theAppendix</t> </li> <li> <t>Addressed DISCUSS items from Mohamed Boucadair and Paul Wouters</t> </li> <li> <t>Addressed AD review comments from Paul Wouters and Orie Steele</t> </li> <li> <t>Fixed some minor issues</t> </li> <li> <t>Updated referenceauthors ofEU Rail specification to V1.0</t> </li> </ul> <t>Changes from 05 -> 06:</t> <ul spacing="normal"> <li> <t>Addressed AD review comments from Mike Bishop, Gorry Fairhurst, Andy Newton, Mohamed Boucadair, Erik Kline, and Eric Vyncke</t> </li> </ul> <t>Changes from 04 -> 05:</t> <ul spacing="normal"> <li> <t>Addressed SECDIR review comments from Carl Wallace</t> </li> </ul> <t>Changes from 03 -> 04:</t> <ul spacing="normal"> <li> <t>Addressed Deb's AD review comments (see "AD Comments on draft-ietf-lamps-automation-keyusages")</t> </li> <li> <t>Added early allocated OIDs</t> </li> </ul> <t>Changes from 02 -> 03:</t> <ul spacing="normal"> <li> <t>Rename id-kp-trustanchorSigning to id-kp-trustAnchorConfigSigning</t> </li> <li> <t>Rename id-kp-updateSigning to id-kp-updatePackageSigning</t> </li> <li> <t>Fixed some nits</t> </li> </ul> <t>Changes from 01 -> 02:</t> <ul spacing="normal"> <li> <t>Updates Sections 3<xref target="RFC9336"/> and6 addressing last call comments (see "WG Last Call<xref target="RFC9509"/> fordraft-ietf-lamps-automation-keyusages-01")</t> </li> </ul> <t>Changes from 01 -> 02:</t> <ul spacing="normal"> <li> <t>Implemented the changes requested during WGLC</t> </li> </ul> <t>Changes from 00 -> 01:</t> <ul spacing="normal"> <li> <t>Fixed some minor nids and wording issues</t> </li> </ul> <t>draft-ietf-lamps-automation-keyusages version 00:</t> <ul spacing="normal"> <li> <t>Updated document and filename after WG adoption</t> </li> </ul> <t>Changes from 00 -> 01:</t> <ul spacing="normal"> <li> <t>Updated last paragraph of Section 1 addressing WG adoption comments by Rich and Russ</t> </li> <li> <t>Updated name and OID of ASN.1 module</t> </li> </ul> <t>draft-brockhaus-lamps-automation-keyusages version 00:</t> <ul spacing="normal"> <li> <t>Broadened the scope to general automation use case and use ERJU as an example.</t> </li> <li> <t>Fixed some nits reported.</t> </li> </ul> <t>draft-brockhaus-lamps-eu-rail-keyusages version 00:</t> <ul spacing="normal"> <li> <t>Initial versiontheir excellent template.</t> <t>We also thank all reviewers ofthethis documentfollowing best practices from RFC 9336 and RFC 9509</t> </li> </ul>for their valuable feedback.</t> </section> <section anchor="contributors"numbered="false" toc="include" removeInRFC="false">numbered="false"> <name>Contributors</name> <contact initials="S." surname="Fazekas-Zisch" fullname="Szofia Fazekas-Zisch"> <organization abbrev="Siemens">Siemens AG</organization> <address> <postal> <street>Breslauer Str. 5</street> <city>Fuerth</city> <code>90766</code> <country>Germany</country> </postal> <email>szofia.fazekas-zisch@siemens.com</email> <uri>https://www.siemens.com</uri> </address> </contact> <contact initials="B." surname="Fouques" fullname="Baptiste Fouques"> <organization>Alstom</organization> <address> <email>baptiste.fouques@alstomgroup.com</email> </address> </contact> <contact initials="D. G." surname="Orta" fullname="Daniel Gutierrez Orta"> <organization>CAF Signalling</organization> <address> <email>daniel.gutierrez@cafsignalling.com</email> </address> </contact> <contact initials="M." surname="Weller" fullname="Martin Weller"> <organization>Hitachi Rail</organization> <address> <email>martin.weller@urbanandmainlines.com</email> </address> </contact> <contact initials="N." surname="Poyet" fullname="Nicolas Poyet"> <organization>SNCF</organization> <address> <email>nicolas.poyet@sncf.fr</email> </address> </contact> </section> </back><!-- ##markdown-source: H4sIAAAAAAAAA9U823LbRpbvqtI/9MgPlqYIUKQutlWzmVAUZTOxLitKcTKK K9UEmmSPQICDBkTTjqfmH/Zp3/Zb9lPmS/ac0924ERTpJJOpdaoiEOjLOafP vU+34zjbW48n7GB7y4+8kE/FCfNjPkocKZKRE/DpTDk8TaIpT2QUOg9ikSo+ FsrZf7m95fHkhKnEh6coVCJUqTphz5M4Fc+3t1Q6nEqloFeymMGw/d7t+fZW wMPxCRPh9tZMnmxvMZZEXt6Hfvpilkzg3QG9UItpLEaq2EZFcWLejXig8GUi kwDm+N492n/Feh8SEfrCZ9+KBbtDcNlu79u7PTaKYgaQjuQ4jQmfBktnPk+E Yjz0meIjkSwcL5pO01B61GJ7iw+HsQASwQiFAWzPRqEntI0FB4oIb3trDmi+ 7VxcD9i7KH6Q4Zi9jqN0tr0FJJxHsQ/IO6wf+qlKYskD1smIjB96N9/c4V9h UYFejCifvVWm6fW3fVg8AOWEtffbRwBEmkyimMbXC/oGhojlAzuNI+9hwlOF RIxiAHAgxRRGwt8WzcIrgEwIWOF3Ig5F7DzC+puvziCJuVKCtbCdF/kwy/OX +wcHes08mSxO2AUScaIbpGESw6vXIp7ycIHvxJTL4IRNNGzu0ML2tdJTuLAM 2C6NJbRKkpk6aTbn87lb+m5RPOOP0mevoyD5qLyJqCLILqKhDGSyKKLV8R5E rAwi7XYBk4OXrfZxAZPTmKchjDsXcrwGHx8BcccWkLXYTA1gZbSAx4ArhsAS xXUcfIxGkrNz/lE8cOX8RSpN3hKmnddrVvM0FirgqYgZLKLLjgp4v9p/cVzE +xxaJetWUBFU7shA9RGh+mWLeMpniVSJYOdR+rdU5GzaCVSiBzJzDk1Ld6Rb fs2pxRglrMoYoRQBe50mUsSx+Miu4oRnA3c750CicciDACS0tIzYzR3bbl97 fKSyhuUpLnicyBCkJAhEnA39Ribcm0h2A+MVBp5SY3dOjb9O4yEPQYHAtxAG FhWCXEovCrhi19FCJPlKX3bPCyOGupE7w0Zfq9AbuSMAY3srjGJUKI+C9OzN ebfdar2yz0ftl/v2+WXrxSE9f+8em7egiHk8RnYprppMUleGSTMWXvPWuel1 XephOmgV/JX+xUC3jTQAUchuhTcJoyAaL5jDOkMUOi9hg0WY8A/sMkp0q6sQ FHVncOm29k7sKIOZ8OTIKGMWjWDplfRYaProZpnG032ISv3bO+dWv9HK8Tlo x5az336uXyoRS6EkAJn1oy7sRqABALWkp8wwhIdXX0ycV19MHEQf7CNIJNqM OA2EWk2MUyJGz7a+wdZs97R3s9ewfbo8jNCYBUvNutDMtkIjdgYSBZ9TqSZg cKqtz7LW/2JqI8m2t6QlUM6+R+3D44xlD/PnV63jdvZ8cJC/B1+Ans8krAmO 5LT3W8fNF69erFhGkcZOID648DeacfjTFIFs+jJu2o7w0N539o+c9svSwj7P 5mC2KUPznggYScRcK3lcsmQiWAyCC44NKLApm8tkAtoDX/funq+mcA9hEjxk 1zwOJKiHMGmwLqhlD8Yy42Zt7sJMNvLlMHDTHOhfrCACAueAjRA89iYFUsxn DpolmLeZzoKI+wqJcdTcP2jiaM7g2ukuhmBRhQfqHvyoErcq57uWu+9+lLMy 3QYT8Jl8VurJBiJ+lB5wXZnhHQZzDHpdB7/jJ3iDo66l2nNFaph9E4GAAnF8 MGv8wWj8IomOLMcSRnMx/EIa6TX9aSaDgMfNMqYalH/+479XAYP4aZ64pv6/ DVrkIRNKd073psNWYOTLMRiswEHVnIjxwhVeUQzCZiCHMY8XTQ9XCnEHjgY1 JRzQ5GVEr6FXpEDhoLfM2U3v9d3bzm3/6pJdnbPbNz2A5Obqute5ZNedm7f9 zkXv8pZ1Ls/s5+7VXbf/lsGCA97yI/AcjOWVGCQWf0tB4FAIFE0ziyM/9eAH ihMzyDARmCao3lBktEIT4zTQHLXbg6gABPZVswXysYn0dUFb6aimyjttZ/+V 0zp6bmg9uL3p3PZe//Br6S1S5ZSQz7o4dgxfeNwXTtnU7NxqjaKqsmV6E9lQ aZwZYp3RKDu/igb7TqvttLQLedkf3P70OoiUAjRWUMFTseeGYHfAY35sjk3j JmjNadPGVPVa1qxcu91sHx0dLSnAXEnS2pvPRl0+sc4INOsObrr4tj+4cvtg x/u9Xu+nVru9v8pukPlXkQtDNFUCE/LYbx4fvGi13UkyDSoaj2TcRJzRKJmD AgSDPwb3D4wk8Oc///FfbGA/BHIkgPm9QCCPg05UQj0BP4DcBJCbCHJ1cQ5p cQ7t4rR/KWfOokB6YM2bsHBtYEKzJL/zSm3AjUWEcR2P24eHB86hswpz0PcQ RcTClYCyN2nO0mFgbE/z4PCw3aospBUplCSZR/J5uoQwolgusvZegZYHlBOG YGjXj5yz1aqt3+kOYJDpLArx3VOL3+tWSNB6BQbNab94wgvrdVlOF+xRphb8 9wuo9WL/4KBMrEKmo5RfYaFI5lH8gHS51I9aMrQlzMhiqIbgWCtZTzLqbL8E 4lEEX0iyA2f/pbO/EckQGuyBX7o9B2I7tL4r6AWDjANBjUTigNsbRtOKcJWa ND1hR/xJhGVqdnvMfPpyCRlc9J3rb/vfO9d3N9dXg95TOg2CU1JqXGHwSwRu qql0wnSKNqX47H5AVfes8MZpuQfusdtyj+C/F26FIQAMVpIghKmcurtOY3Ak xFPL17ns1Do7GZIXV2e/F4L7myB4AX4K6PK+D1OBZyue8vJWYLe95TgO4yaK xt/bWxDuMAzpmS9GmEfQOnZVHjTLHxppeYQIJSjnGmea9hD4QWezEH1f6Rxq qoR2tJIJTwqjydBkYD3wRLXfLpTL2O1EKuZHXkpq3oJYGpjGHYsQIXHM5ARd EoPegCdvUk3espGEyLRBPTNDil1GMp7SD52iZTPuPWDOWudqqbnJ9MLakPYt q6QkYkMByHhBiuSw0dm3dwVUwU5pVB8PmNZ8RLYS4napptL3A1q4ZxgSalcV B/n0jH5+xk/fPkV07iMgABcCUpgDvLvlDHFxeZWhNmHx6ZNJ/Hz+zJA8U1AO CY4qPszAoVfQJiE7rOxUdiGMVcaslK8n0WSfpFMeqoysaKWCBfow2nuVuPod NkqDAN7AMsI45VUHvsDcV8ItjDgN8j0o9TH0iBdsZ3NNsQMoVtXb588uQ1c4 zdHg4cL2hs5aMIpgNZboNhB6wQ7dNoh7q40jZbRsIBaGdYMF8qiSEIpBX85m EQUnIKcQzxJDbCoLRU7SckYcrYSfee6jKAiiOZLbMg5APo3gdwSfY8wbbW/9 kX3HA4npFXhPKcwkhcVGDKrilglRjZi5a8ZaJ6br+m8kwGaQDuhKVJ+eHqgs vLCsM4yHlVGp8qPYQOZdrUb7oyrbg/kE05nCGIUFwQUPowR4FF0aLxHAMtIV boN643YXdqXED+U+aP75RHoTZImCtogqnF+cw4Oph2bF4TOAGhqOn/OF0lPF Uj3gVF4MkZPDZzPrgTGeJEA0EjBQZLHgMIzLzrkMgOIk86HCJwj5/pbidEqM QeSyzKKPmW9FKsKyHwxamAApqv0w+qp5KTGWR+PYnMXyEccGXE0MjgMIZTID RWyNwtE0g6/d7BtO1tFLCfK/2+3s4W5EAKHCEIlXHQeBMaQDpyeXF64eDCIJ SmA9KmZdkbnAiJPGBYAwEwm0g2biAwcNB8oP1B4wJIlwhfmJ5LDKmOf30gCi G1hny3MIBWpEX2B+y+Axi1DrSlIe3PPEDIZaJ08kPQDgELqgj0rDEXYp2o8y TchUh9FqfwC5U5vzsiJk0nceMO3nC9wlQWHbXaMMaTDdzSo525XMDyZoUSVn NFATvZhhjv06XcKkFlMiBFAb3Bd0pXyNRA0/TECfD4UI0dBh7JrAXEaqtS6F QYzMGx1dSweks4iRFzcgQ1F8gY2kdvgWlgVFVZ9okbh9O2Dv3r1jeirtsKxa Fcy/Jb8LNHoql72J5oLAQvMiyCCBWY7hGxAUGGzZimmHhNZl2TPcUC2XLSa4 QjFlQbQpH0aPlBkZBhhbgziQRUV2e1gC5gkvbpULh66DEmWoKV8jkQS5OVaG xzV/7lYta5mJN3NrN7KIJG4lx2A9Pb8DJRDFjnVwyotG45g9CY6eFhsDhWOj ax6pq0ITh4PDqvsRaUzCUla3OwAvoFyoyKEKozCHKlsCZVkT4UaxHIcRuk4g 4mkYQ5QMdP2IpivjvRSj5ArUUZqgz2UcPBmzzFZqiB2ThEGdLsJHGUeh1t3Y ki05gwXojP4AJiMFQqG5nyt0BD4QXAtVFX1SMZqHYgFrA3ZDJmQe/EepOLAs 0Q66xog6LP3jE0vjQuwARor7Da2wVGlvxDqSNv1YIVBu8Jeg5OQ8sEdw16NU ZUuMXGeTWsbzQrWoxUt7NZraasl95WaaEJsRlwzjSNOIo8dq1igllmG+HI1E rJ3hWRAtdBoH1hpdoigdk1lasLmgUaUxlNMoId+C2HJ18o122vJ3IFVCgCG6 U6ILHpGywYEvwJUItJYQHNy0HBQWCqEJOMR2CpZ+mDtssHDikaKoPJNnVkCT sKhXbeLUOJvPWDcKHzWVdOOzAnE/PfPyr58t+VFBYfWQYjsXd4PbnYb+yy6v 6Pmm9593/ZveGT4P3nTevs0etkyLwZuru7dn+VPes3t1cdG7PNOd4S0rvdra uej8sKMN0s7VNW7ndN7uaDKU1LP2LoeG0SCuxDXiaqtEutPu9f/+T+sQVuIP pi4BQlL9A4sR4MccPHw9G3kG+icywhZ4boKT3AIjgADOMFutVQz4EvOQobS5 W1t/vEfKvD9hfxp6s9bhV+YFIlx6aWlWekk0W36z1FkTseZVzTQZNUvvK5Qu w9v5ofTb0r3w8k9/xroR5rRe/vmrrWVrSd4gbqeUAtp74xm8d5etclH54WLa blrt6vKEeyqKeE/Lc09b9u8zBYGTsedPWqHnIDYg8iRUlcwLee/oEIKex/1M ggy9fBAGX0tGI1O4HGUtISWigytKR9CWSQO4gAfJpIG+ASi7ZNFgxgMo6n8g FZYehGMM17WLn5SUHOo4g8xz0h33pW0tQ4LljaL3mYzX5SmWCxGt0a+Y95Vl iaAewJP5nC14vTGoeo4qc+hxauOXN8xL8kg65JB0675r0K41ZNk3MhPaOyYw uyV3w7hPy+YB3YwGxs8zvUsULCihdJI5Uk97UNrNwtVa70aZATN3ChquThCi N/VUdmEmkG/X+1mso8rGYm0OaefHe/njex3Y/Hi/nNX78X0x0QrxCpYfYA0I QrvkwpOmI805LPiGUZjlwLJUI9hO6uLvaN1uwJimQSIh1AVYAASYPOugrbvp pJ3wQiyN1tLkRozvRmp6eTpS2AEmq7hm1Mxls0ueI7lD0nRZAL/MUYb7rVmu 2iOJxZRAOO2xTtMkpQfxwQtAqz0KlxVdK2HCUPLPYFWHMuQFfyda4meKbnTG 7UlIQr/QdCUGIlBinoVXgRglNjdS52LYgqJMkEqLYaPHJSdkUdMRfH0gRCnL wWvmBBd4YcBd0D6v9d6yJE8pWJqifA6X4pOKWNkEckmcTWm21jGcfGTKdXLQ 5npcHSysCpBXKTSMLVaqLOS6Ap/l61LaFKmmndzn5EbW0HmU07NCOeywGgzC x6BjUiQoVZV9ifrsZBKNBfHYU0mdVdRBVL7Al6VcYcYDBeZTRXQNz1M1IzJZ GtNvmyq38hWitZ7IobSatyR7SzsHFQVrd33BqUd1YessUKUXwSIfg1JGC73E Ng9N6d4NDM8GdqdRN/IGFihzUopGSHshvMYSbbCXZbxRs0VuHawY5T7S5VBl sg6LPD9cLOdMIAwdLSkVHF4AuWP2EEZztfQdpD/WlmOKDJXoLBQGgMmyg0BR MhkwgUWglNjUMT3pa7KuvnYGUY+DiU+9atovB8gMRLFvlu1ajvQJcUG61hTA DLLVswke/UtnGz0TT0J70Ay90JMz4GhS9FSPlueTROjFi5lujVIE7zrjWIis LTbi9k3mN/ZJzHGBlrZyrRcJXN8t6tpPz4xucKxvWNzxs8uqsjV9wvfPtnn1 jorOiNfkxkqbv76Bg/RnDCF6XPAz8i2QAnOQtc8ohalc3B/SI5czdZXdEBC5 v6ahdqiKWs6mtUu73A0zcQ4hSadI8npyWqJoHPMZtKzfuSmDjfCigjMw1YGs dHk7YBULCFmR6cmuG+cfYnsqoKRdur///e+00w/rbHnTVMezk5P/YGwAQWrv sttjg/5femy35boXne/3sGKyKDo4EgxS0va6/9XpN73uLeuf9S5v++f93o2Z cntr2VEtOKXLGVPAGdg4MZs1VjktZ5DBKMUNpI7JlGbqCZAvZgI14TLRrtHz v2vEsmTZS0xj8C4Ld1SoESh2zDYdcqZZ3rjVh+nMRm0NqvjhK9ZZuWlYhtV8 skqjdiun6AgVGJhg01Zx/UZxbTA2ylKIunJfsV3hjt0G+/7ibYP90MH/wxzf DK4u91zWrRkiy2NTXkB/RzrGvjWb1oS6RYKtYoPfmnYr/clNybh2X+vLaIjY 3a4bskhT7vvYOxZT3DQpb1raGINeUl2fdjr0Ll2J3nVi9VvTum6Ojem8Sajv srtqqqVAKYgWEwxbs5F2ZWaOh1GU4PEH1G929Ib1wiBIIUVf9DhNGpMCxD1G hoE80xJRa3TRb03TOnVXJClySO52il/qcQ6x1ADRxN1DTDqQ/gfHPom8KNBY W3NHgNVYJ7JathaOfQJ7Eu229uy2JahSJ4rHPJQfacrdgz0Is/3d4z2ddA5F Aq2z7iyrB9092mNTCG6gp5oq/DV7kB92X+yxA/bZGM86PVn8twwrGthPBpXD Fg6UDbNSZawbpl0aplYaNoHmoDRMHQNsNMwhDmP8BfJNp4V4Sm8Vr6rX+PTM 447M22c7GVTN7pPIonjYGinFxBS3Xmxtg1cal2fjUvxfdespsPES9CJTsWrP F8wynr60aafyN8oWQbCSaBGjvaClcgKsqaGou8Z5SbKo/ndzWcr+kh8JXcQy A1JgMGCSawUYaxJQWdiRFdp1y7H5p2dZeG1XcFVTmKFaaWjUIWbUyNAU8mI2 R1xTx1hKuZiNZmnqJwULxbxQAi6xvGeYJqS6cX8gFtRKfNCnGpeaLpADH2UW YZlKp0JthBxVXUGVlTmRttw8ifD/KGOgN3IiS79ilZndZDDlZlal21qzht0R LabpwL7wQrCeJXhsPWY+5lPZHqohLugMrXSsEw3PvlTZz6fzRnofi3K/fmWL XSsiiOJlklQ+Ubba43GMbnwEbEbKqYRrQ6ek6qpGTarf1j6x2xXZ3KeSbNVE u0kKFiqaRAgCFdvsR+kMSYYupiZqEVSGj2Rcop/L+qTvEGVcLS+amdxoMbVN 1QV2ckqRN0gWeZjlPqFPLc2z+g8KrCjd721cqOtCvEzDE4WIAZaHL3LDirlW 69ZyKnWp8CqrdctLw1ytR6+x9NGrUaMz/YG0aB+WMZqK3DlqMO3u36Pv1HLb 73efmYPPe42aIqQP6MqMC+FnIHiMdSJVp6sy7oEeFw9R7zWqgasZW2etVtq4 5ezMRAQzXPFoqImBRRXIaqGoKyUvJs8RYKskGra4r6J4TZqbxM44xCtcg8ay wQOoVsOrtRfAC1w8jUKZGIVaSK1BmAXGAaQcqLJgQTRWppixddwGC1cuqHsK VZNKQq0Yi0cBwm9LZGXhQoCafiod/hW0SZ4dxBL5Jd7C4yyasfAzJZ50GtTX RUZYUS+qKQi9pf/pE+3pAzZTfULlqn9m2WpFBf7SUZadvGi/UId/cXWmy2wA Hhq0oiW5ClsmZf8zHkKVUyALPmFSalZwUgv/fmY3grYc0GH8GTqeOOZf/lT7 r/QZO7Lb07OWHhIkGXA3fpvxxBzlOeIhxc+IgIPnbBjOWKQyD1S0EakBfbWG qPXHGuroWjjfYFwoGr5Ys0H0LeaEv5DMv4LQdaQ+bNlB1wRZVWL/jAFRqevK wKqm60G568pgqqbrYbnrygCqjjue4QVDYTQPhD/WlvjTM05vSETfgTIgCx7I B+MV8/Ahc+UwJ2Mdae03kHegfx/tY70U8owx2WAJ8EIZqkMDe4hK1cxBvKmH xoQGaB0p5iJWy0Z8lDkAGD6Rrz4Swh8CzEbt4Fkm/GmwI71hlACghmJsQ4Oc 5Y024T6mvsm/1v1KBSuqoH4AS9y3oKoiw68QeTIcfnvrT92rsx477b3uXw6+ oux1fjUZ8DfGur8mWbA+T6B1xO6+6fCUythFzbKn8wpnvfP+ZR+Ltwasf3H9 tt/t37LbzuuBznMQQprCpCI7sUd3oFD0XRub/+sxfZhh/88GqpqjA99RkJ3B uVqaN8mYrJHqTbIla6R7k0zJGinfJEuyvdW7PNPiopkVfiKrmuzJMyAeuBZY ewoyk5WhGrlR+piax22dDVXw6OPlmXvA82oatywCeaq8dLdAdjcGlsg+mvJM D/1O2qFDdPNT0wJdrFEaQEwa6Jwr7tdGMbhVFNSC32XOypSCDJv3xMw9XjeR MZj1PH2cOqTBhU/HTaPRiPI9Wv+B0rgvX1+j760A+2NvGgF9moDjqu8x2SvV pSfFGwXy485ZAcwbOZ7ASKaciG4Vsl6WngtpfA7UAIZhndGIS1MBnRnoayrn cEvkzggLrB8KL8mPaPaNvBkVP8SCVYrvIweLkKDhfX6EG3DKD4/v6fSzb9NN lPTFU5Uw9QD3ueP89pI5RyBDvCohjwHu8RoO1rtbce2HJqC9nGSvYa4owCBK r6SOHAJ0OIJsS0wfmYoFb+TLhVdIsPOYTwUe2ofYIr/yARPLgitK7un04AQX APMMUagP5dOptRKEpg49WxOAFKfYIyb/MqzAXR6PwRnT+RyLG6Gq00xGIVp5 yiNwXUqgobj/91zwALiULqvYY7vUIq+Z3RSUvYz/7/+d1y+UEIL/9ly2uc6i 8qJHXPL88Ik9DJuLnY7/7JAZThb9TBwrx6CGqQx8y5aFAVQUpCb9MTCsQcdI IVSkWxmBrbVgm+MMxegQsyQWf1N7LIU9TlE5eqE3sTRWuqghAf5cdxxWNZ7e kG08kWssXldak/fr0JEdrNnPEjcjXRJrSUOHG+nWqcIaam7RmYL78t1UczFk MzDFKKHmTq09XbatzB1F96VLr0y7PTbEu3CUuSoNVpk2LosKXJkKcc70tRkA egTrFJpdqMhfYGAUMbyFUaDZAx2mcwOlCdkc/kDEFCCXwWBAENqrz2pASGRC fSyTChFHpvCEB40l42nkBq8FkwlAneLeoL6TKhXlerdMAzq5CqRiTLrSwEvN LlrJtCE15nxhORx5WGcU7pfvnwNKLl98t5cdwd3FA8s0+kTwx4UmtBl3r7hJ wpWKPEnWveK0A95NTCdb7enuaBfnjcQNZBKFLiWo0NeZ6Jfk6uD5A9bzMdVy wq4DPJyc7Uqbw7l4V9eH4ikbThogLuagsi2E9zionWoUR1O2/4I5X7H9l6ay Qu/1+qxjBz5d7nFMPV6YHhcADJl/WqoWRCzGtNshzFF0cxrRZ2f9QfduMGCS bAANeRFN6MKE0yj1uA8+BXHKNU8D9i4CLRKr6iCdMxOhMX0rYmJGKvahQa5i CXycCKHvlfgjO5cfcIHIq5Mh2is6fFZGP7axPFIQjClJaPnoAGCJV+otk+eI yHN8sinIF+gnnEo1iWYN9jqKgR/OgQSTNFZJg3VCfwEGZ56gSlqiU4P18L7i b/Foi9ZYPXQ8v1uE3oNYBu2QQDtaAm3Q6571b+rB6/IYKAr6m3s1Ix7QiIdL I56JISi2GpR38WzIDnzo2jd4DGOTi7R39rJJsPqbzoujWdHl9ZjSWQavTeAd GPBuBN7LUUyMaM1vox9KT64rlKkMoy3N0girSj9K/BfKpAbmFsHcLgmksgKm 2AEt87E93kt3iHCFFjsIqmR+95q9xW9d/Ib2acMby1ua1k/B1bfOojna4Jm2 eXbPT+mStnev33Z1mFcebp+Ga52skMpQmm2eOdmqcUFMt7c2QiNTgvv7FeVW OmmAe4q0njAk2DUgGfd1vd56qO2AtADg13Cqi0SdkenD4joVxs5XCoKyG7rv AmC5SVVFEWnIQuJvHFfnhHSuqEiL7FbwLyLIKZ42FaFZQr1nBSxsnKaiN2Oj bYIFf6DvQUYv27lya/kbfZEIqwTcp8AVqUM3hT4Ba1+faF1l2gqZtKHA1cjK JGjh0I5idlCTGX8c7b/a3vo/TBAdX9ZfAAA= --></rfc>