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

[David von Oheimb <[e-mail]>]

On Wed, 2023-06-21 at 15:37 -0400, Michael Richardson wrote:
> 
> David von Oheimb <[e-mail]> wrote:
>     > thank you for the update.
> 
>     > The draft (so far) solves reasonably well the very specific
> issue
>     > described in the intro,
> 
> well... you are co-author already :-)

Yes, and I already contributed various parts around early August last
year.

> If this is something you want to add, then let's do it.

I've just pushed a couple of minor improvements.
Yet before I contribute any more substantial things, 
all authors should be in agreement on the way forward.
How about having a design call on this?


>     > * 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')
> 
> Given that we want to stop looking at DNs, I hadn't considered this
> mattered,
> but I agree that there are many cases where it does.  I think that it
> should
> already be possible, but it's escaping me right now to think how it is
> specified in the CSR.

Two years back I mentioned several options how it could be done.
With the new idea it can be done most naturally: as a DN (pattern).


>     > * the spec how to interpret algorithm OIDs is very weak: just by
> means
>     > of a few examples - no systematic semantic rules are given
> 
> That's a reasonable criticism.
> 
>     > * there are no rules preventing conflicting "algorithm
> requirements",
>     > such as OID ecdsaWithSHA384 and OID SHA256,
> 
> You are right.  So what does a client do when it see such a thing?

As I wrote in the other current thread on csrattrs, 
IMO an RFC should not specify any resolution strategy on malformed
CsrAttrs but
just rule out that such nonsensical or ambiguous CsrAttrs are provided
by the server.


>     > * nothing general is specified how to use and interpret the
> multitude
>     > of other OIDs that could potentially be given
> 
> True.
> 
>     > * 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.
> 
> okay, so I'm open to this idea, but how backwards compatible is it?
> Maybe the WG doesn't care.  I just want to specify the SAN.

Pleased to hear that you are open to this new idea for a more through
solution.
What do others think?


>     > 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.
> 
> So, it would replace the SAN method here too.

Yep - it would be implied naturally by the way SANs are to be specified
in PKCS#10 CSRs.


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

BTW, the only thing I am aware of that does not structurally fit in such
a PKCS#10 pattern
is what has been given in the original CsrAttrs example used also in the
new document:
An OID such as ecdsaWithSHA384 intended to indicate what kind of hash
alg is expected 
to be used for the self-signature of the PKCS#10 CSR structure.

I see no real value in specifying the hash algorithm to use for the CSR
self-signature.
Note that anyway this hash alg and value will not become part of the
certificate requested,
and that the type of the public key can be specified by other, more
direct means:
by giving in the subjectPublicKeyInfo field an AlgorithmIdentifier
indicating 
the key type and an empty subjectPublicKey BIT STRING.

Hmm, I just realized that (as opposed to the certificate template
structure of CRMF),
the subject and subjectPublicKeyInfo fields are not optional. Yet we can
simply specify that
 * in case the server has no requirements on the subject field,
   it MUST provide a NULL-DN (which is the empty sequence of RDNs)
 * in case it does not have requirements on the type of the public key,
   it MUST provide an AlgorithmIdentifier with a NULL OID and empty
   parameters.

David