How to get a printable content of a OID

[robmachado]

I need to get a OID content fom Subject alternative name (SAN), OID value: 2.16.76.1.3.3
CNPJ from brasilian certificates.

By the ASN1 class i got only this Octet string :

3081AFA03D0605604C010304A03404323230313031393539303532323535333738383030303030303030303030303030303030303038383734333732787373705350A0210605604C010302A01804164665726E616E646F204A6F7365204B616972616C6C61A0190605604C010303A010040E3538373136353233303030313139A0170605604C010307A00E040C30303030303030303030303081176665726E616E646F4066696D617465632E636F6D2E6272

But is a other way to get this content directly ?

010303A010040E3538373136353233303030313139A0

35 38 37 31 36 35 32 33 30 30 30 31 31 39 => 58716523000119 (this is a CNPJ number)

Tks, for you help

[fgrosse]

Hey Roberto
I'm not quite sure I did completely understand your question yet but I am happy to help :)
Could you provide me with the data you are trying to parse (base64 version would be great)?

As far as I remember, PHPASN1 does currently only support DNS names and IP adresses as SAN but I may extend the framework

[robmachado]

Friderich;

Thank you for your quick response.
Yes, your class is very useful and very well written, but only provide DNS
and IP like you said.

I need to search for information contained in the digital certificate
extension OID like as :

'2.16.76.1.3' =>' Required Attributes Certificates'
'2.16.76.1.3.1'=>' Field otherName citizen person certificate'
'2.16.76.1.3.2'=>' Field in otherName certificate of legal person ',
'2.16.76.1.3.3'=>' Field in otherName certificate of legal person ',
'2.16.76.1.3.4'=>' Field in otherName certificate of legal person ',
'2.16.76.1.3.5'=>' Field otherName citizen person certificate'
'2.16.76.1.3.6'=>' Field otherName citizen person certificate''
'2.16.76.1.3.7'=>' Field in otherName certificate of legal person '

I did it converting the certificate from PEM to DER and using my own "ugly"
functions
but like use something more structured and available on GitHUB.
But my knowledge of digital certificates is quite limited and even more so
in its structure.

I send to you the public key in PEM format, if you could help me I would be
very grateful

Roberto

2013/5/4 Friedrich Große notifications@github.com

Hey Roberto
I'm not quite sure I did completely understand your question yet but I am
happy to help :)
Could you provide me with the data you are trying to parse (base64 version
would be great)?

As far as I remember, PHPASN1 does currently only support DNS names and IP
adresses as SAN but I may extend the framework

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/14#issuecomment-17433960
.

Roberto

Nisi utile est quod facimus stulta est gloriae (Julius Phaedous)

[fgrosse]

Ah so you don't actually want to parse a Subject Alternative Name (SAN) from the certificate extensions but some other arbitrary extensions for which you know the OIDs.

The extensions should have the format

Sequence {
    ObjectIdentifier,
    some_ASN1_Object
}

I think you may have forgotten to attach the certificate for testing. If you send me the certificate I will look into it today.

[robmachado]

Friderich; yes you are correct and structure is exactly this

Sequence {
ObjectIdentifier,
some_ASN1_Object
}

forgive me again for my little knowledge and the certificate is this ...

-----BEGIN CERTIFICATE-----
MIIINTCCBh2gAwIBAgIQbVVJc10C7UUjfYRHQ//7nTANBgkqhkiG9w0BAQsFADB0
MQswCQYDVQQGEwJCUjETMBEGA1UEChMKSUNQLUJyYXNpbDEtMCsGA1UECxMkQ2Vy
dGlzaWduIENlcnRpZmljYWRvcmEgRGlnaXRhbCBTLkEuMSEwHwYDVQQDExhBQyBD
ZXJ0aXNpZ24gTXVsdGlwbGEgRzUwHhcNMTIwNTI0MDAwMDAwWhcNMTMwNTIzMjM1
OTU5WjCBwDELMAkGA1UEBhMCQlIxEzARBgNVBAoUCklDUC1CcmFzaWwxIjAgBgNV
BAsUGUF1dGVudGljYWRvIHBvciBBUiBEYXNjaGkxGzAZBgNVBAsUEkFzc2luYXR1
cmEgVGlwbyBBMTEVMBMGA1UECxQMSUQgLSAzMTYzNjAwMRwwGgYDVQQDExNGaW1h
dGVjIFRleHRpbCBMdGRhMSYwJAYJKoZIhvcNAQkBFhdmZXJuYW5kb0BmaW1hdGVj
LmNvbS5icjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOqNCGrNF3aV
+lfImn2ji7SsyUbwqyddd2GRnZBUv3lOBQ9DhXq+YX1qjkb/EgGwC9EhIermj3Xw
SZ4PjOweubXAVZ8BY2CrjZhjOOQRq5IKvbqStbsYSEOvOyVfbsDuYdralM6SJpyW
wJRdjTprbKUARU2fJBLJgiGGyIwh0KqAIhp3OcwCW9t4B5RT01fcmPa6hhU808dQ
JgqykA1i8ylQjtXzg52tinUOl6zWZZxxkg5y9l73Lf14eDFHcnI4lFv4kS3jkdk8
mwyll2K0nQX+aMcli8aN3K7C/Lj4VQIWuGarVNfzwg3wP3WzzOS+go0UFZ8ZSy52
3kpfnlsNBK0CAwEAAaOCA3QwggNwMIG6BgNVHREEgbIwga+gPQYFYEwBAwSgNAQy
MjAxMDE5NTkwNTIyNTUzNzg4MDAwMDAwMDAwMDAwMDAwMDAwMDg4NzQzNzJ4c3Nw
U1CgIQYFYEwBAwKgGAQWRmVybmFuZG8gSm9zZSBLYWlyYWxsYaAZBgVgTAEDA6AQ
BA41ODcxNjUyMzAwMDExOaAXBgVgTAEDB6AOBAwwMDAwMDAwMDAwMDCBF2Zlcm5h
bmRvQGZpbWF0ZWMuY29tLmJyMAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUnVDPvf8k
yq+xM+sX4kJ6jmkqjlMwDgYDVR0PAQH/BAQDAgXgMIGJBgNVHSAEgYEwfzB9BgZg
TAECAQswczBxBggrBgEFBQcCARZlaHR0cDovL2ljcC1icmFzaWwuY2VydGlzaWdu
LmNvbS5ici9yZXBvc2l0b3Jpby9kcGMvQUNfQ2VydGlzaWduX011bHRpcGxhL0RQ
Q19BQ19DZXJ0aVNpZ25NdWx0aXBsYS5wZGYwggElBgNVHR8EggEcMIIBGDBcoFqg
WIZWaHR0cDovL2ljcC1icmFzaWwuY2VydGlzaWduLmNvbS5ici9yZXBvc2l0b3Jp
by9sY3IvQUNDZXJ0aXNpZ25NdWx0aXBsYUc1L0xhdGVzdENSTC5jcmwwW6BZoFeG
VWh0dHA6Ly9pY3AtYnJhc2lsLm91dHJhbGNyLmNvbS5ici9yZXBvc2l0b3Jpby9s
Y3IvQUNDZXJ0aXNpZ25NdWx0aXBsYUc1L0xhdGVzdENSTC5jcmwwW6BZoFeGVWh0
dHA6Ly9yZXBvc2l0b3Jpby5pY3BicmFzaWwuZ292LmJyL2xjci9DZXJ0aXNpZ24v
QUNDZXJ0aXNpZ25NdWx0aXBsYUc1L0xhdGVzdENSTC5jcmwwHQYDVR0lBBYwFAYI
KwYBBQUHAwIGCCsGAQUFBwMEMIGgBggrBgEFBQcBAQSBkzCBkDBkBggrBgEFBQcw
AoZYaHR0cDovL2ljcC1icmFzaWwuY2VydGlzaWduLmNvbS5ici9yZXBvc2l0b3Jp
by9jZXJ0aWZpY2Fkb3MvQUNfQ2VydGlzaWduX011bHRpcGxhX0c1LnA3YzAoBggr
BgEFBQcwAYYcaHR0cDovL29jc3AuY2VydGlzaWduLmNvbS5icjANBgkqhkiG9w0B
AQsFAAOCAgEAyfdKIKDLGZyOhAsycAgJ7RZyn4/2tN29bd+rLwtkvp/9XJGRCAob
fkLU8UACGzbVHT/bB7sOKIiHvp8CgGyoU/1veo5a1yGMFQobQWGcdEYBOd+6Ax6U
FEOc+Ti+LsXsUA5tRbzTwfXJFFOIgFDgrXl7V4JGjSI3GdyoiEECR9OfM/UFYtr/
pD194Xh6G0lSCuP9xOKpOJ7qk24mcfObcGxooMxmktkt0bevzx5w84RtXJfbube+
p6o7JP06T6JJTGfIUfNKYU8wJ6CV9eUHEMDLHMoH6wnYK7d8rHcAbSoTJGMFlSYZ
OqJrWAbKAPjraFNeNaH675u//Ck127kJVidcuRwtkLZV/OIlQaw/4QSp90QWQOQg
AsOWC9+h8v/RcCYTJpWM22MCq3Xk67nz+mXO8e7LKpzHEh2sjX3gkfw4h80zYfT7
kTsNXVdxAHXiIahKNeRUT8fGhxvyOA0RqAXQBUaOyLyGYWRJ7Is5IqAAU6XiBHYe
oJ3v8BTGYzIK2Ud5dZ23yzBp2ejdQzQX1ETpJoEdgELToHmfBXTkI+7ne59wSRkH
beQXoK5y0U3gh1vIz/53GG0QMuCvq9r9xTMERcFJcpQUxJ2RjwxIFHlIFbNwCeiW
I3DmZaXdR169kRoPIqkV3QIREs/yHBvkxXrwDt416stUnQ8KsxAEatE=
-----END CERTIFICATE-----

[fgrosse]

Hey Roberto,

I have created a new example based on the data you provided (see here). I don't (yet) understand the format of the SANs in this certificate.

This is what I get when I run the script on my shell:

Sequence : [5 children]
├─[0] Context-specific (0xa0) : [2 children]
├──Object Identifier : 2.16.76.1.3.4 (unkown)
├──[0] Context-specific (0xa0) : [1 child]
├───Octet String : 3230313031393539303532323535333738383030303030303030303030303030303030303038383734333732787373705350
├─[0] Context-specific (0xa0) : [2 children]
├──Object Identifier : 2.16.76.1.3.2 (unkown)
├──[0] Context-specific (0xa0) : [1 child]
├───Octet String : 4665726E616E646F204A6F7365204B616972616C6C61
├─[0] Context-specific (0xa0) : [2 children]
├──Object Identifier : Cnpj (2.16.76.1.3.3)
├──[0] Context-specific (0xa0) : [1 child]
├───Octet String : 3538373136353233303030313139
├─[0] Context-specific (0xa0) : [2 children]
├──Object Identifier : 2.16.76.1.3.7 (unkown)
├──[0] Context-specific (0xa0) : [1 child]
├───Octet String : 303030303030303030303030
├─[1] Context-specific (0x81) : Unparseable Object (23 bytes)

It seems like all 5 SAN entries are marked as context specific classes but have the same tag value (except the last one which has tag 1). As you can see the octet strings of each of the entries is again encapsulated in a context specific class :/

I think this looks really strange and I'm not yet sure if having the same explicit tag value for the context specific classes is even allowed by the standard.

If you have any formal English (or German) document describing this kind of SAN I might give it a second try and include this in the SubjectAlternativeNamesclass. Until then you can navigate the given hierarchy if you know exactly how the SAN structure of your certificates is supposed to be. Just proceed like in my given example.

Hope that this helps you
Please let me know if this answers your question so I can close the issue :)

Best regards
Friedrich

[robmachado]

Friedrich;

Tanks very much !!

this will facilitate my work,
now I can get the information more simply.

I hope one day I can repay your kindness.

Best regards
Roberto

[fgrosse]

You are welcome
I like the idea that somebody is using this framework so feel free to open another issue or contact me if you have more questions :)

Best regards
Friedrich

[pzb]

I ran across this issue today and wanted to fill in the gap not covered for anyone else hitting the same issue.

The structure described is an "otherName" as covered in RFC 5280 section 4.2.1.6. otherNames in the SAN are a sequence of two things, an Object Identifier describing the data type and the value. The octet strings in the tree above are the values. Depending on the data type, they might be further decodable.

[fgrosse]

Thx for the comment, based on you hint I will probably implement accessing otherNames directly through the SubjectAlternativeNames class whenever I have the time.
Of course I am also open for any pull requests