Re: [lamps] struggling with CSRAttrs

[Michael Richardson <[e-mail]>]

David von Oheimb <[e-mail]> wrote:
    > Let's keep the original field names.  Also because this underlines the
    > important fact that we do not change the ASN.1 syntax at all, which is
    > critical for bits-on-the-wire compatibility, but we just clarify its
    > use and interpretation.

I'm okay with that.

    > I've just made a pass on lamps-rfc7030-csrattrs.mkd in the GitHub
    > repository.  Its new version contains various suggestions for
    > improvements here and there.  Also updated the subjectAltName example
    > to be of the more usual form of a dNSName and inserted two
    > questions/remarks:

Why did you change the RFC8994/ACP example from a real acp example name to domain.example?
Is there a reason not to include the line numbers from dumpasn1?

In the actual content, it goes from having the critical value shown, to
having:

+        OCTET STRING, encapsulates {
+          SEQUENCE {
+            [2] 'domain.example'
+            }
+          }
+        }

which I don't understand at all.  Is this a different dumpasn1 version?
if not, what are the actual bits on the wire changes?

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

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

    > I also corrected the spelling of my (co-author's) name in
    > presentations/ietf114-lamps-csrattrs.{fodp,pdf}.

Sorry about that.


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide