The PKI Standard - Why do we Continue to Ignore it?

November - 2008

(I think I have now got the correct place to start a new thread - sorry for last stuff-up)

Since I can remember Open Products in general, focused on PGP as a non standard offering for free security methodology.
Out of mainstream commercial use PGP continued to become the de-facto standard as it avoided costly production and verification by limited CA’s.

Most all CA’s offer free and unlimited S/MIME Certificates and SSL Certificates remain a cost item and so they should.

Would you be happy for a NON CA to start to create either their own or free SSL certificates which would make a mockery and dilute safe Https traffic.

Now Open Products including OpenSuse are knocking on the door of major commercial, government and military Domains.
Fully supported SLES and SLED continues to offer the commercial wold a real time contender Operating Systems but we fail in adopting Global Standards in security and validation.

For Suse Linux and indeed Open Browsers and Email Clients there is a very poor and limited uptake of Global Security Standards to the point where Commercial, Government and Military domains can not consider the real-time use of any Open Software which fails in providing support for the Global Security Standard.

In order for us to provide a real world alternative operating systems and applications we can no longer accept Application Clients like Groupwise etc. to bridge the gap in global acceptance. Current handling by either Browser or Email Clients, with respect to correct handling and disposition messages remains poor or completely ignored.

It is clear that we need to look where the PKI Standard emanates and find that it is indeed a NON proprietary standard.

The PKI Standard is formulated by participating Countries of the United Nations, where the standard is defined and available to the World as a non-commercial standard without digital rights. ALL PKI Email Client and Browser handling is documented, however we do not follow it.

The PKI page

  1. Best Practice for PKI users
    https://www.eema.org/pki-challenge/files/pkiC_82.pdf
    All PKI products are highly configurable. This paper aims to provide guidance to those organisations that wish to exploit applications supported by PKI and maximise the chances of interoperability with other PKIs.

  2. Recommendations for vendors
    https://www.eema.org/pki-challenge/files/pkiC_83.pdf
    This document considers the implications for the vendor community in light of the conclusions of the pkiC, and makes recommendations about the features and levels of support for standards that PKI products should exhibit to encourage interoperability between users of different vendors’ products.

  3. Challenges for the PKI Industry
    https://www.eema.org/pki-challenge/files/pkiC_84.pdf
    Aimed at standard bodies, the European Commission, other groups with an interest in this area, and other participants, this paper outlines some of the technical challenges still facing the industry.

I would like to introduce this message as a possible introduction to the discussion to be had by interested and effected parties. This does need to happen soon as we are creating and developing security standards that will not be accepted, the single most startling of which is the functional ability to remove CA validation of PKI certificates from Browser and Email Clients alike.

Hi,

why do you think the opensource community ignores the PKI infrastructure? There is the famous openssl implementation which supports the PKI and is FIPS certified. You can create your own CA with it and sign certificate requests. There is also gnutls available which is also designed to handle x509 certificates and most common opensource software like apache, postfix, etc. can deal with certificates. As you can see the PKI is supported by opensourcre software and is not ignored.

open PGP is standardized by the IETF have a look at the following rfc’s: 3156, 2726, 2015, 1991. It’s you personal preference if you want to use S/MIME or open PGP for signing and encrypting you emails (both are based on the same cryptographic methods).

Have a lot of fun

As Monex says, people don’t and, in any case, which PKI standard do you mean - see Public key infrastructure/ - Wikipedia, the free encyclopedia

RE: Open SSL
I have no issue with a self self signed S/MIME, X5.09 or any PKI certificate as they are indeed useful - particularly for self security when the creator of the certificate is trusted. My issue is about there non-use and not following processing standards. - Chat to me in detail if you would like.

RE: Fake SSL
I do not think any of us wound be happy to see a dilution of SSL certificates - goodness knows its hard enough to ensure your own privacy when purchasing anything over SSL in combination with MS Windoze and the abundances of sypware we currently take our immunity from.

Without SSL standard PKI certificates lets all write our own to fake a secure connection and at the same time record and send all credit card numbers to 1 hacker in the guise of a diluted SSL connection -Year Right! More Net in-confidence business and all of us don’t need right now!

As far as interpretation of the PKI Standard, it is impossible to control how it is adopted in the World. Every ISO suffers to a degree from poor or inappropriate interpretation by a few! If you really want a copy of the standard and my URL references are not helpful then I suggest you approach ISO or UN-IT.
If you really want to chat to me about this please do.

No In dead we DO support it by both accepting and following defined message handling of most Root Certificates in open Browsers. What we do NOT Follow is the accurate processing of S/MIME Digital Certificates very well by most all Email Clients. When were you last able to attach you own private Key in to any email? When were you last successful in installing a Public Key that came to you with an Email. When did you last observe S/MIME Tracking disposition messages to be processed and sent out correctly. When…etc I think you get the message.

Can you tell me where PGP is defined by ISO?

Sorry new to this reply/Quote System see other message I entered yesterday.

As always please chat to me if you like - we need to confine our subject matter a little better - Perhaps we can start with either Root Certificate Handling OR S/MIME Email Digital Certificates for the first of 2 broader sub-headings.

As far as interpretation of the PKI Standard, it is impossible to control how it is adopted in the World. Every ISO suffers to a degree from poor or inappropriate interpretation by a few! If you really want a copy of the standard and my URL references are not helpful then I suggest you approach ISO or UN-IT.
If you really want to chat to me about this please do.

Sorry new to the reply/quote system - I have addressed you question here again in a better format.

Please Chat to me further if you wish and perhaps we both now need to quantify the broad headed into something more meaningful …see other reply message…:expressionless:

I guess at this point you are right. Normally I use thunderbird and the GUI for handling certificates isn’t intuitive. Enigmail for gnupg has a better approach for that :stuck_out_tongue: But I think (I didn’t test it yet) that the implementation works correct without any issues. From this point of view the PKI isn’t ignored but not as user friendly as it should be :slight_smile:

But don’t forget S/MIME is only one example of using certificates. I think it is more important is that postfix and apache fully supports x509 certificates so that it is possible to use https and all secure mail protocols as well as it is important that the open source clients can handle these protocols.

It is in the standard tracks of the IEEE just have a look at the linked rfc’s in my previous post. Not only the ISO is responsible for standards. The IEEE had in the past released very important standards like IPv*, TCP, and much more hence PGP MIME Security with OpenPGP is standard.

Have a lot of fun

RE: Enigmail - Fully supports PGP BUT with S/MIME This will only support the Digital Signing of a Message - The following Functionality is either missing or inappropriate.

**1. Unable to attach Private Key
2. Unable to import a Private Key
3. Unable to Encrypt an email due 1-2 above.
4. Incorrect handling of S/MIME receipts by email recipient.
**
RE: Postfix - All of the above.

Therefore Thunderbird and Postfix does not support PKI at all.
ALL other Open email client suffer the same problem.

RE: Root Certificates for Browser page encryption.

1. I cannot find any way for establishing an SSL connection which auto installs the appropriate client certificate when the page is viewed.
2. I cannot find no way for encrypting a HTTPS page of information!
3. I cannot find a way of creating an SSL/Encrypted Browser Page.
4. I cannot find a way of auto distributing the client certificate for 3. above.
5. I cannot find a way of distribution of the Client certificate that permits viewing of an encrypted SSL Browser Page by either email/POP3 or Postfix.

Therefore functionally we do NOT support the use of PKI in any of its uses and the standard way published for the handling of same. >:)

How can we expect any .GOV.MIL.??? who use ALL HTTPS/Encryption of both Browser and Emails to use OpenSuse??? They cannot do this as we done provide for its functional use by following the Standards!

Re: Establishing of Standards.
Yes the IEEE is responsible for most all Internet Communications Standards.
IF the UN create a way of utilizing the Internet in a Standard manner - I.E the whole of PKI - Then they Publish an ISO.

Being right or wrong is a non-issue - Its just that we currently do noting to support PKI - Therefore we are indifferent - and this is wrong!!!
Please chat to me about the above, Ill meet you in Brussels !!! :slight_smile:

  1. Yep this is right. That is a missing function. But it is possible to attach the certificate which is stored on disk. This isn’t the favored way but better than nothing :wink:
  2. This is possible but not as intuitive as it should be: got to settings -> miscellaneous -> certificates and choose the certificates from other persons tab. There is an import function which should do that. But compared to enigmail this isn’t user friendly enough.
  3. Solve the 2 above and it will function. I think I will test this during the next few days and check if it is possible and then report back.
  4. Same as 3.

Postfix is a MTA which is on the server side and fully supports x509. Otherwise it would be very bad and not as popular as it is. Regarding to the other mail clients I think you are right the situation is the same compared to thunderbird. I just looked into the settings of kmail (kde4) maybe the situation there is a bit better because I found in the settings that it is possible to check online for the certificate validity.

  1. Firefox and konqueror can handle this very easy. Ok in firefox 3 the new warning on unknown (self signed) certificate makes it a bit more complicated but after adding a exception which includes the download of the certificate all works fine and you are never asked again. The older version of firefox was a bit friendlier to unknown (self signed) certificates.
  2. HTTPS creates a secure communication channel between the http server and the web browser client. All exchanged data is encrypted between both ends so that it is not possible for a third person to read the exchanged data. Https is used automatic when you enter https:// in your browser and there should be a visible feedback symbol that indicates the usage of https in your browser and you don’t have to care about encryption and decryption.
  3. The certificate mus be available on the server side (for example apache2) and can be downloaded from there if needed. Most common certificates from trusted (whoever decides this) are already preinstalled in the browsers.
  4. They client key is only necessary when you want to do a client authentication with certificates otherwise it is not necessary that the client has a separate certificate. Hence usually it isn’t needed to distribute the certificates.
  5. You do not have to care about this the browser encrypts the page automatic based on the exchanged key informations (have a look at Transport Layer Security - Wikipedia, the free encyclopedia )

I would say that the user interface of S/MIME into the mail clients should be improved :wink: All other seems to be fine from my point of view.

RE: Attaching the Whole certificate - Are you out of your mind? If I sent my whole S/MIME certificate to another party I may as well give up my total email security. Another party only receives the Private Key of the Certificate - Not the public Key and entire certificate.

**If I sent my S/MIME email certificate to another how are they going to use it. The Subject E=(Is the email address of the sender) - Sorry this idea is totally off the wall.
**
Incoming Digitally Signed Emails, where S/MIME receipt it requested from source is not followed. S/MIME receipt handling is totally different to a plain ‘Return Receipt’

**I would say that we don’t even get past first base with either Email/Client Browser/ Web Browser Functionality as above and the Title Still Stands???

Happy to chat always.**

The certificate normally contain the public key and not the private key. So it is safe to send the certificate. Don’t forget that asymmetric encryption is used so that only the public key is needed to verify signatures and encrypt data. The public key is part of the certificate and the whole certificate is signed with the private key of the originator (CA or a certificate chain to the CA). So if you trust the CA you can verify that the public key in the certificate belongs to the certificate owner and you can use the public key for secure communication with the owner. Hence it is safe to send your certificate but make sure that it does not contain the private key (in some cases it is possible to exchange the certificate with private key).

Have a lot of fun.

Hello,

finally I tried S/MIME with thunderbird and self signed certificates. First step was to create a root certificate I did this via command line and openssl. For this I needed a private key for my new CA (I know it is possible to create a certificate and the key in one step but here I want to use the more detailed way):

openssl genrsa -des3 -out ca.key 4096

After that I created a self signed CA certificate:

openssl req -new -x509 -days 795 -key ca.key -out ca.crt

(note: this certificate does NOT contain the private key. Only the public key is stored inside this certificate.)

Hurray now I have my own Certificate Authority :wink: Now comes the certificate for my mail address. For this I had to create a new key again:

openssl genrsa -des3 -out mail.key 4096

And a certificate request which then will be signed with the CA key. In this certificate request you put your personal informations this time:

openssl req -new -key mail.key -out mail.csr

(note: this certificates contains only my/your public key)

Normally this request is sent to a genuine Certificate Authority but I now have my own authority so I could easily sign it myself :wink:

openssl x509 -req -days 795 -in mail.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out mail.crt

So all was now prepared and I have to setup thunderbird so that my certificate is used by thunderbird. For that I have to import my root CA first. Got to Tools → Internet Options → Content → Certificates → Trusted Root Certificate Authorities and import the ca.crt here. Thunderbird needs the private key and certificate imported so it is necessary to create a pkcs12 file with both in it:

openssl pkcs12 -export -in mail.crt -inkey mail.key -out mail.p12

And this file can be imported to tunderbird “my certificates” Installing an SMIME certificate - MozillaZine Knowledge Base. Now I had to setup my account so that it uses this certificate after that I could send signed and encrypted messages without any problems.

To distribute your key you have to make you certificate (not the pkcs12 file) and the root certificate public available.

Have a lot of fun

Hi Monex

I am happy you have a self signed X.509 Certificate form anyone, however if it was not issues by a CA then its next to useless, with the exception of internal mail. If a CA issues it the certificate can be revoked and ALL emails not already open will be refused.

The other part of the key file also contains my corresponding public key.

IF I send you the certificate file you will have both public and private keys - however you will not be able to use it as it is tied to the issued email account address.

When I sign my email the private key half enables me to do so. When you receive my email the key is validated by my CA - IF you try to open a signed email sent to your nnn address the signed email will open as long as it is access you the same nnn email address it was sent to - If another party tries to open the signed email, it will not open as the yyy address does not appear in the TO:…etc fields.

Also If I revoke the certificate I have used to sign my message you will be knock back from viewing it.

So sending you my single certificate file which contains both parts is next to useless and I would also need to send you the password for installing the key I used to install it.

I can find NO GUI functionality to both attach my public key to an email and as such I do not know if the Public Key would be able to be installed.

Without you having previously installed my public key I cannot send you I cannot encrypt any email.

For testing purposes I would strongly suggest that for email testing you obtain a free, unlimited number of X.509 email certificates from thawte.
thawte is a leading global certificate authority of SSL certificates, extended validation ssl (EV SSL) and code signing digital certificates
Go to the Products menu and use the free email certificates options and follow the bouncing ball.

As far as the rest of open products we have discussed with respect to SSL - as I cannot afford a real SSL certificate for testing, however if you are in Suse.DE Development you could get a free one for testing.

Also as far as I am concerned, if I cannot use the GUI interface of all Email Clients to get POP3 email X5.09 certificates to truly work as above then the Email Client is useless in this respect and its commercial appeal for all users does NOT yet exist.

Alyways happy to chat - Sorry for delay - I have been away of Christmas for a few days :wink:

If indeed the open SSL implementation of Email X.509 does not process the certificate as I have mentioned above when you obtain a real X.509 Email Certificate from Thwate…This is even more evidence that the open SSL implementation of Email Certificates is incorrect - and that is what our discussion is about!

Also with respect to Thunderbirds handling of Digitally Signed Message Disposition Messages - Thunderbird fails!.

If I send an Email from Outlook and Digitally Sign it with an X.509 Certificate from a CA and I have "Tracking’ turned on in outlook - Thunderbird does NOT send back the correct or even no Message Disposition back to the originator as specified by the PKI Digital Email Standard.

Also Thunderbird has no facility to activate Message Disposition for Digitally Signed emails as per above and as per the Standard!

As far as Browser Root Certioficates are concerned I have no issue with the way FF handeles PKI - Its Perfect!

As far as Apache goes I have huge issues with how it handles an HTTPS/Server Issues Certificate connection -
Example - Select any HTTPS site connection which displays VERISIGN or THWATE secure validation Icon
Click on the Icon - There are normally two options Secure/Encrypt
Select either
The Web Site Server should issue a Server Certificate and FF sees this as a pop-up sometimes, but will install the web site SSL Certificate in your browser with permission to either connect or Encrypt further connections.

FF Does handle this properly but I have not seen Apache provide a Web Site that correctly issues a Server Digital Certificate.

[QUOTE=zczc2311;1916794]Hi Monex Sorry forgot to mention

Hi, and welcome back

I think they are not useless as long as your communication partner trust your CA :wink: He installs your CA and verify it by the fingerprint that it is really yours. That’s nothing different compared to the pre-installed certificates he accepts you as a certificate authority and you can now also sign his certificate request so that you have a trust relationship between each other. I see no difference compared to a certificate signed from a certificate authority as long he trusts you and he ensures that the CA is not falsified on the way.

No!!! Only you public key is part of the certificate. Sure it is possible to create a pkcs12 certificate which contains both but this is not the one you exchange between each other.

Normally the certificate is not password protected. Only the private key is protected with a password. That’s related to the Public-key cryptography

Thats true I guess the mail clients lack of this ability especially thunderbird which I tested. Maybe there is ab addon which adds the missing functionality :slight_smile:

Have a lot of fun

[QUOTE=Monex;1918461]Hi, and welcome back

Thanks for further chat

RE: Thunderbird and every other email client I have tried that is an open client lacks all this functionality - I have tried them all

Thunderbird has NO add on at the time of witting - Only the poorly written Enigmail - What has hopeless coding.

This functionality goes to the Basic function of a secure email client that follows the standard - In dead this is what we have been talking about.

So far what we know is that the open SSL/PKI Certificate Manager does not comply with the standard - otherwise it would not be possible to create an X.509 certificate without both private and public keys.

So where are we left now - right back at the beginning text I wrote - nothing more nothing less.

There IS a Standard for all PKI issuance and handling of certified mail - we choose to ignore all of it. - So what .GOV/.MIL/.nnn is going to use an open email client …etc. - The answer remains none.

The only think about open software that does comply is FireFox.

Cheers

I think they are not useless as long as your communication partner trust your CA :wink: He installs your CA and verify it by the fingerprint that it is really yours. That’s nothing different compared to the pre-installed certificates he accepts you as a certificate authority and you can now also sign his certificate request so that you have a trust relationship between each other. I see no difference compared to a certificate signed from a certificate authority as long he trusts you and he ensures that the CA is not falsified on the way.

No!!! Only you public key is part of the certificate. Sure it is possible to create a pkcs12 certificate which contains both but this is not the one you exchange between each other.

Normally the certificate is not password protected. Only the private key is protected with a password. That’s related to the Public-key cryptography

Thats true I guess the mail clients lack of this ability especially thunderbird which I tested. Maybe there is ab addon which adds the missing functionality :slight_smile:

Have a lot of fun/QUOTE

Hi,

I just had a closer (but short) look at rfc 5280 and from my point of view only the public key is part of the certificate and not the private. It would be nice if you can put some more references (the links on the first posts to the pdfs are not working for me) to the standards you refer.

please put a reference to these standards. Otherwise I cannot follow your statements. As already said openssl is FIPS certified and most related applications are based on openssl so that I cannot see any reason why they shouldn’t be used. You always refer on handling on certified mail which is only one utilization of the PKI.

Have a lot of fun and a happy new year

Oh! That is very easy - You have the correct RFC - Suggest you study item 3.1 where the role of the Private and public part of the X.509 are defined - Always happy to chat, especially when the RFC DOES validate my statements:O

Quote - Sorry if the formatting get stuffed up
3.1. X.509 Version 3 Certificate

Users of a public key require confidence that the associated private
key is owned by the correct remote subject (person or system) with
which an encryption or digital signature mechanism will be used.
This confidence is obtained through the use of public key
certificates, which are data structures that bind public key values
to subjects. The binding is asserted by having a trusted CA
digitally sign each certificate. The CA may base this assertion upon
technical means (a.k.a., proof of possession through a challenge-
response protocol), presentation of the private key, or on an
assertion by the subject. A certificate has a limited valid
lifetime, which is indicated in its signed contents. Because a
certificate’s signature and timeliness can be independently checked
by a certificate-using client, certificates can be distributed via

I can’t see why this validates your statement, because there is a certificate which contains the public key and it must be secured that the public key is owned by the correct person. In other words it must be assured that the public key of the owner of the certificate is really his public key. This is secured due to the sign from the CA which checks the given data in the certificate and then digitally signs it with the private key of the CA. To check the signature and hence proofs the correctness of the certificate only the public key of the CA is needed which is part of the CA root certificate.

From this view I cannot follow your statement that the private key is part of the certificate, it isn’t and it isn’t needed because Public-key cryptography is used.

I’m also interested in references from the Digital Email Standard your referred earlier.

Have a lot of fun

My Apologies for being so short in my reply over a very complex matter. I used the part of RFC5280 to validate that there are always 2 parts to the generation of an Email X.509 which was in dispute in our previous messages about the creation of the X.509 .PEM Key itself. - If I understand your past message you wanted me to validate that the generation of the Key MUST contain 2 parts, as the open implementation on PKI does not mandate.

It is far better for us to examine RFC 1422 which supersedes the original mandate of component parts.

RFC1422 Clearly Mandates the mandatory component parts for the generation of an X.509. Email signature which the .PEM file is to contain.

You will see that RFC1422 clearly defines the .PEM file and the X.509 Components. If the openssl implementation does NOT mandate the fields that are to be included in the generation of the .
PEM file or X.509 Certificate then it is in conflict with the standard.

O.K I trust this defines the fields that are mandatory in an X.509 Certificate File that was previously in dispute.

On the subject of Encryption, This RFC only basically covers the Public Key Part and its requirement of the recipient to have to permit bi-lateral Encryption.

RFC1422 3.4.1.1 Generating and Protecting Component Pairs
only generalities on the Encryption Process and discusses both the Public and Private Key paths.

This is a very complex arrangement and requires ALL Players in its function. Th CA, The Private Key and the Public Key to encrypt/decrypt the message.

We need the help now of RFC 1421. This is where the RFC’s start chasing each others tails. In your reading of this RFC please make sure you are looking at references to X.509 NOT X400 is this has been superseded.
**
So Now we have a total Mandate for the required fields of an X.509 Certificate of Email Digital Signatures - The open CA Management, if I understand your previous message, does NOT mandate all these fields and as such we do not follow the correct PKI Standard in its X.509 Email form.**

If you would like to look at more detail in the manner that functionality is required to provide we can discuss Encryption and its process in more detail - Just let me know.

P.S I am very happy you wish to discuss PKI and its implementation. Right or Wrong is irrelevant in life, what is the worst crime is indifference.rotfl!