


  CORE Working Group                                           P. Urien 
  Internet Draft                                          Telecom Paris 
  Intended status: Experimental                              Ethertrust 
                                                                        
                                                          22 March 2026 
  Expires: September 2026 
 
                         Remote APDU Call Secure Lite(RACSL) 
                           draft-urien-core-racsl-00.txt 
 
Abstract 
    
   The Remote APDU Call Lite protocol (RACSL) is a lightweight version 
   of the Remote APDU Call Secure protocol (RACS). RACS is designed for 
   Grids of Secure Elements (GoSE), where servers host Secure Elements 
   (SEs), i.e., tamper-resistant chips providing secure storage and 
   cryptographic capabilities. It supports commands for GoSE inventory 
   and data exchange with secure elements. RACSL targets environments 
   hosting a limited number of secure element-typically one-within an 
   IoT device managed by a microcontroller. It provides commands for 
   data exchange with secure elements, in particular for managing their 
   embedded applications. These commands are transported over TLS 1.3 
   pre-shared key (PSK) sessions, which MAY be secured using a TLS 
   Identity Module (TLS-IM) application hosted within a secure element. 
   RACSL can be used to update TLS-IM applications or to remotely 
   access computing and storage resources hosted in secure elements. 
    
Requirements Language 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
   "OPTIONAL" in this document are to be interpreted as described in 
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
   capitals, as shown here. 
    
Status of this Memo 
    
   This Internet-Draft is submitted in full conformance with the 
   provisions of BCP 78 and BCP 79. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF).  Note that other groups may also distribute 
   working documents as Internet-Drafts. The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/. 
    
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
    
   This Internet-Draft will expire on September 2026. 
   . 

   Urien                     Expires September 2026        [Page 1] 


Copyright Notice 
    
   Copyright (c) 2026 IETF Trust and the persons identified as the 
   document authors.  All rights reserved. 
    
   This document is subject to BCP 78 and the IETF Trust's Legal 
   Provisions Relating to IETF Documents 
   (https://trustee.ietf.org/license-info) in effect on the date of 
   publication of this document. 
   Please review these documents carefully, as they describe your 
   rights and restrictions with respect to this document. Code 
   Components extracted from this document must include Revised BSD 
   License text as described in Section 4.e of the Trust Legal 
   Provisions and are provided without warranty as described in the 
   Revised BSD License. 
    
    
Table of Contents 
   Abstract........................................................... 1 
   Requirements Language.............................................. 1 
   Status of this Memo................................................ 1 
   Copyright Notice................................................... 2 
   1 Introduction..................................................... 3 
   2 Secure Elements in Network Node.................................. 4 
   3 RACSL Protocol................................................... 4 
      3.1 TLS1.3 with pre-shared-key.................................. 4 
      3.2 Server Name Indication...................................... 4 
      3.3 PSK identity................................................ 5 
   4 APDU Serialization............................................... 5 
      4.1 Poweron..................................................... 5 
      4.2 Send APDU................................................... 5 
      4.3 Poweroff.................................................... 5 
   5 IANA Considerations.............................................. 6 
   6 Security Considerations.......................................... 6 
   7 References....................................................... 6 
      7.1 Normative References........................................ 6 
      7.2 Informative References...................................... 6 
   8 Authors' Addresses............................................... 6 
 














   Urien                   Expires September 2026           [page 2] 
 
                      Remote APDU Call Secure Lite        March 2026 
 
1 Introduction 
    
   A Secure Element (SE) is a tamper-resistant microcontroller equipped 
   with host interfaces such as [ISO7816], SPI (Serial Peripheral 
   Interface), or I2C (Inter-Integrated Circuit) [GP-SPI-I2C]. 
    
   According to the [EUROSMART] association, nine billion such secure 
   devices were shipped in 2023. They are widely deployed for 
   electronic payment (EMV cards), telecommunications (SIM/USIM 
   modules), identity (electronic passports), ticketing, and access 
   control. 
    
   According to the [ISO7816] standards, secure elements process 
   ISO7816 request messages and return ISO7816 response messages, known 
   as APDUs (Application Protocol Data Units). 
    
   Four APDU cases are defined: 
    
   - Case 1: A request consists of four bytes (CLA, INS, P1, P2). The 
   response comprises two bytes (SW1, SW2). 
    
   - Case 2: A request consists of CLA, INS, P1, P2, and LE. The 
   response comprises LE bytes plus SW1 and SW2. Typically, LE length 
   (P3 = LE) is one byte; for extended APDUs, LE length is three bytes, 
   with the MSB (P3) set to zero. 
    
   - Case 3: A request consists of CLA, INS, P1, P2, LC, followed by LC 
   bytes. The response comprises two bytes (SW1, SW2). Typically, LC 
   length (P3 = LC) is one byte; for extended APDUs, LC length is three 
   bytes with the MSB set to zero. 
    
   - Case 4: A request consists of CLA, INS, P1, P2, LC, LC bytes, and 
   LE. The response comprises LE bytes plus SW1 and SW2. Typically, LC 
   length is one byte; for extended APDUs, LC length is three bytes 
   with the MSB set to zero, and LE length is two bytes. 
    
   APDUs are transported using protocols such as T=0, T=1, or T=CL 
   (contactless). 
    
   A set of GlobalPlatform [GP] standards controls the lifecycle of 
   embedded software within secure elements, including application 
   downloading, activation, and deletion. These standards rely on APDU 
   exchanges between the secure element and a loader entity. 
    
   According to [GP], applications stored in secure elements are 
   identified by an Application Identifier (AID), up to sixteen bytes 
   in length. 
    
    
    


   Urien                 Expires September 2026             [Page 3] 
 
                      Remote APDU Call Secure Lite        March 2026 
 
2 Secure Elements in Network Node 
    
   An Internet node MAY use one or several secure elements, typically 
   to provide trusted cryptographic services. The goal of the RACSL 
   (Remote APDU Call Secure Lite) protocol is to remotely manage and 
   update these applications. 
    
   The IETF draft [TLS-IM] defines an interface for a secure element 
   application that performs procedures associated with TLS 1.3 
   [RFC8446] in pre-shared key (PSK) mode, combined with Diffie-Hellman 
   key exchange over finite fields or elliptic curves (DHE or ECDHE), 
   hereafter referred to as TLS 1.3-PSK. 
    
   According to [GP], a TLS-IM application is identified by an AID. 
    
   An Internet node supporting TLS-PSK MAY use a TLS-IM application 
   stored within a secure element. According to [GP], an application 
   must be deleted before uploading a new version. Therefore, a secure 
   element MAY store two or more TLS-IM applications with different 
   AIDs. 
    
3 RACSL Protocol 
    
3.1 TLS1.3 with pre-shared-key  
    
   The RACSL protocol is based on TLS 1.3 [RFC8446] in pre-shared key 
   (PSK) mode with Diffie-Hellman key exchange (DHE or ECDHE). Multiple 
   PSK identities MAY be used, each associated with a PSK. 
    
    
   +-----------------+       +-----------+    +-----------+ 
   |      RACSL      |       |  TLS-IM1  |    |  TLS-IM3  | 
   +-----------------+       |    AID1   |    |    AID3   | 
   |   TLS1.3-PSK    |       |           |    |           | 
   +-----------------+       |  TLS-IM2  |    |   OTHER   | 
   |       TCP       |       |    AID2   |    |    AID    | 
   +-----------------+       +-----------+    +-----------+ 
   |       IP        |      Secure Element1  Secure Element2 
   +------------- ---+         ServerName1     ServerName2 
    
3.2 Server Name Indication 
    
   Each secure element is identified by a server name [RFC8446] 
   conveyed in the Server Name Indication (SNI) extension and included 
   in the ClientHello message. 
    
    
    
    
    


   Urien                 Expires September 2026             [Page 4] 
 
                      Remote APDU Call Secure Lite        March 2026 
 
3.3 PSK identity 
    
   In the RACSL context, a PSK identity is associated with an 
   Application Identifier (AID) bound to a TLS-IM application that 
   performs PSK-related procedures. 
   This AID SHALL NOT depend on the server name. When multiple secure 
   elements are available, a dedicated mechanism SHOULD be used to 
   select the secure element hosting the TLS-IM application used for 
   TLS-PSK session establishment. 
    
   +---------------+----------+ 
   | psk-identity1 |   AID1   | 
   | psk-identity2 |   AID2   | 
   | psk-identity2 [   AID3   | 
   +---------------+----------+ 
    
4 APDU Serialization 
    
   Once a TLS 1.3 session has been established, a secure element is 
   selected based on the server name. Three commands are available to 
   send APDUs. Each command is expressed as ASCII text terminated by 
   carriage return (CR) and line feed (LF) characters. 
    
4.1 Poweron 
    
   This command powers on the secure element associated with the server 
   name. 
    
   Syntax: on CR LF 
    
4.2 Send APDU 
    
   This command sends an APDU encoded in hexadecimal format (two 
   characters per byte). It returns a set of bytes encoded in 
   hexadecimal format. 
    
   Syntax: A [hexadecimal encoding] CR LF 
    
   Example:  
   >> A 00A4040006010203040700 (select aid=010203040700) 
   << 9000 (SW1=90, SW2=00) 
    
4.3 Poweroff 
    
   This command powers off the secure element associated with the 
   server name. 
    
   Syntax: off CR LF 
    
    


   Urien                 Expires September 2026             [Page 5] 
 
                      Remote APDU Call Secure Lite        March 2026 
 
5 IANA Considerations 
    
   This draft does not require any action from IANA. 
    
6 Security Considerations 
    
   This entire document is about security. 
    
7 References 
    
7.1 Normative References 
    
   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
   Requirement Levels", BCP 14, RFC 2119,DOI 10.17487/RFC2119, March 
   1997, <https://www.rfc-editor.org/info/rfc2119> 
    
   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 
   2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, 
   <https://www.rfc-editor.org/info/rfc8174>. 
    
   [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 
   Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 
   https://www.rfc-editor.org/info/rfc8446. 
    
   [ISO7816] ISO 7816, "Cards Identification - Integrated Circuit Cards 
   with Contacts", The International Organization for Standardization 
   (ISO). 
    
   [GP-SPI-I2C] GlobalPlatform Technology, APDU Transport over SPI/I2C 
   Version 0.0.0.39, July 2019 
    
7.2 Informative References 
    
   [EUROSMART] Eurosmart, https://eurosmart.com 
    
   [GP] Global Platform, https://globalplatform.org/ 
    
   [TLS-IM] "Identity Module for TLS Version 1.3", draft-urien-tls-im-
   10.txt, January 2024. 
    
   [RACS] "Remote APDU Call Secure (RACS)", draft-urien-core-racs-
   19.txt, February 2024 
    
8 Authors' Addresses 
    
   Pascal Urien 
   Telecom Paris - Ethertrust 
   19 place Marguerite Perey 
   91120 Palaiseau 
   France 
   Email: Pascal.Urien@telecom-paris.fr 

   Urien                 Expires September 2026             [Page 6] 
