CertPub Publisher 1.0 Signing

Abstract

Business Certificate Publisher (BCP) Signing Interface Extension 1.x is an extension to BCP 1.x where certificate owners may use a BCP service to publish in a structured manner in which processes the individual certificate may be recognized when used for signatures.

This specification and the described functionality is an addition to qualities part of signatures, and is not a replacement of advanced signatures (e.g. AdES), certificate revocation lists (CRL), Online Certificate Status Protocol (OCSP) or other measures related to signatures in the individual domain where signatures are used.

Changelog

Version 1.0.0, 2019-MM-DD

Issue Description

None

Initial document.

1. Definitions

Business Cerficiate Publisher (BCP)

BCP is the service providing structured information about certificate(s) used in individual processes (e.g. business document exchange). This service is extended by this specification.

Business Certificate Locator (BCL)

BCL is the service used to discover the BCP service used by a particular participant. BCL is not further described in this spesification.

Process

A structed exchange of information between two parties with a clear start and end. In the case of exchange between more than two parties is the process split into multiple processes between two parties.

Process identifier

Each process is identified by a URN and a qualifier. Those identifiers and their qualifiers are distributed separatly.

Role

Role identifies the role of a each of the parties taking part in information exchange in a process. A role is either REQUEST identifying the party receiving the first message in the exchange, or RESPONSE identifying the other party.

Party

Organization or some unit of an organization taking part in information exchange where PKI certificates are used as part of security measures.

Participant identifier

Identification of a pary part of information exchange. Identifiers are based upon ISO6523 and their registered International Code Designators (ICD). Example of identifier for a Norwegian organization number: 0192:991825827.

Participant identifier qualifier

Participant identifiers are qualified to recognize the use of ICDs and known issuers. The identifier iso6523-actorid-upis is used for this purpose.

Interval

A period defined by start time and end time to the second where a certificate is used as part of a combination of process and role. Each period is recorded for later verification.

Signature

Some kind of signature where PKI certificates are used to generate and verify the signature. Signature is used for integrity control and verification of source.

2. Introduction

Publishing of certificates used for signing is the next logical step after introducing Business Certificate Publisher (BCP) to publish certificates used for encryption of content.

Use of encryption in combination of PKI requires some kind of distribution effort and routines by both sender and receiver to be able to send encrypted content. Introduction of BCP for encryption certificates made it possible to use a generic interface to fetch the certificate for use in the specific information exchange without any activities upfront.

Exchange of certificates used for signing requires the same distribution effort and routines as certificates used for encryption. On the other hand will signature certificates also require information about which certificate was used at a the time of signing, rather than the certificate currently in use.

This specification describes the interface used to publish certificates used for signing and routines to be implemented by clients.

3. Use case

3.1. Avoiding fake orders

Description

To avoid handling of fake orders are all orders signed using a PKI certificate and the certificate used is verified towards the certficiate whitelist of each customer.

Roles

Customer, Supplier

Assumtions

  • Customer is known to Supplier by e.g. a contract.

  • Customer and Supplier has not exchanged certificates upfront.

  • The ordering process is a known process with necessary identification of the parties and the process itself.

Flow

  1. Supplier receives a new order sent by Customer.

  2. Customer is recognized by the handling system of Supplier.

  3. The signature attached to the order is verified successfully and verifies the integrity of the order and the certificate used is extracted.

  4. Supplier looks up in the BCP service which certificates was activated by Customer for signing of orders at the time of signing, effectively a whitelist of zero or more certificates.

  5. Supplier verifies the certificate used for signing of order is part of the whitelist received from the BCP service.

Result

Supplier will continue processing of order if the certificate is successfully validated towards the whitelist, otherwise will all handling of the order stop.

4. Responsibilities

4.1. Responsibilities of BCP service

Registration in BCL

When BCP service runs in a configuration with BCL is the BCP service provider responsible for registrion of the participant in the BCL service. This BCP extension inherits the same BCL service identifier as for the BCP 1.x specification.

Validation of certificates

All certificates used for signatures must be validated before made available in the publisher. All certificates registered to one or more processes must be validated towards the relevant CRL/OCSP service minimum every 24 hours.

Automatic disabling

When a certificate fail validation must the BCP service remove the certificate from active use.

  • Expired certificate - End the current interval at the time of expiration. Reenabling in the service is not possible.

  • Suspended certificate - End the current interval at the time of suspension or when suspension is detected. May be reenabled in the service upon request from the customer.

  • Revoced certificate - End the current interval at the time of revocation or when revocation is detected. Reenabling is the service is not possible.

4.2. Responsibilities of BCP client

Validation of certificates

All certificates verified towards the BCP whitelist must be validated independent of the BCP whitelist. Use of BCP for certificates for signatures is simply an addition to other validations and quality measures.

Handling responses

All responses must be verified according to the steps outlined for each lookup type. Even when using a shorthand API path must the default values be validated.

Caching

Clients are free to perform caching of the response accoring to the agreements within the particular business domain. Caching of date specific responses is encouraged as long as the UTC date is older than the current UTC date.

5. Supported lookups

BCP is inspired by OASIS BDXR SMP, and support two requests for lookup; list of supported profiles for a given particiapnt and certificates for a combination of participant, process and role.

5.1. General

5.1.1. Addressing the BCP service

Lookups are performed in the context of the BCP service. In the case of BCP not running as root application for the hostname is URL paths defined by BCP to be applied to the BCP context. BCP context is in a distibuted setup received from the BCL.

Table 1. Example 1

API path

api/v1/sig/[..]

BCP context
(from BCL response)

https://bcp.example.com/

Request URI

https://bcp.example.com/api/v1/sig/[..]
Table 2. Example 2

API path:

api/v1/sig/[..]

BCP context
(from BCL response)

https://example.com/bcp/

Request URI

https://example.com/bcp/api/v1/sig/[..]

5.1.2. Values in paths

Values in paths must be urlencoded when replacing value holders described in this document. Service implementations are free to support non-encoded values; however, client implementations must implement with encoding of values. Any other parts of the URL are not subject to encoding.

Table 3. Value holders and their values

Value holder

Value

Example

[ParticipantID]

Participant identifier qualifier + :: + Participant identifier

iso6523-actorid-upis::9908:910076787

[ProcessID]

Process identifier qualifier + :: + Process identifier

busdox-procid-ubl::urn:www.cenbii.eu:profile:bii05:ver2.0

[RoleID]

REQUEST or RESPONSE

REQUEST

[Date]

Pattern: YYYY-MM-DD

2019-09-01

5.1.3. Date and time

All dates and timestamps must be expressed according to UTC.

5.1.4. Allowed HTTP codes

Clients is expected to handle HTTP codes per the list below.

HTTP Code Description

200

Content available.

3xx

Not in use

404

No content found for the lookup.

5xx

Error in the service, try again later.

5.1.5. HTTPS and signed responses

It is recommended to provide BCP using HTTPS. BCP services must use the included XML Signature (XMLDsig) for integrity of the response.

5.2. List of supported processes

API path

api/v1/sig/[ParticipantID]

Supported methods

GET

Response element

Participant

5.2.1. Creating response

  1. All currently supported combinations of process identifiers and roles are listed.

  2. Responses are always signed by the BCP service certificate.

5.2.2. Response

<?xml version="1.0" encoding="UTF-8" ?>
<Participant xmlns="urn:fdc:difi.no:2019:bcp:v1:signing"> <!--(1)-->
  <ParticipantIdentifier qualifier="iso6523-actorid-upis">9908:910076787</ParticipantIdentifier> <!--(2)-->
  <Timestamp>2019-09-01T15:00:00Z</Timestamp> <!--(3)-->
  <ProcessReference qualifier="cenbii-procid-ubl" role="REQUEST">urn:fdc:peppol.eu:poacc:bis:ordering:3</ProcessReference> <!--(4)-->
  <ProcessReference qualifier="cenbii-procid-ubl" role="RESPONSE">urn:fdc:peppol.eu:poacc:bis:ordering:3</ProcessReference> <!--(4)-->
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">[...]</Signature>
</Participant>

  1. Root element of the participant response.

  2. Participant identifier identifying the party.

  3. The timestamp of creation of the response.

  4. One or more process identifiers and roles identifying supported processes.

5.2.3. Verification of response

Before trusting the response, the following steps must be done by the client:

  1. Validate signature of the response.

  2. Verify certificate used for signing towards known whitelist.

  3. Verify participant identifier is equal to the one requested.

5.3. Certificate whitelist

API path

api/v1/sig/[ParticipantID]/[ProcessID](/[RoleID])(/[Date])

Supported methods

GET

Response element

Process (with Date)

Default values

[RoleID] - REQEST
[Date] - Current date in UTC

5.3.1. Creating response

  1. A response is always generated if the combination of process and role is currently or previously suppored.

  2. HTTP code 404 is returned if the combination of process and role is currently or previously not supported.

  3. Default values are provided even when the value is not part of the requested path.

  4. Intervals relevant to the requested date is listed. If the certificate was enable e.g. in the morning and in the evening separatly must both be listed.

  5. Intervals are always explicitly provided with the actual timestamps and not timestamps relevant to the requested datde.

  6. Intervals still active is provided without to timestamp.

  7. Responses are always signed by the BCP service certificate.

5.3.2. Response

<?xml version="1.0" encoding="UTF-8" ?>
<Process xmlns="urn:fdc:difi.no:2019:bcp:v1:signing"> <!--(1)-->
  <ParticipantIdentifier qualifier="iso6523-actorid-upis">9908:910076787</ParticipantIdentifier> <!--(2)-->
  <ProcessIdentifier qualifier="cenbii-procid-ubl">urn:fdc:peppol.eu:poacc:bis:ordering:3</ProcessIdentifier> <!--(3)-->
  <Role>REQUEST</Role> <!--(4)-->
  <Date>2019-09-01</Date> <!--(5)-->
  <Certificate serialNumber="4567890973354"> <!--(6)-->
    <Binary> <!--(7)-->
      MIIJZzCCCE+gAwIBAgIQVyH9xTZ0aC1DIaI0Zqc1ujANBgkqhkiG9w0BAQsFADCB
      kjELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
      A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxODA2BgNV
      BAMTL0NPTU9ETyBSU0EgRXh0ZW5kZWQgVmFsaWRhdGlvbiBTZWN1cmUgU2VydmVy
      IENBMB4XDTE4MDYyMDAwMDAwMFoXDTIwMDYxOTIzNTk1OVowggFDMRIwEAYDVQQF
      Ewk5OTE4MjU4MjcxEzARBgsrBgEEAYI3PAIBAxMCTk8xFTATBgsrBgEEAYI3PAIB
      ARMET3NsbzEdMBsGA1UEDxMUUHJpdmF0ZSBPcmdhbml6YXRpb24xCzAJBgNVBAYT
      5oEMrhtx5dcFV745w/QhJAqeVri61vswDQYJKoZIhvcNAQELBQADggEBAAEZInvO
      ...
      HU+wdyN2lZase7tw6nYETfuNQAlrfQZ0G59jB1GA4lyT7qWnyC6cGEuc8EdGxRt/
      EcLMC7R9rLNA9sx+Ysh9vPj84rrG39WZ0DFMloEjlcbsxJ5ezVsqj0a356AbrMI/
      1OdC0XIL7U4g//3detq151BGooi1zQ/FeRWi4dlC7j9OzyKNbGV+WbjCmIFQnPZs
      mK4TbTm0rKD5dW3FJNuB0cVM/hiFG8dN13vClTIVwje1JxKPtOwcXW3t1xUbdvZ9
      dnK7aHRw0wf5oNSXG8lE1B/X449POspXEQjn0HbfkCJ6Fs1bywIEQzQOHdBGlmsk
      lqIUwrWEfwtCjpc=
    </Binary>
    <Interval from="2019-05-01T12:34:00Z"/> <!--(8)-->
  </Certificate>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">[...]</Signature>
</Process>

  1. Root element of the process response.

  2. Participant identifier identifying the party.

  3. Process identifier identifying the process.

  4. Role identifier.

  5. The date of which the response is for.

  6. Zero or more certificate listings identified by certificate serial number.

  7. The complete certificate.

  8. One or more intervals of when the certificate is valid at the requested date.

5.3.3. Verification of response

Before trusting the response, the following steps must be done by the client:

  1. Validate signature of the response.

  2. Verify certificate used for signing towards known whitelist.

  3. Verify participant identifier is equal to the one requested.

  4. Verify process identifier is equal to the one requested.

  5. Verify the role identifier is equal to the one requested.

  6. Verify the date is equal to the one requested.

5.4. Historic list of supported processes

API path

api/v1/sig/historic/[ParticipantID]

Supported methods

GET

Response element

Participant

5.4.1. Creating response

  1. All historically supported combinations of process identifiers and roles are listed.

  2. Responses are always signed by the BCP service certificate.

5.4.2. Response

<?xml version="1.0" encoding="UTF-8" ?>
<Participant xmlns="urn:fdc:difi.no:2019:bcp:v1:signing"> <!--(1)-->
  <ParticipantIdentifier qualifier="iso6523-actorid-upis">9908:910076787</ParticipantIdentifier> <!--(2)-->
  <Timestamp>2019-09-01T15:00:00Z</Timestamp> <!--(3)-->
  <ProcessReference qualifier="cenbii-procid-ubl" role="REQUEST">urn:fdc:peppol.eu:poacc:bis:ordering:3</ProcessReference> <!--(4)-->
  <ProcessReference qualifier="cenbii-procid-ubl" role="RESPONSE">urn:fdc:peppol.eu:poacc:bis:ordering:3</ProcessReference> <!--(4)-->
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">[...]</Signature>
</Participant>

  1. Root element of the participant response.

  2. Participant identifier identifying the party.

  3. The timestamp of creation of the response.

  4. One or more process identifiers and roles identifying supported processes.

5.4.3. Verification of response

Before trusting the response, the following steps must be done by the client:

  1. Validate signature of the response.

  2. Verify certificate used for signing towards known whitelist.

  3. Verify participant identifier is equal to the one requested.

5.5. Historic certificate whitelist

API path

api/v1/sig/historic/[ParticipantID]/[ProcessID](/[RoleID])

Supported methods

GET

Response element

Process (with Timestamp)

Default values

[RoleID] - REQEST

5.5.1. Creating response

  1. A response is always generated if the combination of process and role is currently or previously suppored.

  2. All intervals related to the certificates listed is provided.

  3. Intervals are always explicitly provided with the actual timestamps.

  4. Intervals still active is provided without to timestamp.

  5. Responses are always signed by the BCP service certificate.

5.5.2. Response

<?xml version="1.0" encoding="UTF-8" ?>
<Process xmlns="urn:fdc:difi.no:2019:bcp:v1:signing"> <!--(1)-->
  <ParticipantIdentifier qualifier="iso6523-actorid-upis">9908:910076787</ParticipantIdentifier> <!--(2)-->
  <ProcessIdentifier qualifier="cenbii-procid-ubl">urn:fdc:peppol.eu:poacc:bis:ordering:3</ProcessIdentifier> <!--(3)-->
  <Role>REQUEST</Role> <!--(4)-->
  <Timestamp>2019-09-01T15:00:00Z</Timestamp> <!--(5)-->
  <Certificate serialNumber="4567890973354"> <!--(6)-->
    <Binary> <!--(7)-->
      MIIJZzCCCE+gAwIBAgIQVyH9xTZ0aC1DIaI0Zqc1ujANBgkqhkiG9w0BAQsFADCB
      kjELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
      A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxODA2BgNV
      BAMTL0NPTU9ETyBSU0EgRXh0ZW5kZWQgVmFsaWRhdGlvbiBTZWN1cmUgU2VydmVy
      IENBMB4XDTE4MDYyMDAwMDAwMFoXDTIwMDYxOTIzNTk1OVowggFDMRIwEAYDVQQF
      Ewk5OTE4MjU4MjcxEzARBgsrBgEEAYI3PAIBAxMCTk8xFTATBgsrBgEEAYI3PAIB
      ARMET3NsbzEdMBsGA1UEDxMUUHJpdmF0ZSBPcmdhbml6YXRpb24xCzAJBgNVBAYT
      5oEMrhtx5dcFV745w/QhJAqeVri61vswDQYJKoZIhvcNAQELBQADggEBAAEZInvO
      ...
      HU+wdyN2lZase7tw6nYETfuNQAlrfQZ0G59jB1GA4lyT7qWnyC6cGEuc8EdGxRt/
      EcLMC7R9rLNA9sx+Ysh9vPj84rrG39WZ0DFMloEjlcbsxJ5ezVsqj0a356AbrMI/
      1OdC0XIL7U4g//3detq151BGooi1zQ/FeRWi4dlC7j9OzyKNbGV+WbjCmIFQnPZs
      mK4TbTm0rKD5dW3FJNuB0cVM/hiFG8dN13vClTIVwje1JxKPtOwcXW3t1xUbdvZ9
      dnK7aHRw0wf5oNSXG8lE1B/X449POspXEQjn0HbfkCJ6Fs1bywIEQzQOHdBGlmsk
      lqIUwrWEfwtCjpc=
    </Binary>
    <Interval from="2019-05-01T12:34:00Z"/> <!--(8)-->
  </Certificate>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">[...]</Signature>
</Process>

  1. Root element of the process response.

  2. Participant identifier identifying the party.

  3. Process identifier identifying the process.

  4. Role identifier.

  5. The timestamp of creation of the response.

  6. Zero or more certificate listings identified by certificate serial number.

  7. The complete certificate.

  8. One or more intervals of when the certificate is valid at the requested date.

5.5.3. Verification of response

Before trusting the response, the following steps must be done by the client:

  1. Validate signature of the response.

  2. Verify certificate used for signing towards known whitelist.

  3. Verify participant identifier is equal to the one requested.

  4. Verify process identifier is equal to the one requested.

  5. Verify the role identifier is equal to the one requested.

  6. Verify the timestamp is withing the last 24 hours.

Appendix A: XSD files (normative)

The following XSD files are part of this spesification: