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

TCPInformation ::= SEQUENCE
{
sourcePort [0] OCTET STRING (SIZE (2))OPTIONAL,
destinationPort [1] OCTET STRING (SIZE (2))OPTIONAL,
sequenceNumber [2] OCTET STRING (SIZE (4))OPTIONAL,
ackNumber [3] OCTET STRING (SIZE (4))OPTIONAL,
dataOffset [4] BIT STRING (SIZE (4))OPTIONAL,
-- First 4 bits
controlBits [5] BIT STRING (SIZE (6))OPTIONAL,
-- Last 6 bits
windowSize [6] OCTET STRING (SIZE (2))OPTIONAL,
checkSum [7] OCTET STRING (SIZE (2))OPTIONAL,
urgentPointer [8] OCTET STRING (SIZE (2))OPTIONAL,
options [9] OCTET STRING (SIZE (0..40))OPTIONAL
}

UDPInformation ::= SEQUENCE
{
sourcePort [0] OCTET STRING (SIZE (2))OPTIONAL,
destinationPort [1] OCTET STRING (SIZE (2))OPTIONAL,
length [2] OCTET STRING (SIZE (2))OPTIONAL,
checkSum [3] OCTET STRING (SIZE (2))OPTIONAL
}

CCPayload ::= SEQUENCE
{
payloadDirection [0] PayloadDirection OPTIONAL,
timeStamp [1] GeneralizedTime OPTIONAL,
-- For aggregated payloads (see clause 6.2.3)
cCContents [2] CCContents,
...,
microSecondTimeStamp [3] MicroSecondTimeStamp OPTIONAL
-- For aggregated payloads (see clause 6.2.3)
}

PayloadDirection ::= ENUMERATED
{
fromTarget(0),
toTarget(1),
...,
indeterminate(2),
-- Indication whether intercepted CC was travelling to or from the target
-- or that the direction was indeterminate
combined(3),
-- Indication applicable to some services that the traffic is actually a combination
-- of To and From
notapplicable(4)
-- Indication that direction of interceptable service does not make sense
}

CCContents ::= CHOICE
-- Any of these choices may be commented out if they are not being used, see clause A.3
{
undefinedCC [0] OCTET STRING,
emailCC [1] EmailCC,
iPCC [2] IPCC,
uMTSCC [4] OCTET STRING,
eTSI671CC [5] OCTET STRING,
...,
l2CC [6] L2CC,
tTRAFFIC-1 [7] TS101909201.TTRAFFIC,
cTTRAFFIC-1 [8] TS101909201.CTTRAFFIC,
tTRAFFIC-2 [9] TS101909202.TTRAFFIC,
cTTRAFFIC-2 [10] TS101909202.CTTRAFFIC,
pstnIsdnCC [11] PstnIsdnCC,
iPMMCC [12] IPMMCC


7
}

MicroSecondTimeStamp ::= SEQUENCE
{
seconds [0] INTEGER (0..18446744073709551615),
-- number of seconds since 1970-1-1 00:00Z also known as unix time epoch
microSeconds [1] INTEGER (0..999999),
...
}

IPCC ::= SEQUENCE
{
iPCCObjId [0] RELATIVE-OID,
iPCCContents [1] IPCCContents
}

IPCCContents ::= CHOICE
{
iPPackets [0] OCTET STRING,
...
}



10/37si


8
Załącznik nr 5
Koncepcja Podpisu Elektronicznego
Wybrane żądania HI1, po ich przygotowaniu w LEMF, są podpisywane elektronicznie przez
użytkownika LEMF. Użytkownik do podpisu żądania wykorzystuje swój indywidualny klucz
prywatny oraz certyfikat X.509, który przyporządkowuje dane identyfikujące użytkownika do jego
klucza publicznego. Enkapsulowane żądanie HI1, wraz z podpisem elektronicznym jest przesyłane
do ADMF.
By ADMF mógł sprawdzić podpis elektroniczny żądania HI1 złożony przez użytkownika LEMF
konieczne jest by obie strony: LEMF i ADMF, wykorzystywały ten sam format (składnie) podpisu
elektronicznego. Formatem tym jest CMS (Cryptographics Message Syntax) zdefiniowany w
[RFC3852].
Podpisywanie żądania HI1 przez użytkownika LEMF jest możliwe pod warunkiem posiadania
przez niego indywidualnego klucza prywatnego oraz certyfikatu X.509. Również ADMF musi
posiadać pewną wiedzę o certyfikatach użytkowników LEMF, by móc sprawdzać poprawność
podpisów elektronicznych. Dla tego celu wykorzystuje się infrastrukturę klucza publicznego PKI.
Indywidualne certyfikaty X.509 użytkowników systemu LEMF są wystawiane przez CA (urząd ds.
certyfikatów) w instytucji, która administruje i użytkuje dany system LEMF. Certyfikat tego CA
jest jednocześnie dostępny w systemie ADMF administrowanego przez operatora. Zarządzanie
certyfikatami X.509, listami CRL oraz infrastrukturą klucza publicznego PKI zostało opisane w
osobnym punkcie.
Poniższy rysunek poglądowo przedstawia enkapsulowanie w HI1LEMFPDU struktury CMS
zawierającej treść żądania HI1 oraz podpis, zakodowane z wykorzystaniem DER
(cmsDERSignedRequest).


HI1LEMFPDU

Content
Request
SignedRequest
OCTET STRING -
struktura CMS
zakodowana DER
(cmsDERSignedRequest)

Rysunek 1: Enkapsulowanie podpisanego żądania HI1 w Hi1LEMFPDU

Poniższy rysunek poglądowo przedstawia enkapsulowanie żądania HI1 (Command) i jego podpisu
(SignatureValue) w cmsDERSignedRequest:


OCTET STRING -

struktura CMS
zakodowana DER
(cmsDERSignedRequest)
ContetnInfo
(SignedData)
EncapsulatedContentInfo
Data
UnsignedRequestDetail
Command
SignerInfo
SignatureValue

Rysunek 2: Enkapsulowanie żądania HI1 i jego podpisu w strukturze CMS

Wykorzystywane standardy
[RFC3852] Housley, R., „Cryptographic Message Syntax (CMS)”, RFC 3852, July 2004.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370,
August 2002.
[RFC3279] Bassham, L., Polk, W., R. Housley, "Algorithms and Identifiers for the Internet
X.509 Public Key Infrastructure Certificate and Certificate Revocation Lists
CRL Profile", RFC 3279, April 2002.
[RFC3280] Housley, R., Polk, T, Ford, W., Solo, D., "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC
3280, April 2002.
[RFC3281] Farrell, S., Housley, R., "An Internet Attribute Certificate Profile for
Authorization", RFC3281, April 2002.
[RFC4055] Housley, R., Kaliski, B., Schaad, J., "Additional Algorithms and Identifiers for
RSA Cryptography for use in the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June
2005.
[RFC3447] Jonsson, J., Kaliski, B., "Public-Key Cryptography Standards (PKCS) #1: RSA
Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3126] Pinkas D., Ross J., Pope N. "Electronic Signature Formats for long term
electronic signatures", RFC 3126, September 2001


2

Wiadomości przesyłane w Hi1, które wymagają podpisania
Następujące żądania, przesyłane z LEMF do ADMF, mogą i muszą być podpisane elektronicznie:
• activate,
• deactivate,
• modificate.
ądania te są polami wyboru typu Command:
Command ::= CHOICE
{
activate [1] Activate,
deactivate [2] Deactivate,
modificate [3] Modificate,
...
}

Pole command oraz pole time, które określa czas złożenia podpisu, wchodzą w skład typu
UnsignedRequestDetail:
UnsignedRequestDetail ::= SEQUENCE
{
time [1] TimeStamp,
command [3] Command,
...
}

Zawartość pola typu UnsignedRequestDetail wraz z podpisem tego pola jest zapisywane w
strukturze CMS.
Format podpisanego żądania Hi1
Na potrzeby podpisu elektronicznego stosuje się format Cryptographics Message Syntax (CMS)
zdefiniowany w [RFC3852]. Struktura CMS jest identyfikowana przez następujący OID:
CryptographicMessageSyntax2004 OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24) }.

Struktura CMS zapisywana jest, z wykorzystaniem kodowania DER, w polu
cmsDERSignedRequest typu SignedRequest:
SignedRequest ::= SEQUENCE
{
version
[1]
SignedRequestVersion,
signStandard
[2]
OBJECT
IDENTIFIER,
-- CryptographicMessageSyntax2004 { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)
cms-2004(24) }
cmsDERSignedRequest
[3] OCTET STRING
-- cmsDERSignedRequest
[3] ANY DEFINED BY signStandard
}
3