[lamps] New suggestion for a full and straightforward solution - Re: I-D Action: draft-ietf-lamps-rfc7030-csrattrs-04.txt

Hi Mike et al.,

thank you for the update.

The draft (so far) solves reasonably well the very specific issue
described in the intro,
but as I wrote on several occasions over recent years, in particular in
summer 2021, 
most of the CsrAttrs spec is still ad-hoc - there are may more
weaknesses and unclarities not addressed, such as

 * it remains entirely unclear how a server could specify regular
   subject DN values, which may be needed in addition to specifying
   SANs,
   possibly including partial specification of RDNs (such as : "include
   a CN with value chosen by the client, while OU should have value
   'xyz')
 * the spec how to interpret algorithm OIDs is very weak: just by means
   of a few examples - no systematic semantic rules are given
 * there are no rules preventing conflicting "algorithm requirements",
   such as OID ecdsaWithSHA384 and OID SHA256,
 * nothing general is specified how to use and interpret the multitude
   of other OIDs that could potentially be given
 * while addressed by examples, a general description is missing what it
   means if for instance a cert extension 
   will have a value but the CSRattrs only give the OID - this issue is
   the only one easy to cure in the current form of the draft.

So, while the draft so far gives clarification for a particular use case
of SANs and partly for other X.509v3 extensions, 
the use of CsrAttrs is still heavily underspecified and thus
implementations are still far from reaching interoperability.

As I did already on 2021-07-30, I invite everyone to have a look at the
solution we took in the Lightweight CMP Profile, 
which also defines a "Get Certificate Request Template" feature
in section 4.3.3 including an example in Appendix A.
The basic idea is to re-use the certificate template structure that is
also used in the actual CSRs (which in this case is in CRMF).

Today I had the thought that we can take over the same principle also
for EST CsrAttrs, even in a backward-compatible way!
Namely, by placing a partially filled CertificationRequestInfo structure
as the only(!) AttrOrOID element in the CsrAttrs
(with an OID identifying it, which likely needs to be defined for this
purpose). In this way, the server can specify in a straightforward
and pretty self-evident way what it expects from the client in the
actual PKCS#10 CSR, which has the very same content structure.

Within the CertificationRequestInfo structure,
the server can give for instance SANs and an other X.509v3 extensions as
well subject DNs etc. with desired values
exactly in the way they will appear in the CSR (and in the cert derived
from this data). This should also simplify implementations.
It can also give OIDs while leaving out the associated values, which
means that the client is expected to fill this in.
This scheme also works for specifying the type of the public key, where
an AlorithmIdentifier can be given with an empty key value.

Examples would look very similar to the one given in Lightweight CMP
Profile Appendix A with the difference being that
there the structure used is of type CertTemplate, while for EST it will
be of type CertificationRequestInfo as in PKCS#10, 
embedded in a simple CsrAttr sequence with one element containing the
"attribute" choice with the new OID for CertificationRequestInfo.

David

On Thu, 2023-06-15 at 16:00 -0700, internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Limited
> Additional
> Mechanisms for PKIX and SMIME (LAMPS) WG of the IETF.
> 
>    Title           : Clarification of RFC7030 CSR Attributes
> definition
>    Authors         : Michael Richardson
>                      Owen Friel
>                      Dr. David von Oheimb
>                      Dan Harkins
>    Filename        : draft-ietf-lamps-rfc7030-csrattrs-04.txt
>    Pages           : 13
>    Date            : 2023-06-15
> 
> Abstract:
>    The Enrollment over Secure Transport (EST, RFC7030) is ambiguous in
>    its specification of the CSR Attributes Response.  This has
> resulted
>    in implementation challenges and implementor confusion.
> 
>    This document updates RFC7030 (EST) and clarifies how the CSR
>    Attributes Response can be used by an EST server to specify both
> CSR
>    attribute OIDs and also CSR attribute values, in particular X.509
>    extension values, that the server expects the client to include in
>    subsequent CSR request.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030-csrattrs/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-lamps-rfc7030-csrattrs-04.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lamps-rfc7030-csrattrs-04
> 
> Internet-Drafts are also available by rsync at
> rsync.ietf.org::internet-drafts
> 
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
> 