Subject: RE: ASN.1 question on 2459

From: [email-masked]
Date: Fri, 1 Oct 1999 11:42:14 -0400

ASN.1 is unusual in that it formally defines a type for null (i.e., NULL).

In the case of AlgorithmIdentifier for an RSA signature, PKCS #1 specifies
what to do in section 11:

<quote>
These object identifiers are intended to be used in the algorithm field of a
value of type AlgorithmIdentifier. The parameters field of that type, which
has the algorithm-specific syntax ANY DEFINED BY algorithm, would have ASN.1
type NULL for these algorithms.
</quote>

RFC 2459 describes the same thing in section 7.2.1:

<quote>
When any of these three OIDs appears within the ASN.1 type
AlgorithmIdentifier, the parameters component of that type shall be the
ASN.1 type NULL.
</quote>

Most of this stuff makes sense. You just need to dig a little.

Frank Balluffi
CertCo

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]]
Sent: Thursday, September 30, 1999 4:33 PM
To: [email-masked]; [email-masked]
Subject: RE: ASN.1 question on 2459

> From: "Salter, Thomas A" <[email-masked]>
>  > 
>  > But wait ... there are more ways to represent nothing!  Some people
>  > encode an OPTIONAL item that is not used as a BER NULL (0x05 0x00)
>  > instead of just leaving it out.  I understand that there is a
>  > legitimate semantic difference between a sequence of zero 
>  > elements and
>  > a sequence that is absent.  But as far as I know there is no semantic
>  > distinction between a NULL that is present and an element that is
>  > absent; the only reason to encode an optional element as a NULL would
>  > be, as Peter says, to bulk up your certificates.
>  > 
> 
> If they do that, then some people are wrong.  A NULL can only be used if
it
> is allowed by the ASN.1 definition.  Some people might write the ASN.1 so
> that an item is a CHOICE of some element or NULL, but otherwise you cannot
> do what you describe.

The RFC 2459 definition of Algorithm Identifier is:

-------------------

AlgorithmIdentifier ::= SEQUENCE {
  algorithm   ALGORITHM-ID.&id({SupportedAlgorithms}),
  parameters  ALGORITHM-ID.&Type({SupportedAlgorithms}
                                 { @algorithm} ) OPTIONAL )
                                 
ALGORITHM-ID ::= CLASS {
  &id  OBJECT IDENTIFIER UNIQUE,
  &Type OPTIONAL }
  WITH SYNTAX { OID &id [PARMS &Type] }
  
SupportedAlgorithms ALGORITHM-ID ::= { ..., --extensible
  rsaMD2 |
  dsaSHA-1 |
      -- and others
}

rsaMD2    ALGORITHM-ID ::= { OID md2WithRSAEncryption PARMS NULL }
dsaSHA-1  ALGORITHM-ID ::= { OID id-dsa-with-sha1     PARMS Dss-Parms }

----------------------

The RFC 2459 examples show an RSA certificate with explicit NULL
parameters (example D3) and DSA certificates with absent
parameters in the two signature fields (examples D1 and D2).

The use of an explicit NULL is allowed by the ASN.1 definitions of the
RSA algorithms, but there seems to be no semantic associated with a
present NULL as opposed to an absent NULL.  The only apparent effect of
encoding three NULLs in example D3 is to increase the size of the
certificate by six octets.

---

From: [email-masked]
Date: Fri, 1 Oct 1999 11:58:43 -0400

I meant to add the following.

David Kemp wrote, "the only reason to encode an optional element as a NULL
would
be, as Peter says, to bulk up your certificates"

The reason to encode an optional element as a NULL is because the
specification says to do so. Below are examples of specifications that say
to do so.

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 01, 1999 11:42 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: ASN.1 question on 2459

<quote>

<quote>

Frank Balluffi
CertCo

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]]
Sent: Thursday, September 30, 1999 4:33 PM
To: [email-masked]; [email-masked]
Subject: RE: ASN.1 question on 2459

it

-------------------

ALGORITHM-ID ::= CLASS {

----------------------