> From: [email protected] On Behalf Of
[email protected]
> Sent: Thursday, 16 February, 2012 03:07
> To: [email protected]
> Subject: Define own x.509v3 Extension, "myterious zeros"
> 
> Hallo mailing list.
> 
> I want to define an own Extension for a specific usage, how 
> can I do that?!
> 
In general, get a unique OID from someone who has an OID arc 
assigned to them, and choose the ASN.1 structure for your value.

If you want to use commandline OpenSSL to create a cert, or CSR, 
with such an extension in it, add it to the relevant extensions 
section of your config file. You can optionally name the OID 
(in oid_section or oid_file) or just use the numeric form;
you can add code to OpenSSL to parse and/or display the value, 
or you can use the 'arbitrary' syntax. man x509v3_config .
By default commandline will display unknown extensions in hex, 
unless you add code to display.

>From a custom app you can add OID names (and NIDs) with OBJ_ 
routines (I don't recall details) or just use directly. For 
the value, you can write your own code (perhaps in a library) 
or call the same code you added to OpenSSL for commandline.

> And there is something I wonder about while reading 
> documentations of  
> x.509 Format: Using RSA with sha 1, on some places in the 

Note that most of these questions and answers aren't specific 
to RSA keys, or SHA-1 (or RSA) signature.

> certificate  
> (between key header and the header of the structure within, between  
> the Key Structure Header and the Modulus and at the beginning of the  
> signature) there are leading "0"-Bytes, would be kind if 
> anybody could  
> tell me, why this is the case.
> 
> I also wonder why the key structure (Exponent & Modulus) is marked  
> using a "0x03"-Byte, as this should mean it's a primitive.....
> 
I'm not sure exactly what you mean by your nonstandard terminology, 
but the SubjectPublicKeyInfo in an X.509 cert is a SEQUENCE of 
AlgorithmIdentifier which in turn is a SEQUENCE of an OID plus 
a potentially varying ASN.1 type usually NULL; then a BIT STRING 
*containing* the actual key data. This encodes as 
  30 len   30 len   06 len OID   05 zlen   03 len padb keydata 
where each of the len fields can be one to three octets; in 
the three octet form the third could be but rarely is zero. 
The length of NULL is always 00. All currently used public key 
encodings are integral octets so padb is always 00.

For RSA (only) keydata is a DER SEQUENCE of two INTEGERs, 
modulus n and exponent e, as 30 len 02 len val 02 len val, 
with the same notes on len as above, except that RSA public 
exponents are almost always small and use one-octet length.

Every INTEGER in DER is encoded as two's complement, with 
a leading sign octet if necessary. RSA moduli are usually 
chosen to be exactly N bits in *magnitude* where N is a 
convenient power of two like 1024, 1536, 2048. (This isn't 
required, it's just convenient and common.) For example, 
a 2048-bit RSA modulus will have a numeric value between 
2^2047 and 2^2048-1 (actually 2^2047+1 to 2^2048-1, because 
a large prime can't be even). Such a value must be DER 
encoded with a leading sign octet of 00.

> and why the extensions are encapsulated 2 times (first by a A3-type  
> and then by a sequence [of sequences])
> 
The extensions field is defined as OPTIONAL [3]EXPLICIT 
(tagged) SEQUENCE OF SEQUENCE { OID,BOOLEAN,OCTET STRING }.
A context tag N-explicit is encoded as A0+N len then the 
normal encoding (here sequence of sequence). (Except if 
N >= 20 it's more complicated.) 3 was apparently chosen 
because 1 and 2 had already been assigned for OPTIONAL 
issuerUniqueID and subjectUniqueID which were added in v2 
but very rarely used. DER allows untagged optional elements 
if they can be distinguished by their primitive tags, and 
here extensions could. But generally standards bodies like 
CCITT/ITU-T prefer consistent tagging, and usually explicit 
tagging because it makes generic tools more effective.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [email protected]
Automated List Manager                           [email protected]

Reply via email to