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 the EDIFACT KEYMAN message worksDiagram of the UN/EDIFACT KEYMAN Security key and certificate management message. Trading partner or certification authority sends it to trading partner. It usually starts the exchange. It is usually followed by AUTACK. Inside the UNB and UNH envelopes, the directory D.21A requires, in the . 2 conditional segment groups are listed by their trigger segment.How the EDIFACT KEYMAN message worksSecurity key and certificate management: who sends it, where it fits and what the directory marks mandatory1 WHERE IT FITSUSUALLY FOLLOWSStarts the exchangeKEYMANSENDERTrading partner orcertification authorityRECEIVERTrading partnerUSUALLY FOLLOWED BYAUTACKSecure authenticationand acknowledgement2 WHAT DIRECTORY D.21A REQUIRESInterchange: sender and recipient IDsUNB … UNZMessage KEYMANUNH … UNTBODY AND SEGMENT GROUPS+ 2 conditional groups, starting with:USEUSLBlue box: mandatory segment group. Conditional groups are listed by the trigger segment that starts them; a group is sent only when its data applies.Conditional segments outside groups are not drawn.Structure: mandatory segments and groups in the UN/EDIFACT directory D.21A listing for KEYMAN. Your trading partner's implementation guide adds itsown requirements.
How the EDIFACT KEYMAN message worksDiagram of the UN/EDIFACT KEYMAN Security key and certificate management message. Trading partner or certification authority sends it to trading partner. It usually starts the exchange. It is usually followed by AUTACK. Inside the UNB and UNH envelopes, the directory D.21A requires, in the . 2 conditional segment groups are listed by their trigger segment.How the EDIFACT KEYMANmessage worksSecurity key and certificate management: whosends it, where it fits and what the directorymarks mandatory1 WHERE IT FITSUSUALLY FOLLOWSStarts the exchangeKEYMANSENDERTrading partneror certificationauthorityRECEIVERTrading partnerUSUALLY FOLLOWED BYAUTACKSecure authentication andacknowledgement2 WHAT DIRECTORY D.21A REQUIRESInterchange: sender and recipient IDs(UNB … UNZ)Message KEYMAN (UNH … UNT)BODY AND SEGMENT GROUPS+ 2 conditional groups, starting with:USEUSLBlue box: mandatory segment group. Conditionalgroups are listed by the trigger segment thatstarts them; a group is sent only when its dataapplies. Conditional segments outside groups arenot drawn.Structure: mandatory segments and groups in theUN/EDIFACT directory D.21A listing for KEYMAN.Your trading partner's implementation guide adds itsown requirements.

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.

Expand diagram Download SVG

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

This message KEYMAN Security key and certificate management

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.

Related messages

Related control and acknowledgments messages

All 4 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.