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

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

Hi Michael,

thank you for planning on a design meeting on this topic.
Next week for me on each day anything between 15:00 and 22:00 CEST (1 to
8 PM GMT) will work,
except (as usual) Tue after 17:30 CEST.
The week after that would work for me somewhat less well - no possible
time on Tue 7/11,
and on Wed 7/12 only until 18:00 CEST.

David


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