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

[Michael Richardson <[e-mail]>]

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 :-)
If this is something you want to add, then let's do it.

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

    > * 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?

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

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

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

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [