Subject: Re: [lamps] ASN.1 Module in draft-ietf-lamps-cmp-updates

From: Russ Housley <[email-masked]>
Date: Sat, 1 May 2021 17:29:19 -0400

Hendrik:

Now that we have the ASN.1 in A.2 sorted out, I started looking at the older syntax in A.1.

I cannot find a source of the PKCS-9 module that uses the older syntax.  You are IMPORTing a very simple thing.  Maybe the best way forward is to just define it in you module with a coment that it matches the attribute defined in PKCS-9.

The Certificate is being IMPORTed from RFC2459.  I thin you should IMPORT from RFC 5280.

I am sure there is more to find, but I am kind of stuck at this point.

Russ

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 3 May 2021 15:35:37 +0000

Russ: 

Thank's for checking the ASN.1

> Von: Russ Housley <[email-masked]>
> Gesendet: Samstag, 1. Mai 2021 23:29
> 
> Hendrik:
> 
> I cannot find a source of the PKCS-9 module that uses the older syntax.  You are
> IMPORTing a very simple thing.  Maybe the best way forward is to just define it
> in you module with a coment that it matches the attribute defined in PKCS-9.

I use the definition of localKeyId from RFC 2985. If I cannot directly import it, I guess I need to IMPORT octetStringMatch from X.501 instead.

   selectedAttributeTypes
           FROM UsefulDefinitions {joint-iso-itu-t ds(5) module(1)
           usefulDefinitions(0) 3}

   octetStringMatch
           FROM SelectedAttributeTypes selectedAttributeTypes

And then I can add the syntax of localKeyId

   -- Syntax needed from RFC 2985
   -- Object Identifiers

   pkcs-9 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
                                 rsadsi(113549) pkcs(1) 9}

   pkcs-9-at-localKeyId               OBJECT IDENTIFIER ::= {pkcs-9 21}

   localKeyId ATTRIBUTE ::= {
           WITH SYNTAX OCTET STRING
           EQUALITY MATCHING RULE octetStringMatch
           SINGLE VALUE TRUE
           ID pkcs-9-at-localKeyId
   }

> The Certificate is being IMPORTed from RFC2459.  I thin you should IMPORT

I would change 
id-pkix1-explicit-88(1) --> id-pkix1-explicit-88(18)
id-pkix1-implicit-88(2) --> id-pkix1-implicit-88(19)

Hendrik

---

From: Russ Housley <[email-masked]>
Date: Mon, 3 May 2021 11:57:21 -0400

Hendrik:

I think we are talking past each other.

ATTRIBUTE is a CLASS, and the 1988 ASN.1 syntax hoes not support CLASS.  That was the biggest change in the newer syntax.

In the 1988 ASN.1 syntax, an attribute is defined with:

   -- attribute data types --

   Attribute       ::=     SEQUENCE {
        type            AttributeType,
        values  SET OF AttributeValue
                -- at least one value is required -- }

   AttributeType           ::=   OBJECT IDENTIFIER

   AttributeValue          ::=   ANY

So, the common name attribute is defines with an OID and a type:

   id-at           OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4}

   id-at-commonName        AttributeType   ::=     {id-at 3}

   X520CommonName  ::=      CHOICE {
      teletexString         TeletexString (SIZE (1..ub-common-name)),
      printableString       PrintableString (SIZE (1..ub-common-name)),
      universalString       UniversalString (SIZE (1..ub-common-name)),
      utf8String            UTF8String (SIZE (1..ub-common-name)),
      bmpString             BMPString (SIZE(1..ub-common-name))   }

   ub-common-name  INTEGER ::=     64

Maybe you can find an 1988 ASN.1 version of PKCS-9, but I did not.

If one cannot be found, the this module will need to include something like:

  localKeyIdSyntax ::= OCTET STRING

Of course a comment to explain the relationship is needed.

Russ

> On May 3, 2021, at 11:35 AM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Russ: 
>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Tue, 4 May 2021 06:31:24 +0000

Russ

Thank you for helping me with the ASN.1!
I have to admit, am no expert ASN.1 syntax and the differences of the different versions. Therefore, I really appreciate your support.
Before providing an update of the draft, I want to make sure to understand your suggestion correctly.

The situation is:
- There is no PKCS-9 module in ASN.1 1988 syntax.
- Therefore, I cannot import localKeyId and have to add appropriate syntax for it in ASN.1 1988 syntax to Appendix A.1

I would delete the following import 

       localKeyId
              FROM PKCS-9 {iso(1) member-body(2) us(840) rsadsi(113549)
                           pkcs(1) pkcs-9(9) modules(0) pkcs-9(1)}
       -- The import of localKeyId is added due to the updates made in
       -- CMP Updates [thisRFC]

And add this syntax into the 1988 ASN.1 module 

   -- There is no 1988 ASN.1 module of PKCS#9 available to import the syntax of 
   -- the localKeyId attribute type and value from. Therefore, the syntax is added 
   -- here as needed for the updates made in CMP Updates [thisRFC].

 

Is this sufficient?
Is there a specific place in the A.1 where to add this section?

Hendrik

> ATTRIBUTE is a CLASS, and the 1988 ASN.1 syntax hoes not support CLASS.  That
> was the biggest change in the newer syntax.
> 
> >> I cannot find a source of the PKCS-9 module that uses the older
> >> syntax.  You are IMPORTing a very simple thing.  Maybe the best way
> >> forward is to just define it in you module with a coment that it matches the
> attribute defined in PKCS-9.
> >
> > I use the definition of localKeyId from RFC 2985. If I cannot directly import it, I
> guess I need to IMPORT octetStringMatch from X.501 instead.
> >
> >   selectedAttributeTypes

---

From: Russ Housley <[email-masked]>
Date: Tue, 4 May 2021 09:08:53 -0400

That looks fine to me.  That would solve the issue that I raise.

Russ

> On May 4, 2021, at 2:31 AM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Russ
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Tue, 4 May 2021 16:43:32 +0000

Just submitted the updates I-D with the agreed changes to Appendix A.1

Hendrik

> > I have to admit, am no expert ASN.1 syntax and the differences of the
> different versions. Therefore, I really appreciate your support.
> > - Therefore, I cannot import localKeyId and have to add appropriate
> > syntax for it in ASN.1 1988 syntax to Appendix A.1
> >

---

From: Russ Housley <[email-masked]>
Date: Tue, 4 May 2021 17:44:28 -0400

Thanks Hendrick.

This allowed me to proceed with further checking.  With one more change, I was about to get the module to compile.

You need to change the very last line before "END" to:

   LocalKeyIdValue ::= OCTET STRING

This needs to begin with a capital letter, or it will not compile properly.

Do not submit a new version just for this, but please make sure it happens before we are done.

Russ

> On May 4, 2021, at 12:43 PM, Brockhaus, Hendrik <[email-masked]> wrote:
>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 5 May 2021 06:06:21 +0000

Thanks for checking the ASN.1 again.

> Do not submit a new version just for this, but please make sure it happens

I noted the change for the next version.

Hendrik