Add extra informations to certs
Hello, We need to put some extra informations (simple strings) into the certificates (e.g. year of birth, ...). I have looked around the internet, but don't really find any usefull stuff. So, do you have some links or hints where to start? How to read out this extra informations? Thanks from germany Dirk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Add extra informations to certs
A private X509v3 extension, perhaps? -Original Message- From: owner-openssl-us...@openssl.org on behalf of Dirk Reske Sent: Tue 3/31/2009 8:29 AM To: openssl-users@openssl.org Subject: Add extra informations to certs Hello, We need to put some extra informations (simple strings) into the certificates (e.g. year of birth, ...). I have looked around the internet, but don't really find any usefull stuff. So, do you have some links or hints where to start? How to read out this extra informations? Thanks from germany Dirk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org winmail.dat
Re: Add extra informations to certs
Hi, On Tue, Mar 31, 2009 at 05:29:15PM +0200, Dirk Reske wrote: We need to put some extra informations (simple strings) into the certificates (e.g. year of birth, ...). I have looked around the internet, but don't really find any usefull stuff. define a private extension. See RFC3280, section 4.2 for an introduction to extensions. How do you create and read the certificates? From the command line or in your own software based on OpenSSL? Best regards, Martin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Add extra informations to certs
li...@kaiser.cx schrieb: Hi, On Tue, Mar 31, 2009 at 05:29:15PM +0200, Dirk Reske wrote: We need to put some extra informations (simple strings) into the certificates (e.g. year of birth, ...). I have looked around the internet, but don't really find any usefull stuff. define a private extension. See RFC3280, section 4.2 for an introduction to extensions. How do you create and read the certificates? From the command line or in your own software based on OpenSSL? Best regards, Martin The project is still in planning phase, so not all things are clear. We want to read out the custom values in an apache module. Dirk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Add extra informations to certs
li...@kaiser.cx writes: Hi, On Tue, Mar 31, 2009 at 05:29:15PM +0200, Dirk Reske wrote: We need to put some extra informations (simple strings) into the certificates (e.g. year of birth, ...). I have looked around the internet, but don't really find any usefull stuff. define a private extension. See RFC3280, section 4.2 for an introduction to extensions. Presumably the standard subject directory attributes extension might be appropriate. http://tools.ietf.org/html/rfc5280#section-4.2.1.8 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Add extra informations to certs
Hi Dirk: Dirk Reske wrote: li...@kaiser.cx schrieb: Hi, On Tue, Mar 31, 2009 at 05:29:15PM +0200, Dirk Reske wrote: We need to put some extra informations (simple strings) into the certificates (e.g. year of birth, ...). I have looked around the internet, but don't really find any usefull stuff. define a private extension. See RFC3280, section 4.2 for an introduction to extensions. How do you create and read the certificates? From the command line or in your own software based on OpenSSL? Best regards, Martin The project is still in planning phase, so not all things are clear. We want to read out the custom values in an apache module. If this is a web based project, I would recommend against using attributes in Certificates - first of all, there are a VERY small set of the standard RFC3280 extensions that the mod_ssl will parse out, and make easily available to any sort of web module or application, let alone make it easy for you to pull out any custom attribute. Second, it's just plain bad PKI to put attributes in Identity Certificates. I would suggest, instead, to use some form of Federation (WS-Fed, SAML, Cardspace, etc.) to handle your attributes. This allows you to have the certificates be long life, and not tied to attributes which may change over time. Have fun. Patrick. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Add extra informations to certs
Patrick Patterson schrieb: Hi Dirk: Dirk Reske wrote: li...@kaiser.cx schrieb: Hi, On Tue, Mar 31, 2009 at 05:29:15PM +0200, Dirk Reske wrote: We need to put some extra informations (simple strings) into the certificates (e.g. year of birth, ...). I have looked around the internet, but don't really find any usefull stuff. define a private extension. See RFC3280, section 4.2 for an introduction to extensions. How do you create and read the certificates? From the command line or in your own software based on OpenSSL? Best regards, Martin The project is still in planning phase, so not all things are clear. We want to read out the custom values in an apache module. Second, it's just plain bad PKI to put attributes in Identity Certificates. What do you mean with this? Dirk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Add extra informations to certs
Hi Dirk: Dirk Reske wrote: Patrick Patterson schrieb: Second, it's just plain bad PKI to put attributes in Identity Certificates. What do you mean with this? Well, to quote IETF RFC3281 (which has to do with Attribute Certificates): Some people constantly confuse PKCs and ACs. An analogy may make the distinction clear. A PKC can be considered to be like a passport: it identifies the holder, tends to last for a long time, and should not be trivial to obtain. An AC is more like an entry visa: it is typically issued by a different authority and does not last for as long a time. As acquiring an entry visa typically requires presenting a passport, getting a visa can be a simpler process. Authorization information may be placed in a PKC extension or placed in a separate attribute certificate (AC). The placement of authorization information in PKCs is usually undesirable for two reasons. First, authorization information often does not have the same lifetime as the binding of the identity and the public key. When authorization information is placed in a PKC extension, the general result is the shortening of the PKC useful lifetime. Second, the PKC issuer is not usually authoritative for the authorization information. This results in additional steps for the PKC issuer to obtain authorization information from the authoritative source. For these reasons, it is often better to separate authorization information from the PKC. Yet, authorization information also needs to be bound to an identity. An AC provides this binding; it is simply a digitally signed (or certified) identity and set of attributes. (where PKC is a public key certificate (i.e.: Identity Certificate) and AC is an attribute Certificate). Now - the problem with implementing ACs, is that there are VERY few systems out there that implement them correctly, or at all - unless you are in a position to control everything about your environment (i.e.: Military or Intelligence agency), then ACs probably won't work in your environment. So, to achieve the separation of Attributes and Identity, as I said in my other mail, you should probably look at a technology that was conceived for the express purpose of transmitting attributes about a security principle around - i.e. Identity Federation :) Have fun. --- Patrick Patterson Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Add extra informations to certs
On Tue, Mar 31, 2009 at 1:56 PM, Dirk Reske d...@devhost.de wrote: Second, it's just plain bad PKI to put attributes in Identity Certificates. What do you mean with this? Placing additional attributes in the Identity Certificates makes those attributes available to everyone who can read them, and since the entire certificate must be sent in order for the certificate to be verified that means that it is an information leakage vulnerability -- someone who doesn't need to know a piece of information (e.g. the birthdate) suddenly does, and that can allow for a 'pretexting' attack. (This is a form of fraud where someone poses as a victim, usually across the phone, to obtain information that only the victim should be allowed to obtain. This was recently used in US politics to discredit someone from a position in the government hierarchy.) In the US, companies technically do not need to know the date-of-birth in order to comply with COPPA -- all they need to know is whether someone is over 13 and under 18. A trusted third party could know the birthdate, and sign a certificate (included as an attribute) that someone is (at the time of signing) subject to COPPA restrictions or not. -Kyle H __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Add extra informations to certs
Patrick Patterson schrieb: Hi Dirk: Dirk Reske wrote: Patrick Patterson schrieb: Second, it's just plain bad PKI to put attributes in Identity Certificates. What do you mean with this? Well, to quote IETF RFC3281 (which has to do with Attribute Certificates): "Some people constantly confuse PKCs and ACs. An analogy may make the distinction clear. A PKC can be considered to be like a passport: it identifies the holder, tends to last for a long time, and should not be trivial to obtain. An AC is more like an entry visa: it is typically issued by a different authority and does not last for as long a time. As acquiring an entry visa typically requires presenting a passport, getting a visa can be a simpler process. Authorization information may be placed in a PKC extension or placed in a separate attribute certificate (AC). The placement of authorization information in PKCs is usually undesirable for two reasons. First, authorization information often does not have the same lifetime as the binding of the identity and the public key. When authorization information is placed in a PKC extension, the general result is the shortening of the PKC useful lifetime. Second, the PKC issuer is not usually authoritative for the authorization information. This results in additional steps for the PKC issuer to obtain authorization information from the authoritative source. For these reasons, it is often better to separate authorization information from the PKC. Yet, authorization information also needs to be bound to an identity. An AC provides this binding; it is simply a digitally signed (or certified) identity and set of attributes. " (where PKC is a public key certificate (i.e.: Identity Certificate) and AC is an attribute Certificate). Now - the problem with implementing ACs, is that there are VERY few systems out there that implement them correctly, or at all - unless you are in a position to control everything about your environment (i.e.: Military or Intelligence agency), then ACs probably won't work in your environment. So, to achieve the separation of Attributes and Identity, as I said in my other mail, you should probably look at a technology that was conceived for the express purpose of transmitting attributes about a security principle around - i.e. Identity Federation :) Have fun. --- Patrick Patterson Chief PKI Architect Carillon Information Security Inc. http://www.carillon.com Thanks, but we only want to add extra identity informations. No Authorization stuff. Dirk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Add extra informations to certs
Kyle Hamilton schrieb: On Tue, Mar 31, 2009 at 1:56 PM, Dirk Reske d...@devhost.de wrote: Second, it's just plain bad PKI to put attributes in Identity Certificates. What do you mean with this? Placing additional attributes in the Identity Certificates makes those attributes available to everyone who can read them, and since the entire certificate must be sent in order for the certificate to be verified that means that it is an information leakage vulnerability -- someone who doesn't need to know a piece of information (e.g. the birthdate) suddenly does, and that can allow for a 'pretexting' attack. (This is a form of fraud where someone poses as a victim, usually across the phone, to obtain information that only the victim should be allowed to obtain. This was recently used in US politics to discredit someone from a position in the government hierarchy.) In the US, companies technically do not need to know the date-of-birth in order to comply with COPPA -- all they need to know is whether someone is over 13 and under 18. A trusted third party could know the birthdate, and sign a certificate (included as an attribute) that someone is (at the time of signing) subject to COPPA restrictions or not. -Kyle H Yes, we know about the security issues with the extended private data. But this is no commercial project, but a case study at our university. Dirk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Add extra informations to certs
On Tue, Mar 31, 2009 at 2:18 PM, Dirk Reske d...@devhost.de wrote: Yes, we know about the security issues with the extended private data. But this is no commercial project, but a case study at our university. Dirk Alright. (If any university in the US tried to do anything like this they'd be up on ethics charges at the very least, but... alright.) If you need to create your own private extensions, you need to obtain a Private Enterprise Number from the IANA -- you can get to the page to request one at http://pen.iana.org/pen/PenApplication.page . This is a fully-qualified number in the OID space, of the form 1.4.3.1.6.1.(PEN). These OIDs are required to be unique, and never reused -- and their semantics never changed once allocated. This shouldn't generally be a problem, because you can have as many subtrees off of your PEN as you might possibly want. At this moment, the webserver hosting the PEN application page doesn't seem to be working, but information on the authority for the program can be found in RFC 2578. -Kyle H __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
