339074 - Verify certutil produces correct PKCS#10 requests

Status: RESOLVED INVALID

(NSS :: Tools, defect)

Description

[Kai Engert [:KaiE:]]

Use certutil to produce a cert request, e.g.
  certutil -d . -R -s "CN=test"

Feed the request to the dumpasn1 tool, e.g.
  dumpasn1 -i -l

The dumpasn1 reports an error about a contained object of zero length.

Wan-Teh proposed it should be verified whether the error is in the request or the dump tool.

   0  334: SEQUENCE {
   4  184:  SEQUENCE {
   7    1:   INTEGER 0
  10   15:   SEQUENCE {
  12   13:    SET {
  14   11:     SEQUENCE {
  16    3:      OBJECT IDENTIFIER commonName (2 5 4 3)
         :       (X.520 id-at (2 5 4))
  21    4:      PrintableString 'test'
         :       }
         :      }
         :     }
  27  159:   SEQUENCE {
  30   13:    SEQUENCE {
  32    9:     OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
         :      (PKCS #1)
  43    0:     NULL
         :      }
  45  141:    BIT STRING, encapsulates {
  49  137:     SEQUENCE {
  52  129:      INTEGER
         :       00 BB 15 90 D4 C5 84 5B 2E 29 AD 88 E6 10 89 A3
         :       8B 0E E8 90 17 3B 5C 56 B0 30 97 3D F7 1D FC 0F
         :       06 8B 93 B5 77 91 06 26 F6 B9 1D 76 C1 9B 9F EF
         :       0D F5 10 D2 90 B7 05 34 31 CD 98 08 74 6C 42 81
         :       27 20 8A 35 BB 21 7E 0F 80 E7 07 22 97 6E FA D9
         :       BC 22 D0 20 BC 9A C6 52 ED 0C 87 07 BD 49 24 D1
         :       E8 62 02 25 17 A8 B1 44 AD CE A3 B8 75 88 2D F0
         :       7A 9E CF D7 55 67 9A A2 05 F6 9B 94 7A 82 20 D9
         :           [ Another 1 bytes skipped ]
 184    3:      INTEGER 65537
         :       }
         :      }
         :     }
 189    0:   [0]
         :    Error: Object has zero length.
         :    }
 191   13:  SEQUENCE {
 193    9:   OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 1 1 4)
         :    (PKCS #1)
 204    0:   NULL
         :    }
 206  129:  BIT STRING
         :   28 91 F8 70 50 2B 88 FC 46 38 0E 53 B2 FE 1F D4
         :   3A 93 65 63 89 5C A8 AC 79 E2 21 D5 62 23 B4 01
         :   18 C9 10 7B CF 99 8F 8F 2F 67 B2 CA EB 0E 30 59
         :   8C DC C3 38 07 0C 8A 4E 04 E5 87 39 81 F3 B0 FF
         :   5E 43 DA F3 57 2B AB 39 17 AE 01 CA 0C 78 91 63
         :   05 FF 5D D0 AC 31 9A 89 7C 46 D1 74 62 CE 97 03
         :   AF 25 39 E9 63 D6 F0 D5 2C C3 A4 22 FD 6B 66 0A
         :   E2 00 67 86 A8 40 9F 76 0D F1 CA 6B F2 58 D1 2F
         :   }

0 warnings, 1 error.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

dumpasn1 always reports any zero-length component to be an error 
(er, at least for constructed ones).  But IMO, they are not always errors.

PKCS#10 defines the abstract syntax of an 

CertificationRequestInfo ::= SEQUENCE {
    version INTEGER { v1(0) } (v1,...),
    subject Name,
    subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
    attributes [0] Attributes{{ CRIAttributes }}
}

Attributes { ATTRIBUTE:IOSet } ::= SET OF Attribute{{ IOSet }}
CRIAttributes ATTRIBUTE ::= {
                          ... -- add any locally defined attributes here -- }
Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
    type ATTRIBUTE.&id({IOSet}),
    values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type})
}

There are no required attributes.  
The number of attributes in the set is not constrained.
But the syntax for the context-dependent [0] tagged attributes is not OPTIONAL.

So, when we encode a PKCS#10 request with no attributes, we encode it with 
a zero length set.  

If the standards clearly dictate that we should be doing some other encoding
in this case, I invite a citation of the relevant portions.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

I think this bug should go back to UNCONFIRMED state until there is a 
confirmed bug here.   Anyone know how to do that?

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Concerning sets-of and sequences-of, X.609 says:

> 8.10.2 The contents octets shall consist of *zero*, one or more complete
> encodings of data values from the type listed in the ASN.1 definition.

Notice that zero is explicitly allowed.

Comment 4

[Wan-Teh Chang]

Peter, your dumpasn1 tool complains that an "Object has zero length"
in the PKCS #10 output generated by NSS.  Could you help us resolve
this issue?  Thanks.

Comment 5

[Peter Gutmann]

(In reply to comment #4)
> Peter, your dumpasn1 tool complains that an "Object has zero length"
> in the PKCS #10 output generated by NSS.  Could you help us resolve
> this issue?  Thanks.

It's due to an error in the spec.  From the X.509 Style Guide:

According to the PKCS #10 spec, the attributes field is mandatory, so if it's empty it's encoded as a zero-length field. The example however assumes that if there are no attributes, the field shouldn't be present, treating it like an OPTIONAL field. A number of vendors conform to the example rather than the specification, but just to confuse the issue RSADSI, who produced PKCS #10, regard things the other way around, with the spec being right and the example being wrong. The most obvious effect of this is that TIPEM (which was the only available toolkit for PKCS#10 for a long time) follows the spec and does it "wrong (sense #2)", whereas more recent independant implementations follow the example and do it "wrong (sense #1)".

So there shouldn't really be a zero-length object there, but many (most?) implementations encode it that way.  Since dumpasn1 can't really read the mind of the person dumping the binary, it plays it safe and reports an error.

Comment 6

[Peter Gutmann]

(In reply to comment #5)
> According to the PKCS #10 spec, the attributes field is mandatory, so if it's
> empty it's encoded as a zero-length field. The example however assumes that if
> there are no attributes, the field shouldn't be present, treating it like an
> OPTIONAL field. 

I should mention that there are multiple generations of PKCS #10 spec, the error originated around 1990 and has been propagated forwards since then for backwards-compatibility, a bit like the dropped OPTIONAL after the parameters in an AlgorithmIdentifier, which is why lots of implementations encode NULL as the parameter value when it should actually be omitted altogether.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Peter,  please cite a standard according to which the zero length component
is an error.  I read X.690 as saying it is explicitly allowed.

Comment 8

[Peter Gutmann]

(In reply to comment #7)
> Peter,  please cite a standard according to which the zero length component
> is an error.  I read X.690 as saying it is explicitly allowed.

It has nothing to do with X.690, the PKCS #10 spec was ambiguous as to whether it was mandatory or optional.  If it was optional then a zero-length value wouldn't be allowed (since the entire element would be omitted rather than encoding it as a zero-length value), thus dumpasn1 warns about it.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

So, you're saying that dumpasn1 is treating this context-dependent 0 tag
as if it was optional.  What is the basis for that?
Does dumpasn1 recognizze this as a PKCS#10 item?
or does dumpasn1 perhaps treat all context-dependent tags as optional?
or?