[lamps] Re: I-D Action: draft-ietf-lamps-fn-dsa-certificates-00.txt

[Michael StJohns <[e-mail]>]

On 5/27/2026 11:31, Carl Wallace wrote:
>
> This is not specific to this spec, but re: "-- PRIVATE-KEY no ASN.1 
> wrapping; YYYY octets --", there seems to be emerging awareness that 
> the CONTAINING clauses do not allow for the type be omitted. Do we 
> want to continue abusing that syntax (and essentially relegate the 
> constraint to a comment), accept a tag/length for the value, drop the 
> constraints (and codify comment as constraint), or try to figure a way 
> to shoehorn raw bytes into a field with an ASN.1 constraint (possibly 
> by abusing ENCODED BY to define something like the unwrap operator in 
> CBOR).
>
>

Hi Carl -

I believe that this -

    pk-fn-dsa-512 PUBLIC-KEY ::= {
       IDENTIFIER id-fn-dsa-512
       -- KEY no ASN.1 wrapping; XXXX octets --

       KEY FN-DSA-512-PublicKey (ENCODED BY oer)
       PARAMS ARE absent
       CERT-KEY-USAGE { digitalSignature, nonRepudiation,
                        keyCertSign, cRLSign }
       -- PRIVATE-KEY no ASN.1 wrapping; YYYY octets --

       PRIVATE-KEY FN-DSA-PrivateKey (ENCODED BY oer)
       }

    oer OBJECT IDENTIFIER ::= {joint-iso-itu-t asn1 (1) oer-encoding (6)
    basic (0) }

When used with this:

       SubjectPublicKeyInfo  ::=  SEQUENCE  {
           algorithm            AlgorithmIdentifier{PUBLIC-KEY,
                                    {PublicKeyAlgorithms}},
           subjectPublicKey
               BIT STRING (CONTAINING PUBLIC-KEY.&KeyValue(
                              {PublicKeyAlgorithms}{@algorithm.algorithm})
    }

Does what you want.

X.696 - Octet Encoding Rules (See section 8.5) - treats anything inside 
a CONTAINING clause as not needing either type or length fields on the 
outermost type of the contained object. (Because the type can be 
inferred from the definition, and the length can be inferred by the BIT 
STRING or OCTET STRING containing that object - and for these keys also 
by the SIZE() constraint on the object definition).   If the object is 
structured (e.g. SEQUENCE {}), this doesn't work as cleanly, but mostly 
we're finding a need for this construct with raw'ish key material.

Strangely, Jim Schaad had defined a similar construct for the 
SIGNED{ToBeSigned} macro (which is different than the macro in X.509) 
but didn't carry it through to the SubjectPublicKeyInfo or 
PrivateKeyInfo.    PrivateKeyInfo would look like this:

      PrivateKeyInfo ::= SEQUENCE {
          version                   INTEGER,
          privateKeyAlgorithm       AlgorithmIdentifier{PUBLIC-KEY, {...}},
          privateKey
              OCTET STRING (CONTAINING PUBLIC-KEY.&PrivateKey(
               {PublicKeyAlgorithms}{@privateKeyAlgorithm.algorithm}),
          attributes                [0] IMPLICIT Attributes OPTIONAL
       }


Mike