Subject: Re: [pkix] RFC 3279's section 2.3.5 at odds with section 3 (errata 1909)

From: <[email-masked]>
Date: Wed, 27 Jan 2010 13:12:50 +0100

Since Tim and Russ are co-authors of RFC 3279, I probably 
need to handle this errata...

It appears that the incorrect OID for id-characteristics-two-basis 
is an actual bug (even though this OID is not really used much,
especially after RFC 5480); the others are just typos that are
unlikely to cause significant confusion for anyone.

So, I would propose that we split this errata into two. The
first one would contain this, and would be marked "Verified":

Section 2.3.5 says:
      id-characteristic-two-basis OBJECT IDENTIFIER ::= {
           characteristic-two-field basisType(1) }
It should say:
      id-characteristic-two-basis OBJECT IDENTIFIER ::= {
           characteristic-two-field basisType(3) }

And the other one contains the three typos; we mark that as
"Held for Document Update".

(see http://www.ietf.org/iesg/statement/errata-processing.html 
for description about what these mean).

Tim, Russ, others: does this sound OK to you?

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Jim Wigginton
> Sent: 12 October, 2009 19:51
> To: Sean Turner
> Cc: [email-masked]
> Subject: Re: [pkix] RFC 3279's section 2.3.5 at odds with section 3
> 
> I've submitted an errata!  Would have done so earlier but I'm not
> actually super familiar with the whole RFC process.
> 
> Anyway, I also included one other issue:
> 
> Section 3 defines { pkcs-1 5 } as follows:
> 
> sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 }
> 
> Section 2.2.2 defines it as follows:
> 
> sha-1WithRSAEncryption OBJECT IDENTIFIER ::= {
> iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
> pkcs-1(1) 5 }
> 
> ie. one has a dash and the other doesn't.
> 
> On Mon, Oct 12, 2009 at 7:55 AM, Sean Turner <[email-masked]> wrote:
> > Jim,
> >
> > RFC 3279 section 2.3.5 has been updated by RFC 5480.  I believe all
> of these
> > are addressed by that update. Comments inline.
> >
> > Jim Wigginton wrote:
> >>>
> >>> From RFC 3279#section-2.3.5:
> >>
> >> ----------------------------
> >>
> >>   ansi-X9-62 OBJECT IDENTIFIER ::=
> >>                             { iso(1) member-body(2) us(840) 10045 }
> >>
> >>   When certificates contain an ECDSA or ECDH public key, the
> >>   id-ecPublicKey algorithm identifier MUST be used. The id-
> ecPublicKey
> >>   algorithm identifier is defined as follows:
> >>
> >>     id-public-key-type OBJECT IDENTIFIER  ::= { ansi-X9.62 2 }
> >>
> >>     id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }
> >>
> >> ----------------------------
> >>
> >> The "id-public-key-type OBJECT IDENTIFIER  ::= { ansi-X9.62 2 }"
> line
> >> in section 2.3.5 is problematic.  First, ansi-X9.62 isn't valid - it
> >> should be ansi-X9-62.  Second, id-ecPublicKey doesn't reference
> >> id-public-key-type - it references id-publicKeyType.  Section 3 of
> the
> >> RFC refers to it as id-publicKeyType, as well.
> >
> > We didn't use "asni-X9-62" instead we spelled out each component in
> the OID.
> >  It's more text overall, but I think clearer.
> >
> >> Also, from the same section 2.3.5...
> >>
> >> ----------------------------
> >>
> >>   ansi-X9-62 OBJECT IDENTIFIER ::=
> >>                             { iso(1) member-body(2) us(840) 10045 }
> >> ...
> >>      id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }
> >> ...
> >>      characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2
> }
> >> ...
> >>      id-characteristic-two-basis OBJECT IDENTIFIER ::= {
> >>           characteristic-two-field basisType(1) }
> >> ...
> >>      gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }
> >>
> >> ----------------------------
> >>
> >> Per all that, the OID of gnBasis should be 1.2.840.10045.1.2.1.1.
> >
> > In RFC 5480, we only allow namedCurve and prohibit the other two so
> this
> > issue is OBE there.
> >
> >> Here's what section 3 says:
> >>
> >> ----------------------------
> >>
> >>   ansi-X9-62 OBJECT IDENTIFIER ::= {
> >>        iso(1) member-body(2) us(840) 10045 }
> >> ...
> >>   id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }
> >> ...
> >>   characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
> >> ...
> >>   id-characteristic-two-basis OBJECT IDENTIFIER ::= {
> >>        characteristic-two-field basisType(3) }
> >> ...
> >>   gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }
> >>
> >>
> >> ----------------------------
> >>
> >> Per all that, the OID of gnBasis should be 1.2.840.10045.1.2.3.1.
> >> oid-info.com suggests that the latter is correct:
> >>
> >> http://www.oid-info.com/get/1.2.840.10045.1.2.1.1
> >> http://www.oid-info.com/get/1.2.840.10045.1.2.3.1
> >
> > I went and looked in SECG.  The OID there is:
> >
> > gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }
> >
> > id-characteristic-two-basis OBJECT IDENTIFIER ::= { characteristic-
> two-field
> > basisType(3) }
> >
> > characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
> >
> > id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1)}
> >
> > ansi-X9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
> 10045}
> >
> > Stringing all that together: 1.2.840.10045.1.2.3.1 is the right OID
> for
> > gnBasis.
> >
> > Granted, I wouldn't mind an errata to fix the following:
> >
> > Replace "ansi-X9.62" with "ansi-X9-62" in Section 2.3.5.
> > Replace "id-public-key-type" with "id-publicKeyType" in Section
> 2.3.5.
> > Replace "basisType(2)" with "basisType(3)" in Section 2.3.5.
> >
> > Are you going to submit an errata to RFC 3279 for these?
> >
> > spt
> >
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix