On 9/28/2012 4:45 PM, Valentin Bud wrote:
Hello Jakob,
On Fri, Sep 28, 2012 at 04:20:00PM +0200, Jakob Bohm wrote:
Simple really:
Indeed. When you know a certain topic and you've studied for a certain
time it's really simple. For me, for now, compliant RFC CA is a nebula.
I am starting to see the what pieces this puzzle needs and to be able to
find documentation so I can study the topic.
The OID must be written in decimal, not hexadecimal.
Didn't know that before Erwann answered. I guess it's logic for the
number to be in decimal since all the others are in decimal, on the OID
tree I mean. The reason, I guess is from encoding.
Just to clarify:
The encoding is that each dot-separated part is encoded as a purely
binary integer. All but the first two parts use a variable length
encoding which can handle numbers from 0 to infinity (if you have
infinite many bytes to store it in).
Writing OIDs as decimal numbers in text is a notational convention,
which may be codified somewhere (I learned most of the encoding
from the "Introduction to ASN.1" paper in the old "PKCS standards"
.ZIP file from RSA Labs, not from reading the ITU standards).
Please refer to the ITU-T page you referenced to figure out
how the bytes and bits of your UUID map to numeric parts of
the OID and then write those out in decimal.
Should have looked more carefully on the UUID generation page and read
[1]. Some new material to study.
Now what I didn't know when I wrote my first answer is how the UUID
fields (a structure of multiple fixed size integers, written slightly
differently in different standards) were supposed to be mapped to one
or more binary integers when following the procedure in [2].
I now see that one simply takes the 32 hex digits and treat them as
a large 128 bit hexadecimal int.
Thank you for pointing me in the right direction.
There is another way to get a unique OID space for a company, which
predates (I think) the UUID based method:
Register for an "Enterprise number" with IANA. This gets you a
sequentially assigned int, which can then be prefixed with
"1.3.6.1.4.1." to get a private OID space, which you should then
immediately subdivide using small ints as the next element.
For instance our in-house CA has the policy OID 1.3.6.1.4.1.36644.3.1
where .3 is our subdivision for private X.509 stuff and .1 is then
our first allocation under that space. We track our sub-allocations
in a simple document that is stored somewhere covered by our general
server backups.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
