{"id":14794,"date":"2026-08-05T01:50:52","date_gmt":"2026-08-05T08:50:52","guid":{"rendered":"https:\/\/omnitrust.com\/blog\/atributos-de-solicitud-de-ilm-pki-sin-la-clase-magistral-de-pki\/"},"modified":"2026-10-29T05:15:20","modified_gmt":"2026-10-29T12:15:20","slug":"atributos-de-solicitud-de-ilm-pki-sin-la-clase-magistral-de-pki","status":"publish","type":"post","link":"https:\/\/www.omnitrust.com\/es\/blog\/atributos-de-solicitud-de-ilm-pki-sin-la-clase-magistral-de-pki\/","title":{"rendered":"Atributos de solicitud de ILM: PKI sin la clase magistral de PKI"},"content":{"rendered":"\r\n

Summary:<\/span><\/span><\/strong> ILM request attributes allow an RA profile to declare what a certificate request requires, where each value comes from, and what a client can never set. This way, the requester completes a short form instead of learning PKI, and the trust guarantees remain exactly where they were.<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

\u00a0<\/div>\r\n\r\n\r\n\r\n
\r\n

Nobody wants a certificate. They want what stops working without it. Every additional question you ask is a cost you’re imposing through your own policy.<\/span><\/span><\/p>\r\n<\/div>\r\n\r\n\r\n\r\n

\u00a0<\/div>\r\n\r\n\r\n\r\n

Consider what a developer typically faces when requesting an internal certificate. Which template? Which algorithm and key size? Which extensions, with what key usages? What should the subject include, and in what order? Which of the various types of subject alternative names applies here?<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

Every question has a correct answer. However, the developer is rarely the one who knows it. So the answer is usually found by copying a previous request, asking a colleague, or guessing. Then the request is rejected, and the cycle repeats.<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

Meanwhile, the PKI team is being blamed for being slow. In reality, they are being asked to oversee decisions that were never the applicant’s responsibility.<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

\u00a0<\/div>\r\n\r\n\r\n\r\n

What do the request attributes actually declare?<\/span><\/span><\/h2>\r\n\r\n\r\n\r\n

Now, an AR profile in ILM can include a request attributes configuration. That configuration is a policy statement, not a form definition. It specifies what attributes a request has and links each attribute to a value source.<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

These links are the important part. A value can be collected from the applicant, derived by the platform, or set by policy. Consequently, the profile codifies three different types of knowledge that previously resided on a wiki page.<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
Source of value<\/span><\/span><\/th>\r\nWho decides<\/span><\/span><\/th>\r\nTypical example<\/span><\/span><\/th>\r\n<\/tr>\r\n<\/thead>\r\n
Compiled<\/span><\/span><\/td>\r\nThe applicant<\/span><\/span><\/td>\r\nThe hostname for which the certificate is issued<\/span><\/span><\/td>\r\n<\/tr>\r\n
Derivative<\/span><\/span><\/td>\r\nThe platform<\/span><\/span><\/td>\r\nOwner and group, taken from the authenticated identity<\/span><\/span><\/td>\r\n<\/tr>\r\n
Set by policy<\/span><\/span><\/td>\r\nThe PKI team, just once<\/span><\/span><\/td>\r\nKey algorithm, key usage, extension set<\/span><\/span><\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n
The request attributes link each value to who is legitimately responsible for the decision.<\/span><\/span><\/figcaption>\r\n<\/figure>\r\n\r\n\r\n\r\n

Read the table as a division of labor. The applicant is only asked what they actually know. Everything else is either derived or already decided.<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

\u00a0<\/div>\r\n\r\n\r\n\r\n

Politics extends even to the application itself.<\/span><\/span><\/h2>\r\n\r\n\r\n\r\n

A form that collects the correct values \u200b\u200bonly solves half the problem. Those values \u200b\u200bmust then be correctly submitted to the certificate signing request.<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

ILM projects attribute field mappings onto the generated PKCS#10 request. Therefore, the CSR reflects the profile policy rather than what a client library might have assembled. The subject and extensions are constructed from the same declaration completed by the requester.<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

Uploaded requests receive the same treatment. If you provide your own CSR, ILM validates it against the RA profile’s request attributes policy instead of simply accepting it. Additionally, a request can be registered first and issued later, so pre-registration and issuance are separate steps when a workflow requires it.<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

\u00a0<\/div>\r\n\r\n\r\n\r\n

Errors that a protocol client can act upon<\/span><\/span><\/h2>\r\n\r\n\r\n\r\n

This is the detail that determines whether the whole process feels seamless. Most certificate requests don’t even come from a person. They come from ACME, EST, SCEP, or CMP clients running unattended.<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

When a customer like this violates the policy, a generic error message is useless. The customer can’t interpret it, can’t retry in a meaningful way, and can’t provide any actionable information. Someone ends up reading the log days later.<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

ILM translates request attribute policy violations into native ACME, EST, SCEP, and CMP errors. Because the error is presented in the protocol’s own vocabulary, the client can behave correctly. Furthermore, the request attribute set can be resolved using the CSR attributes endpoint, allowing a client to check what is expected before composing anything.<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

\r\n
\r\n

Asking the platform what it needs is a better protocol than guessing and being rejected.<\/span><\/span><\/p>\r\n<\/blockquote>\r\n<\/figure>\r\n\r\n\r\n\r\n

\u00a0<\/div>\r\n\r\n\r\n\r\n

Extensions without custom code<\/span><\/span><\/h2>\r\n\r\n\r\n\r\n

Certificate extensions are a common reason why organizations end up maintaining custom tools. A policy needs a custom extension, and suddenly the issuance path incorporates a patch.<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

ILM now incorporates a custom OID registry for certificate extensions, registers known system extensions, and exposes an endpoint that lists system OIDs. This effectively turns a custom extension into a configuration. Additionally, platform RDN codes such as EMAIL are now accepted in subject names, eliminating a known class of rejected requests.<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

\u00a0<\/div>\r\n\r\n\r\n\r\n

Fluid does not mean permissive<\/span><\/span><\/h2>\r\n\r\n\r\n\r\n

It would be easy to interpret all this as a relaxation of control. It is precisely the opposite, and the distinction matters.<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

Previously, an applicant could include almost anything in a CSR, and the platform’s job was to detect it afterward. Now, the profile defines what is allowed, values \u200b\u200bthat the client shouldn’t control are derived or set, and uploaded requests are checked against the same policy. In other words, fewer questions for the applicant and fewer opportunities to make a mistake.<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

Trust in a PKI stems from consistently applying the policy. It has never depended on forcing people to prove they understand it. Therefore, shifting the difficulty to the profile increases trust rather than reducing it.<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

One honest caveat: someone still needs to write the policy. Request attributes don’t decide what your PKI should allow. They make that decision explicit, reusable, and enforceable from a single source, instead of being repeatedly interpreted by guesswork.<\/span><\/span><\/p>\r\n\r\n\r\n\r\n

\u00a0<\/div>\r\n\r\n\r\n
\r\n\r\n\r\n
\u00a0<\/div>\r\n\r\n\r\n\r\n
\r\n

Key points<\/span><\/span><\/h3>\r\n\r\n\r\n\r\n