EldoS | Feel safer!

Software components for data protection, secure storage and transfer

TSL Verification

Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.
#14974
Posted: 11/08/2010 04:44:45
by Eugene Mayevski (Team)



Sincerely yours
Eugene Mayevski
#18716
Posted: 01/13/2012 10:48:12
by Eugene Mayevski (Team)

Can anybody please explain what should be done in this task?

TSLs are published in human-readable form which is not possible to handle.


Sincerely yours
Eugene Mayevski
#18723
Posted: 01/14/2012 14:34:10
by Karel Benák (Standard support level)
Joined: 03/16/2011
Posts: 13

For example Czech TSL is in machine processable XML form on URL http://tsl.gov.cz/publ/TSL_CZ.xtsl, EU TSL is in machine processable XML form on URL https://ec.europa.eu/information_society/policy/esignature/trusted-list/tl-mp.xml
#18724
Posted: 01/14/2012 15:04:31
by Eugene Mayevski (Team)

And what is "processable"? What does SecureBlackbox have to do with this?


Sincerely yours
Eugene Mayevski
#34255
Posted: 08/17/2015 11:56:23
by Nuno Pereira (Basic support level)
Joined: 08/17/2015
Posts: 3

Hi,
I'm just starting my adventures in the world of digital signatures, so I don't fully understand all of the concepts, but it seems to me that TSL is a signed document with a list of trusted authorities with their certificates (and policies?).
If I am understanding correctly the functionality provided by TSL, what SecureBlackbox could do with TSL is to allow to validate a certificate/signature using the authorities in the TSL instead of the Local machine Certificate Store (or as a complement).
I'm starting to work with digital signatures because of legal requirements for Digital Signatures on some operations/documents and in some countries (Brazil for example) the certificates used should be validated with a custom list of Root CA and allow only the use of certificates that have one of these root CA in the top of the chain.
Portugal also publishs the TSL in xml (probably all countries in the EU should do this).

Does SecureBlackbox has support for TSL?

thanks,
Nuno Pereira
#34256
Posted: 08/17/2015 12:09:25
by Eugene Mayevski (Team)

1) SecureBlackbox has the XML parser which you can use to process the particular TSL.
2) You can use any custom list of trusted ROOT or CA certificates when validating a certificate.

The problem with automated TSL handling is that they seem to have different formats for each TSL (or for each country), so we can't parse them easily ourselves.


Sincerely yours
Eugene Mayevski
#34387
Posted: 09/07/2015 13:10:38
by Nuno Pereira (Basic support level)
Joined: 08/17/2015
Posts: 3

Hi,

So if I understand correctly your suggestion is to parse the XML to create a list of certificates and supply the certificate list to SecureBlackbox trusted ROOT or CA lists.Is this correct?
Will SecureBlackbox XML parser offer some advantage over the standard .NET XML parser in accomplishing this task?
(I was hoping for an easier way to do this, but I guess we’ll have to do this)

Anyway, in this case it seems to me that this is an EU standard as all the TSL that I’ve found from EU member countries uses the same format, but it makes sense that a standard should be created to all TSLs around the world: It would make all our lives easier (at least my life would be easier).

Thanks,
Nuno Pereira
#34388
Posted: 09/07/2015 13:54:25
by Eugene Mayevski (Team)

Quote
Nuno Pereira wrote:
So if I understand correctly your suggestion is to parse the XML to create a list of certificates and supply the certificate list to SecureBlackbox trusted ROOT or CA lists.Is this correct?


Yes, almost. SecureBlackbox doesn't have "trusted root or CA lists", instead you pass the certificates you want to use or to trust to TElX509CertificateValidator when you use it for validation. But you got the idea right.

Quote
Nuno Pereira wrote:
Will SecureBlackbox XML parser offer some advantage over the standard .NET XML parser in accomplishing this task?


In case of .NET there's no particular difference.

Quote
Nuno Pereira wrote:
Anyway, in this case it seems to me that this is an EU standard as all the TSL that I’ve found from EU member countries uses the same format


Indeed I have found the specifications that describe the XML format (see https://www.eldos.com/sbb/wishlist.php?vox_idea_id=154 for references). It's possible that we'll implement some kind of parser in future.


Sincerely yours
Eugene Mayevski
#38802
Posted: 03/07/2017 08:04:55
by Peter Rybar (Standard support level)
Joined: 10/04/2013
Posts: 2

http://www.nbu.gov.sk/en/trust-services/trusted-list/index.html

TL in a machine processable form
http://ep.nbusr.sk/kca/tsl/tsl.xml

TL can be also extended with
Documentation of TL X.509 XML Scheme for Trusted List (pdf, 497kB)
http://ep.nbusr.sk/kca/tsl/tlX509XMLSchemaDocumentation.pdf

The extension URLContentTypeAndAuthorizedServiceList is not specified in TS 119 612 v2.1.1 and
therefore it is specified in this document and shall be included in "Service information extensions" specified
in TS 119 612 v2.1.1 Clause 5.5.9. It specifies, in the form suitable for automated (machine) processing,
additional information on one or more URLs where relying parties can obtain the service tokens issued by
this service or the service tokens issued by another service authorized by this service e.g. indirect CRL or
OCSP response. See Clause 7.10 of ITU-T Rec. X.509 or ISO/IEC 9594-8: "The revocation and a
notification of the revocation may be done directly by the same authority that issued the certificate, or
indirectly by another authority duly authorized by the authority that issued the certificate."
The content of the URL element of URLContentTypeAndAuthorizedService element can be included in the
element specified in TS 119 612 v2.1.1 Clause 5.5.7 "Service supply points" element.
The ContentType element of the URLContentTypeAndAuthorizedService element contains Content-Type of
data/protocol provided at URL address in the form defined in Section 3.1.1.5 IETF RFC 7231 for
identification of data in the form which is suitable for automated (machine) processing. If the ContentType
element is empty, the content on the URL address will provide only human readable information
inconvenient for the machine processing.
When the AuthorizedService element is included in the URLContentTypeAndAuthorizedService element
then TLServiceIdentifier element contains the service identifier of the other service (or only the TL issuer
Country Code part and the other service certificate is stored in the TLServiceX509Certificate element) as a
link (shortcut) ensuring that the other service was explicitly authorized by this service for providing the
information on tokens issued by this service on the URL address specified in this URL field. The
AuthorizedService element shall be included only in case when the URL address is pointing to the other
service, e.g. when this service certificate expires, but the status of the issued token must be also provided
after the service certificate expiration (see Article 24(4) of Regulation (EU) No 910/2014 "This information
shall be made available at least on a per certificate basis at any time and beyond the validity period of the
certificate in an automated manner that is reliable, free of charge and efficient.").
The service identifier of the other service included in TLServiceIdentifier element consists of two forms: The
first form of the TL service identifier is "TLIxx-y" and the second form is "TLIxx-", where "xx" is the TL
issuer’s Country Code (see 5.1.5 TS 119 612 v2.1.1).
The form "TLIxx-y" is used only when the value of
'TLServiceIdentifier' field of the service digital identifier is assigned by the TLSO in the TL sub-element
"Other" of the element "Service digital identity" specified in TS 119 612 v2.1.1 Clause 5.5.3 and contains
data in the "TLIxx-y" form.
When "TLIxx-" form is used in TLServiceIdentifier element then the element TrustAnchor must contain
TLServiceX509Certificate element and can also contain optional ExplicitAcceptablePolicySet element or
pathLenConstraint element as a subset of
Trust Anchor Format RFC 5914
fields to achieve simplification
and interoperability when the trusted list is used.
The element notBefore of the AuthorizedService element contains the date and the time from which the
period of the other authorized service starts.
The optional element notAfter of the AuthorizedService element is present only when the end of the period,
in which the other service is authorized by this service, is known.
The change of the URLContentTypeAndAuthorizedServiceList extension does not affect the status of the
trusted list service and therefore it is not necessary to move the actual fields of the service to the history.
Summary:
The URL address points to the tokens issued by this service or to the tokens issued by the other service,
which is authorized to take over some parts of this service, e.g. the other service is issuing verification
tokens (indirect CRL or OCSP responses) for certificates issued by this service. When the other service of
this TL or the service of another Member State's TL is authorized by this service to provide services related
to this service, it shall be indicated by the presence of the AuthorizedService element.
The
AuthorizedService element contains in TLServiceIdentifier element:
1. the TL service identifiers 'TLIxx-y' as the value included in the 'TLServiceIdentifier' element in "Other"
element of the 'Service digital identities' (see 5.5.3 TS 119 612 v2.1.1) or
2. when the 'TLServiceIdentifier' element is not present in "Other" element of the 'Service digital identities'
(see 5.5.3 TS 119 612 v2.1.1) then TLServiceIdentifier element contains 'TLIxx-' where "xx" is the TL issuer
Country Code and in the TLServiceX509Certificate element is X.509 certificate of the authorized service.
NOTE: When this service is the 'certificates creation' service (as defined in Regulation (EU) No 910 2014),
this service must store certificates and its certificate status in the database, managed by this service (see
Article 24(3) of Regulation (EU) No 910 2014). The certificate status in the form of the verification tokens
(like indirect CRL or OCSP responses) is provided from the database of this service by this service or by
other service which was authorized to do it by this service.
EXAMPLES of the Content-Type of data/protocol provided by URL:
(Content-Type: text/html;charset=utf-8),
(Content-Type: application/ocsp-request)
URL of OCSP protocol for OCSP request for information ".ORQ",
(Content-Type: application/ocsp-response)
One pre-produced cryptographically signed response ".ORS"
e.g. for TLS server certificate,
(Content-Type: application/pkix-crl)
One CRL ".crl",
(Content-Type: application/pkix-cert)
One certificate ".cer",
(Content-Type: application/pkcs7-mime)
Certificates stored in CMS ".p7c" (for a degenerate SignedData see
IETF RFC 5751),
(Content-Type: application/timestamp-query)
URL for the time-stamp request in the ASN.1 DER-encoded
Time-Stamp message ".TSQ" (see IETF RFC 3161) .
#38803
Posted: 03/07/2017 08:25:42
by Eugene Mayevski (Team)

Peter, thank you very much for the information.

The problem is that we provide a universal tool for a wide range of customers worldwide. It is not feasible for us as a business to create country-specific TSL parsers. However, I might have a custom private offer for you in regards to this specific task. I will get back to you with this offer within 2 days.


Sincerely yours
Eugene Mayevski
Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.

Reply

Statistics

Topic viewed 9749 times

Number of guests: 2, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!