Una de las dudas más comunes cuando alguien evalúa implementar firma electrónica en México es esta:

“¿Necesito NOM-151 para que mi firma sea válida?”

La respuesta corta es: no.
Y asumir que sí es uno de los errores más comunes al diseñar soluciones de firma electrónica en México.

Entender por qué es clave para construir una implementación sólida.

1. ¿Qué es la NOM-151 realmente?

La NOM-151 es una norma que regula la conservación de mensajes de datos.

En términos simples, sirve para:

• Garantizar que un documento no ha sido alterado a partir del momento de la emisión de la constancia.
• Proporcionar una fecha cierta

Es decir: protege la integridad del documento, no el proceso de firma.

Si quieres entenderla a detalle, puedes ver esta explicación completa:
https://blog.mifiel.com/nom-151/

2. Entonces… ¿la NOM-151 valida una firma electrónica?

No.

La NOM-151 no valida, no certifica y no “legaliza” una firma electrónica.

Esto significa que:

• No importa si tienes NOM-151
• Si tu proceso de firma está mal implementado, sigue siendo débil legalmente

3. ¿Qué hace válida una firma electrónica en México?

La validez de una firma electrónica depende de que cumpla con el Código de Comercio (principalmente artículos 89 al 97).

En la práctica, necesitas poder demostrar:

• Quién firmó (identidad)
• Que la persona aceptó el contenido (consentimiento)
• Que el documento no fue alterado después (integridad)
• Evidencia del proceso (trazabilidad)

Si quieres profundizar en cómo diseñar y verificar esta evidencia, puedes ver este artículo:
https://blog.mifiel.com/diseno-tecnico-verificacion-evidencia-digital/

Esto es completamente independiente de la NOM-151.

4. Entonces, ¿para qué sirve la NOM-151?

La NOM-151 entra después de la firma.

Su función es “sellar” el documento para probar que no ha cambiado desde cierto momento en el tiempo.

Piensa en esto como:

• Firma electrónica → crea el acuerdo
• NOM-151 → protege el documento en el tiempo

5. Un error común (muy importante)

Error común:
“Si tengo NOM-151, mi firma ya es válida”

Realidad:
La NOM-151 no valida la firma.
Solo certifica que el documento se ha mantenido íntegro en el tiempo.

Y hay un riesgo importante:

• Si el proceso de firma es débil
• Y lo “certificas” con NOM-151

Estás congelando un documento con evidencia deficiente.

6. ¿Qué tipos de firma puedes implementar?

Existen distintos mecanismos para manifestar voluntad en un entorno digital:

• Firma electrónica simple (ej. clic, OTP)
• Firma autógrafa en pantalla (dedo o stylus)
• Firma electrónica avanzada (certificados digitales)

Cada uno tiene distinto peso probatorio, pero ninguno depende de la NOM-151 para ser válido.

Puedes ver una comparación completa aquí:
https://blog.mifiel.com/comparacion-tipos-de-firmas/

7. Entonces, ¿qué deberías implementar?

Si estás digitalizando procesos, lo correcto es pensar en capas:

1. Proceso de firma sólido
   • Identidad
   • Consentimiento
   • Evidencia y trazabilidad

2. NOM-151
   • Conservación
   • Integridad a largo plazo
   • Fecha cierta

8. Resumen

La firma electrónica da validez legal.
La NOM-151 da integridad y fecha cierta.

Son complementarias, no equivalentes.

9. La pregunta correcta

Cuando se evalúa una implementación de firma electrónica, la conversación suele empezar con:

“¿Necesito NOM-151?”

Pero esa no es la pregunta más importante.

Primero hay que resolver:

• ¿Cómo se está capturando la identidad del firmante?
• ¿Cómo se demuestra el consentimiento?
• ¿Qué evidencia se genera del proceso?

Solo después tiene sentido preguntarse:

• ¿Cómo se van a conservar esos documentos en el tiempo?

The post NOM-151 y firma electrónica: lo que sí hace (y lo que no) appeared first on Mifiel Blog.

En litigio mercantil con evidencia electrónica, el problema rara vez es “si existe la NOM-151”. El problema es qué hacen los jueces con ella, y cuándo.

La tesis 2031573 intenta corregir una práctica cada vez más común: juzgados que, en el auto inicial, pretenden “verificar” si un documento digital cumple NOM-151 con una simple lectura del archivo, y en función de eso previenen o incluso desechan la demanda.

La razón de decidir (ratio decidendi) del criterio es clara: el juez no puede verificar técnicamente el cumplimiento de la NOM-151 por inspección ocular en el auto inicial. Si existe controversia, es técnica, y su cauce natural es la contradicción probatoria, típicamente con pericial.

Hasta ahí, bien.

El problema es que, al explicar la NOM-151 y su relación con el Código de Comercio, el criterio también incurre en dos errores que conviene neutralizar antes de que se vuelvan “verdades de pasillo”:

1. al igual que esta otra tesis, mete FEA donde no va, y
2. describe mal el modelo de conservación: sugiere que el PSC “almacena” el mensaje bajo su control y que de ahí se desprende la “ulterior consulta”.

Este artículo separa lo rescatable de lo peligroso y propone una lectura jurídicamente limpia: NOM-151 sirve para integridad/fecha; la ulterior consulta depende del repositorio real del Mensaje de Datos (plataforma, sistema de firma o el propio soporte del mensaje, como el XML de un CFDI).

1) El acierto central: NOM-151 no se “verifica” a ojo (y menos en el auto inicial)

La NOM-151 no es un checklist visual. Es un esquema técnico basado en huellas digitales (hash) y sellos de tiempo. Su verificación, por definición, es técnica.

Por eso, la razón de decidir (ratio decidendi) de la tesis es útil: en el auto inicial el juez no está en posición de decidir “cumple/no cumple NOM-151” leyendo archivos. Si la parte actora exhibe documentos digitales con sus anexos, y la demandada pretende desconocer su integridad, fecha, correspondencia o autenticidad técnica, lo correcto es que esa discusión se tramite donde corresponde: en prueba, no como filtro de admisión.

Esta sola idea corrige un daño procesal frecuente: demandas desechadas por intuición tecnológica disfrazada de control judicial.

2) Si la actora exhibe constancia, el juez no valida: la controversia la activa la demandada

Una derivación práctica de lo anterior es simple:

• La actora puede exhibir el documento digital y, si cuenta con constancia NOM-151, acompañarla como soporte de integridad/fecha.
• El juez, en el auto inicial, no debe “validar” técnicamente esa constancia.
• Si la demandada considera que el documento está alterado, no corresponde o no pasó una verificación, debe objetar y llevar la discusión a pericial.

Esto no es un privilegio: es la ubicación correcta de una controversia técnica. Lo contrario —que el juez “decida NOM-151” en la puerta del juicio— convierte el auto inicial en un pseudo-laboratorio forense sin herramientas ni contradicción.

3) Primer error: la insistencia en FEA como requisito general

El criterio (como otros recientes) incurre en un vicio que ya es patrón: convertir la Firma Electrónica Avanzada (FEA) en requisito general, como si fuera el único modo de firmar electrónicamente con efectos jurídicos.

Eso es un error por dos razones:

• Normativa: el Código de Comercio reconoce efectos jurídicos a los mensajes de datos y a las firmas electrónicas sin exigir que toda firma sea avanzada. La pregunta jurídica no es “¿es FEA?”, sino “¿el método es atribuible/fiable para el caso?”.
• Conceptual: la FEA sirve para atribución (quién firmó) bajo un modelo específico; pero NOM-151 regula integridad y fecha, no identidad ni voluntad.

Cuando un tribunal mete FEA dentro de NOM-151, normalmente está repitiendo la confusión de siempre: querer resolver atribución con una herramienta de integridad.

4) Segundo error (más grave): afirmar que el PSC debe recibir/custodiar el Mensaje de Datos

Aquí está el punto neurálgico.

Algunas resoluciones sostienen —o dejan entrever— que la conservación de mensajes de datos puede hacerse “a través” de un Prestador de Servicios de Certificación (PSC), y que eso permitiría “ulterior consulta” porque el PSC tendría el documento bajo su control.

Ese mapa es incorrecto. Y no es una cuestión de interpretación: la NOM-151 lo niega expresamente.

Lo que dice realmente la NOM-151 (Apéndice A)

La NOM establece que para generar una constancia de conservación:

• la solicitud se forma conforme a RFC 3161, en formato ASN.1;
• se utiliza la huella digital electrónica del Mensaje de Datos;
• y la regla decisiva: al PSC no hay que darle el Mensaje de Datos: 

“A.2.4  En todo momento, el interesado deberá mantener el control sobre el mensaje de datos por lo que el Prestador de Servicios de Certificación únicamente recibirá la huella digital electrónica del mensaje de datos.” – Apéndice A de la NOM – 151

La NOM es explícita: el interesado mantiene en todo momento el control sobre el mensaje, y el PSC únicamente recibe la huella.

Esto cambia por completo la lógica probatoria:

• Si el PSC no recibe el Mensaje de Datos, entonces la constancia NOM-151 no presupone custodia del documento por el PSC.
• Y si no hay custodia, la “ulterior consulta” no puede derivarse de que el PSC “lo tenga”.

Dicho sin rodeos: NOM-151 no es almacenamiento del mensaje; es prueba de integridad/fecha sin transferir el mensaje.

5) Artículos 93 y 49 del Código de Comercio: integridad y ulterior consulta son requisitos distintos

El punto fino —y el que la tesis desdibuja— es que el Código de Comercio no habla de un solo requisito, sino de dos condiciones acumulativas cuando se trata de Mensajes de Datos:

1. integridad del contenido, y
2. accesibilidad para su ulterior consulta.

El artículo 93 lo plantea como regla de equivalencia funcional: cuando la ley exige forma escrita, se tiene por cumplida en Mensaje de Datos siempre que la información “se mantenga íntegra” y “sea accesible para su ulterior consulta”, sin importar el formato. Y si además se exige firma, ese requisito se cumple cuando el Mensaje de Datos sea atribuible a las partes.

El artículo 49 repite el mismo binomio en materia de conservación: para efectos de conservar o presentar “originales” en Mensajes de Datos, exige que la información se haya mantenido “íntegra e inalterada” desde su generación definitiva y que “sea accesible para su ulterior consulta”. Y añade un mandato normativo clave: la Secretaría de Economía emitirá la Norma Oficial Mexicana que establezca los requisitos que deberán observarse para la conservación de mensajes de datos.

De ahí se desprende una lectura limpia (y operativa) que evita la confusión:

• La accesibilidad (“ulterior consulta”) es un requisito legal del Código, no una prestación que nazca mágicamente de la constancia.
• La NOM existe “para la conservación”, es decir, para fijar el estándar técnico con el que se acredita integridad/fecha.
• Pero como el Apéndice A de la NOM-151 ordena que el PSC reciba solo la huella y que el interesado mantenga el control del Mensaje de Datos, la constancia no presupone custodia del contenido por el PSC y, por tanto, no puede ser el fundamento de la ulterior consulta.

Por eso, en litigio conviene separar capas:

• Integridad/fecha → se robustece con NOM-151 (huella + sello de tiempo).
• Ulterior consulta → se acredita desde el repositorio real del mensaje: la plataforma donde se generó y firmó, el archivo original conservado por el interesado, o el propio soporte autocontenible del Mensaje de Datos (por ejemplo, el XML de un CFDI) y su conservación.

6) Qué sí prueba NOM-151 y qué no (para litigar sin confusiones)

Conviene decirlo de manera frontal, porque muchas prevenciones nacen de no separar capas:

NOM-151 ayuda a probar:

• Integridad del contenido respecto de un momento verificable.
• Fecha (vía sello de tiempo) asociada a la huella.

NOM-151 no prueba por sí sola:

• Atribución (quién firmó).
• Voluntad (consentimiento).
• Accesibilidad (ulterior consulta) del mensaje, porque la NOM no implica custodia del contenido por el PSC.

7) Uso litigioso correcto: invoca la razón de decidir (ratio decidendi), pero cuidado con la letra chiquita

Esta tesis es útil, pero viene con letra chiquita. Si la citas sin filtrar, corres el riesgo de importar al expediente dos ideas equivocadas (FEA como requisito general y PSC como custodio del Mensaje de Datos).

La forma correcta de usarla es quirúrgica: toma lo bueno y descarta lo venenoso.

1. Invoca la razón de decidir (ratio decidendi): en el auto inicial el juez no puede “verificar” NOM-151 por lectura visual; si hay controversia técnica, debe tramitarse con prueba (y, si hace falta, pericial).
   
2. Aclara el mapa técnico real: la NOM-151 no presupone que el PSC reciba o custodie el Mensaje de Datos; el PSC recibe solo la huella y el control del mensaje permanece en el interesado.
   
3. Amarra con 49 y 93: la ley exige integridad y ulterior consulta; NOM-151 robustece la integridad/fecha, pero la accesibilidad se acredita desde el repositorio real del mensaje (plataforma o soporte del propio Mensaje de Datos).
   

En resumen: cítala por lo que resuelve, no por todo lo que opina.

Conclusión

La tesis aporta algo valioso: frena el impulso de convertir el auto inicial en un examen improvisado de criptografía.

Pero su explicación sobre conservación y “ulterior consulta” puede inducir un error práctico serio: creer que la NOM-151 implica que el PSC guarda el Mensaje de Datos y por eso “se puede consultar después”.

La lectura correcta es otra:

• El Código de Comercio (arts. 49 y 93) exige integridad y accesibilidad.
• La NOM-151 aporta un estándar técnico para acreditar integridad/fecha, sin transferir el contenido al PSC.
• La “ulterior consulta” se prueba por el lugar donde el Mensaje de Datos existe y se conserva: la plataforma, el sistema de firma, o el propio soporte del mensaje (por ejemplo, el XML).

NOM-151 no es almacenamiento. Es el ancla criptográfica que te permite decir: “esto existía así, desde entonces”. La consulta ulterior vive en el repositorio; la integridad vive en la constancia.

The post NOM-151 en el auto inicial: la tesis que acierta al frenar el “ojo clínico”, pero se equivoca sobre conservación y consulta ulterior appeared first on Mifiel Blog.

¿Qué es la NOM-151?

La NOM-151 define los requisitos para conservar documentos digitales de manera legal y segura. Las constancias de conservación permiten garantizar que un archivo no ha sido alterado desde su creación. Para una descripción más detallada visita este artículo.

La API de Mifiel para obtener constancias de conservación

Las API de NOM 151 de Mifiel cuenta con dos endpoints, uno para generar constancias y otro para recuperar constancias generadas anteriormente:

1. Generar constancia de conservación (POST):
   • Endpoint: /api/v1/psc/nom151
   • Parámetros aceptados en el cuerpo de la solicitud:
     • hash: Cadena hash SHA256 del documento (obligatorio).
     • external_id: Identificador único opcional para referencia externa (opcional).
   • Respuesta incluye:
     • id: Identificador único de la constancia.
     • nom151: Cadena en Base64 de la constancia generada.
     • created_at: Fecha de creación de la constancia.
     • certificate: Certificado del Prestador de Servicios de Certificación (PSC) que emitió la constancia.
     • hash: Cadena hash SHA256 proporcionada.
2. Recuperar constancia de conservación (GET):
   • Endpoints:
     • Por external_id: /api/v1/psc/nom151?external_id={:external_id}
     • Por id: /api/v1/psc/nom151/{:id}
   • Respuesta incluye:
     • id: Identificador único de la constancia.
     • nom151: Cadena en Base64 de la constancia generada.
     • created_at: Fecha de creación de la constancia.
     • certificate: Certificado del PSC emisor.
     • hash: Cadena hash SHA256 proporcionada​.

API NOM 151: Primeros pasos

Mifiel cuenta con dos ambientes, el de pruebas (Sandbox) y el productivo. Para iniciar con pruebas sigue los siguientes pasos:

1. Crear una cuenta en el Sandbox de Mifiel. Selecciona “Ninguna de las anteriores en las opciones”.
2. Contáctanos por Chat (ícono verde en la esquina inferior derecha) y solicita que te habilitemos la API y créditos de Constancias de Conservación para hacer pruebas.
3. Genera tus API keys en la sección de Configuraciones de API.

Tus primeras constancias

Una vez tengas tus API keys el siguiente paso es generar una constancia de conservación vía la API de NOM 151 de Mifiel. Para simplificar tus pruebas a continuación podrás consultar unos ejemplos es distintos lenguajes de programación para obtener una constancia de conservación de un archivo PDF. Los ejemplos incluyen la función de obtener el hash256 del PDF, manejar la autenticación en Mifiel usando tus API keys y la obtención de la constancia de conservación.

require 'faraday'
require 'digest'
require 'base64'
require 'json'

# Variables de configuración
SANDBOX_API_URL = "https://app-sandbox.mifiel.com/api/v1/psc/nom151"
SANDBOX_API_KEY = "your_sandbox_api_key"
SANDBOX_API_SECRET = "your_sandbox_api_secret"
PDF_PATH = "path/to/your-document.pdf"

# Función para calcular el hash SHA256 de un archivo
def calculate_sha256(file_path)
  digest = Digest::SHA256.new
  File.open(file_path, 'rb') do |file|
    buffer = ''
    digest.update(buffer) while file.read(1024, buffer)
  end
  digest.hexdigest
end

# Función principal
def generate_constancia
  begin
    # Calcular el hash SHA256 del archivo PDF
    pdf_hash = calculate_sha256(PDF_PATH)

    # Crear el payload
    payload = {
      hash: pdf_hash
    }

    # Crear encabezado de autenticación
    auth_header = "Basic " + Base64.strict_encode64("#{SANDBOX_API_KEY}:#{SANDBOX_API_SECRET}")

    # Crear conexión Faraday
    connection = Faraday.new do |conn|
      conn.request :json # Para enviar el cuerpo como JSON
      conn.response :json, parser_options: { symbolize_names: true } # Para parsear la respuesta como JSON
      conn.adapter Faraday.default_adapter
    end

    # Realizar la solicitud POST
    response = connection.post(SANDBOX_API_URL) do |req|
      req.headers['Authorization'] = auth_header
      req.headers['Content-Type'] = 'application/json'
      req.body = payload
    end

    # Manejar la respuesta
    if response.success?
      puts "Constancia generada con éxito:"
      puts response.body
    else
      puts "Error al generar la constancia: #{response.status}"
      puts response.body
    end
  rescue StandardError => e
    puts "Error al realizar la solicitud: #{e.message}"
  end
end

# Ejecutar la función
generate_constancia

const axios = require("axios");
const fs = require("fs");
const crypto = require("crypto");

// Variables de configuración
const SANDBOX_API_URL = "https://app-sandbox.mifiel.com/api/v1/psc/nom151";
const SANDBOX_API_KEY = "your_sandbox_api_key";
const SANDBOX_API_SECRET = "your_sandbox_api_secret";
const PDF_PATH = "path/to/your-document.pdf";

// Función para calcular el hash SHA256 de un archivo
function calculateSHA256(filePath) {
  const fileBuffer = fs.readFileSync(filePath);
  return crypto.createHash("sha256").update(fileBuffer).digest("hex");
}

// Función principal
async function generateConstancia() {
  try {
    // Calcular el hash SHA256 del archivo PDF
    const pdfHash = calculateSHA256(PDF_PATH);

    // Crear el payload
    const payload = {
      hash: pdfHash,
    };

    // Crear encabezado de autenticación
    const authHeader =
      "Basic " +
      Buffer.from(`${SANDBOX_API_KEY}:${SANDBOX_API_SECRET}`).toString("base64");

    // Enviar la solicitud POST
    const response = await axios.post(SANDBOX_API_URL, payload, {
      headers: {
        "Content-Type": "application/json",
        Authorization: authHeader,
      },
    });

    // Manejar la respuesta
    console.log("Constancia generada con éxito:");
    console.log(response.data);
  } catch (error) {
    if (error.response) {
      console.error("Error en la respuesta del servidor:");
      console.error(error.response.data);
    } else {
      console.error("Error al realizar la solicitud:");
      console.error(error.message);
    }
  }
}

// Ejecutar la función
generateConstancia();

import hashlib
import base64
import requests

# Variables de configuración
SANDBOX_API_URL = "https://app-sandbox.mifiel.com/api/v1/psc/nom151"
SANDBOX_API_KEY = "your_sandbox_api_key"
SANDBOX_API_SECRET = "your_sandbox_api_secret"
PDF_PATH = "path/to/your-document.pdf"

# Función para calcular el hash SHA256 de un archivo
def calculate_sha256(file_path):
    sha256_hash = hashlib.sha256()
    with open(file_path, "rb") as file:
        for byte_block in iter(lambda: file.read(4096), b""):
            sha256_hash.update(byte_block)
    return sha256_hash.hexdigest()

# Función principal
def generate_constancia():
    try:
        # Calcular el hash SHA256 del archivo PDF
        pdf_hash = calculate_sha256(PDF_PATH)

        # Crear el payload
        payload = {
            "hash": pdf_hash
        }

        # Crear encabezado de autenticación
        auth_header = base64.b64encode(f"{SANDBOX_API_KEY}:{SANDBOX_API_SECRET}".encode()).decode()

        # Realizar la solicitud POST
        headers = {
            "Authorization": f"Basic {auth_header}",
            "Content-Type": "application/json"
        }

        response = requests.post(SANDBOX_API_URL, json=payload, headers=headers)

        # Manejar la respuesta
        if response.status_code == 200 or response.status_code == 201:
            print("Constancia generada con éxito:")
            print(response.json())
        else:
            print(f"Error al generar la constancia: {response.status_code}")
            print(response.json())
    except Exception as e:
        print(f"Error al realizar la solicitud: {e}")

# Ejecutar la función
generate_constancia()

<?php

// Variables de configuración
$SANDBOX_API_URL = "https://app-sandbox.mifiel.com/api/v1/psc/nom151";
$SANDBOX_API_KEY = "your_sandbox_api_key";
$SANDBOX_API_SECRET = "your_sandbox_api_secret";
$PDF_PATH = "path/to/your-document.pdf";

// Función para calcular el hash SHA256 de un archivo
function calculateSHA256($filePath) {
    $hash = hash_file('sha256', $filePath);
    return $hash;
}

// Función principal
function generateConstancia($url, $apiKey, $apiSecret, $pdfPath) {
    try {
        // Calcular el hash SHA256 del archivo PDF
        $pdfHash = calculateSHA256($pdfPath);

        // Crear el payload
        $payload = json_encode([
            "hash" => $pdfHash
        ]);

        // Crear encabezado de autenticación
        $authHeader = "Basic " . base64_encode("$apiKey:$apiSecret");

        // Configurar la solicitud cURL
        $ch = curl_init($url);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
        curl_setopt($ch, CURLOPT_POST, true);
        curl_setopt($ch, CURLOPT_HTTPHEADER, [
            "Authorization: $authHeader",
            "Content-Type: application/json"
        ]);
        curl_setopt($ch, CURLOPT_POSTFIELDS, $payload);

        // Ejecutar la solicitud
        $response = curl_exec($ch);
        $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);

        // Manejar errores de cURL
        if ($response === false) {
            throw new Exception('Error en la solicitud cURL: ' . curl_error($ch));
        }

        // Cerrar cURL
        curl_close($ch);

        // Manejar la respuesta
        if ($httpCode === 200 || $httpCode === 201) {
            echo "Constancia generada con éxito:\n";
            echo $response . "\n";
        } else {
            echo "Error al generar la constancia (HTTP $httpCode):\n";
            echo $response . "\n";
        }
    } catch (Exception $e) {
        echo "Error: " . $e->getMessage() . "\n";
    }
}

// Ejecutar la función
generateConstancia($SANDBOX_API_URL, $SANDBOX_API_KEY, $SANDBOX_API_SECRET, $PDF_PATH);

?>

using System;
using System.IO;
using System.Net.Http;
using System.Net.Http.Headers;
using System.Security.Cryptography;
using System.Text;
using System.Text.Json;
using System.Threading.Tasks;

class Program
{
    // Variables de configuración
    private const string SANDBOX_API_URL = "https://app-sandbox.mifiel.com/api/v1/psc/nom151";
    private const string SANDBOX_API_KEY = "your_sandbox_api_key";
    private const string SANDBOX_API_SECRET = "your_sandbox_api_secret";
    private const string PDF_PATH = "path/to/your-document.pdf";

    static async Task Main(string[] args)
    {
        try
        {
            // Calcular el hash SHA256 del archivo PDF
            string pdfHash = CalculateSHA256(PDF_PATH);

            // Crear el payload
            var payload = new
            {
                hash = pdfHash
            };

            string payloadJson = JsonSerializer.Serialize(payload);

            // Configurar el cliente HTTP
            using HttpClient client = new HttpClient();
            var authHeader = Convert.ToBase64String(Encoding.UTF8.GetBytes($"{SANDBOX_API_KEY}:{SANDBOX_API_SECRET}"));
            client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", authHeader);
            client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));

            // Crear el contenido de la solicitud
            var content = new StringContent(payloadJson, Encoding.UTF8, "application/json");

            // Realizar la solicitud POST
            HttpResponseMessage response = await client.PostAsync(SANDBOX_API_URL, content);

            // Manejar la respuesta
            if (response.IsSuccessStatusCode)
            {
                string responseBody = await response.Content.ReadAsStringAsync();
                Console.WriteLine("Constancia generada con éxito:");
                Console.WriteLine(responseBody);
            }
            else
            {
                string errorBody = await response.Content.ReadAsStringAsync();
                Console.WriteLine($"Error al generar la constancia: {response.StatusCode}");
                Console.WriteLine(errorBody);
            }
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Error: {ex.Message}");
        }
    }

    // Método para calcular el hash SHA256 de un archivo
    private static string CalculateSHA256(string filePath)
    {
        using FileStream stream = File.OpenRead(filePath);
        using SHA256 sha256 = SHA256.Create();
        byte[] hashBytes = sha256.ComputeHash(stream);
        StringBuilder hashString = new StringBuilder();
        foreach (byte b in hashBytes)
        {
            hashString.Append(b.ToString("x2"));
        }
        return hashString.ToString();
    }
}

The post Integra constancias de conservación (NOM 151) en tu proyecto con la API REST de Mifiel appeared first on Mifiel Blog.

Pero ¿qué es la NOM-151? ¿Es necesario cumplirla para que los contratos electrónicos y sus firmas tengan validez? ¿Se requiere contratar a un PSC para ello? A lo largo de este artículo responderemos estas dudas y al finalizar tendrás clara la importancia de esta Norma Oficial Mexicana.

¿Qué es la NOM-151?

La NOM-151 es una regulación técnica que indica cómo conservar íntegros los documentos electrónicos relacionados con actos comerciales, es decir, guardar y mantener seguros, completos y sin alteraciones estos documentos a lo largo del tiempo.

¿Por qué es importante cumplir la NOM-151 en contratos electrónicos?

Como una regulación que surge del artículo 49 del Código de Comercio, cumplir con la NOM-151-SCFI-2016 es indispensable para las empresas que suscriben acuerdos de manera electrónica en México por tres razones:

1. Permite acreditar fecha cierta

Para efectos fiscales, cumplir la NOM-151 permite acreditar fecha cierta en caso de una auditoría del SAT. Además, la fecha cierta es un requisito judicial de la Ley Nacional de Extinción de Dominio para presumir buena fe en contratos de arrendamiento de bienes.

2. Otorga mayor fortaleza probatoria a evidencias electrónicas

Según el artículo 210-A del Código Federal de Procedimientos Civiles, la integridad es uno de los criterios de valoración que debe seguir el juez para admitir pruebas electrónicas, y al cumplir la NOM-151 se garantiza la integridad.

3. Es una obligación en actos de comercio

El Artículo 49 del Código de Comercio indica la obligación de conservar por 10 años todo documento mercantil, y la NOM-151 establece la forma de lograrlo cuando estos documentos son electrónicos.

¿Cómo se logra la conservación íntegra de documentos electrónicos?

De acuerdo con la NOM-151, la conservación íntegra de documentos electrónicos se logra mediante sellos digitales llamados constancias de conservación. Estos sellos indican la existencia de un documento digital en un momento determinado del tiempo y garantizan que se mantenga inalterable a partir de ese momento.

Los emisores de estos sellos son los Prestadores de Servicios de Certificación (PSCs), entes acreditados por el gobierno para tal fin.

¿Es necesario contratar a un PSC para cumplir la NOM-151 en contratos digitales?

Aunque los PSCs son los emisores de las constancias de conservación, no es necesario contratar a un PSC directamente para cumplir la NOM-151 en todos tus acuerdos electrónicos.

Piensa en ello como un servicio automotriz. Cuando requieres diferentes reparaciones para tu automóvil, puedes acudir a diversos talleres especializados para que las realicen: centros llanteros para cambiar tus llantas, un taller de estética automotriz para proteger la pintura, entre otros.

Pero la solución más cómoda y rápida es acudir a un taller mecánico integral que se encargue de todo el proceso—incluso de llevar y traer tu auto de vuelta a tu domicilio.

Lo mismo sucede con el cumplimiento de la NOM-151. Puedes ir con los PSCs y comprarles la constancia de conservación para que ellos la emitan e incorporen en tu documento electrónico, y encargarte de manera independiente de recolectar las firmas del contrato con la solución de firma electrónica que tú prefieras.

Pero con Mifiel el proceso se simplifica, ya que es una solución integral que te permite gestionar tu firma electrónica de documentos mediante las funcionalidades que tu organización requiere e incluye constancias de conservación de un PSC en cada documento firmado.

Relación entre las constancias de conservación y la firma electrónica

Suele pensarse que las constancias de conservación son un elemento para dar validez a una firma electrónica, incluso el único o principal. Pero esto no es así. ¿Por qué?

Primero debemos entender el funcionamiento de las constancias de conservación. Estas constancias garantizan la integridad de los documentos digitales que las incorporan sin importar que dichos documentos tengan o no firmas electrónicas, y en caso de tener firmas electrónicas, sin importar que estas firmas cumplan o no con los requisitos legales para ser válidas en México.

Segundo, sobre los requisitos legales de la firma electrónica. Una firma electrónica en cualquier documento debe cumplir ciertos requisitos que establece el Código de Comercio para tener validez legal: el artículo 89 señala los requisitos de una firma electrónica simple, y el artículo 97 los requisitos adicionales de una firma electrónica avanzada. El cumplimiento de la NOM-151 mediante constancias de conservación no es uno de estos requisitos.

Entonces, cuando en un documento hay una firma electrónica mal ejecutada, esta no será válida sin importar que el documento incorpore una constancia de conservación.

De la misma manera, un documento con firmas electrónicas ejecutadas correctamente no podrá garantizar su integridad en el tiempo si no incorpora una constancia de conservación, aunque sus firmas serán legalmente válidas.

En resumen, una constancia de conservación nunca define la validez legal de las firmas electrónicas de un documento, pero contar con ella permite garantizar la integridad del documento firmado.

Mifiel, la solución para cumplir con la NOM-151 y otorgar fecha cierta a tus contratos

La NOM-151 establece cuál es la forma de mantener sin alteraciones los documentos electrónicos involucrados en actos mercantiles, independientemente de que contengan o no firmas electrónicas.

El vehículo para cumplir con esta NOM son las constancias de conservación de mensajes de datos. Cuando una constancia de conservación se incorpora en un contrato electrónico u otro documento legal privado, este documento podrá acreditar el requisito fiscal de fecha cierta y gozará de mayor fuerza probatoria en caso de presentarse como evidencia en juicio.

Si requieres firmar contratos o acuerdos comerciales, gestionarlos y otorgarles fecha cierta mediante el cumplimiento de la NOM-151, Mifiel es la solución adecuada para ti

Contáctanos mediante el chat si estás interesado en implementar las constancias de conservación y cumplir la NOM-151 en tus procesos contractuales.

Chatea con Mifiel

The post NOM-151: qué establece y cómo cumplirla en documentos electrónicos appeared first on Mifiel Blog.

Cuando se opta por un servicio de firma electrónica avanzada por sus ventajas como la garantía de no repudio, existen algunos requisitos mínimos legales y técnicos que siempre deberían cumplir y que deben considerarse antes que cualquier otro factor. Estos se enumeran en las cuatro Fracciones del Artículo 97 del Código de Comercio.

¿Qué ventajas confiere la ley a la firma electrónica avanzada? Te platicamos en el webinar Entendiendo la Firma Electrónica Avanzada.

El Dr. Alfredo Reyes Krafft, abogado experto en firmas electrónicas, nos explica en el video a continuación cada requisito y cómo los cumple Mifiel. Si quieres conocer con mayor detalle estos puntos, después del video encontrarás la interpretación.

Primer requisito: la Firma es del firmante

La Fracción I de este Artículo indica “Los Datos de Creación de la Firma, en el contexto en que son utilizados, corresponden exclusivamente al Firmante”.

Para asegurarlo, el servicio de firma digital debe trabajar exclusivamente con Firmas Electrónicas Avanzadas (FEA) de alguno de los PSC acreditados por la Secretaría de Economía (SE) para emitir certificados digitales, o bien, alguna de las Agencias Certificadoras autorizadas por el Banco de México (Banxico) para firma de certificados.

Dichas entidades obtienen su acreditación al demostrar, entre otros requisitos, que la Firma Electrónica Avanzada se crea bajo exclusivo control del usuario. Un ejemplo es el Servicio de Administración Tributaria (SAT), Agencia Certificadora autorizada por Banxico, que emite sin costo los certificados públicos de e.firma o FIEL y tiene cobertura nacional, logrando un amplio alcance.

Al momento de firmar un documento, la plataforma de firmas debe corroborar la validez y vigencia del certificado ante la certificadora que lo emitió, negando la firma si el certificado no pertenece a un PSC, venció o se revocó antes de firmar.

Segundo requisito: el firmante tiene control exclusivo de la Firma

Asimismo, la Fracción II señala “Los Datos de Creación de la Firma estaban, en el momento de la firma, bajo el control exclusivo del Firmante”.

Esto significa que al momento de firmar digitalmente, la llave privada del usuario y la contraseña que la protege estuvieron bajo control de su dueño y nunca se compartieron al servicio de firmas.

Para asegurarlo, es indispensable que el proceso de firma se realice localmente en el dispositivo del firmante. Posteriormente enviar el certificado público y el resultado de la firma a los servidores de la plataforma. Si se compartiera la llave privada *.key y su respectiva contraseña con el servicio, se estaría incumpliendo con esta disposición y pondría al usuario en peligro ya que la plataforma podría firmar otros documentos en nombre del usuario.

Tercer requisito: pueden detectarse alteraciones a la Firma o al Documento después de firmar

Por último, las Fracciones III y IV del Artículo en cuestión indican “Es posible detectar cualquier alteración de la Firma Electrónica hecha después del momento de la firma, y respecto a la integridad de la información de un Mensaje de Datos, es posible detectar cualquier alteración de ésta hecha después del momento de la firma”.

Esto es inherente a la propia tecnología de la Firma Electrónica Avanzada. Por ello, en tanto se cumplan los requisitos anteriores, este debería estar cubierto.

Adicional: integridad en el tiempo

Cuando se firma electrónicamente, es muy recomendable tener un elemento que asegure la integridad del documento firmado (y sus firmas) en el tiempo. El Artículo 49 del Código de Comercio indica “Para efectos de la conservación o presentación de originales, en el caso de mensajes de datos, se requerirá que la información se haya mantenido íntegra e inalterada a partir del momento en que se generó por primera vez en su forma definitiva”.

Ese mismo Artículo deriva en la inclusión de una Constancia de Conservación que cumpla con los requisitos de la NOM 151. El proveedor del servicio de firma de documentos es quien debería emitirla, o bien, tramitarla ante un PSC que pueda hacerlo.

Es importante mencionar que las constancias NOM151 dotan a los documentos de fecha cierta, un requisito del SAT. Además, los documentos con firma electrónica simple también pueden obtener constancia de conservación.

Conclusión

Si la plataforma que elijas para darte el servicio de firma electrónica avanzada de documentos cumple con estos requisitos, todos tus documentos firmados gozarán de garantía de integridad, y sus firmas tendrán presunción de atribución y garantía de no repudio. Estas blindarán el contrato en caso de llegar a un litigio.

En Mifiel cumplimos a cabalidad con las cuatro fracciones del Artículo 97 y el segundo párrafo del Artículo 49 del Código de Comercio mexicano ya que trabajamos con la FIEL del SAT, la firma se ejecuta en el dispositivo del firmante y todos los documentos firmados con nosotros cuentan con una constancia de conservación NOM 151 tramitada ante un PSC autorizado para ello.

¿Quieres conocer más sobre el servicio de Mifiel e implementarlo en tus procesos? Comunícate con nosotros haciendo clic en el siguiente botón.

Contacta a Mifiel

The post Requisitos mínimos que una plataforma de firma electrónica avanzada debe cumplir en México appeared first on Mifiel Blog.

La forma más adecuada para ello es que el proveedor del servicio incluya constancias de conservación, también conocidas como NOM 151, en los documentos. Pero ¿qué son las constancias de conservación y cómo funcionan?

Por qué los documentos firmados electrónicamente deberían tener constancia de conservación

Las firmas electrónicas tienen una gran ventaja frente a la firma autógrafa: cuentan con presunción de atribución y en el caso de la firma electrónica avanzada, con garantía de no repudio. Sin embargo, al firmar electrónicamente, debe asegurarse que el documento se mantenga íntegro a lo largo del tiempo.

Para garantizarlo, es necesario algún tipo de recibo reconocido por la autoridad, el cual indique una fecha en que el documento existió y que además permita detectar alteraciones en el mismo. En documentos electrónicos, este recibo se conoce como constancia de conservación de mensajes de datos.

Además de garantizar la presunción de integridad, la constancia de conservación otorga al documento una fecha cierta. La fecha cierta es un requisito de la autoridad fiscal para comprobar la existencia de operaciones y de la Ley Nacional de Extinción de Dominio para gozar presunción de buena fe al arrendar bienes.

Qué es y cómo se emite una constancia de conservación

Para evitar una descripción técnica de su funcionamiento, utilicemos la analogía de un recibo emitido por un tercero autorizado por el gobierno —o por el mismo gobierno— y comparemos con lo especificado en la Norma Oficial Mexicana que indica cómo debe emitirse la constancia, la NOM-151-SCFI-2016.

Imagina que realizas un trámite de gobierno y debes presentar un documento que solo aceptan si tiene el sello —que funciona como recibo— de la instancia correspondiente. Para obtenerlo, debes llevar el documento a una ventanilla donde un funcionario estampa un sello inviolable en cada hoja que incluye fecha y hora de presentación. Además, el funcionario firma con su rúbrica cada sello que estampa para que sea verificable que fue él quien utilizó el sello.

Es importante mencionar que al funcionario no le interesa el contenido del documento, su trabajo es solo estampar todas las hojas que conforman el documento que se le presenta.

Una vez hecho esto, acudes a la dependencia en donde estás presentando el trámite. Revisando que cada hoja tenga un sello firmado, el personal que te recibe el documento puede validar que no lo modificaste después de pasar por la ventanilla. Viendo el sello, también puede verificar la fecha y hora en que te presentaste en la ventanilla y al ver la rúbrica, quién estampó el sello en tus hojas.

Una constancia de conservación es el equivalente digital de este proceso. Para obtenerla:

1. En vez de un funcionario en una ventanilla, la constancia la otorga un tercero de confianza llamado Prestador de Servicios de Certificación (PSC) autorizado por el gobierno.
2. No debe presentarse el documento entero para que se selle cada hoja, únicamente se envía electrónicamente el hash del documento, que es una huella digital única del mismo obtenida mediante un algoritmo de cifrado.
3. Al recibir el hash de documento, el PSC genera un sello digital que incluye la fecha y hora exacta de su recepción la cual obtiene de un reloj atómico. Además, usando una firma electrónica avanzada, el PSC firma este sello (rúbrica digital).

Al final del proceso, terminamos con un sello digital que contiene fecha y hora así como la firma del PSC. Este sello se denomina constancia de conservación y otorga fecha cierta al documento.

Ahora bien, ¿qué sucede si de manera malintencionada se modifica el XML obtenido? Por ejemplo, ¿cambiando o eliminando una de las firmas? Al verificar el documento, el hash resultante será distinto, evidenciando que el documento original firmado sufrió alguna alteración.

De no haber constancia de conservación, ¿el documento pierde validez? No, pero si en algún momento es necesario presentarlo como prueba en un juicio, será conveniente asegurar que no ha sido alterado. La forma más adecuada es la constancia de conservación.

Entonces, ya que todo documento firmado electrónicamente debería incluir una constancia NOM151, Mifiel cumple con ello. Pero ¿cómo lo hace?

Cómo trabaja Mifiel con las constancias de conservación

Es importante aclarar que Mifiel no es un PSC ni requiere serlo para brindar una plataforma de firma electrónica. Sin embargo, para asegurar el cumplimiento de la NOM 151, siempre utilizamos los servicios de uno.

Todos los documentos firmados mediante la plataforma cuentan con una constancia de conservación. Esta se incluye en el XML firmado que está en poder tanto de Mifiel como de firmantes y espectadores (incluyendo a quien solicita la firma).

Para validar documentos firmados en Mifiel, tenemos una herramienta de código abierto que verifica el hash, los certificados, las firmas y la constancia de conservación. Es equivalente a que un perito criptográfico haga las validaciones necesarias para constatar que el documento cumpla con lo establecido en los Artículos 89 y 97 del Código de Comercio y con la NOM 151.

Si la verificación es exitosa, tu documento cuenta con las presunciones y garantías legales que la ley le otorga a las firmas electrónicas y a los documentos con constancia de conservación, las cuales te serán de gran ayuda al llevar el documento a un juicio.

¿Quieres integrar la firma electrónica en tus procesos garantizando la integridad de tus documentos? Ponte en contacto con nosotros.

Contacta a Mifiel

The post Constancia de Conservación NOM 151, indispensable en documentos firmados electrónicamente appeared first on Mifiel Blog.