natgillin/translations-raw huggingface dataset:
Når en tjeneste optages på listen ved blot at angive »Sdi« af (Root) CA betyder det, at det sikres (af den QC-udstedende CSP, men også af det organ, som er ansvarlig for overvågningen/akkrediteringen af den pågældende CSP), at et eventuelt slutenhedscertifikat under dette (Root) CA (hierarki) indeholder tilstrækkeligt mange ETSI-definerede og maskinprocesserbare oplysninger til at vurdere, hvorvidt det er et QC, og hvorvidt det er understøttet af et SSCD. Såfremt sidstnævnte påstand ikke er sand (f.eks. hvis der ikke er nogen ETSI-standardiseret maskinprocesserbar angivelse på QC'et af, hvorvidt det understøttes af et SSCD) kan det ved blot at angive »Sdi« for dette (Root) CA kun antages, at QC'er udstedt under dette (Root) CA-hierarki ikke er understøttet af et SSCD. For at betragte disse QC'er som værende understøttet af et SSCD, skal »Sie« anvendes til at angive denne kendsgerning (dette indikerer også, at det er garanteret af den QC-udstedende CSP og overvåget/akkrediteret af henholdsvis overvågningsorganet eller akkrediteringsorganet).
Listing a service by just providing the ‘Sdi’ of a (Root) CA would mean that it is ensured (by the CSP issuing QCs but also by the Supervisory/Accreditation Body in charge of the supervision/accreditation of this CSP) that any end-entity certificate issued under this (Root) CA (hierarchy) contains enough ETSI defined and machine-processable information to assess whether or not it is a QC, and whether it is supported by an SSCD. In the event, for example, that the latter assertion is not true (e.g. there is no ETSI standardised machine-processable indication in the QC about whether it is supported by an SSCD), then by listing only the ‘Sdi’ of that (Root) CA, it can only be assumed that QCs issued under this (Root) CA hierarchy are not supported by any SSCD.
Generelle principper – Redigeringsregler – CSPQS-indgange (angivne tjenester)
In order to consider those QCs as supported by an SSCD, the ‘Sie’ should be used to indicate this fact (this also indicates that it is guaranteed by the CSP issuing QCs and supervised/accredited by the Supervisory or Accreditation Body respectively). General principles — Editing rules — CSPQC entries (listed services)
Hvis det i forbindelse med en angivet tjeneste, som er identificeret at en »Sdi«, sikres (garanteret af CSPQC og overvåget/akkrediteret af SB/AB), at et QC faktisk indeholder QcCompliance-erklæringen og kun nogle af disse QC'er skal understøttes af SSCD'er (dette kan f.eks. differentieres af forskellige CSP-specifikke Certificate Policy OIDs eller gennem andre CSP-specifikke oplysninger i QC'et, uanset om de er direkte eller indirekte, maskinprocesserbare eller ikke), men HVERKEN indeholder QcSSCD-erklæringen ELLER ETSI QCP(+) OID, er anvendelsen af en passende »Sdi« muligvis ikke tilstrækkelig OG »Sie«-feltet skal anvendes til at angive udtrykkelige oplysninger om SSCD-støtte sammen med eventuelt udvidede oplysninger for at identificere det omfattede certifikatsæt. Dette vil sandsynligvis kræve medtagelse af forskellige »SSCD support information values« for samme »Sdi«, når »Sie«-feltet anvendes.
If it is ensured (guarantee provided by CSPQC 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. This is likely to require the inclusion of different ‘SSCD support information values’ for the same ‘Sdi’ when making use of the ‘Sie’ field.
Hvis det i forbindelse med en angivet tjeneste, som er identificeret at en »Sdi«, sikres (garanteret af CSPQC og overvåget/akkrediteret af SB/AB), at et QC ikke indeholder QcCompliance-erklæring, QCP OID, QcSSCD-erklæring, eller QCP + OID, men det sikres, at kun nogle af disse slutenhedscertifikater udstedt under denne »Sdi« skal være QC'er og/eller understøttet af SSCD'er (dette kan f.eks. differentieres af forskellige CSPQC-specifikke Certificate Policy OIDs eller gennem andre CSP-specifikke oplysninger i QC'et, uanset om de er direkte eller indirekte, maskinprocesserbare eller ikke), vil anvendelsen af en passende »Sdi« ikke være tilstrækkelig OG »Sie«-feltet skal anvendes til at angive udtrykkelige oplysninger om SSCD-støtte. Dette vil sandsynligvis kræve medtagelse af forskellige »SSCD support information values« for samme »Sdi«, når »Sie«-feltet anvendes.
If it is ensured (guarantee provided by CSPQC 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 CSPQC specific Certificate Policy OIDs or through other CSPQC 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. This is likely to require the inclusion of different ‘SSCD support information values’ for the same ‘Sdi’ when making use of the ‘Sie’ field.
Under visse omhyggeligt forudsete og nøje styrede forhold kan et overvågningsorgan/akkrediteringsorgan i en medlemsstat beslutte at anvende X.509v3-certifikatet fra et Root eller Upper level QC (dvs. en certificeringscenter, som ikke direkte udsteder slutenhedskvalificerede certifikater, men som certificerer et hierarki af certificeringscentre ned til certificeringscentre, som udsteder QC'er til slutenheder) som »Sdi« for en enkelt indgang i listen over tjenester fra en angivet CSP. Følgerne (fordele og ulemper) ved at bruge et sådant X.509v3 Root CA eller Upper CA som »Sdi«-værdier for TL-tjenesteindgange skal nøje overvejes og godkendes af medlemsstaterne.
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. 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.
De generelle redigeringsretningslinjer kan illustreres med følgende eksempel: I forbindelse med en CSPQC, der anvender ét Root CA, hvorunder flere CA'er udsteder kvalificerede certifikater og ikke-kvalificerede certifikater, men for hvilke QC'erne faktisk kun indeholder QcCompliance-erklæringen og ingen angivelse af, om den understøttes af et SSCD, ville angivelsen af Root CA »Sdi« alene i henhold de oven for forklarede regler betyde, at ethvert QC, der udstedes under dette Root CA-hierarki, IKKE er understøttet af et SSCD. Hvis disse QC'er faktisk understøttes af et SSCD, anbefales det kraftigt at anvende QcSSCD-erklæringen i de QC'er, der udstedes fremover. I mellemtiden (indtil det sidste QC, som ikke indeholder disse oplysninger, er udløbet) bør TSL gøre brug af »Sdi«-feltet og den dermed forbundne »Qualifications«-udvidelse, f.eks. filtrering af certifikater gennem specifikke CSPQC-definerede OID, som potentielt anvendes af CSPQC til at skelne mellem forskellige typer QC'er (hvoraf nogle er og andre ikke er understøttet af et SSCD) og inklusive udtrykkelig »SSCD support information« for sådanne filtrerede certifikater gennem anvendelse af »Qualifiers«.
In order to illustrate the general editing guidelines, the following example can be given: In the context of a CSPQC 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. 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.
angiver, at alle udstedte slutenhedscertifikater fra det »Sdi«-identificerede CA (tilsvarende inden for CA-hierarkiet begyndende med det »Sdi«-identificerede RootCA) er QC'er forudsat, at det i certifikatet hævdes at være dette gennem anvendelse af passende QcStatements (dvs. QcC, QcSSCD) og/eller ETSI-definerede QCP(+) OIDs (og dette sikres af overvågnings/akkrediteringsorganet, jf. ovenstående »generelle redigeringsretningslinjer«)
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: A ‘CA/QC’‘Sti’ entry (similarly a CA/QC entry further qualified as being a RootCA/QC through the use of ‘Sie’ additionalServiceInformation extension)
og HVIS der findes en »Sdi«- »Qualification«-oplysning, så skal de certifikater, som identificeres i tilgift til den generelle ovenstående fortolkningsregel gennem anvendelsen af denne »Sdi-«Qualification-indgang, som konstrueres ud fra princippet om en sekvens af filtre, der yderligere identificerer et sæt certifikater og leverer visse yderligere oplysninger vedrørende SSCD-støtte og/eller »juridisk person som genstand« (f.eks. certifikater, der indeholder specifik OID i certifikatpolitikudvidelsen og/eller har et »Key usage«-mønster og/eller filtreres gennem anvendelse af en specifik værdi, der skal forekomme i et specifikt certifikatfelt eller udvidelse, osv.) overvejes i overensstemmelse med følgende sæt »qualifiers«, som kompenserer for de manglende oplysninger i det tilsvarende QC, dvs.:
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 CSPQC. 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.:
for at angive SSCD-støtte:
to indicate the SSCD support:
»QCWithSSCD« — en kvalifikatorværdi, der betyder »QC understøttet af et SSCD«, eller
‘QCWithSSCD’ qualifier value meaning ‘QC supported by an SSCD’, or
Dette kan gøres ved at angive disse tjenester som sådan i TSL-implementeringen af TL (dvs. med en »service type identifier«, som yderligere kvalificeres af en »additionalServiceInformation«-udvidelse, der afspejler en OCSP eller en CRL-tjeneste som en del af leveringen af QC'er, f.eks. med henholdsvis tjenestetypen »OCSP/QC« eller »CRL/QC«), eftersom disse tjenester kan betragtes som del af de overvågede/akkrediterede kvalificerede tjenester, der vedrører levering af QC-certificeringstjenester. Selvfølgelig skal OCSP-respondenter eller CRL-udstedere, hvis certifikater er underskrevet af CA'er i hierarkiet for en angiven CA/QC-tjeneste, betragtes som »valide« i overensstemmelse med den angivne CA/QC-tjenestes statusværdi.
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. 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.
Antallet af optegnelser i listen pr. anerkendt CSP kan mindskes i det omfang der findes én eller flere »Upper« CA-tjenester, f.eks. i forbindelse med et kommercielt hierarki af CA'ere fra Root CA ned til udstedende CA'er.
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.
Selv i sådanne tilfælde skal princippet om at sikre en entydig forbindelse mellem en CSPQC-certificeringstjeneste og det sæt af certifikater, der fremstår som identificerede QC'er, dog opretholdes og sikres.
However even in those cases, the principle of ensuring the unambiguous link between a CSPQC certification service and the set of certificates meant to be identified as QCs has to be maintained and ensured.
Eventuelt kan certificeringscentret generere brugernes nøgler [[ETSI TS 102 042]. CA'et anses for identificeret gennem de identifikationsoplysninger, der findes i udstederfeltet i det CA-certifikat, der vedrører (certificering af) den offentlige nøgle, og som CA faktisk anvender til udstedelse af enhedscertifikater. Et CA kan have flere signeringsnøgler. Hver enkelt CA-signeringsnøgle er identificeret af en unik identifikatordel i feltet Authority Key Identifier i CA's certifikat.
Optionally the Certification Authority may create the users' keys [ETSI TS 102 042]. The CA is deemed to be identified through the identification information present in the Issuer field of the CA certificate related to (certifying) the public key associated with the CA’s private signing key and which, effectively, is used by the CA to issue entity certificates. A CA may have several signing keys.
Certificeringscenter, der udsteder kvalificerede certifikater (Certification Authority issuing Qualified Certificates)
Every CA signing key is uniquely identified by a unique identifier as part of the Authority Key Identifier field in the CA’s certificate. Certification Authority issuing Qualified Certificates
»Tag«
Tag
Oplysninger om ordningen
Scheme Information
Dette hele tal begyndende med »1«SKAL øges med 1 for hver efterfølgende udgivelse af TSL'en. Det MÅ IKKE sættes tilbage til »1«, når ovenstående »TSL version identifier« øges.
Starting from ‘1’ at the first release of the TSL, this integer value SHALL be incremented by 1 at each subsequent release of the TSL. It SHALL NOT be recycled to ‘1’ when the ‘TSL version identifier’ above is incremented.
Det SKAL indeholde adressen på den juridiske person eller bemyndigede organisation, som er angivet i feltet »Scheme operator name« (punkt 5.3.4), både til postformål og elektronisk kommunikation. Det skal indeholde både »PostalAddress« (dvs. vej, sted [stat eller region/kommune], [postnummer] og ISO 3166-1 alpha-2 landekode) i overensstemmelse med punkt 5.3.5.1 og »ElectronicAddress« (dvs. e-mail og/eller websted URI) i overensstemmelse med punkt 5.3.5.2.
It SHALL specify the address of the legal entity or mandated organization identified in the ‘Scheme operator name’ field (clause 5.3.4) for both postal and electronic communications. It SHALL include both ‘PostalAddress’ (i.e. street address, locality, [state or province], [postal code] and ISO 3166-1 alpha-2 country code) as compliant with clause 5.3.5.1; and ‘ElectronicAddress’ (i.e. e-mail and/or website URI) as compliant with clause 5.3.5.2.
Dette felt er PÅKRÆVET og SKAL angive URI(»er«), hvor brugerne (afhængige parter) kan få oplysninger om den specifikke ordning (med EN som obligatorisk sprog og potentielt ét eller flere nationalsprog). Det SKAL være en sekvens af flersprogede pointers (med engelsk EN som det obligatoriske sprog og med potentielt et eller flere nationalsprog). Den/de URI(»er«), der henvises til, SKAL indeholde en sti til relevante oplysninger om ordningen.
This field is REQUIRED and SHALL specify the URI(s) where users (relying parties) can obtain scheme-specific information (with EN as the mandatory language and with potentially one or more national languages). This SHALL be a sequence of multilingual pointers (with EN as the mandatory language, and with potentially one or more national languages).
Generelle indledende oplysninger, som er fælles for alle medlemsstater, vedrørende positivlistens anvendelsesområde og kontekst og den/de pågældende overvågnings/akkrediteringsordning(er).
The appropriate information about the scheme SHALL include as a minimum: General introductory information that would be common to all Member States with regard to the scope and context of the Trusted List, and the underlying supervision/accreditation scheme(s).
CSP'er, som ikke udsteder QC'er, men leverer understøttende tjenester kan være omfattet af en »frivillig akkrediteringsordning« (jf. definitionen og bestemmelserne i direktiv 1999/93/EF) og/eller en nationalt defineret »anerkendt godkendelsesordning«, som gennemføres på nationalt plan med henblik på overvågning af overholdelse af direktivets bestemmelser og eventuelt af nationale bestemmelser om levering af certificeringstjenester (som omhandlet i direktivets artikel 2, stk. 11). Nogle af de fysiske eller binære (logiske) genstande, der genereres eller udstedes som følge af leveringen af en certificeringstjeneste, kan være berettiget til at få en særlig »kvalifikation«, fordi de overholder nationalt fastsatte bestemmelser og krav, men en sådan »kvalifikations« betydning vil sandsynligvis udelukkende begrænse sig til det nationale plan.
CSPs not issuing QCs but providing ancillary services, may fall under a “voluntary accreditation” system (as defined in and in compliance with Directive 1999/93/EC) and/or under a nationally defined “recognised approval scheme” implemented on a national basis for the supervision of compliance with the provisions laid down in Directive 1999/93/EC and possibly with national provisions with regard to the provision of certification services (in the sense of Art. 2,11 of the Directive). Some of the physical or binary (logical) objects generated or issued as a result of the provision of a certification service may be entitled to receive a specific “qualification” on the basis of their compliance with the provisions and requirements laid down at national level but the meaning of such a “qualification” is likely to be limited solely to the national level.
og HVIS der findes oplysninger om »Sie«»Qualification«, skal de certifikater, som identificeres gennem anvendelse af denne »Sie«»Qualification«-indgang, som konstrueres ud fra princippet om en sekvens af »filtre«, der yderligere identificerer et sæt certifikater, betragtes i overensstemmelse med de tilknyttede »kvalifikatorer«, som giver visse yderligere oplysninger om »SSCD-støtte« og/eller »juridisk person som genstand« (f.eks. de certifikater, der indeholder specifik OID i certifikatpolitikudvidelsen, og/eller har et specifikt mønster for »nøglebrug«, og/eller filtreres gennem anvendelse af en specifik værdi, der skal forekomme i et specifikt certifikatfelt eller udvidelse, osv.). Kvalifikatorerne indgår i følgende sæt »kvalifikatorer«, som anvendes til at kompensere for de manglende oplysninger i det tilsvarende QC-indhold, og som henholdsvis anvendes til:
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, must be considered according to the associated qualifiers 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.). Those qualifiers are part of the following set of “qualifiers” used to compensate for the lack of information in the corresponding QC content, and that are used respectively:
Den generelle fortolkningsregel for enhver anden type »Sti«-angivelse er, at den angivne tjeneste, som er navngivet i overensstemmelse med »Sn«-feltværdien og entydigt identificeret af »Sdi«-feltværdien, har en aktuel overvågnings/akkrediteringsstatus i overensstemmelse med »Scs«-feltværdien fra den dato, der er angivet i »startdato og tid for den aktuelle status«. Særlige fortolkningsregler for eventuelle yderligere oplysninger vedrørende en angivet tjeneste (f.eks. feltet »Service information extensions«) kan, hvis det er relevant, findes i den medlemsstatsspecifikke URI som led i nærværende felt »Scheme type/community/rules«.
The general interpretation rule for any other “Sti” type entry is that the listed service named according to the “Sn” field value and uniquely identified by the “Sdi” field value has a current supervision/accreditation status according to the “Scs” field value as from the date indicated in the “Current status starting date and time”. Specific interpretation rules for any additional information with regard to a listed service (e.g. “Service information extensions” field) may be found, when applicable, in the Member State specific URI as part of the present “Scheme type/community/rules” field.
Dette felt er PÅKRÆVET og SKAL indeholde adressen på den juridiske person eller bemyndigede organisation, som er angivet i feltet »TSP name« (punkt 5.4.1), både til postformål og elektronisk kommunikation. Det skal indeholde både »PostalAddress« (dvs. vej, sted [stat eller region/kommune], [postnummer] og ISO 3166-1 alpha-2 landekode) i overensstemmelse med punkt 5.3.5.1 og »ElectronicAddress« (dvs. e-mail og/eller websted URI) i overensstemmelse med punkt 5.3.5.2.
This field is REQUIRED and SHALL specify the address of the legal entity or mandated organization identified in the ‘TSP name’ field (clause 5.4.1) for both postal and electronic communications. It SHALL include both ‘PostalAddress’ (i.e. street address, locality, [state or province], [postal code] and ISO 3166-1 alpha-2 country code) as compliant with clause 5.3.5.1; and ‘ElectronicAddress’ (i.e. e-mail and/or website URI) as compliant with clause 5.3.5.2.