Subject: [Spasm] ATTRIBUTE ASN.1 information object class

From: "Erik Andersen" <[email-masked]>
Date: Tue, 6 Jun 2017 11:04:06 +0200

@ Jean-Paul and Paul, there is a question to you somewhere below.

RFC 7030, Enrollment over Secure Transport (EST), have in section 4.2.1 a
reference to an attribute type called ChangeSubjectName defined in RFC 6402.
The EST specification is potentially going to be used in smart grid
security.

RFC 6402 defines this attribute type as:

at-cmc-changeSubjectName ATTRIBUTE ::=     { TYPE ChangeSubjectName
IDENTIFIED BY id-cmc-changeSubjectName }

This looks very different from an "ordinary" attribute specifications. The
ATTRIBUTE ASN.1 object class is imported from RFC 5912, where you will find 

ATTRIBUTE ::= CLASS {

&id             OBJECT IDENTIFIER UNIQUE,

&Type           OPTIONAL,

&equality-match MATCHING-RULE OPTIONAL,

&minCount       INTEGER DEFAULT 1,

&maxCount       INTEGER OPTIONAL  

WITH SYNTAX {

[TYPE           &Type]

[EQUALITY MATCHING RULE &equality-match]

[COUNTS [MIN &minCount] [MAX &maxCount]]

IDENTIFIED BY &id  }

This is a redefinition of the ATTRIBUTE information object class that has
been defined in Rec. ITU-T X.501 | ISO/IEC 9594-2 since the stone age. This
is in my opinion a NO-NO. It seems quite inappropriate in ITU-T
recommendations and in International Standards, such a smart grid security
standards, to reference any IETF attribute type specified using this
modified information object class. We wold in some case have to import both
ATTRIBUTE from RFC 5912 and from X.501 into the same module. This will not
work. It will also cause confusion with IETF. EST references both the  PKCS
#9 attributes types (RFC 2985) specified using the X.501 information object
class and the changeSubjectName specified using the modified information
object class.

It appears that in case where we need to reference an attribute type
specified using the alternative ATTRIBUTE information object class, we have
to redefine such attribute types using the X.501 information object class.
Here comes the question to the ASN.1 guys: Can we do that without changing
the object reference and the object identifier?   

Best regard,

Erik

---

From: Russ Housley <[email-masked]>
Date: Tue, 6 Jun 2017 09:53:01 -0400

Erik:

There was a huge change in the handling of Attribute between X.501-1989 and X.501-1993.  The syntax in RFC 5912 seems to use the modern ASN.1, but the older Attribute semantics.

Russ

> On Jun 6, 2017, at 5:04 AM, Erik Andersen <[email-masked]> wrote:
> 
> RFC 7030, Enrollment over Secure Transport (EST), have in section 4.2.1 a reference to an attribute type called ChangeSubjectName defined in RFC 6402. The EST specification is potentially going to be used in smart grid security.
>  
> at-cmc-changeSubjectName ATTRIBUTE ::=     { TYPE ChangeSubjectName IDENTIFIED BY id-cmc-changeSubjectName }
>  
> This looks very different from an “ordinary” attribute specifications. The ATTRIBUTE ASN.1 object class is imported from RFC 5912, where you will find 
>  
> ATTRIBUTE ::= CLASS {
> This is a redefinition of the ATTRIBUTE information object class that has been defined in Rec. ITU-T X.501 | ISO/IEC 9594-2 since the stone age. This is in my opinion a NO-NO. It seems quite inappropriate in ITU-T recommendations and in International Standards, such a smart grid security standards, to reference any IETF attribute type specified using this modified information object class. We wold in some case have to import both ATTRIBUTE from RFC 5912 and from X.501 into the same module. This will not work. It will also cause confusion with IETF. EST references both the  PKCS #9 attributes types (RFC 2985) specified using the X.501 information object class and the changeSubjectName specified using the modified information object class.
>  
> It appears that in case where we need to reference an attribute type specified using the alternative ATTRIBUTE information object class, we have to redefine such attribute types using the X.501 information object class. Here comes the question to the ASN.1 guys: Can we do that without changing the object reference and the object identifier?   
>  
> Best regard,
>  
> Erik

---

From: Paul Thorpe <[email-masked]>
Date: Tue, 6 Jun 2017 07:42:07 -0700 (Pacific Daylight Time)

Hi Erik,

Jean-Paul gave a similar answer to what I had in mind when I saw your 
message.  You could import both definitions of ATTRIBUTE, but would need 
to prefix them with the module name from which they came when you 
referenced them to indicate which one you are referring to.

----------------------------------------------------------------------------
Paul E. Thorpe                                 Toll Free    : 1-888-OSS-ASN1
OSS Nokalva                                    International: 1-732-302-0750
Email: [email-masked]                          Tech Support : 1-732-302-9669
http://www.oss.com                             Fax          : 1-732-302-0023

On Tue, 6 Jun 2017, Erik Andersen wrote:

> RFC 7030, Enrollment over Secure Transport (EST), have in section 4.2.1 a reference to an attribute type
> called ChangeSubjectName defined in RFC 6402. The EST specification is potentially going to be used in
> smart grid security.
>
> 
> 
> This looks very different from an “ordinary” attribute specifications. The ATTRIBUTE ASN.1 object class is
> imported from RFC 5912, where you will find
>
> 
> 
> ATTRIBUTE ::= CLASS {
> 
> This is a redefinition of the ATTRIBUTE information object class that has been defined in Rec. ITU-T X.501
> | ISO/IEC 9594-2 since the stone age. This is in my opinion a NO-NO. It seems quite inappropriate in ITU-T
> recommendations and in International Standards, such a smart grid security standards, to reference any IETF
> attribute type specified using this modified information object class. We wold in some case have to import
> both ATTRIBUTE from RFC 5912 and from X.501 into the same module. This will not work. It will also cause
> confusion with IETF. EST references both the  PKCS #9 attributes types (RFC 2985) specified using the X.501
> information object class and the changeSubjectName specified using the modified information object class.
>
> 
> 
> It appears that in case where we need to reference an attribute type specified using the alternative
> ATTRIBUTE information object class, we have to redefine such attribute types using the X.501 information
> object class. Here comes the question to the ASN.1 guys: Can we do that without changing the object
> reference and the object identifier? 
>
> 
> 
> Best regard,
>
> 
> 
> Erik 
> 
> 
>

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 6 Jun 2017 16:50:35 +0200

Hi Russ,

Yes, it is true that the first edition of X.501 used the terrible ASN.1 macro notation and that the ATTRIBUTE specification was changed to using ASN.1 information object class in the 1993 edition. So the current ATTRIBUTE notation has been around maybe not from the stone age, but since 1993. The syntax in RFC 5912 is quite different from the one that has been in X.501 since 1993.  The syntax in RFC 5912 is not the same as the modern ASN.1 from X.501.  I acknowledge that semantics is almost the same and that the bits on the line are the same.

Erik

Fra: Russ Housley [mailto:[email-masked]] 
Sendt: 06 June 2017 15:53
Til: Erik Andersen <[email-masked]>
Cc: LAMPS <[email-masked]>; Carsten Strunge <[email-masked]>; Paul Thorpe <[email-masked]>; Jean-Paul LEMAIRE <[email-masked]>
Emne: Re: [Spasm] ATTRIBUTE ASN.1 information object class

Erik:

Russ

On Jun 6, 2017, at 5:04 AM, Erik Andersen <[email-masked] <mailto:[email-masked]> > wrote:

ATTRIBUTE ::= CLASS {

&Type           OPTIONAL,

WITH SYNTAX {

[TYPE           &Type]

IDENTIFIED BY &id  }

Best regard,

Erik

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 6 Jun 2017 17:59:35 +0200

Hi Paul,

Thanks for your comment. I was not aware that we could prefix with module name. However, doing this makes our specification unnecessary messy and more difficult to understand. There will be a need for some rather complicated notes to explain why we are using two different notations for the same thing.

Do you agree with Jean-Paul that it from an ASN.1 point of view would be legal to redefine RFC 5912 attribute types using the same object name and object identifier or should we define completely new replacement attribute types. We will run into the same issue when defining the CMS profile.

Will the following be legal?

Changing

at-cmc-changeSubjectName ATTRIBUTE ::=     { 
  TYPE ChangeSubjectName 
  IDENTIFIED BY id-cmc-changeSubjectName }

to

 at-cmc-changeSubjectName ATTRIBUTE ::=     {
  SYNTAX  ChangeSubjectName 
  ID           id-cmc-changeSubjectName }

Kind regards,

Erik

-----Oprindelig meddelelse-----
Fra: Spasm [mailto:[email-masked]] På vegne af Paul Thorpe
Sendt: 06 June 2017 16:42
Til: Erik Andersen <[email-masked]>
Cc: LAMPS <[email-masked]>; Carsten Strunge <[email-masked]>; Jean-Paul LEMAIRE <[email-masked]>
Emne: Re: [Spasm] ATTRIBUTE ASN.1 information object class

Hi Erik,

Jean-Paul gave a similar answer to what I had in mind when I saw your message.  You could import both definitions of ATTRIBUTE, but would need to prefix them with the module name from which they came when you referenced them to indicate which one you are referring to.

On Tue, 6 Jun 2017, Erik Andersen wrote:

> RFC 7030, Enrollment over Secure Transport (EST), have in section 
> 4.2.1 a reference to an attribute type called ChangeSubjectName 
> defined in RFC 6402. The EST specification is potentially going to be used in smart grid security.
>
> 
> 
> This looks very different from an “ordinary” attribute specifications. 
> The ATTRIBUTE ASN.1 object class is imported from RFC 5912, where you 
> will find
>
> 
> 
> ATTRIBUTE ::= CLASS {
> 
> | ISO/IEC 9594-2 since the stone age. This is in my opinion a NO-NO. 
> | It seems quite inappropriate in ITU-T
> recommendations and in International Standards, such a smart grid 
> security standards, to reference any IETF attribute type specified 
> using this modified information object class. We wold in some case 
> have to import both ATTRIBUTE from RFC 5912 and from X.501 into the 
> same module. This will not work. It will also cause confusion with IETF. EST references both the  PKCS #9 attributes types (RFC 2985) specified using the X.501 information object class and the changeSubjectName specified using the modified information object class.
>
> 
> 
> specified using the alternative ATTRIBUTE information object class, we 
> have to redefine such attribute types using the X.501 information 
> object class. Here comes the question to the ASN.1 guys: Can we do that without changing the object reference and the object identifier?
>
> 
> 
> Best regard,
>
> 
> 
> Erik
> 
> 
>

---

From: Paul Thorpe <[email-masked]>
Date: Tue, 6 Jun 2017 09:10:32 -0700 (Pacific Daylight Time)

Hi Erik,

I see no problem with that kind of change as long as the class definition 
components are compatible.  The "TYPE", "IDENTIFIED BY", "SYNTAX" and "ID" 
are not critical to the definitions.  Changing those words does not alter 
the underlying class definition.  They potentially make it easier for a 
human reader to understand the object definitions while writing them.