help with x.509 extrensions - Openssl

This is a discussion on help with x.509 extrensions - Openssl ; I have been working on trying to add extenstions to a CA certificate
and coming up short. I read through doc/openssl.txt, as well as the
man pages for openssl, ca, and req. I also searched google and the
list archives. ...

help with x.509 extrensions

I have been working on trying to add extenstions to a CA certificate
and coming up short. I read through doc/openssl.txt, as well as the
man pages for openssl, ca, and req. I also searched google and the
list archives. Maybe I am just dense. I don't believe I need to write
any code. I don't care about pretty printing. I am using openssl
0.9.8b. The error message is below.

Re: help with x.509 extrensions

Hi there;

On July 14, 2008 11:36:34 am Oil Supply wrote:
> I have been working on trying to add extenstions to a CA certificate
> and coming up short. I read through doc/openssl.txt, as well as the
> man pages for openssl, ca, and req. I also searched google and the
> list archives. Maybe I am just dense. I don't believe I need to write
> any code. I don't care about pretty printing. I am using openssl
> 0.9.8b. The error message is below.
>
> #This is the extension I want to add
> fooname=this is a block of text
> basicConstraints = CA:true
> keyUsage = cRLSign, keyCertSign
> [ crl_ext ]
> authorityKeyIdentifier=keyid:always,issuer:always

What is fooname? What is the encoding? An extension is represented (in the
simplest form), as an OID (that identifies which extension it is, and a value
that is encoded as per the RFC (or other document) rules for that extension.

So, for instance, if fooname is an extension that corresponds to the
OID '1.2.3.4', and it is of value UTF8String, then I think that the right way
to encode it could be:

1.2.3.4 = UTF8:This is a block of text

I've not tried the above, and Stephen or one of the others can give you a
better answer than I, but I hope that gets you started in the right
direction.

One thing - DO NOT pull an OID out of thin air... register your OID properly
with IANA.

As an aside - populating certificates with "Private Extensions" is usually
a "VERY BAD IDEA", since 100% of the applications that you try to use them
with will, at the best, ignore the value, thus rendering the purpose of
putting it in the certificate moot, or, at worst, try and interpret it, and
crash.

If you are just putting in extra text, I would suggest writing this text into
the Subscriber agreement, or writing it into the CP, and referencing it
indirectly via the certificatePolicy standard extension.

Re: help with x.509 extrensions

On Mon, Jul 14, 2008 at 1:51 PM, Patrick Patterson wrote:
>
>> #This is the extension I want to add
>> fooname=this is a block of text
>> basicConstraints = CA:true
>> keyUsage = cRLSign, keyCertSign
>> [ crl_ext ]
>> authorityKeyIdentifier=keyid:always,issuer:always
>
> What is fooname? What is the encoding? An extension is represented (in the
> simplest form), as an OID (that identifies which extension it is, and a value
> that is encoded as per the RFC (or other document) rules for that extension.
>
> So, for instance, if fooname is an extension that corresponds to the
> OID '1.2.3.4', and it is of value UTF8String, then I think that the right way
> to encode it could be: 1.2.3.4 = UTF8:This is a block of text

Hi Pat. According to the docs and what I read, this should just "work".

In this case, fooname is just a string. I am starting simple to get
the syntax down, then I will tackle other types. So I am not trying
anything fancy. I did try your suggestion if trying using the bare OID
but got the same error.
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majordomo@openssl.org

Re: help with x.509 extrensions

On Mon, Jul 14, 2008, Oil Supply wrote:
> On Mon, Jul 14, 2008 at 1:51 PM, Patrick Patterson
> wrote:
> >
> >> #This is the extension I want to add
> >> fooname=this is a block of text
> >> basicConstraints = CA:true
> >> keyUsage = cRLSign, keyCertSign
> >> [ crl_ext ]
> >> authorityKeyIdentifier=keyid:always,issuer:always
> >
> > What is fooname? What is the encoding? An extension is represented (in the
> > simplest form), as an OID (that identifies which extension it is, and a value
> > that is encoded as per the RFC (or other document) rules for that extension.
> >
> > So, for instance, if fooname is an extension that corresponds to the
> > OID '1.2.3.4', and it is of value UTF8String, then I think that the right way
> > to encode it could be: 1.2.3.4 = UTF8:This is a block of text
>
> Hi Pat. According to the docs and what I read, this should just "work".
>

Well whatever docs they are it wont ;-)

OpenSSL has no idea how to process "fooname" or the value.
> In this case, fooname is just a string. I am starting simple to get
> the syntax down, then I will tackle other types. So I am not trying
> anything fancy. I did try your suggestion if trying using the bare OID
> but got the same error.

Re: help with x.509 extrensions

Thanks Dr. Henson,

So that leaves me with some more questions.

What is the new_oids section supposed to be used for? Because it looks
like I just add a name=oid and then for simple strings, add the
extension as name= the man pages refer to this as well. That
is my confusion.

My initial try at this syntax "1.2.3.4 = ASN1:UTF8:This is a block of
text" failed my first time (before I posted for help) because I didn't
add the ASN1, but even that attempt was more of a shot in the dark.

Anyway, I corrected it and it works and I can try some other sequences.

Oil

On Mon, Jul 14, 2008 at 3:35 PM, Dr. Stephen Henson wrote:
> On Mon, Jul 14, 2008, Oil Supply wrote:
>
>> On Mon, Jul 14, 2008 at 1:51 PM, Patrick Patterson
>> wrote:
>> >
>> >> #This is the extension I want to add
>> >> fooname=this is a block of text
>> >> basicConstraints = CA:true
>> >> keyUsage = cRLSign, keyCertSign
>> >> [ crl_ext ]
>> >> authorityKeyIdentifier=keyid:always,issuer:always
>> >
>> > What is fooname? What is the encoding? An extension is represented (in the
>> > simplest form), as an OID (that identifies which extension it is, and a value
>> > that is encoded as per the RFC (or other document) rules for that extension.
>> >
>> > So, for instance, if fooname is an extension that corresponds to the
>> > OID '1.2.3.4', and it is of value UTF8String, then I think that the right way
>> > to encode it could be: 1.2.3.4 = UTF8:This is a block of text
>>
>> Hi Pat. According to the docs and what I read, this should just "work".
>>
>
> Well whatever docs they are it wont ;-)
>
> OpenSSL has no idea how to process "fooname" or the value.
>
>> In this case, fooname is just a string. I am starting simple to get
>> the syntax down, then I will tackle other types. So I am not trying
>> anything fancy. I did try your suggestion if trying using the bare OID
>> but got the same error.
>
> The correct syntax for that example is:
>
> 1.2.3.4 = ASN1:UTF8:This is a block of text
>
> Steve.
> --
> Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
> OpenSSL project core developer and freelance consultant.
> Homepage: http://www.drh-consultancy.demon.co.uk
> __________________________________________________ ____________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager majordomo@openssl.org
>
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majordomo@openssl.org

Re: help with x.509 extrensions

On Mon, Jul 14, 2008, Oil Supply wrote:
> Thanks Dr. Henson,
>
> So that leaves me with some more questions.
>
> What is the new_oids section supposed to be used for? Because it looks
> like I just add a name=oid and then for simple strings, add the
> extension as name= the man pages refer to this as well. That
> is my confusion.
>

That should work but it wont result in "name" being displayed on things like
browsers: only OpenSSL will now about the mapping between name and the OID.

Re: help with x.509 extrensions

>> What is the new_oids section supposed to be used for? Because it looks
>> like I just add a name=oid and then for simple strings, add the
>> extension as name= the man pages refer to this as well. That
>> is my confusion.
>>
>
> That should work but it wont result in "name" being displayed on things like
> browsers: only OpenSSL will now about the mapping between name and the OID.Thanks again, Dr. Henson.

Ok, so to add an extension to a certificate so that the human name
"fooname" will be displayed in a browser or by openssl x509 command, I
need to write some routines to encode the name and what-not. And that
is explained in doc/openssl.txt in the source tree?

Do you, by you, I mean anyone on the list, think having the human
readable name in the certificate is a requirement?

Re: help with x.509 extrensions

On July 15, 2008 10:38:45 am Oil Supply wrote:
> >> What is the new_oids section supposed to be used for? Because it looks
> >> like I just add a name=oid and then for simple strings, add the
> >> extension as name= the man pages refer to this as well. That
> >> is my confusion.
> >
> > That should work but it wont result in "name" being displayed on things
> > like browsers: only OpenSSL will now about the mapping between name and
> > the OID.Thanks again, Dr. Henson.
>
> Ok, so to add an extension to a certificate so that the human name
> "fooname" will be displayed in a browser or by openssl x509 command, I
> need to write some routines to encode the name and what-not. And that
> is explained in doc/openssl.txt in the source tree?
>
No - you need to have it incorporated in an RFC or other standard that
browsers and Certificate processing routines implement.

All you encode in the certificate is an OID and a value - the way that a
program knows how to interpret and display it is built into the logic of the
program, based on the definition a the standard.
> Do you, by you, I mean anyone on the list, think having the human
> readable name in the certificate is a requirement?
>
If you are including a value in there that is meant to be read by a person,
then yes. If you are including a value in there that is meant to be
interpretted and acted upon by a Relying Party computer program, then no -
but then, as I said in my previous message, if you include a private
extension, the chances of either of these being possible with a
non-proprietary client is approximately nil. If your certificates are only
ever being used by a proprietary client in a closed community, then feel free
to add Private Extensions. If not, then it would probably be better to find a
way to express what you want to convey using one of the standard extensions.

Re: help with x.509 extrensions

> If you are including a value in there that is meant to be read by a person,
> then yes. If you are including a value in there that is meant to be
> interpretted and acted upon by a Relying Party computer program, then no -
> but then, as I said in my previous message, if you include a private
> extension, the chances of either of these being possible with a
> non-proprietary client is approximately nil. If your certificates are only
> ever being used by a proprietary client in a closed community, then feel free
> to add Private Extensions. If not, then it would probably be better to find a
> way to express what you want to convey using one of the standard extensions.

ah, now that clears things up. Thanks Patrick.

I am toying with the efficacy to use certificate attributes to make
application decisions (access control, look and feel, etc), so yes, a
private, closed system.

My idea, not a new one by any means, is to separate user provisioning
from application logic. I want to have an authoritative source of the
user and their role, and based on that, the application does something
special. I know there are probably easier ways to do this like assign
a user a role in the app, but I may want to have the user access
multiple apps and using a certificate seems like a good option. I will
certainly use the standard options where I can. I am reading through
the IETF PKIX docs even as we speak.

Re: help with x.509 extrensions

On July 15, 2008 10:57:21 am you wrote:
> > If you are including a value in there that is meant to be read by a
> > person, then yes. If you are including a value in there that is meant to
> > be interpretted and acted upon by a Relying Party computer program, then
> > no - but then, as I said in my previous message, if you include a private
> > extension, the chances of either of these being possible with a
> > non-proprietary client is approximately nil. If your certificates are
> > only ever being used by a proprietary client in a closed community, then
> > feel free to add Private Extensions. If not, then it would probably be
> > better to find a way to express what you want to convey using one of the
> > standard extensions.
>
> ah, now that clears things up. Thanks Patrick.
>
> I am toying with the efficacy to use certificate attributes to make
> application decisions (access control, look and feel, etc), so yes, a
> private, closed system.
>
The main problem with doing this is scalability - every time your user changes
preferences, they will need to go through the process to get a new
certificate. Every time they move jobs, or change access rights, they will
need a new certificate. This means that you need to revoke the old one, and
somehow issue them a new one. Setting this up in a manner that actually has
the certificates mean something is non-trivial. If you don't care about
having trusted certificates, then I would strongly suggest doing your
identity management another way - PKI is notoriously user-unfriendly. If you
do care about having trusted certificates, then I strongly encourage you to
de-couple identity and access management. The current state of the art for
doing this, BTW, is Identity federation... you may want to take a look at it
instead of shoehorning things into certificates that were never meant to go
there (For the purists on the list - yes, there are attribute certificates,
but I have yet to see anyone actually using them
> My idea, not a new one by any means, is to separate user provisioning
> from application logic. I want to have an authoritative source of the
> user and their role, and based on that, the application does something
> special. I know there are probably easier ways to do this like assign
> a user a role in the app, but I may want to have the user access
> multiple apps and using a certificate seems like a good option. I will
> certainly use the standard options where I can. I am reading through
> the IETF PKIX docs even as we speak.
>
Sounds like what you really want is N-0 user Federation. SAML2.0 or WS-Fed
will both do what you want - and if you implement it using Cardspace (active
requestor profile) you should be able to get it to work relatively
painlessly.

Re: help with x.509 extrensions

On Tue, Jul 15, 2008 at 7:57 AM, Oil Supply wrote:
>> If you are including a value in there that is meant to be read by a person,
>> then yes. If you are including a value in there that is meant to be
>> interpretted and acted upon by a Relying Party computer program, then no -
>> but then, as I said in my previous message, if you include a private
>> extension, the chances of either of these being possible with a
>> non-proprietary client is approximately nil. If your certificates are only
>> ever being used by a proprietary client in a closed community, then feel free
>> to add Private Extensions. If not, then it would probably be better to find a
>> way to express what you want to convey using one of the standard extensions.
>
> ah, now that clears things up. Thanks Patrick.
>
> I am toying with the efficacy to use certificate attributes to make
> application decisions (access control, look and feel, etc), so yes, a
> private, closed system.

There's actually a type of certificate out there that is called an
"Attribute Certificate" that can provide access-control rights. You
might want to look into this -- generally, the CA would in this case
be the authenticator (either Active Directory, or Kerberos, or
something that provides centralized user authentication) which issues
certificates with relatively-short times, revoked whenever the user
logs out or otherwise changes some security attribute (such as group
membership).
> My idea, not a new one by any means, is to separate user provisioning
> from application logic. I want to have an authoritative source of the
> user and their role, and based on that, the application does something
> special. I know there are probably easier ways to do this like assign
> a user a role in the app, but I may want to have the user access
> multiple apps and using a certificate seems like a good option. I will
> certainly use the standard options where I can. I am reading through
> the IETF PKIX docs even as we speak.

I should mention that Lotus Domino has been doing this for nearly 20
years. If it had a lower cost-of-entry (currently it's around $35,000
for a single server, plus licenses to run Notes clients, plus client
licenses for Notes clients to access the Domino server) I'd recommend
it as a potentially-viable approach.

Re: help with x.509 extrensions (OFFTOPIC)

Hi Kyle;

On July 15, 2008 02:22:59 pm Kyle Hamilton wrote:
> I should mention that Lotus Domino has been doing this for nearly 20
> years. If it had a lower cost-of-entry (currently it's around $35,000
> for a single server, plus licenses to run Notes clients, plus client
> licenses for Notes clients to access the Domino server) I'd recommend
> it as a potentially-viable approach.
>

You may want to take a look at Lotus Foundations (http://www.nitix.com) - I'm
sure that they are selling that for a lot less than 35K, and I know it
includes a bunch of client licenses.

Re: help with x.509 extrensions

Thanks Kyle. I am going to look at this and Patrick's suggestions for
SAML and WS-Fed. They seem to be viable options.

On Tue, Jul 15, 2008 at 2:22 PM, Kyle Hamilton wrote:
> On Tue, Jul 15, 2008 at 7:57 AM, Oil Supply wrote:
>>> If you are including a value in there that is meant to be read by a person,
>>> then yes. If you are including a value in there that is meant to be
>>> interpretted and acted upon by a Relying Party computer program, then no -
>>> but then, as I said in my previous message, if you include a private
>>> extension, the chances of either of these being possible with a
>>> non-proprietary client is approximately nil. If your certificates are only
>>> ever being used by a proprietary client in a closed community, then feel free
>>> to add Private Extensions. If not, then it would probably be better to find a
>>> way to express what you want to convey using one of the standard extensions.
>>
>> ah, now that clears things up. Thanks Patrick.
>>
>> I am toying with the efficacy to use certificate attributes to make
>> application decisions (access control, look and feel, etc), so yes, a
>> private, closed system.
>
> There's actually a type of certificate out there that is called an
> "Attribute Certificate" that can provide access-control rights. You
> might want to look into this -- generally, the CA would in this case
> be the authenticator (either Active Directory, or Kerberos, or
> something that provides centralized user authentication) which issues
> certificates with relatively-short times, revoked whenever the user
> logs out or otherwise changes some security attribute (such as group
> membership).
>
>> My idea, not a new one by any means, is to separate user provisioning
>> from application logic. I want to have an authoritative source of the
>> user and their role, and based on that, the application does something
>> special. I know there are probably easier ways to do this like assign
>> a user a role in the app, but I may want to have the user access
>> multiple apps and using a certificate seems like a good option. I will
>> certainly use the standard options where I can. I am reading through
>> the IETF PKIX docs even as we speak.
>
> I should mention that Lotus Domino has been doing this for nearly 20
> years. If it had a lower cost-of-entry (currently it's around $35,000
> for a single server, plus licenses to run Notes clients, plus client
> licenses for Notes clients to access the Domino server) I'd recommend
> it as a potentially-viable approach.
>
> Alas, it's not.
>
> -Kyle H
> __________________________________________________ ____________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager majordomo@openssl.org
>
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majordomo@openssl.org