natgillin/translations-raw huggingface dataset:
В идеалния случай всяко издадено КУ следва да съдържа определената от ETSI декларация QcCompliance [9], когато е обявено като КУ, и да съдържа определената от ETSI декларация QcSSCD, когато се твърди, че то се поддържа от SSCD при генерирането на електронни подписи и/или всяко издадено КУ включва един от обектните идентификатори (OID) на политиката за сертифициране QCP/QCP+, определени в ETSI EN 319 411-2 [10].
Ideally each issued QC should include the ETSI defined QcCompliance [9] statement when it is claimed that it is a QC and should include the ETSI defined QcSSCD statement when it is claimed that it is supported by an SSCD to generate eSignatures, and/or that each issued QC includes one of the QCP/QCP+ certificate policy Object Identifiers (OIDs) defined in ETSI EN 319 411-2 [10].
Използването на различни стандарти от страна на ДУУ, издаващи КУ, голямата свобода на интерпретация, която тези стандарти позволяват, както и липсата на осведоменост относно наличието и приоритета на някои технически спецификации или стандарти са довели до разлики в действителното съдържание на издаваните понастоящем КУ (напр. относно използването или не на определените от ETSI декларации) и съответно не позволяват на получателя просто да разчита на удостоверението на подписващата страна (и свързаната с него верига от удостоверения) при извършването на оценка (най-малкото на машинна такава) дали удостоверението, поддържащо електронен подпис, е обявено за КУ и дали то е или не е свързано със SSCD, чрез което е бил създаден електронният подпис.
The use by CSPs issuing QCs of different standards as references, the wide degree of interpretation of those standards as well as the lack of awareness of the existence and precedence of some normative technical specifications or standards has resulted in differences in the actual content of currently issued QCs (e.g. the use or not of those QcStatements defined by ETSI) and consequently are preventing the receiving parties from simply relying on the signatory’s certificate (and associated chain/path) to assess, at least in a machine readable way, whether or not the certificate supporting an eSignature is claimed to be a QC and whether or not it is associated with an SSCD through which the eSignature has been created.
При вписване на услуга в доверителния списък попълването на полетата „Service type identifier“ („Sti“ — „Идентификатор на типа на услугата“), „Service name“ („Sn“ — „Име на услугата“) и „Service digital identity“ („Sdi“ — „Цифрова идентификация на услугата“) с информация, предоставена в полето „Service information extensions“ („Sie“ — „Разширена информация за услугата“), дава възможност да се определи напълно специфичният тип квалифицирано удостоверение, издадено от удостоверяваща услуга на включен в списъка ДУУ, издаващ КУ, и да се предостави информация дали то се поддържа от SSCD или не (когато такава информация липсва в издаденото КУ).
Completing the ‘Service type identifier’ (‘Sti’), ‘Service name’ (‘Sn’), and ‘Service digital identity’ (‘Sdi’) fields of the service entry in the Trusted List with information provided in the ‘Service information extensions’ (‘Sie’) field allows for the full determination of a specific type of qualified certificate issued by a listed CSP certification service issuing QCs and provides information about whether or not it is supported by an SSCD (when such information is missing in the issued QC).
С това вписване е свързана специфична информация в полето „Service current status“ („Scs“ — „Актуално състояние на услугата“).
A specific ‘Service current status’ (‘Scs’) information is associated with this entry.
Това е показано на графика 2 по-долу.
This is depicted in Figure 2 below.
Включването в списъка на услуга, за която се предоставя само „Sdi“ на (базовия) УО ще означава, че е гарантирано (от ДУУ, издаващ КУ, но и от надзорния/акредитиращия орган, отговарящ за надзора/акредитацията на този ДУУ), че всяко потребителско удостоверение, издадено в рамките на йерархията на този (базов) УО, съдържа достатъчно определена от ETSI и обработваема машинно информация, за да може да бъде преценено дали то е или не е КУ и дали се поддържа от SSCD.
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 or not it is supported by an SSCD.
Когато например последното твърдение не е вярно (т.е. в КУ липсва стандартизирана от ETSI и машинно обработваема информация дали то се поддържа от SSCD), то въз основа само на „Sdi“ на (базовия) УО ще може единствено да се предположи, че КУ, издадени от тази йерархична верига на (базов) УО, не се поддържат от 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.
За да се обозначи, че такива КУ трябва да се считат за поддържани от SSCD, следва да се използва полето „Sie“ (това означава също, че коректността на информацията се гарантира от ДУУ, издаващ КУ и намиращ се под надзора/акредитацията съответно на надзорен или акредитиращ орган).
In order to indicate that those QCs must be considered as supported by an SSCD, the ‘Sie’ field should be used (this also indicates that this information is guaranteed by the CSP issuing QCs and supervised/accredited by the Supervisory or Accreditation Body respectively).
Вписване на услуга за услуга на ДУУ, който издава КУ и е включен в доверителния списък
Service entry for a listed CSP service issuing QCs in the Trusted List
Основни принципи – правила за редактиране – вписвания за ДУУКУ (включени в списъка услуги)
General principles — Editing rules — CSPQC entries (listed services)
Вписване за включен в ДУУКУ:
Service entry for a listed CSPQC:
„име“
“name”
Публичен ключ
Public Key
Структурата включва последователност от кортежи, съставени от:
Structured as a sequence of tuples made of:
„филтриращи“ елементи, като разширението за политиката на сертифициране (OID) на X.509 допълнително определяне на (наборите) от КУ, които са обхванати, и
“Filtering” elements (e.g. X.509 Certificate Policy extension (OID)) to further determine those (sets) of QC to be covered, and
„квалификатори“, прилагани към филтрираните (набори от) КУ във връзка с „квалифицираното“ състояние, поддръжката от SSCD и/или издаването на юридическо лице, напр.:
“Qualifiers” to be applied to those filtered (sets of) QC’s about “qualified” status, SSCD support status and/or issuance to Legal Person, i.e.: QCWithSSCD
QCWithSSCD
QCNoSSCD
QCNoSSC, напр.:usAsInCert (*)
QCSSCDStatusAsInCert (*)
„актуално състояние“
“current status”
Указателите са изразени като URI
Indicators expressed as URIs
Означава, че тази информация гарантирано е включена във всяко на посочения в Sdi-[Sie] УО/КУ (ако тази информация липсва в това означава NoSSCD — не се поддържа от SSCD)
meaning that such information is ensured to be contained in any QC under Sdi-[Sie] defined CA/QC (if nothing in QC, then meaning is NoSSCD)
Настоящите технически спецификации на общ образец за доверителен списък позволяват във вписването за услугата да се използва комбинация от пет основни елемента на информацията:
The present Trusted List common template technical specifications allow for the use of a combination of five main parts of information in the service entry:
идентификатор на типа на услугата в полето „Service type identifier“ („Sti“), напр. за да се идентифицира УО, издаващ КУ („CA/QC“ — „УО/КУ“),
The ‘Service type identifier’ (‘Sti’), e.g. identifying a CA issuing QCs (‘CA/QC’),
име на услугата в полето „Service name“ („Sn“),
The ‘Service name’ (‘Sn’),
информация в полето „Service digital identity“ („Sdi“), идентифицираща услуга от списъка, напр. публичния ключ (като минимум) на УО, издаващ КУ,
The ‘Service digital identity’ (‘Sdi’) information identifying a listed service, e.g. the public key (as a minimum) of a CA issuing QCs,
за услуги от типа УО/КУ — незадължителна информация в полето „Service information extension“ („Sie“), позволяваща включването на определен брой специфични за услугата позиции във връзка с отмяна на изтекли удостоверения, допълнителни характеристики на КУ, поглъщане на ДУУ от друг ДУУ и друга допълнителна информация за услугата.
For CA/QC services, optional ‘Service information extension’ (‘Sie’) information that allows for the inclusion of a number of specific service-related items of information relating to revocation status of expired certificates, additional characteristics of QCs, takeover of CSP by another CSP and other additional service information.
Например допълнителните характеристики на КУ се представят чрез поредица от един или повече кортежи, като всеки кортеж включва:
For example, the additional characteristics of QCs are represented by a sequence of one or more tuples, each tuple providing:
критерии за допълнително идентифициране (филтриране) в рамките на идентифицираната в полето „Sdi“ удостоверителна услуга, които определят набора от квалифицирани удостоверения, за които се изисква/предлага допълнителна информация, с цел обозначаване на „квалифицирано“ състояние, поддръжка от SSCD и/или издаване на юридическо лице; както и
Criteria to be used to further identify (filter) under the ‘Sdi’ identified certification service that precise set of qualified certificates for which additional information is required/provided with regard to the indication of the ‘qualified’ status, the SSCD support and/or issuance to a Legal Person, and
свързана информация („квалификатори“), указваща дали този набор от квалифицирани удостоверения трябва да се счита за квалифициран, дали се поддържа или не от SSCD и дали тази свързана информация е част от КУ в стандартизиран формат, позволяващ машинна обработка, и/или информация дали такива КУ се издават и на юридически лица (по подразбиране те се издават само на физически лица);
The associated information (‘qualifiers’) on whether this set of qualified certificates is to be considered as ‘qualified’, is supported by an SSCD or not or whether this associated information is part of the QC under a standardised machine-processable form, and/or information regarding the fact that such QCs are issued to Legal Persons (by default they are to be considered as issued only to Natural Persons),
информацията за „актуалното състояние“ на тази вписана услуга изяснява:
The ‘current status’ information for this service entry providing information on:
дали услугата е под надзор или акредитирана, и
Whether it is a supervised or accredited service, and
какво е състоянието на надзора/акредитацията.
The supervision/accreditation status itself.
Насоки за редактиране и използване на вписвания на услуги, предлагани от ДУУКУ
Editing and usage guidelines for CSPQC services entries
Основните насоки за редактиране са:
The general editing guidelines are:
Ако е сигурно (гаранция от страна на ДУУКУ, който е под надзор/акредитация на надзорен орган (НО)/акредитиращ орган (АО), че за вписана в списъка услуга, идентифицирана чрез „Sdi“, всяко КУ, поддържано от SSCD, съдържа определената от ETSI декларация QcCompliance и декларацията QcSSCD и/или идентификатора QCP + Object Identifier (OID), то използването на подходяща „Sdi“ е достатъчно и полето „Sie“ може да се използва по желание, като не е необходимо да съдържа информация за поддръжката от SSCD.
If it is ensured (guarantee provided by CSPQC and supervised/accredited by Supervisory Body (SB)/Accreditation Body (AB)) that, for a listed service identified by a ‘Sdi’, any QC supported by an SSCD does contain the ETSI defined QcCompliance statement, and does contain the QcSSCD statement and/or QCP+ Object Identifier (OID), then the use of an appropriate ‘Sdi’ is sufficient and the ‘Sie’ field can be used as an option and will not need to contain the SSCD support information.
Ако е сигурно (гаранция от страна на ДУУКУ, който е под надзор/акредитация на НО/АО), че за вписана в списъка услуга, идентифицирана чрез „Sdi“, всяко КУ, което не се поддържа от SSCD, съдържа декларацията QcCompliance и/или QCP OID и не съдържа декларацията QcSSCD или QCP + OID, то използването на подходяща „Sdi“ е достатъчно и полето „Sie“ може да се използва по желание, като не е необходимо да съдържа информация за поддръжката от SSCD (което означава, че не се поддържа от SSCD).
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 not supported by an SSCD does contain the QcCompliance statement and/or the QCP OID, and does not contain the QcSSCD statement or QCP+ OID, then the use of an appropriate ‘Sdi’ is sufficient and the ‘Sie’ field can be used as an option and does not have to contain the SSCD support information (meaning it is not supported by an SSCD).
Ако е сигурно (гаранция от страна на ДУУКУ, който е под надзор/акредитация на НО/АО), че за вписана в списъка услуга, идентифицирана чрез „Sdi“, всяко КУ съдържа декларацията QcCompliance, като някои от тези КУ се поддържат от SSCD, а други не (това може да бъде указано напр. чрез различни специфични за ДУУ OID на политиката за сертифициране или чрез друга специфична за ДУУ информация в КУ, пряко или непряко, в машинно обработваем формат или не), но удостоверенията, които не се поддържат от SSCD, не съдържат НИТО декларацията QcSSCD, НИТО определения от ETSI идентификатор QCP(+) OID, то използването на подходяща „Sdi“ може да не бъде достатъчно И полето „Sie“ трябва да се използва за предоставяне на изрична информация относно поддръжката от SSCD, както и на възможна разширена информация за идентифициране на обхванатия набор от удостоверения.
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 a certificate that is supported by an SSCD 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.
Това вероятно ще изисква включването на различни „стойности, характеризиращи поддръжката от SSCD“ за една и съща информация в полето „Sdi“, когато се използва полето „Sie“.
This is likely to require the inclusion of different ‘SSCD support information values’ for the same ‘Sdi’ when making use of the ‘Sie’ field.
Ако е сигурно (гаранция от страна на ДУУКУ, който е под надзор/акредитация на НО/АО), че за вписана в списъка услуга, идентифицирана чрез „Sdi“, нито едно КУ не съдържа декларацията QcCompliance, QCP OID, декларацията QcSSCD или QCP(+) OID, но е сигурно, че някои от тези потребителски удостоверения, издадени с тази „Sdi“, са предвидени да бъдат КУ и/или да се поддържат от SSCD, а други не (това може да бъде указано напр. чрез различни специфични за ДУУКУ OID на политиката за сертифициране или чрез друга специфична за ДУУ информация в КУ, пряко или непряко, в машинно обработваем формат или не), то използването на подходяща информация в „Sdi“ няма да бъде достатъчно И полето „Sie“ трябва да се използва за включване на изрична информация относно квалификацията.
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 qualification information.
Основен принцип по подразбиране е, че при вписаните в доверителния списък ДУУ трябва да има едно вписване за услуга за всеки публичен ключ за удостоверителна услуга от типа УО/КУ, т.е. удостоверяващ орган, издаващ (пряко) КУ.
As a general default principle, for a listed CSP in the Trusted List there must be one service entry per single public key for a CA/QC type certification service, i.e. per Certification Authority (directly) issuing QCs.
При някои изключителни обстоятелства и грижливо контролирани условия надзорният/акредитиращият орган на държавата членка може да реши да използва като „Sdi“ за едно вписване в списъка с услуги от включен в списъка ДУУ публичния ключ на базов УО или УО от по-високо ниво в рамките на PKI на ДУУ (напр. в контекста на йерархична верига на УО на ДУУ, свързваща един базов УО с няколко издаващи УО), вместо да вписва всички подчинени услуги на издаващи УО (т.е. включване на удостоверяващ орган, който не издава пряко потребителски КУ, но сертифицира йерархични вериги от УО до нивото на УО, издаващи потребителски КУ).
In some exceptional circumstances and carefully managed conditions, the Member State’s Supervisory Body/Accreditation Body may decide to use, as the ‘Sdi’ of a single entry in the list of services from this listed CSP, the public key of a Root or Upper level CA within the CSP’s PKI (e.g. in the context of a CSP’s hierarchy of CAs from a Root CA down to several issuing CAs) instead of listing all sub-ordinate issuing CA services (i.e. listing a Certification Authority not directly issuing end-entity QCs but certifying a hierarchy of CAs down to CAs issuing QCs to end-entities).
Последствията (предимства и недостатъци) от използването на публичния ключ на такъв базов УО или УО от по-високо ниво като стойност в „Sdi“ при вписване на услуги в доверителен списък трябва да бъдат добре премислени, когато се прилагат от държавите членки.
The consequences (advantages and disadvantages) of using such Root CA or Upper CA public key as ‘Sdi’ value in a Trusted List service entry must be carefully considered when implemented by Member States.
Освен това, когато се прилага това разрешено изключение от основния принцип, държавите членки трябва да осигурят необходимата документация, даваща възможност за конструиране и проверка на удостоверителната верига.
Moreover, when using this authorised exception to the default principle, the Member State must provide the necessary documentation to facilitate certification path building and verification.
Например в контекста на ДУУКУ, използващи един базов УО, в чиято йерархична верига различни УО издават квалифицирани и неквалифицирани удостоверения, но чиито КУ съдържат само декларацията QcCompliance без информация относно поддръжката от SSCD, вписването на „Sdi“ само на базовия УО ще означава (съгласно правилата, обяснени по-горе), че никое КУ, издадено от йерархичната верига на този базов УО, не се поддържа от SSCD.
As an example, 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 none of the QC issued under this Root CA is supported by an SSCD.
Ако са налице КУ, които в действителност се поддържат от SSCD, но удостоверенията не съдържат машинно обработваема декларация, указваща такава поддръжка, настоятелно се препоръчва в издаваните в бъдеще квалифицирани удостоверения да се използва декларацията QcSSCD.
If there are QCs that are actually supported by an SSCD but with no machine processable statement indicating such support included in the certificates, it would be strongly recommended to make use of the QcSSCD statement in the QCs issued in the future.
Междувременно (до изтичане на срока на валидност на последното УО, което не съдържа тази информация) в доверителния списък следва да се използва полето „Sie“ и свързаното разширение „Qualifications Extension“, напр. филтриране на информация за идентифициране на набор(и) от удостоверения чрез специфични определени от ДУУКУ OID, които евентуално се използват от ДУУКУ за разграничаване на различните видове КУ (поддържани от SSCD или не), и съдържащи изрична „информация за поддръжката от SSCD“ с оглед на набора (наборите) от удостоверения, идентифицирани (филтрирани) въз основа на „квалификатори“.
In the meantime (until the last QC not containing this information has expired), the Trusted List should make use of the ‘Sie’ field and associated ‘Qualifications Extension’, e.g. providing filtering information to identify set(s) of certificates through use of specific CSPQC defined OID(s) potentially used by the CSPQC to distinguish between different types of QCs (some supported by an SSCD and some not) and associating explicit ‘SSCD support information’ to those identified (filtered) set(s) of certificates through the use of ‘Qualifiers’.
Основните насоки за използване на приложения за електронни подписи, услуги или продукти, ползващи доверителния списък в съответствие с настоящите технически спецификации, са следните:
The general usage guidelines for electronic signature applications, services or products relying on a Trusted List compliant with the present Technical Specifications are as follows:
Стойност „CA/QC“ („УО/КУ“) в полето „Sti“ (по подобен начин това важи за стойност „CA/QC“ („УО/КУ“), квалифицирана допълнително като базова (RootCA/QC) чрез полето „Sie“ (additionalServiceInformation Еxtension)
A ‘CA/QC’‘Sti’ entry (similarly a CA/QC entry further qualified as being a ‘RootCA/QC’ through the use of ‘Sie’ additionalServiceInformation Extension)
указва, че всички издадени от идентифицирания чрез „Sdi“ УО (по същия начин това важи за базовия УО, указан в „Sdi“ при йерархична верига) потребителски удостоверения са КУ, при условие че са декларирани като такива в удостоверението с помощта на подходяща машинно обработваема декларация от тип QcStatement (т.e. QcCompliance) и/или определени от ETSI QCP(+) OID, като това се гарантира от надзорен/акредитиращ орган (вж. по-горе „Основните насоки за редактиране“)
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 machine processable QcStatement (i.e. QcCompliance) and/or ETSI defined QCP(+) OIDs (and this is ensured by Supervisory/Accreditation Body, see above ‘general editing guidelines’)
Забележка: ако в полето „Sie“ липсва информация за „Qualifications Extension“ („разширени квалификации“) или ако потребителско удостоверение, което е обявено за КУ, не е идентифицирано допълнително чрез свързани „Qualifications Extension“ („разширени квалификации“) в поле „Sie“, то машинно обработваемата информация, която се съдържа в КУ, се приема за коректна въз основа на факта, че е под надзор/акредитирана.
Note: if no ‘Sie’‘Qualifications Extension’ information is present or if an end-entity certificate that is claimed to be a QC is not further identified through a related ‘Sie’‘Qualifications Extension’, then the machine-processable information to be found in the QC is supervised/accredited to be accurate.
Това означава, че се гарантира, че употребата (или не) на подходящи декларации от тип QcStatements (т.e. QcCompliance, QcSSCD) и/или определени от ETSI QCP(+) OID е в съответствие с това, което се твърди от ДУУКУ
That means that the usage (or not) of the appropriate QcStatements (i.e. QcCompliance, QcSSCD) and/or ETSI defined QCP(+) OIDs is ensured to be in accordance with what it is claimed by the CSPQC.