Subject: Re: draft-ietf-pkix-rfc3770bis-01: OID Import

From: Peter Sylvester <[email-masked]>
Date: Fri, 15 Apr 2005 10:25:16 +0200 (MEST)

> >
> >Now you say that it is not a matter of taste.
> 
> No.  I shared the reason that I prefer to include the OIDs rather than 
> IMPORTing them.  They both work.

I say that what you give as a reason is not a matter of taste.

And your reasoning tries to just justify technical hack.

What you are technically doing is to define a new element in the
pkix kp arc in this module. I have not see that you have obtained
authorisation to do this from the owner of the pkix kp arc. 

> >By the way, further down the example is an import of something that is NOT 
> >SIMPLE.
> >
> >Using this technique requires to keep track of all copies, and IF a
> >copied definitions changes slightly in the main definition module
> >THEN you get inconsistencies.
> 
> True.  Neither of the alternatives is perfect.  They have different kinds 
> of pain.

There is nothing wrong in IMPORT in this particular case.
IMO it is PERFECTLY in line with all (what I know) of ASN1 etc. 

We are not etalking about pains created by difficulties of correct
organisation of ASN.1 modules or using current and non-obsolete syntax
versions. 
 
> > > I have had to make edits to old ASN.1 modules to avoid errors that are
> > > introduced when one modules imports stuff from another that imports stuff
> > > from another that imports stuff from another.  The changes are almost
> > > always in parts that are not needed for the part that is needed.  I'll 
> > give
> > > a recent example.
> > >
> > > RFC 2634 imports from CMS.  The ASN.1 module says:
> > >
> > > -- RFC 2630: Cryptographic Message Syntax (CMS)
> > >      ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
> > >      FROM CryptographicMessageSyntax
> > >         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
> > >           pkcs-9(9) smime(16) modules(0) cms(1) }
> > >
> > > I needed to change this to:
> > >
> > > -- RFC 3852: Cryptographic Message Syntax (CMS)
> > >      ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
> > >      FROM CryptographicMessageSyntax2004
> > >         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
> > >           pkcs-9(9) smime(16) modules(0) cms-2004(24) }
> > >
> > > Why?  It did not have anything to do with ContentType,
> > > IssuerAndSerialNumber, or SubjectKeyIdentifier.  It had to do with
> > > something else in the RFC 2630 module.
> >
> >Do you mean the usage of 'Name' which is used in IssuerAndSerialNumber?
> >You don't change the definition of a module. You make a new one.
> >I don't see the point.
> 
> This module also had in import from RFC 3280, and the RFC 2634 imported 
> from RFC 2630, which had an import from RFC 2459, there was some 
> conflict.  I do not recall more detail than that.  By shifting the import 
> to RFC 3852, the subordinate import shifted to RFC 3280, resolving the 
> conflict.

Sorry, arguments that are not explained have no meaning to me. 
Anyway, if there was a problem and a REAL conflict, i.e. a different
definition, then duplication of the elements using same name
would have created more problems because you don't keep track.
if in your case the definitions do not change, I don't see why
you need to import then from a different place.

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 15 Apr 2005 10:14:47 -0400

>organisation of ASN.1 modules or using current and non-obsolete syntax

This gets to the real problem.  If the entire pkix OID registry
(http://www.imc.org/ietf-pkix/pkix-oid.asn) were maintained
as an ASN.1 module and always IMPORTed, this would
eliminate problems caused by importing modules containing both
structures and OIDs when only the OIDs are needed.

Given that there is not yet a "pkix-useful-definitions" module, Russ'
strategy of local definitions is a reasonable workaround:

1) an OID, once assigned, can never change so there is no danger
of an initially-correct copy getting out of sync with the original.
(An OID can be deprecated, but its meaning cannot be modified.)

2) the name assigned to an OID has only local scope, and
many names can be assigned to the same OID without causing
problems (other than confusing readers).   One module can
locally define "id-bogus-aca"  and use that name within the module
and still interoperate successfully with a different module
that IMPORTs "id-aca" from PKIXAttributeCertificate.

Recommendation: create a module containing only PKIX
constant definitions (OIDs, bounds, etc).  Start importing
it into other modules as they are revised for other reasons.