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

P.S. Some things I forgot to answer/comment on in my below email:

> > but how backwards compatible is it?

The newly suggested approach is fully backward compatible.

Note that it does not touch the existing ASN.1 syntax at all,
only a new attribute type with a new OID and dependent type is defined.
Existing clients and servers can continue as before.

I'd suggest that a new server MUST (or just SHOULD ?) use the new
approach
as long as it can expect that its clients will understand it,
and that new clients MUST handle the new attribute if present,
and otherwise MUST fall back to the old approach.

If a new server uses the new approach and really wants to specify the
hash algorithm
to use for the PKCS#10 self-signature (though I see no real use for
doing this, see below),
it can do so essentially in the same way as suggested before, namely by
providing
an extra attribute with a suitable OID. In this case, for consistency
with the new approach,
this MUST not be done at the outer level (as an extra CsrAttrs sequence
element),
but as part of the new embedded CertificationRequestInfo structure.

David

On Thu, 2023-06-22 at 18:58 +0200, David von Oheimb wrote:
> 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 thorough
> 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
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm