Subject: [smime] Review on S/MIME OIDs

From: "Jim Schaad" <[email-masked]>
Date: Tue, 22 Oct 2013 15:50:37 -0700

Russ,

Here are some review comments as part of doing the Shepard Write-up.

1.  The ASN1-97 reference should be updated to the latest version.  I
currently have these as 11/2008.

2.  The root of the arc should be

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

(addition of a name for the last number in the list)

3.  In section 3.2, I am not sure that I understand what the description
field is supposed to indicate.  I expect this to be a descriptive field, and
thus not need the hyphens.  I would also expect that the table should
probably include the tag that is used for the field when it exists in an
ASN.1 file.  Thus it would be

0   Module Identifiers   mod  [This RFC]

4.  There is a naming philoshpy change that occurred part of the way through
our use of the arc  This means that the string id-mod-domsec does not appear
in RFC 3274, instead it simply uses domsec for the assigned name of the arc.
Should this document be using the same names as are in the actual ASN.1
modules or should we be using the new strings that do not appear in the
modules.

5.  Should we publish the current ASN.1 module as an informational appendix?
It might be useful for people to look at

Jim

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 Oct 2013 10:42:07 -0400

> currently have these as 11/2008.

Isn't that ASN1-08?

I chose to reference the two incompatible versions of the syntax.

> (addition of a name for the last number in the list)

Doing this would define two labels, smime and id-smime.

> 0   Module Identifiers   mod  [This RFC]

I'm fine with removing the hyphens.  I do not see the value in the "mod" column.  It is just a convention that I used to help me manage the OID registry.

> modules or should we be using the new strings that do not appear in the

There was no change in the convention.  Some RFCs use a module name other than the object identifier.  I do not see that as a problem.

> 5.  Should we publish the current ASN.1 module as an informational appendix?

Subsequent additions to the registry would make the module incomplete.  So, the value would be fleeting.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 23 Oct 2013 09:42:42 -0700

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Wednesday, October 23, 2013 7:42 AM
> To: Jim Schaad
> Cc: 'Sean Turner'; [email-masked]
> Subject: Re: Review on S/MIME OIDs
> 
> Jim:
> 

And I agree that you should.  I think you should reference ASN1-88 and
ASN1-08.  You currently have 88 and 97.  While I agree that 97 and 08 are
basically compatible, it makes sense to use the latest version.

> Doing this would define two labels, smime and id-smime.

No this does not define two labels.  The label inside of the object
identifier is not in the same namespace as the one on the left hand side.

> 
> > 3.  In section 3.2, I am not sure that I understand what the
> > description field is supposed to indicate.  I expect this to be a
> > descriptive field, and thus not need the hyphens.  I would also expect
> > that the table should probably include the tag that is used for the
> > field when it exists in an
> I'm fine with removing the hyphens.  I do not see the value in the "mod"
> column.  It is just a convention that I used to help me manage the OID
> registry.

Again, there are two names, the name of the module which does not need to be
in this table because we don't need to register that and the name in the OID
arc which is a different name space and should be part of this registration
table.

> 
> > 4.  There is a naming philoshpy change that occurred part of the way
> > through our use of the arc  This means that the string id-mod-domsec
> > does not appear in RFC 3274, instead it simply uses domsec for the
> assigned name of the arc.
> > Should this document be using the same names as are in the actual
> > ASN.1 modules or should we be using the new strings that do not appear
> > in the modules.
> 
> There was no change in the convention.  Some RFCs use a module name
> other than the object identifier.  I do not see that as a problem.

Again, I am looking at the name in the oid arc and not the name of the
module.  Different namespaces.

> So, the value would be fleeting.

True, but it might be useful short term.  I don't have any drastic need to
do this.  It would just be useful for checking things.

Jim