[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


Peter:


> Note:  I am starting a separate thread for each of the unresolved
> issues.  I hope this draws more people into the discussion.
>
> Peter:
>
> > > >4 *** The OID arcs should be imported from
> > > >
> > > >
> > > >IMPORTS
> > > >
> > > >    id-pe, id-kp
> > > >    FROM PKIX1Explicit88 { iso(1) identified-organization(3)
> > > >             dod(6) internet(1) security(5) mechanisms(5) pkix(7)
> > > >             id-mod(0) id-pkix1-explicit(18) }
> > > >
> > > >    id-aca FROM
> > > >    PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
> > > > internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 
> > > >                 id-mod-attribute-cert(12)}
> > >
> > > This is a matter of taste.  Neither approach leads to implementation
> > issues.
> >
> >Since, as you say, there are no implmentation issues. but this is not
> >a matter of taste. Importing the correct definition is something else
> >that making the 'hopefully' identical one.
> >
> >There is ONE authoritive place to have 'this' id-aca defined.
> >(and another id-aca elsewhere)
>
> I do not know about other people, but would rather avoid IMPORT statements
> for simple things.  IMPORT is a great tool for complex structures, but for
> a simple constant, it is not worth the effort.

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.
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. 


> 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. 

Russ