EDIFACT message guide · Control and acknowledgments
KEYMAN Security key and certificate management
The UN/EDIFACT service message used to manage security keys and certificates, both symmetric and public or private keys.
- Sent by
- Trading partner or certification authority
- Received by
- Trading partner
- Standard
- UN/EDIFACT · Service message
- X12 equivalent
- No direct equivalent
What is the EDIFACT KEYMAN message?
KEYMAN is the UN/EDIFACT security key and certificate management message. It provides for the management of security keys and certificates. A key may be a secret key used with symmetric algorithms, or a public or private key used with asymmetric algorithms.
Secure EDI depends on both parties holding valid keys and certificates. KEYMAN lets them request, deliver, renew and revoke keys and certificates using the same infrastructure as their business messages, supporting security services such as those carried by AUTACK.
How to read this diagram: the top row shows who sends KEYMAN, to whom, and which messages usually come before and after it. The lower part shows what the directory D.21A itself requires: the envelopes around KEYMAN and the segments and segment groups it marks mandatory. Conditional groups are listed by their trigger segment rather than drawn in full. This is the directory's minimum, not a trading partner's requirement: a message implementation guide usually makes some conditional groups mandatory, restricts the codes and may use an older directory.
When it is used
- Exchanging public key certificates with a partner
- Renewing keys before expiry
- Revoking compromised keys or certificates
Where it fits in the message flow
Structure
Mandatory segments in KEYMAN (directory D.21A)
In UN/EDIFACT directory D.21A, the KEYMAN message has 13 segment positions arranged in 5 segment groups. These are the segments and segment groups marked mandatory at message level, in order; a mandatory group is shown with the segment that starts it. Segments inside conditional groups are needed only when the group is used. This is the directory’s requirement; earlier syntax versions define the message differently, and partners agree which version they use. This structure comes from one published copy of the directory and has not been independently verified: confirm it before you build a map.
- UNH
- UNT
Practical example
KEYMAN in practice
A corporate client's signing certificate for bank payments is due to expire. Its security system sends the bank a KEYMAN with the new certificate a month before expiry. The bank validates and registers it, and later AUTACK signatures are checked against the new certificate.
Implementation
Implementation considerations for KEYMAN
- Track certificate expiry dates and renew in advance.
- Verify new keys and certificates through a trusted channel.
- Revoke compromised keys and certificates immediately.
- Agree the certificate authorities both parties trust.
How ECOM helps
Automate KEYMAN with ECOM
Solution
B2B Integration
Connect every customer, supplier, carrier and bank across EDI, API, file and portal channels.
Solution
Managed File Transfer
Design, migrate and operate secure, auditable file exchange across partners and systems.
Industry
Financial Services
Secure file transfer and B2B integration for banks and financial institutions.
Compare X12 and EDIFACT, or see answers to general questions in the EDI FAQ.
Related messages
Related control and acknowledgments messages
Need help with KEYMAN?
ECOM maps, tests and monitors EDIFACT messages for your trading partners and integrates them with your ERP.