Rządowy projekt ustawy o zmianie ustawy - Prawo telekomunikacyjne oraz niektórych innych ustaw

SignedRequestVersion ::= INTEGER
{
v1 (0)
}

W kolejnych punktach przybliżono najważniejsze elementy struktury CMS. Pełny opis specyfikacji
znajduje się w [RFC3852].
Typ ContentInfo
Podstawowym typem dla CMS jest ContentInfo. Typ ten jest identyfikowany przez następujący
OID:
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16)
ct(1) 6 }

Typ ContentInfo został zdefiniowany następująco:
ContentInfo ::= SEQUENCE
{
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType
}

ContentType ::= OBJECT IDENTIFIER

Pole contentType musi identyfikować typ SignedData, określony przez następujący identyfikator
OID:
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

Typ ContentInfo zostało opisany w [RFC3852], pkt 3.
Typ SignedData
Typ SignedData struktury CMS składa się z zawartości dowolnego typu oraz podpisów
elektronicznych tej zawartości. Typ SignedData został zdefiniowany następująco:
SignedData ::= SEQUENCE
{
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos
}

Pole digestAlgorithms zawiera zbiór identyfikatorów algorytmów funkcji skrótu. Wymagania
dotyczące tych algorytmów zostały opisana w pkt. 0
Pole encapContentInfo zawiera treść żądania Hi1, która wymaga podpisania.
Pole certificates zawiera zbiór certyfikatów niezbędnych do określenia poprawności podpisów
znajdujących się w polu signersInfos.
Opcjonalne pole crls zawiera zbiór list unieważnionych i zawieszonych certyfikatów (ang.


4

Certificate Revocation List - CRL). Na potrzeby zarządzania certyfikatami i listami CRL
wykorzystuje się infrastrukturę klucza publicznego PKI. PKI oraz formaty certyfikatów i list CRL
zostały opisane w osobnym punkcie.
Pole signerInfos jest zbiorem podpisów elektronicznych.
Typ SignedData zostało opisany w [RFC3852], pkt 5.1.
EncapsulatedContentInfo
Typ EncapsulatedContentInfo został zdefiniowany następująco:
EncapsulatedContentInfo ::= SEQUENCE
{
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL
}

ContentType ::= OBJECT IDENTIFIER

Pole eContentType musi identyfikować typ data:
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }

Pole eContent zawiera żądanie HI1 przeznaczone do podpisania w postaci UnsignedRequestDetail.
Typ EncapsulatedContentInfo został opisany w [RFC3852], pkt 5.2
Typ SignerInfo
Typ SignerInfo został zdefiniowany następująco:
SignerInfo ::= SEQUENCE
{
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL
}

Pole sid identyfikuje certyfikat podmiotu, który złożył podpis. Zgodnie z [RFC3852], pkt 5.3 muszą
zostać zaimplementowane obie formy SignerIdentifier: issuerAndSerialNumber oraz
subjectKeyIdentifier.
Pole digestAlgorithm zawiera identyfikator zastosowanego algorytmu funkcji skrótu. Wymagania
dotyczące algorytmów funkcji skrótu zostały opisana w pkt. 0
Pole signedAttrs zawiera zbiór atrybutów, które są podpisywane. Zalecane jest, by wykorzystywany
był atrybut określający czas złożenia podpisu. Ponadto w polu tym zostanie zawarta informacja o
rodzaju zobowiązania (ang. commitment type) poprzez umieszczenie identyfikatora obiektu:
commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) cti(6) 1 } wskazującego, że podpisujący pracownik LEA stworzył,
zaaprobował i wysłał podpisaną wiadomość ([RFC3126], pkt 3.12.1).
Pole signatureAlgorithm zawiera identyfikator zastosowanego algorytmu podpisu elektronicznego.
Wymagania dotyczące algorytmów podpisów elektronicznych zostały opisane w pkt 0
Pole signature typu SignatureValue zawiera wyliczoną wartość podpisu elektronicznego dla treści


5

żądania Hi1.
Opcjonalne pole unsignedAttrs zawiera zbiór atrybutów, które nie są podpisywane.
Typ SignerInfo został opisany w [RFC3852], pkt 5.3
Algorytmy kryptograficzne
Algorytmy funkcji skrótu
Identyfikatory stosowanych algorytmów funkcji skrótu określone są w polu digestAlgorithms typu
SignedData oraz w polu digestAlgorithm typu SignerInfo. Alogorytmy funkcji skrótu, które muszą
być obsługiwane przez ADMF w celu zapewnienia możliwości wyliczenia skrótu na potrzeby
sprawdzenia podpisu elektronicznego zostały wyspecyfikowane w tabeli poniżej:

lp
Algorytm
Identyfikator obiektu OID
Dokument określający OID
.
1. SHA-1

{ iso(1) identified-organization(3)
[RFC3370]
(id-sha1)
oiw(14) secsig(3) algorithms(2) 26 }
[RFC4055]
2. SHA-224

{ joint-iso-itu-t(2) country(16) us(840) [RFC4055]
(id-sha224)
organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 4 }
3. SHA-256

{ joint-iso-itu-t(2) country(16) us(840) [RFC4055]
(id-sha256)
organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 1 }
4. SHA-384

{ joint-iso-itu-t(2) country(16) us(840) [RFC4055]
(id-sha348)
organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 2 }
5. SHA-512

{ joint-iso-itu-t(2) country(16) us(840) [RFC4055]
(id-sha512)
organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 3 }
6. RIPEMD-160
{ iso(1) identifiedOrganization(3)
http://homes.esat.kuleuven.be/~bosselae/r
(id-
teletrust(36) algorithm(3)
ipemd160.html
ripemd160)
hashAlgorithm(2) 1 }

http://www.teletrust.de/index.php?id=513
7. RIPEMD-256 { iso(1) identified-organization(3)
http://homes.esat.kuleuven.be/~bosselae/r
(id-
teletrust(36) algorithm(3)
ipemd160.html
ripemd256)
hashAlgorithm(2) ripemd256(3) }

http://www.teletrust.de/index.php?id=513

ADMF może posiadać zaimplementowaną obsługę dodatkowych algorytmów funkcji skrótu.
LEMF na potrzeby podpisów elektronicznych powinien stosować algorytm funkcji skrótu SHA-512
(rozwiązanie preferowane) lub inny algorytm z rodziny SHA-2 (SHA-384, SHA-256, SHA-224)
lub algorytm RIPEMD-256. Ze względu na znane słabości, algorytmu SHA-1 nie powinien być
wykorzystywany przez LEMF.
Algorytmy podpisu
Identyfikator stosowanego algorytmu podpisu jest określony w polu signatureAlgorithm typu
SignerInfo. Algorytmy podpisu, które muszą być obsługiwane przez ADMF w celu zapewnienia
możliwości sprawdzenia podpisu zostały wyspecyfikowane w tabeli poniżej:



6

lp
Algorytm
Identyfikator obiektu OID
Dokument
Długości klucza [bity]
.
określający
OID
1. RSA
{ iso(1) member-body(2) us(840)
[RFC3370]
1024, 2048, 4096
(rsaEncryptio
rsadsi(113549) pkcs(1) pkcs-1(1)
n)
1 }
2. DSA

{ iso(1) member-body(2) us(840)
[RFC3370]
1024, 2048, 4096
(id-dsa)
x9-57 (10040) x9cm(4) 1 }

ADMF może posiadać zaimplementowaną obsługę dodatkowych algorytmów podpisów.
LEMF na potrzeby podpisów elektronicznych powinien stosować algorytm podpisu RSA lub DSA
o długości klucza przynajmniej 2048 bitów (zalecany jest algorytm RSA lub DSA o długości klucza
4096 bitów).
Składanie podpisu
Podpis składany jest indywidualnie, przez uprawnionego użytkownika systemu LEMF. Użytkownik
ten wyposażony jest w indywidualną, imienną kartę inteligentną lub inny „komponent techniczny”.
Karta inteligentna jest nośnikiem klucza prywatnego oraz certyfikatu X.509 tego użytkownika.
Generowanie podpisu dla zadanej wiadomości (żądania Hi1) odbywa się na karcie inteligentnej.
Generowanie (wyliczanie) podpisu odbywa się w sposób określony w [RFC3852].
Każde żądanie HI1 z podpisem w formacie CMS (cmsDERSignedRequest) powinno zawierać
przynajmniej jeden poprawny podpis elektroniczny. Podpis ten powinien zawierać certyfikaty
X.509 i może zawierać listy CRL.
LEMF musi zapewnić, że certyfikat użytkownika, który podpisuje żądanie jest ważny w chwili
składania podpisu elektronicznego.
Sprawdzanie poprawności podpisu
Sprawdzenie poprawności podpisu żądania w HI1 odbywa się w ADMF i w sposób określony w
[RFC3852]. W szczególności ADMF weryfikuje całą ścieżkę certyfikacji pomiędzy certyfikatem
użytkownika LEMF, który złożył podpis i certyfikatem głównego urzędu ds. certyfikatów CA,
który jest w LEA.
Realizowane są tylko te żądania, które zawierają przynajmniej jeden poprawny podpis
elektroniczny. Sprawdzenie podpisu polega na znalezieniu pierwszego poprawnego podpisu
elektronicznego w strukturze CMS. Oznacza to w szczególności, że żądanie, które zawiera jeden
niepoprawny podpis elektroniczny (np certyfikat użytkownika stracił ważność) i jeden poprawny
podpis elektroniczny zostanie obsłużone.
Poprawność podpisu elektronicznego sprawdzana jest przez ADMF tylko raz, po otrzymaniu
podpisanego żądania Hi1.
ądania w HI1 muszą być podpisane przez użytkownika (certyfikat wystawiony na osobę fizyczną).
ądania podpisane przez urząd ds. certyfikatów nie są realizowane.
W przypadku braku możliwości stwierdzenia poprawności podpisu (np. z powodu braku
certyfikatu) podpis jest uznawany za niepoprawny i żądanie HI1 nie jest obsługiwane.
10/38si


7


Załącznik nr 6

1.Struktura pliku z wykazem połączeń abonenta telefonii stacjonarnej
Poniżej zamieszczona została struktura pliku XML proponowana jako format danych,
w którym przedsiębiorca telekomunikacyjny dostarczać powinien dane o usługach
telekomunikacyjnych realizowanych na rzecz abonenta sieci stacjonarnej.

<?xml version="1.0" encoding="ISO-8859-2" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<!-- definicja formatu numeru telefonu (maks. 18 cyfr) -->
<xs:simpleType name="t_numer">
<xs:restriction base="xs:string">
<xs:pattern value="[0-9]{1,18}"/>
</xs:restriction>
</xs:simpleType>

<!-- definicja formatu wykorzystywanej daty -->
<xs:simpleType name="t_data">
<xs:restriction base="xs:dateTime"/>
</xs:simpleType>

<!-- definicja formatu nazwy abonenta -->
<xs:simpleType name="t_nazwa">
<xs:restriction base="xs:string">
<xs:maxLength value="50"/>
</xs:restriction>
</xs:simpleType>

<!-- definicja formatu adresu i lokalizacji aparatu abonenta -->
<xs:simpleType name="t_adres">
<xs:restriction base="xs:string">
<xs:maxLength value="200"/>
</xs:restriction>
</xs:simpleType>

<!-- definicja formatu długosci połaczenia w sekundach-->
<xs:simpleType name="t_dlugosc">
<xs:restriction base="xs:nonNegativeInteger"/>
</xs:simpleType>

<!-- definicja formatu identyfikatora operatora ( 4lub 5 cyfr)-->
<xs:simpleType name="t_operator">
<xs:restriction base="xs:string">
<xs:pattern value="[0-9]{4,5}"/>
</xs:restriction>
</xs:simpleType>

<!-- definicja listy rodzajów połaczenia -->
<xs:simpleType name="t_lista_rodzajow">
<xs:restriction base="xs:string">
<xs:pattern value="audio|data|sms|faks"/>
</xs:restriction>
</xs:simpleType>