natgillin/translations-raw huggingface dataset:
If it is ensured (guarantee provided by CSP QC and supervised/accredited by SB/AB) that, for a listed service identified by a ‘Sdi’, any QC does contain the QcCompliance statement, and some of these QCs are meant to be supported by SSCDs and some not (e.g. this may be differentiated by different CSP specific Certificate Policy OIDs or through other CSP specific information in the QC, directly or indirectly, machine-processable or not), but it contains NEITHER the QcSSCD statement NOR the ETSI QCP(+) OID, then the use of an appropriate ‘Sdi’ may not be sufficient AND the Sie field must be used to indicate explicit SSCD support information together with a potential information extension to identify the covered set of certificates. 
Dersom det for en listeført tjeneste som er identifisert med en «Sdi», er sikret (garanti fra CSP QC og under kontroll/akkreditert av kontrollorgan/akkrediteringsorgan) at et QC inneholder QcCompliance-erklæringen, og det er meningen at noen av disse QC-ene skal støttes av SSCD og andre ikke (f.eks. kan dette differensieres av forskjellige CSP-spesifikke Certificate Policy-OID-er eller gjennom andre CSP-spesifikke opplysninger i QC, direkte eller indirekte, maskinlesbart eller ikke), men det inneholder VERKEN QcSSCD-erklæringen ELLER ETSI QCP(+) OID, er det ikke sikkert at bruken av en egnet «Sdi» er tilstrekkelig, OG «Sie»-feltet må brukes for å gi uttrykkelige opplysninger om SSCD-støtte sammen med eventuelt utvidede opplysninger for å identifisere det settet med sertifikater som omfattes.
If it is ensured (guarantee provided by CSP QC and supervised/accredited by SB/AB) that for a listed service identified by a ‘Sdi’, any QC does not contain any of the QcCompliance statement, the QCP OID, the QcSSCD statement, or the QCP + OID but it is ensured that some of these end-entity certificates issued under this ‘Sdi’ are meant to be QCs and/or supported by SSCDs and some not (e.g. this may be differentiated by different CSP QC specific Certificate Policy OIDs or through other CSP QC specific information in the QC, directly or indirectly, machine-processable or not), then the use of an appropriate Sdi will not be sufficient AND the Sie field must be used to include explicit SSCD support information. 
Dersom det for en listeført tjeneste som er identifisert med en «Sdi», er sikret (garanti fra CSP QC og under kontroll/akkreditert av kontrollorgan/akkrediteringsorgan) at et QC ikke inneholder noen QcCompliance-erklæring, QCP OID, QcSSCD-erklæringen eller QCP + OID, men det er sikret at noen av disse sluttenhetssertifikatene som er utstedt under denne «Sdi», er ment å være QC-er og/eller støttet av SSCD, og andre ikke (f.eks. kan dette differensieres av forskjellige CSP QC -spesifikke Certificate Policy-OID-er eller gjennom andre CSP QC -spesifikke opplysninger i QC, direkte eller indirekte, maskinlesbart eller ikke), vil ikke bruken av en egnet «Sdi» være tilstrekkelig, OG «Sie»-feltet må brukes for å ta med uttrykkelige opplysninger om SSCD-støtte.
As a general default principle, for a listed CSP in the Trusted List there must be one service entry per single X.509v3 certificate for a CA/QC type certification service, i.e. a Certification Authority (directly) issuing QCs. 
Som et generelt standardprinsipp skal det for en CSP som er oppført på pålitelighetslisten, være én tjenestepost for hvert enkelt X.509v3-sertifikat for en sertifiseringstjeneste av CA/QC-typen, dvs. en sertifiseringsmyndighet (CA) som (direkte) utsteder QC-er.
In some carefully envisaged circumstances and carefully managed conditions, a Member State Supervisory Body/Accreditation Body may decide to use the X.509v3 certificate of a Root or Upper level CA (i.e. a Certification Authority not directly issuing end-entity QCs but certifying a hierarchy of CAs down to CAs issuing QCs to end-entities) as the Sdi of a single entry in the list of services from a listed CSP. 
Under noen nøye forutsatte omstendigheter og nøye styrte forhold kan en medlemsstats kontroll-/akkrediteringsorgan beslutte å bruke X.509v3-sertifikatet for en rot-CA eller overordnet (Upper Level) CA (dvs. en sertifiseringsmyndighet som ikke direkte utsteder sluttenhets-QC-er, men som sertifiserer et hierarki av CA-er ned til CA-er som utsteder QC-er til sluttenheter), som «Sdi» for én enkelt post på listen over tjenester fra en listeført CSP.
The consequences (advantages and disadvantages) of using such X.509v3 Root CA or Upper CA as Sdi values of TL services entries must be carefully considered and endorsed by Member States. 
Konsekvensene (fordeler og ulemper) ved å bruke en slik X.509v3 rot-CA eller overordnet CA som «Sdi» -verdier for pl-tjenesteposter, må vurderes nøye og godkjennes av medlemsstatene.
Moreover, when using this authorized exception to the default principle, Member State must provide the necessary documentation to facilitate certification path building and verification. 
Når dette tillatte unntaket fra standardprinsippet benyttes, skal imidlertid medlemsstaten gi nødvendig dokumentasjon for å forenkle sertifiseringsbanens oppbygging og verifisering.
In order to illustrate the general editing guidelines, the following example can be given: 
De overordnede retningslinjene for redigering kan illustreres med følgende eksempler:
In the context of a CSP QC using one Root CA under which several CAs are issuing QCs and non-QCs, but for which the QCs do contain only the QcCompliance statement and no indication of whether it is supported by an SSCD, listing the Root CA ‘Sdi’ only would mean, under the rules explained above, that any QC issued under this Root CA hierarchy is NOT supported by an SSCD. 
I forbindelse med en CSP QC som bruker en rot-CA, som flere CA-er utsteder QC-er og ikke-QC-er under, men der QC-ene inneholder bare QcCompliance-erklæringen og ingen angivelse av om den støttes av et SSCD, vil i henhold til reglene forklart ovenfor, oppføring av bare rot-CA-ens «Sdi» innebære at alle QC-er utstedt under dette rot-CA-hierarkiet, IKKE støttes av et SSCD.
If those QCs are actually supported by an SSCD, it would be strongly recommended to make use of the QcSSCD statement in the QCs issued in the future. 
Dersom disse QC-ene faktisk støttes av et SSCD, vil det sterkt anbefales å bruke QcSSCD-erklæringen i QC-er som utstedes i framtiden.
In the meantime (until the last QC not containing this information has expired), the TSL should make use of the Sie field and associated Qualifications extension, e.g. filtering certificates through specific CSP QC defined OID(s) potentially used by the CSP QC to distinguish between different types of QCs (some supported by an SSCD and some not) and including explicit ‘SSCD support information’ with regards to those filtered certificates through the use of ‘Qualifiers’. 
I mellomtiden (til det siste QC som ikke inneholder disse opplysningene, utløper), bør TSL-en bruke «Sie» -feltet og tilknyttede «Qualifications» -utvidelser, f.eks. filtrering av sertifikater gjennom spesifikke CSP QC -definerte OID(-er) som kan brukes av CSP QC for å skille mellom forskjellige typer QC-er (noen støttet av et SSCD og andre ikke), og inklusive eksplisitt «SSCD support information» for slike filtrerte sertifikater ved bruk av «Qualifiers».
The general usage guidelines for electronic signature applications, services or products relying on a TSL implementation of a Trusted List according to the present Technical Specifications are as follows: 
De overordnede retningslinjene for bruk for applikasjoner, tjenester eller produkter for elektroniske applikasjoner som er avhengige av en TSL-gjennomføring av en pålitelighetsliste i samsvar med de gjeldende tekniske spesifikasjonene, er som følger:
A ‘CA/QC’‘Sti’ entry (similarly a CA/QC entry further qualified as being a RootCA/QC through the use of ‘Sie’ additionalServiceInformation extension) 
En «CA/QC» «Sti»-post (og tilsvarende en CA/QC-post ytterligere kvalifisert som en «rot-CA/QC» ved bruk av utvidelsen «Sie» «additionalServiceInformation»)
indicates that from the ‘Sdi’ identified CA (similarly within the CA hierarchy starting from the ‘Sdi’ identified RootCA), all issued end-entity certificates are QCs provided that it is claimed as such in the certificate through the use of appropriate QcStatements (i.e. QcC, QcSSCD) and/or ETSI defined QCP(+) OIDs (and this is ensured by Supervisory/Accreditation Body, see above ‘general editing guidelines’) 
angir at fra den «Sdi»-identifiserte CA (og tilsvarende i CA-hierarkiet fra den «Sdi»-identifiserte rot-CA) er alle utstedte sluttenhetssertifikater QC-er, forutsatt at det i sertifikatet hevdes at de er dette ved bruk av egnede Qc-erklæringer (dvs. QcC, QcSSCD) og/eller ETSI-definert QCP(+) OID-er (og dette er sikret av kontroll-/akkrediteringsorgan, se «overordnede retningslinjer for redigering» ovenfor)
if no ‘Sie’‘Qualification information’ is present or if an end-entity certificate that is claimed to be a QC is not ‘further identified’ through a related ‘Sie’ entry, then the ‘machine-processable’ information to be found in the QC is supervised/accredited to be accurate. 
Dersom ingen «Sie» «Qualification»-opplysninger foreligger, eller dersom et sluttenhetssertifikat som hevdes å være et QC, ikke er ytterligere identifisert gjennom en tilhørende «Sie»-post, skal de maskinlesbare opplysningene som skal ligge i QC-et, være under kontroll/akkrediteres for å være korrekte.
That means that the usage (or not) of the appropriate QcStatements (i.e. QcC, QcSSCD) and/or ETSI defined QCP(+) OIDs is ensured to be in accordance with what it is claimed by the CSP QC . 
Det betyr at bruken (eller ikke) av de egnede Qc-erklæringene (dvs. QcC, QcSSCD) og/eller ETSI-definerte QCP(+) OID-ene er sikret å være i samsvar med det som hevdes av CSP QC .
and IF «Sie» «Qualification» information is present, then in addition to the above default usage interpretation rule, those certificates that are identified through the use of this ‘Sie’‘Qualification’ entry, which is constructed on the principle of a sequence of ‘filters’ further identifying a set of certificates and providing some additional information regarding ‘SSCD support’ and/or ‘Legal person as subject’ (e.g. those certificates containing a specific OID in the Certificate Policy extension, and/or having a specific ‘Key usage’ pattern, and/or filtered through the use of a specific value to appear in one specific certificate field or extension, etc.), are to be considered according to the following set of ‘qualifiers’, compensating for the lack of information in the corresponding QC, i.e.: 
og DERSOM «Sie» «Qualification»-opplysninger foreligger, skal i tillegg til den ovennevnte fortolkningsregelen for standard bruk, de sertifikatene som identifiseres ved bruk av denne «Sie» «Qualification»-posten, som bygger på prinsippet om en sekvens av filtre som ytterligere identifiserer et sett med sertifikater og gir ytterligere opplysninger om SSCD-støtte og/eller at sertifikatet utstedes til en juridisk person (f.eks. de sertifikatene som inneholder en spesifikk OID i Certificate Policy-utvidelsen, og/eller har et spesifikt «Key usage»-mønster, og/eller filtreres ved bruk av en spesifikk verdi som skal vises i et spesifikt sertifikatfelt eller i en utvidelse osv.), vurderes i henhold til følgende sett med «qualifiers», som kompenserer for mangelen på opplysninger i tilsvarende QC, dvs.:
to indicate the SSCD support: 
for å angi SSCD-støtte:
‘QCWithSSCD’ qualifier value meaning ‘QC supported by an SSCD’, or 
«QCWithSSCD» som betyr «QC som støttes av et SSCD», eller
‘QCNoSSCD’ qualifier value meaning ‘QC not supported by an SSCD’, or 
«QCNoSSCD» som betyr «QC som ikke støttes av et SSCD», eller
‘QCSSCDStatusAsInCert’ qualifier value meaning that the SSCD support information is ensured to be contained in any QC under the ‘Sdi’ - ‘Sie’ provided information in this CA/QC entry; 
«QCSSCDStatusAsInCert» som betyr at det er sikret at opplysninger om SSCD-støtte er med i ethvert QC under «Sdi-»/«Sie»-angitte opplysninger i denne CA/QC-posten,
to indicate issuance to Legal Person: 
for å angi utstedelse til juridisk person:
‘QCForLegalPerson’ qualifier value meaning ‘Certificate issued to a Legal Person’. 
«QCForLegalPerson» som betyr «Sertifikat utstedt til en juridisk person».
The cases where the CRLs and OCSP responses are signed by keys other than from a CA issuing QCs (‘CA/QC’) should also be covered. 
De tilfellene der CRL-er og OCSP-svar underskrives av andre nøkler enn fra en CA som utsteder QC-er («CA/QC»), bør også omfattes.
This may be covered by listing those services as such in the TSL implementation of the TL (i.e. with a ‘Service type identifier’ further qualified by an ‘additionalServiceInformation’ extension reflecting an OCSP or a CRL service as being part of the provision of QCs, e.g. with a service type of ‘OCSP/QC’ or ‘CRL/QC’ respectively) since these services can be considered as part of the supervised/accredited ‘qualified’ services related to the provision of QC certification services. 
Dette kan gjøres ved å listeføre disse tjenestene som sådanne i TSL-gjennomføringen av pl (dvs. med en «Service type identifier» som er ytterligere kvalifisert ved en «additionalServiceInformation»-utvidelse som gjenspeiler at en OCSP eller en CRL-tjeneste er en del av ytingen av QC-er, f.eks. med tjenestetype henholdsvis «OCSP/QC» eller «CRL/QC»), ettersom disse tjenestene kan anses som en del av de kontrollerte/akkrediterte kvalifiserte tjenestene i tilknytning til yting av QC-sertifiseringstjenester.
Of course, OCSP responders or CRL Issuers whose certificates are signed by CAs under the hierarchy of a listed CA/QC service are to be considered as ‘valid’ and in accordance with the status value of the listed CA/QC service. 
Selvsagt skal OCSP-respondere eller CRL-utstedere hvis sertifikater underskrives av CA-er under hierarkiet for en listeført CA/QC-tjeneste, anses som gyldige og i samsvar med statusverdien for den listeførte CA/QC-tjenesten.
A similar provision can apply to certification services issuing non-qualified certificates (of a ‘CA/PKC’ service type) using the default ETSI TS 102 231 OCSP and CRL service types. 
En lignende bestemmelse kan få anvendelse på sertifiseringstjenester som utsteder ikke-kvalifiserte sertifikater (av typen «CA/PKC»-tjeneste) ved å bruke standard OCSP- og CRL-tjenestetyper i ETSI TS 102 231.
Note that the TSL implementation of the TL MUST include revocation services when related information is not present in the AIA field of end certificates, or when not signed by a CA that is one of the listed CAs. 
Vær oppmerksom på at TSL-gjennomføringen av pl MÅ omfatte tilbakekallingstjenester når tilhørende opplysninger ikke foreligger i AIA-feltet på sluttsertifikater, eller når de ikke er underskrevet av en CA som er listeført.
Moving towards interoperable QC profile 
Utvikling mot en samvirkende QC-profil
As a general rule, it must be tried to simplify (reduce) as far as possible the number of entries of services (different ‘Sdi’’s). 
Som en generell regel skal det forsøkes å forenkle (redusere) antallet tjenesteposter (forskjellige «Sdi-er») så mye som mulig.
This must be balanced however with the correct identification of those services that are related to the issuing of QCs and the provision of the trusted information on whether or not those QCs are supported by an SSCD when this information is missing from the issued QC. 
Dette må imidlertid balanseres mot riktig identifikasjon av de tjenestene som er knyttet til utstedelsen av QC-er, og levering av pålitelige opplysninger om hvorvidt disse QC-ene støttes av et SSCD eller ikke, når disse opplysningene mangler fra et utstedt QC.
Ideally the use of the ‘Sie’ field and ‘Qualification’ extension should be (strictly) restricted to those specific cases to be solved that way, as QCs should contain enough information with regard to the claimed qualified status and the claimed support or not by an SSCD. 
Helst bør bruken av «Sie»-feltet og «Qualification»-utvidelsen (strengt) begrenses til de særlige tilfellene som skal løses på den måten, siden QC-er bør inneholde nok opplysninger med hensyn til hevdet kvalifisert status og hevdet støtte av et SSCD eller ikke.
Member States should, as much as possible, enforce the adoption and use of interoperable QC profiles. 
Medlemsstatene bør i så stor grad som mulig sikre at samvirkende QC-profiler innføres og brukes.
The proposed Common Template for a Member State Trusted List will be structured into the following categories of information: 
Den foreslåtte felles malen for en medlemsstats pålitelighetsliste vil bli strukturert i følgende kategorier av opplysninger:
A sequence of fields holding unambiguous identification information about every supervised/accredited CSP under the scheme (this sequence is optional, i.e. when not used, the list will be deemed to be empty meaning that no CSP is either supervised or accredited in the associated Member State in the context of the Trusted List scope); 
En sekvens av felter som inneholder entydige identifikasjonsopplysninger om hver kontrollert/akkreditert CSP i ordningen (denne sekvensen er valgfri, dvs. når den ikke brukes, vil listen bli ansett for å være tom, noe som betyr at ingen CSP er under kontroll eller akkreditert i den tilhørende medlemsstaten innenfor rammen av pålitelighetslistens virkeområde).
For each listed CSP, a sequence of fields holding unambiguous identification of a supervised/accredited certification service provided by the CSP (this sequence must have a minimum of one entry); 
For hver listeført CSP, en sekvens av felter som inneholder entydig identifikasjon av en kontrollert/akkreditert sertifiseringstjeneste som CSP-en yter (denne sekvensen må ha minst én post).
For each listed supervised/accredited certification service, identification of the current status of the service and the history of this status. 
For hver listeført kontrollert/akkreditert sertifiseringstjeneste, identifikasjon av tjenestens gjeldende og historiske status.
In the context of a CSP issuing QCs, the unambiguous identification of a supervised/accredited certification service to be listed must take into consideration those situations where not enough information is available in the qualified certificate about its ‘qualified’ status, its potential support by an SSCD and especially in order to cope with the additional fact that most of the (commercial) CSPs are using one single issuing Qualified CA to issue several types of end-entity certificates, both qualified and non-qualified. 
I forbindelse med en CSP som utsteder QC-er, må den entydige identifikasjonen av en kontrollert/akkreditert sertifiseringstjeneste som skal listeføres, ta hensyn til de situasjonene der det ikke foreligger nok opplysninger i det kvalifiserte sertifikatet om dets status som kvalifisert, dets mulige støtte fra et SSCD, og særlig for å kunne håndtere det ytterligere faktum at de fleste (kommersielle) CSP-ene bruker én enkelt utstedende kvalifisert CA til å utstede flere typer sluttenhetssertifikater, både kvalifiserte og ikke-kvalifiserte.
The number of entries in the list per recognised CSP might be reduced where one or several Upper CA services exist, e.g. in the context of a commercial hierarchy of CAs from a Root CA down to issuing CAs. 
Antall poster på listen per anerkjent CSP kan reduseres dersom det finnes én eller flere overordnede CA-tjenester, f.eks. i forbindelse med et kommersielt hierarki av CA-er fra en rot-CA ned til utstedende CA-er.
However even in those cases, the principle of ensuring the unambiguous link between a CSP QC certification service and the set of certificates meant to be identified as QCs has to be maintained and ensured. 
Selv i disse tilfellene må imidlertid prinsippet om å sikre den entydige forbindelsen mellom en CSP QC -sertifiseringstjeneste og settet med sertifikater som er ment å skulle identifiseres som QC-er, vedlikeholdes og sikres.
The following information will be part of this category: 
Følgende opplysninger vil inngå i denne kategorien:
A Trusted List tag facilitating the identification of the Trusted List during electronic searches and also to confirm its purposes when in human-readable form, 
et pålitelighetslistemerke som forenkler identifikasjonen av pålitelighetslisten under elektroniske søk, og som også bekrefter dens formål når den har et menneskelesbart format,
A Trusted List format and format version identifier, 
en identifikator for pålitelighetslistens format og versjon,
A Trusted List sequence (or release) number, 
pålitelighetslistens sekvensnummer (eller utgivelsesnummer),
A Trusted List type information (e.g. for identification of the fact that this Trusted List is providing information on the supervision/accreditation status of certification services from CSPs supervised/accredited by the referenced Member State for compliance with the provisions laid down in Directive 1999/93/EC); 
typeopplysninger for pålitelighetslisten (f.eks. for å identifisere det faktum at denne pålitelighetslisten gir opplysninger om kontroll-/akkrediteringsstatusen for sertifiseringstjenester fra CSP-er som er under kontroll/akkreditert av den aktuelle medlemsstaten, for overholdelse av bestemmelsene fastsatt i direktiv 1999/93/EF),
A Trusted List owner information (e.g. name, address, contact information, etc. of the Member State Body in charge of establishing, publishing securely and maintaining the Trusted List), 
eieropplysninger for pålitelighetslisten (f.eks. navn, adresse, kontaktopplysninger osv. for det organet i medlemsstaten som er ansvarlig for å utarbeide, offentliggjøre sikkert og vedlikeholde pålitelighetslisten),
Information about the underlying supervision/accreditation scheme(s) to which the Trusted List is associated, including but not limited to: 
opplysninger om den eller de underliggende kontroll-/akkrediteringsordningene som pålitelighetslisten er tilknyttet, herunder, men ikke begrenset til
the country in which it applies, 
staten den gjelder for,
information on or reference to the location where information on the scheme(s) can be found (scheme model, rules, criteria, applicable community, type, etc.), 
opplysninger om eller referanse til det stedet der opplysninger om ordningen(e) er å finne (modell, regler, kriterier, aktuelt område, type osv.),
period of retention of (historical) information; 
oppbevaringsperiode for (historiske) opplysninger,
Trusted List policy and/or legal notice, liabilities, responsibilities, 
politikk og/eller juridisk uttalelse, forpliktelser og ansvar i forbindelse med pålitelighetslisten,
Trusted List issue date and time and next foreseen update, 
pålitelighetslistens utstedelsesdato og tidspunkt for neste planlagte ajourføring.
Unambiguous identification information about every CSP recognised by the scheme 
Entydige identifikasjonsopplysninger om hver CSP som ordningen anerkjenner
This set of information will include at least the following: 
Dette settet med opplysninger vil omfatte minst følgende:
The CSP organisation name as used in formal legal registrations (this may include the CSP organisation UID following Member State practices), 
CSP-organisasjonens navn slik det brukes i formelle, juridiske registre (dette kan omfatte CSP-organisasjonens UID etter praksis i medlemsstaten),
The CSP address and contact information, 
CSP-ens adresse og kontaktopplysninger,
Additional information on the CSP either included directly or by reference to a location from where such information can be downloaded, 
ytterligere opplysninger om CSP-en, enten tatt med direkte eller ved referanse til et sted der disse opplysningene kan lastes ned fra.
For each listed CSP, a sequence of fields holding unambiguous identification of a certification service provided by the CSP and supervised/accredited in the context of Directive 1999/93/EC 
For hver listeført CSP, en sekvens av felter som inneholder entydig identifikasjon av en sertifiseringstjeneste som CSP-en yter, og som er under kontroll/akkreditert innenfor rammen av direktiv 1999/93/EF
This set of information will include at least the following for each certification service from a listed CSP: 
Dette settet med opplysninger vil omfatte minst følgende for hver sertifiseringstjeneste fra en listeført CSP: