Re: [lamps] struggling with CSRAttrs

[Michael Richardson <[e-mail]>]

{sorry for the time warp mail}

David von Oheimb <[e-mail]> wrote:
    mcr> Is there a reason not to include the line numbers from dumpasn1?

    > Actually there are two reasons:

    >  * those numbers are byte offsets and lengths, which are not important
    > here and just add clutter

okay, but they might help someone who was trying to understand the example.

    > * the numbers would be very cumbersome to
    > keep consistent when adapting the example

This isn't hard to manage if we store DER files into the repo, and generate
the dumpasn1 in the Makefile.

   > See also the emails by Corey and me in this thread of Aug 2nd.

Yes, I'm now clued in to what's going on.

    >> >    (TODO: Do we want to allow an empty extnValue (which is of type >
    >> OCTET STRING), which would mean that the client is told to include >
    >> an X.509 extension of the given type and fill in the concrete value >
    >> itself?)
    >>
    >> Yes, I thought we allowed exactly that before, as:
    >>
    >> Attribute: type = extensionRequest (1.2.840.113549.1.9.14) value =
    >> macAddress (1.3.6.1.1.1.1.22)
    >>
    >> in RFC7030.

    > Good point that this effect could already be achieved by such a type of
    > CSR attribute that is different from the "new" approach using a CSR
    > attribute of type extensionRequest.  Yet IMO the new approach is more
    > adequate because there the (request for an) extension is in the context
    > of the extensionRequest attribute, rather than "out of place" in some
    > other attr, where its OID is harder to understand and to process
    > without this context.  So I'd suggest stating that any such
    > to-be-filled-in extensions SHOULD be placed inside the CSR attribute of
    > type extensionRequest with an empty OCTET STRING as the extnValue.

I have captured this as:
  https://github.com/mcr/lamps-rfc7030-csrattrs/issues/8

    >>
    >> >    (TODO: Note that this mechanism does not support telling the
    >> client >    to include in the CSR a specific subject DN, simply
    >> because there is >    no OID for this.  I think we should better make
    >> this clear, or we > have to define such an OID if setting a subject
    >> name should be > supported.)
    >>
    >> I don't understand.  Telling the client to include a specific subject
    >> is exactly the problem we are dealing with... or are you making a
    >> distinction here between subject DN and subjectAltName?
    >>
    > There is a clear distinction between

    >  * a cert/CSR subject, which is (essentially) mandatory and is a
    > (Distinguished) Name and
    > * the Subject Alternative Names (SANs)
    > optionally given as X.509 extension values.

Oh, yes, I get this now.
I noticed though that one of the options for GeneralName is a DN.
I wonder if that would be meaningful, with the first DN going into the SubjectName.

However.  https://www.ietf.org/archive/id/draft-ietf-uta-rfc6125bis-07.html#appendix-A-2.2
says that we should not be using SN anymore, that it can be blank, but
of course, we can't do that in CA certificates, because the DN becomes the IN

    > As I wrote on March 9th
    > <https://mailarchive.ietf.org/arch/msg/spasm/KSBlnRVVTcgpEAM8eA_uEssHY2I/>
    > and April 5th
    > <https://mailarchive.ietf.org/arch/msg/spasm/PqCEDBk_Vd59bDDxb7hVDg41PKM/>
    > and likely already before, while SANs can be expressed as part of an
    > extensionRequest CSR attribute, a regular subject field so far cannot
    > be expressed in a CsrAttrs structure.  This is because no OID has been
    > defined that could be used, e.g., in the 'type' field of a CSR
    > attribute and the CsrAttrs structure does not have any other field
    > where a subject Name could be placed.

I guess the question is: is this something we need to fix.
Tracking in: https://github.com/mcr/lamps-rfc7030-csrattrs/issues/9

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



--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-