Re: IPv6 address encoding in commonName
Jackob, I thank you for all this. I will be studying it over the coming week(s). Bob On 8/15/19 5:39 PM, Jakob Bohm via openssl-users wrote: [Top posting to match] Note that the actual DC name element is still used for actual domains when interacting with Microsoft Active Directory authentication, including associated X.509 certificates. So it shouldn't be used for something contrary. The shortest useful form in terms of certificate size would probably be: Put an informal (but fixed format) description of the address scope in the user readable CN in certificates at all levels (rootCA, itemCA and end cert). Put appropriate human readable organization name or equivalent in the O name element in rootCA and itemCA. Make the end cert DN as short as possible. For example "CN=HIT CA 2 example corp,O=example corp,C=TH" -> "CN=HIT factory CA xy,O=Example Chon Buri plant,C=TH" -> "CN=HIT CA for [...],O=In your device,C=XX" -> "CN=[2001:db8:a:b::],C=XX" (Using "XX" to represent the device might be in any country). Put the actual address in the appropriate SAN in the end cert (this will be a binary address). Put name restrictions in the all the CAs (intermediary and special purpose root), these will be a binary address and length for the allowed type and the appropriate "nothing" notation for all the other defined name restriction types except the distinguished name type. Do not include ID number fields except the certificate serial number, which also protects the signature hash algorithm via randomization (since SHA-1 phase out began, but potentially useful for modern algorithms). Use a short offline-compatible revocation URL such as "ex.th/xy.crl" for hierarchies run by the hypothetical EXample conglomerate in THailand, where the xy part is a very short name assigned by that conglomerate to the issuing central CA or factory intermCA. On 15/08/2019 18:49, Robert Moskowitz wrote: On 8/14/19 6:47 PM, Michael Richardson wrote: Robert Moskowitz wrote: > I am fiddling around with an intermediate CA signing cert that the CA's > 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 address. Actually a > Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to be revised soon). > For a client cert, it would be easy to put the HIT in subjectAltName per RFC > 8002 (with a null subjectName), but a CA cert MUST have a non-empty > subjectName. > Thus all I want in this subjectName is commonName with the HIT. > I am looking for examples of IPv6 addresses in commonName. I thought that RFC3779 did exactly what you want, but it does not define new Subject DN, but rather a new extension that will be bound to the Subject. (I was surprised that RFC3779 was not in the SIDR WG's list of documents,but I guess it preceeded the SIDR working group, and occured in PKIX) In ANIMA's ACP document, we have an abomination that leverages rfc822Name, mostly because we figure the odds of getting anything else through off-the-shelf CAs is nil. Note to consumed with things in your stomach: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-20#section-6.1.2 Jakob Bohm via openssl-users wrote: > As the author of a proposal in this area, could you define a notation > for IPv6 DNs, perhaps one that actually reflects the hierarchical nature > of IPv6 addresses? RFC3779 does some of that, but not in the DN itself. > You could take inspiration from the (unfortunately rarely used) > hierarchical DN representation of DNS names (this used the DNS > specific DC name components). Overall the goal is to allow X.500 > distinguished name restrictions to work correctly. Yes, we could abuse the DC component. Were you thinking about: DC=2001/DC=0db8 This looks closest to what is needed here, as the prefix for HHITs is currently proposed at /64. So it would be DC=2001/DC=0024/DC=0028/DC=0014 But the OID for DC is bi: 0.9.2342.19200300.100.1.25 Ouch. So I will research this more, but for this early stage in the development I will use: CN=2001:24:28:14::/64 Thanks for all the comments here. > In practice you could follow the nibble notation as already used > for delegation of IPv6 reverse lookups in DNS. so more correctly: DC=2/DC=0/DC=0/DC=1/DC=d/DC=b/DC=8 > However for the CN in the end cert you could perhaps use the full > DNS reverse IPv6 name > "x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa" > or the URL/Mail notation "[:::::::]" > where the hex notation shall be the shortest form permitted by the > IPv6 notation spec. Bob, this seems like the best immediate hack to me. Enjoy Jakob Enjoy Jakob
Re: IPv6 address encoding in commonName
[Top posting to match] Note that the actual DC name element is still used for actual domains when interacting with Microsoft Active Directory authentication, including associated X.509 certificates. So it shouldn't be used for something contrary. The shortest useful form in terms of certificate size would probably be: Put an informal (but fixed format) description of the address scope in the user readable CN in certificates at all levels (rootCA, itemCA and end cert). Put appropriate human readable organization name or equivalent in the O name element in rootCA and itemCA. Make the end cert DN as short as possible. For example "CN=HIT CA 2 example corp,O=example corp,C=TH" -> "CN=HIT factory CA xy,O=Example Chon Buri plant,C=TH" -> "CN=HIT CA for [...],O=In your device,C=XX" -> "CN=[2001:db8:a:b::],C=XX" (Using "XX" to represent the device might be in any country). Put the actual address in the appropriate SAN in the end cert (this will be a binary address). Put name restrictions in the all the CAs (intermediary and special purpose root), these will be a binary address and length for the allowed type and the appropriate "nothing" notation for all the other defined name restriction types except the distinguished name type. Do not include ID number fields except the certificate serial number, which also protects the signature hash algorithm via randomization (since SHA-1 phase out began, but potentially useful for modern algorithms). Use a short offline-compatible revocation URL such as "ex.th/xy.crl" for hierarchies run by the hypothetical EXample conglomerate in THailand, where the xy part is a very short name assigned by that conglomerate to the issuing central CA or factory intermCA. On 15/08/2019 18:49, Robert Moskowitz wrote: On 8/14/19 6:47 PM, Michael Richardson wrote: Robert Moskowitz wrote: > I am fiddling around with an intermediate CA signing cert that the CA's > 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 address. Actually a > Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to be revised soon). > For a client cert, it would be easy to put the HIT in subjectAltName per RFC > 8002 (with a null subjectName), but a CA cert MUST have a non-empty > subjectName. > Thus all I want in this subjectName is commonName with the HIT. > I am looking for examples of IPv6 addresses in commonName. I thought that RFC3779 did exactly what you want, but it does not define new Subject DN, but rather a new extension that will be bound to the Subject. (I was surprised that RFC3779 was not in the SIDR WG's list of documents,but I guess it preceeded the SIDR working group, and occured in PKIX) In ANIMA's ACP document, we have an abomination that leverages rfc822Name, mostly because we figure the odds of getting anything else through off-the-shelf CAs is nil. Note to consumed with things in your stomach: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-20#section-6.1.2 Jakob Bohm via openssl-users wrote: > As the author of a proposal in this area, could you define a notation > for IPv6 DNs, perhaps one that actually reflects the hierarchical nature > of IPv6 addresses? RFC3779 does some of that, but not in the DN itself. > You could take inspiration from the (unfortunately rarely used) > hierarchical DN representation of DNS names (this used the DNS > specific DC name components). Overall the goal is to allow X.500 > distinguished name restrictions to work correctly. Yes, we could abuse the DC component. Were you thinking about: DC=2001/DC=0db8 This looks closest to what is needed here, as the prefix for HHITs is currently proposed at /64. So it would be DC=2001/DC=0024/DC=0028/DC=0014 But the OID for DC is bi: 0.9.2342.19200300.100.1.25 Ouch. So I will research this more, but for this early stage in the development I will use: CN=2001:24:28:14::/64 Thanks for all the comments here. > In practice you could follow the nibble notation as already used > for delegation of IPv6 reverse lookups in DNS. so more correctly: DC=2/DC=0/DC=0/DC=1/DC=d/DC=b/DC=8 > However for the CN in the end cert you could perhaps use the full > DNS reverse IPv6 name > "x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa" > or the URL/Mail notation "[:::::::]" > where the hex notation shall be the shortest form permitted by the > IPv6 notation spec. Bob, this seems like the best immediate hack to me. Enjoy Jakob Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, 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
Re: client certs with no subjectName only SAN
On 8/15/19 4:13 PM, Salz, Rich wrote: subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark subjectAltName as non-critical" Fine with me. I can believe that OpenSSL doesn't support empty subjectName's. An empty one, with no relative disintuished name components, is not the same as not present. It does seem empty with that -subj / command line option. I am not seeing subjectName in this dump of the cert: $ openssl asn1parse -i -in $dir/certs/device1.cert.pem 0:d=0 hl=4 l= 439 cons: SEQUENCE 4:d=1 hl=4 l= 361 cons: SEQUENCE 8:d=2 hl=2 l= 3 cons: cont [ 0 ] 10:d=3 hl=2 l= 1 prim: INTEGER :02 13:d=2 hl=2 l= 9 prim: INTEGER :C98FB27BE19574CF 24:d=2 hl=2 l= 5 cons: SEQUENCE 26:d=3 hl=2 l= 3 prim: OBJECT :ED25519 31:d=2 hl=2 l= 29 cons: SEQUENCE 33:d=3 hl=2 l= 27 cons: SET 35:d=4 hl=2 l= 25 cons: SEQUENCE 37:d=5 hl=2 l= 3 prim: OBJECT :commonName 42:d=5 hl=2 l= 18 prim: UTF8STRING :2001:24:28:14::/64 62:d=2 hl=2 l= 30 cons: SEQUENCE 64:d=3 hl=2 l= 13 prim: UTCTIME :190815195117Z 79:d=3 hl=2 l= 13 prim: UTCTIME :200824195117Z 94:d=2 hl=2 l= 0 cons: SEQUENCE 96:d=2 hl=2 l= 42 cons: SEQUENCE 98:d=3 hl=2 l= 5 cons: SEQUENCE 100:d=4 hl=2 l= 3 prim: OBJECT :ED25519 105:d=3 hl=2 l= 33 prim: BIT STRING 140:d=2 hl=3 l= 226 cons: cont [ 3 ] 143:d=3 hl=3 l= 223 cons: SEQUENCE 146:d=4 hl=2 l= 9 cons: SEQUENCE 148:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 153:d=5 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000 157:d=4 hl=2 l= 17 cons: SEQUENCE 159:d=5 hl=2 l= 9 prim: OBJECT :Netscape Cert Type 170:d=5 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:030205A0 176:d=4 hl=2 l= 51 cons: SEQUENCE 178:d=5 hl=2 l= 9 prim: OBJECT :Netscape Comment 189:d=5 hl=2 l= 38 prim: OCTET STRING [HEX DUMP]:16244F70656E53534C2047656E65726174656420436C69656E74204365727469666963617465 229:d=4 hl=2 l= 29 cons: SEQUENCE 231:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Identifier 236:d=5 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:041497B0DCA27493CF765E826C089C467383D3868E9A 260:d=4 hl=2 l= 31 cons: SEQUENCE 262:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Authority Key Identifier 267:d=5 hl=2 l= 24 prim: OCTET STRING [HEX DUMP]:30168014B145189B33826C7429692A15933B1C31D237D6CA 293:d=4 hl=2 l= 14 cons: SEQUENCE 295:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage 300:d=5 hl=2 l= 1 prim: BOOLEAN :255 303:d=5 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:030205E0 309:d=4 hl=2 l= 29 cons: SEQUENCE 311:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Extended Key Usage 316:d=5 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:301406082B0601050507030206082B06010505070304 340:d=4 hl=2 l= 27 cons: SEQUENCE 342:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Subject Alternative Name 347:d=5 hl=2 l= 20 prim: OCTET STRING [HEX DUMP]:301287102001002400280014B8AF2789CBB9F7AC 369:d=1 hl=2 l= 5 cons: SEQUENCE 371:d=2 hl=2 l= 3 prim: OBJECT :ED25519 376:d=1 hl=2 l= 65 prim: BIT STRING
Re: client certs with no subjectName only SAN
subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark subjectAltName as non-critical" I can believe that OpenSSL doesn't support empty subjectName's. An empty one, with no relative disintuished name components, is not the same as not present.
client certs with no subjectName only SAN
There are a number of things I am not clear on, and so far my searching and reading is coming up short. If there is no subjectName, only subjectAltName, is the subjectName still present in the cert only empty or is it totally gone. I have found that if I put -subj / in the openssl req, I end up with an empty subjectName. Or is there someway to totally remove this from the cert? For the subjectAltName, is it suppose to be flagged critical? I have seen references of: subjectAltName=critical,email:certt...@example.com Is this correct and the way to set SAN as critical? thanks The cert I have made so far is: $openssl x509 -noout -text -in $dir/certs/device1.cert.pem Certificate: Data: Version: 3 (0x2) Serial Number: c9:8f:b2:7b:e1:95:74:cf Signature Algorithm: ED25519 Issuer: CN = 2001:24:28:14::/64 Validity Not Before: Aug 15 19:51:17 2019 GMT Not After : Aug 24 19:51:17 2020 GMT Subject: Subject Public Key Info: Public Key Algorithm: ED25519 ED25519 Public-Key: pub: 7a:a6:f2:7d:14:8f:fd:a9:55:d9:6f:d6:04:a1:e6: 6d:9e:34:1f:d3:2b:59:80:cc:2f:4c:83:4f:81:a0: 10:36 X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Client, S/MIME Netscape Comment: OpenSSL Generated Client Certificate X509v3 Subject Key Identifier: 97:B0:DC:A2:74:93:CF:76:5E:82:6C:08:9C:46:73:83:D3:86:8E:9A X509v3 Authority Key Identifier: keyid:B1:45:18:9B:33:82:6C:74:29:69:2A:15:93:3B:1C:31:D2:37:D6:CA X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, E-mail Protection X509v3 Subject Alternative Name: IP Address:2001:24:28:14:B8AF:2789:CBB9:F7AC Signature Algorithm: ED25519 32:2e:7d:4d:ad:4d:87:4c:57:1a:df:ef:e3:ec:2b:b5:a7:fe: 2f:48:73:32:72:1a:b6:4a:cd:e4:88:75:98:4d:b0:9a:79:48: 2b:2c:12:68:0f:c0:86:bd:d9:4e:4b:85:fb:f3:91:68:f4:ec: 18:99:dd:7e:d5:f8:b6:f0:08:0e
RE: OPENSSL_init_crypto with OPENSSL_INIT_NO_ATEXIT issue
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Dan Heinz > Sent: Thursday, August 15, 2019 13:19 > blows up. Not entirely conventional, but it might be revealing. > > It is actually in a call to libxml2 and does not > appear to be related to OpenSSL. Now I just need to figure out why libxml2 > is not freeing it. Some quick online searching (I don't have the source for libxml2 handy on this machine) suggests it may be the globalkey variable, allocated in xmlOnceInit. Some old messages from the libxml2 mailing list suggest it ought to be TlsFree'd in the DLL_PROCESS_DETACH case of libxml2's DllMain. If I were investigating this, I'd grab the libxml2 sources and build it for debug, then debug the process at fault with breakpoints set appropriately. -- Michael Wojcik Distinguished Engineer, Micro Focus
RE: OPENSSL_init_crypto with OPENSSL_INIT_NO_ATEXIT issue
>The output certainly suggests something is calling TlsAlloc between the call
>made for destructor_key.value and the one for private_drbg, and that index is
>never freed. You always get 7 when allocating destructor_key.value because
>that >index was freed when you unloaded OpenSSL, and so it's the next
>available one when you load OpenSSL again.
>
>It may not be OpenSSL itself that's calling TlsAlloc and not releasing an
>index - it may be one of its dependencies.
>
>Have you duplicated this under a debugger, with a breakpoint on TlsAlloc? The
>earlier messages suggest that you may have, but it's not entirely clear from
>what you posted. You ought to be able to catch the offending call and get at
>>least a partial traceback.
>
>If you're having trouble tracing it, you could try adding this:
>
>{int i; for (i=8; i
>right after the code that calls TlsAlloc for private_drbg, and seeing what
>blows up. Not entirely conventional, but it might be revealing.
After some further debugging, it appears there is an unknown TSAlloc called
which returned index 8. OpenSSL was allocating index 7, then the index 8 was
allocated somewhere outside the OpenSSL library, and finally OpenSSL allocated
indexes 9, 10, and 11. I was able to call TlsFree(8) in my DLLMain when my DLL
is unloaded and I didn't have any more issues. Obviously, that is not a fix
and I was further able to track down at least where the allocation was
happening. It is actually in a call to libxml2 and does not appear to be
related to OpenSSL. Now I just need to figure out why libxml2 is not freeing
it.
Thank you Matt and Michael for you help. :-)
Difference ASN1_item_d2i_bio / ASN1_d2i_bio_of ?
Hi,
I want to read several bespoke ASN1 types from a BIO. DECLARE_ASN1_FUNCTIONS
does not include d2i bio routines, so what is the best way to define them?
I have seen both ASN1_item_d2i_bio() and ASN1_d2i_bio_of() and it is not clear
to me why one might be used over the other.
E.g. cms_io.c has a one-line function calling ASN1_item_d2i_bio():
CMS_ContentInfo *d2i_CMS_bio(BIO *bp, CMS_ContentInfo **cms)
{
return ASN1_item_d2i_bio(ASN1_ITEM_rptr(CMS_ContentInfo), bp, cms);
}
Whereas ocsp.h has a macro using ASN1_d2i_bio_of, which itself is defined in
terms of ASN1_d2i_bio():
# define d2i_OCSP_REQUEST_bio(bp,p)
ASN1_d2i_bio_of(OCSP_REQUEST,OCSP_REQUEST_new,d2i_OCSP_REQUEST,bp,p)
Regards,
Andrew.
Re: IPv6 address encoding in commonName
On 8/14/19 6:47 PM, Michael Richardson wrote: Robert Moskowitz wrote: > I am fiddling around with an intermediate CA signing cert that the CA's > 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 address. Actually a > Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to be revised soon). > For a client cert, it would be easy to put the HIT in subjectAltName per RFC > 8002 (with a null subjectName), but a CA cert MUST have a non-empty > subjectName. > Thus all I want in this subjectName is commonName with the HIT. > I am looking for examples of IPv6 addresses in commonName. I thought that RFC3779 did exactly what you want, but it does not define new Subject DN, but rather a new extension that will be bound to the Subject. (I was surprised that RFC3779 was not in the SIDR WG's list of documents,but I guess it preceeded the SIDR working group, and occured in PKIX) In ANIMA's ACP document, we have an abomination that leverages rfc822Name, mostly because we figure the odds of getting anything else through off-the-shelf CAs is nil. Note to consumed with things in your stomach: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-20#section-6.1.2 Jakob Bohm via openssl-users wrote: > As the author of a proposal in this area, could you define a notation > for IPv6 DNs, perhaps one that actually reflects the hierarchical nature > of IPv6 addresses? RFC3779 does some of that, but not in the DN itself. > You could take inspiration from the (unfortunately rarely used) > hierarchical DN representation of DNS names (this used the DNS > specific DC name components). Overall the goal is to allow X.500 > distinguished name restrictions to work correctly. Yes, we could abuse the DC component. Were you thinking about: DC=2001/DC=0db8 This looks closest to what is needed here, as the prefix for HHITs is currently proposed at /64. So it would be DC=2001/DC=0024/DC=0028/DC=0014 But the OID for DC is bi: 0.9.2342.19200300.100.1.25 Ouch. So I will research this more, but for this early stage in the development I will use: CN=2001:24:28:14::/64 Thanks for all the comments here. > In practice you could follow the nibble notation as already used > for delegation of IPv6 reverse lookups in DNS. so more correctly: DC=2/DC=0/DC=0/DC=1/DC=d/DC=b/DC=8 > However for the CN in the end cert you could perhaps use the full > DNS reverse IPv6 name > "x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa" > or the URL/Mail notation "[:::::::]" > where the hex notation shall be the shortest form permitted by the > IPv6 notation spec. Bob, this seems like the best immediate hack to me.
Re: IPv6 address encoding in commonName
Richard Levitte wrote: > On Thu, 15 Aug 2019 00:47:41 +0200, Michael Richardson wrote: >> >> >> Robert Moskowitz wrote: > I am fiddling around >> with an intermediate CA signing cert that the CA's > 'name' is it HIP >> (RFC 7401) HIT which is a valid IPv6 address. Actually a > >> Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to be revised >> soon). >> >> > For a client cert, it would be easy to put the HIT in subjectAltName >> per RFC > 8002 (with a null subjectName), but a CA cert MUST have a >> non-empty > subjectName. >> >> > Thus all I want in this subjectName is commonName with the HIT. > I >> am looking for examples of IPv6 addresses in commonName. >> >> I thought that RFC3779 did exactly what you want, but it does not >> define new Subject DN, but rather a new extension that will be bound >> to the Subject. (I was surprised that RFC3779 was not in the SIDR >> WG's list of documents,but I guess it preceeded the SIDR working >> group, and occured in PKIX) > OpenSSL does support that extension... crypto/x509v3/v3_addr.c (moved > to crypto/x509/v3_addr.c in next major version) is all about that as > far as I can see. > Thanks for bringing that up. Trying to infer some kind of meaning into > commonName would be a mistake (isn't previous such hacks the very > reason we have the subjectAltName extension?) Yes, but we didn't let (intermediate) CAs have an empty subject DN, SAN-only, because we don't have an IssuerAltName for the next level. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature
