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

Russ Housley <housley@vigilsec.com> Thu, 14 April 2005 16:50 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01603 for <pkix-archive@lists.ietf.org>; Thu, 14 Apr 2005 12:50:23 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EG0lCL036753; Thu, 14 Apr 2005 09:00:47 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EG0klD036752; Thu, 14 Apr 2005 09:00:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3EG0jB1036744 for <ietf-pkix@imc.org>; Thu, 14 Apr 2005 09:00:45 -0700 (PDT) (envelope-from housley@vigilsec.com)
Received: (qmail 17427 invoked by uid 0); 14 Apr 2005 15:00:39 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.165.114) by woodstock.binhost.com with SMTP; 14 Apr 2005 15:00:39 -0000
Message-Id: <6.2.0.14.2.20050414104914.0505b020@mail.binhost.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Thu, 14 Apr 2005 11:00:39 -0400
To: Peter Sylvester <Peter.Sylvester@edelweb.fr>
From: Russ Housley <housley@vigilsec.com>
Subject: draft-ietf-pkix-rfc3770bis-01: OID Import
Cc: ietf-pkix@imc.org
In-Reply-To: <200504140849.j3E8nim01640@chandon.edelweb.fr>
References: <200504140849.j3E8nim01640@chandon.edelweb.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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.

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.

I would rather not have to make these kinds of edits, so I prefer to 
duplicate simple constants like OID arcs.

Russ