RE: Changing the expiry date of a cert
Is it possible to extend the expiry of this certificate without changing any other fields in the certificate? to which it seems that the answer is Yes, How could the answer be anything other than yes? All too easily. Because as you ourself point out, such a change would invalidate the signature. And if a new signature is acquired - for all practical purposes it is a new certificate, regardless of how much in common it happens to have with the old one. Could there be some mysterious force that compels you to change other fields? I never heard that there was a minimal change that was allowed without invalidating the cert. :-) Or you can argue that the answer is no, since you have to at least change the signature and you pretty much have to change the serial number. Exactly! And the OP replies: Yes. Thats what I was trying to ask. So, how can I change the expiry date of an existing certificate without changing any other field ? Is there any openssl command that I may use ? Did you not read or understand my answer? There is no difference between changing the date on the old certificate and issuing a new certificate. If one wants to preserve the old serial number and old signatures - the answer is no-how, no way. If one wants to have the same cert with a new expiration date - then just get a new cert with that one change (like David described). Just issue a new certificate the same way you issued the original one, changing only the expiration date (and the signature, if you want). Tell everyone you changed the expiration date on the original, they won't be able to tell that you're lying. Yes! :-) And how can the signature not be changed? It's a different stream of bits (from the original cert), so it necessarily requires a new (different) signature. Sorry if this sounds like insane ranting. I'm really trying to be helpful, but it seems like it didn't sink in the first time. :-) Let's see how the 2nd iteration goes. :-) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Error while encryption or Decrypting
That line means if benc still points at something, free it. The problem
is - more likely than not, somebody has already freed benc, but did not set
benc to zero (or NULL). As a result, this check (line 640) says benc is not
zero, so it must be pointing at something that must be freed, so invoke the
free().
Trace the use of benc and make sure whoever freed it before line 640, also
set it to zero.
Better way of freeing in the context would be:
if (benc != NULL) {
if (BIO_free(benc) == 0)
abort_with_error(Cannot free benc!);
benc = 0;
}
where abort_with_error() is your own function.
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pink Princess
Sent: Monday, July 30, 2007 06:50
To: Brad Hards
Cc: openssl-users@openssl.org
Subject: Re: Error while encryption or Decrypting
Dear brad
Thanks for the advice and the hint
I have been through the free commands to check where the error occured
In APPS folder in enc.c file
whenever I comment this line(640)
if (benc != NULL) BIO_free(benc);
the dump core disappear
I am working in check what does this line mean and what is benc
regards
On 7/29/07, Brad Hards [EMAIL PROTECTED] wrote:
On Saturday 28 July 2007 01:49, Pink Princess wrote:
*** glibc detected *** /home/noura/workspace/256OpenSSL/apps/openssl:
double free or corruption (!prev): 0x0820d170 ***
This is the most likely problem - you are free()ing memory that has already
been free()d. Maybe you are free()ing memory that openssl is cleaning up
later.
Try running under valgrind or a debugger.
Brad
RE: Certificates, users and machines
... is it necessary to issue ONE certificate to EACH individual. Yes. The problem of granting access based on membership in a group is an authorization problem. Correct. This doesn't have anything to do with certificates -- permissions and roles change independently of binding of key to identity. LDAP, flat files, /etc/group, etc. Mostly correct. Often is convenient to have not only identity - but also attributes of it certified. I.e. for the sake of the argument identity Michael may have an attribute employee of Tenebras, and another attribute permitted access to dev repository A12. I'm driving at Attribute Certificates. They are supposed to have shorter life than identity certs, but still long enough to be usable. You could have a hierarchy, with a subordinate CA for each role or group, if you want to manage it that way. I wouldn't. He would have to have attribute CA's for each attribute - not necessarily for each value of the attribute. I.e. an attribute CA Personnel Department could issue attribute certificates employed in position X, granted access to resource Y... The question of whether attribute certs are better or worse for authorization than e.g. flat files is similar to whether cert-based identity authentication is better or worse than e.g. LDAP-based one or flat files e.g. Unix /etc/passwd. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Certificates, users and machines
Well, the Subject Distinguished Name should have the Organization... Can you envision long-lived certs issued by gov't - like passports? In that case, Organization would not have the same semantics. But this is less relevant for our discussion. ...but I strongly disagree with you if you think access permissions belong anywhere in a cert. It appears to be convenient to have _separate_ certs - called ATRIBUTE certs - that carry that information. More convenient than other means of conveying this same information. In the above example - identity cert is your passport issued by (for the sake of the argument) USA, attribute cert issued by a different authority is your visa to enter (for the sake of the argument) India issued by Indian consulate and with life-time shorter than your passport. Attribute certs are a lousy way to encode security policy. Matter of taste. You really only need signed assertions if the relying party has no trusted method of communication with the policy server (file/db/etc). Of course. Just like you really only need identity certs if the relying party has no trusted method of communicating with authentication server. I.e. if everything in your shop (and other shops you're communicating with) is Kerberized - you don't need PKI. Revocation is a pain, certificate status is a pain, Of course. That's true for *all* the PK issues - be it identity or attribute certs. and you've just multiplied your public key computation load by a factor of three of four. No, you merely double it. One - check that the identity cert is valid, two - that the attribute cert that *you* are interested in (out of a dozen that may be attached to this identity cert) is OK. Much better to check whether the authenticated party has permission to do what's requested at the time of the request. Authentication and authorization are very disticnt and different things. Nonetheless, checking permissions is not that different from checking authenticity. For example - what means are there to check authenticity? And to check authorization? Group membership is questionable -- the OU is certainly a kind of group, but for the purposes of access control a party may belong to many groups, and a robust policy might restrict access to certain hours during certain days of the week. The idea is that credentials that are long-lived and are meaningful more-or-less universally (identity and - to a lesser extent - employment) seem to fit well in the identity cert. Credentials that have shorter life, but still somewhat persistent (and meaningful across localities) - would fit in the attribute certs. And credentials that are not meaningful outside of local environment and/or are very short-lived - probably are better served by online query to the policy server. ...[from a different post]...Authentication involve untrusted networks, passwords which can be stolen or forgotten etc. But once you trust authentication, decisions about authorization of authenticated users for certain operation are typically within your server system. If the only credential necessary for authorization decision is requestor's identity, and all the policy information is readily available online - then yes. Imagine a situation in the future: you are coming to a car dealer and present your identity cert plus an attribute cert issued by a bank that says owner of identity cert X has been approved for a loan for a new car in amount of up to $XX valid till XXX. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Certificates, users and machines
For both the responses I got, it looks like the server need to access the information (whether identity or attribute or whatever) present in the certificate and use that to decide the permissions for the peer that represented this certificate. Is my understanding correct? Partially so. An Attribute Certificate is a _separate_ certificate that becomes meaningful only when presented together with the identity cert. Its purpose is to be able to add and remove certified attributes to an identity cert, without having to re-issue the identity cert itself. I also agree that this is authorization problem. I was just trying to get information on whether certificate handling in openssl restricts me from issuing certificates to a group instead of individuals. I guees I know it now. The answer is - yes it does [restrict]. Sounds good. Now, my server will be expecting a few specfic attributes in the certificate presented by peer, in order to regulate access to different services, right? That would be one way of doing it... In design you should balance the expense of the authorization process against convenience of its use. I.e. are you going to authorize users based on credentials vouched by a 3rd party? If not - then somehting like a local policy server is a more elegant and computationally cheaper solution. So the question is which APIs in openssl allow me to access this information in the certificate? I'm afraid OpenSSL hasn't implemented Attribute Cert support yet. So the above discussion is moot from practical point of view. You'd need to search on the Net for one of a couple of OpenSSL enhancements that implement it (still in development stage), or use a policy server-based approach. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: RE: HTTPS security model
There are security paradigms such as SSH where you use leap of faith: strictly you haven't authenticated the remote end, but you know that your peer is the other box next to you, you verified its PK fingerprint visually, so you approve (authorize) that peer from now on. You are directly contradicting yourself. You say SSH is an example where you don't authenticate the remote end and then proceed to explain how you *do* identify the remote end. Leap of faith comes when the user does not verify the peer key fingerprint, but (99.999% of cases correctly) assumes that the computer he just connected to (for th first time) is the correct peer. Theoretically it is not necessarily so, practically it's good enough in most cases. From that point on, the observed public key is memorized to properly authenticate the peer. In fact, SSH's security model is much the same as HTTPS -- if the remote end does not present a certificate that proves it is the correct endpoint, the user is forced to manually approve the connection. Same thing. Comparable... Authentication and authorization are the same thing. Absolutely not! Authentication is who I am talking to. Authorization is what I allow you. You are changing the context. Obviously, in a very general case, authentication and authorization are the same thing. Hope you meant to say not. But we're talking about HTTPS. In the case of HTTPS, 'authorization' is the question of whether the connection is secure from third parties, those other than the endpoint of the SSL connection. In the case of HTTPS, 'authentication' is the question of who the other endpoint is. In this case, they are the same thing. They are both needed to make sure the legitimate party is the only party, and that is the *only* thing you care about. It is not possible nor sensible to separate them. OK. Let's go back to what I'm replying to: :The difficulty for the end user here is that the little lock icon is :overloaded: it is taken to mean both session is secured against :spying AND session is with a trusted partner. One could argue that :this confounds authentication (verifying the cert.) and authorization :(asserting trust of the target site). If there's nobody the communication needs to be secure from, there is no need for security at all. Yes, but this is not the case. If there's somebody the communication does need to be secured from, I am just as screwed if they are a spy or if they are the endpoint of the connection. Soi they are the same question -- there is no overloading. Proponents of the requested change believe that it is much likelier to have your communications observed by a passive attacker, than to have an active attacker in the path that masquerades as e.g. amazon.com. Not that the later is impossible - just less probable and less frequent. I'd adopt the change and created a new icon - say a small fence instead of a small lock to denote that the link is encrypted but the peer is not authenticated. :-) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: How to check if the certificate is self signed
Traditionally the term self-signed applied to certificates that are NOT signed by anybody but the owner of the given key pair. With all the relevant security implications. What is the purpose of checking for self-signed cert? To see if only the owner signed that key? Of to see that key owner ALSO signed the key? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Goetz Babin-Ebell Sent: Wednesday, October 25, 2006 11:49 To: openssl-users@openssl.org Subject: Re: How to check if the certificate is self signed -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ambarish Mitra schrieb: Hello Ambarish, On Wed, Oct 25, 2006, Goetz Babin-Ebell wrote: openssl verify -CAfile self_signed_cert.pem self_signed_cert.pem should return: self_signed_cert.pem: OK Maestro Steve appended: Indeed, technically a certificate with issuer and subject names identical is self-issued and may or may not be self signed. It has to be signed with its own key to be self signed which the above command checks. Is there a difference between certificate issue and sign? I was under the impression that a certificate is said to be issued only when it is signed. Can there be a case when a cert is issued, but is not signed? Please enlighten. A certificate is _issued_ by a CA authority with a given name. But a certificate is _signed_ by a private key. It is always possible to have more than one certificate with the same subject name. Only the combination issuer name / serial number must be unique. (Last time I checked OpenSSL has problems with more than one CA certificate with the subject name...) Let assume the following scenario: * CA1: subj: CN=CA,issr: CN=CA, Ser: 1, Key: #1, signed: Key #1 * CA2: subj: CN=CA,issr: CN=CA, Ser: 2, Key: #2, Signed: Key #2 * Usr1: subj: CN=User1, issr: CN=CA, Ser: 3, Key: #3, Signed: Key #1 * Usr2: subj: CN=User2, issr: CN=CA, Ser: 4, Key: #4, Signed: Key #2 As far as I remember X509 does not totally disallow this, but OpenSSL will have problems to verify the user certificates: All certificates are issued by the CA with the name CN=CA, but they are signed alternatively by the keys #1 and #2... Bye Goetz - -- DMCA: The greed of the few outweighs the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFP4da2iGqZUF3qPYRAr7aAJwIfipWcSzyWupBwYr8TU23MGeDkQCghPFR xiztkrNLS6ypH3GZUICmUnc= =B59/ -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Attribute Certificate with OpenSSL?
First - thank you! At least it was something. I went through the Web sit and the code distro itself. Web site shows how to use their command x509AT. Great. There's no AT-related README though, no documentation, no edits or patch-format changes. Thus hard to figure out the scope of changes involved. The Web page states that it is beta code. References to Lopez and Montenegro pages are dead. I.e. dead unmaintained project. So OpenSSL did not pick the Attribute Certificate extensions that Lopez and Montenegro added? Is there an alternative distro supporting AT? Is there (official?) work going on on (cleanly :-) adding support for Attribute Certs to OpenSSL? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Saurabh Arora Sent: Wednesday, September 13, 2006 17:58 To: openssl-users@openssl.org Subject: Re: Attribute Certificate with OpenSSL? On 9/14/06, Mouse [EMAIL PROTECTED] wrote: Did anybody use OpenSSL successfully for creating and processing Attribute Certificates? very much .. chek dis link.. http://openpmi.sourceforge.net/ Is there any helpful HOWTO or TFM? download openssl distro(patched to support AC) frm d same link. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Attribute Certificate with OpenSSL?
Your API looks good - perhaps your code combined with x509AT from Univ. of Malaga can provide the complete coverage? And yes - I'd like to take a look at your code (assuming it's under GPL, or OpenSSL license). I'll check with my bosses to see if they'd approve more active participation. Thank you! Regards, Uri -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Diaz Sanchez Sent: Thursday, September 14, 2006 10:00 To: openssl-users@openssl.org Subject: RE: Attribute Certificate with OpenSSL? Hello, I developed a beta API code for OpenSSL that may help you. Find enclosed a pdf document with the description. Tell me if you are interested or anybody wants to help me to improve it. Take into account that is a very very beta code. Apart from that, Jose Antonio Montenegro and Javier Lopez from Malaga University have been working on authorization for a very long time with very good results. I think that OpenPMI is not an unmaintained project. Try to contact the authors through http://www.lcc.uma.es/LCC?-f=indexlang.lcc-l=english Regards, Daniel -- Daniel Diaz Sanchez Telecommunication Engineer Researcher / Teaching Assistant Dep. Ing. Telemática Universidad Carlos III de Madrid Av. Universidad, 30 28911 Leganés (Madrid/Spain) Tel: (+34) 91-624-8817, Fax: -8749 Web: www.it.uc3m.es/dds web: http://www.it.uc3m.es/pervasive Mail: dds[at].it.uc3m.es Skype: dds.it.uc3m.es -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Mouse Enviado el: jueves, 14 de septiembre de 2006 15:49 Para: openssl-users@openssl.org Asunto: RE: Attribute Certificate with OpenSSL? First - thank you! At least it was something. I went through the Web sit and the code distro itself. Web site shows how to use their command x509AT. Great. There's no AT-related README though, no documentation, no edits or patch-format changes. Thus hard to figure out the scope of changes involved. The Web page states that it is beta code. References to Lopez and Montenegro pages are dead. I.e. dead unmaintained project. So OpenSSL did not pick the Attribute Certificate extensions that Lopez and Montenegro added? Is there an alternative distro supporting AT? Is there (official?) work going on on (cleanly :-) adding support for Attribute Certs to OpenSSL? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Saurabh Arora Sent: Wednesday, September 13, 2006 17:58 To: openssl-users@openssl.org Subject: Re: Attribute Certificate with OpenSSL? On 9/14/06, Mouse [EMAIL PROTECTED] wrote: Did anybody use OpenSSL successfully for creating and processing Attribute Certificates? very much .. chek dis link.. http://openpmi.sourceforge.net/ Is there any helpful HOWTO or TFM? download openssl distro(patched to support AC) frm d same link. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Attribute Certificate with OpenSSL?
Did anybody use OpenSSL successfully for creating and processing Attribute Certificates? Is there any helpful HOWTO or TFM? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Including attributes in the signed certificate
There is one more problem with attributes and official CA's. If you are your own CA, it makes a big difference (less trust around in the world - but you can enforce any attribute verification policy that you choose yo). Atttributes are added at the time of certification (good - so they can't be maliciously changed/removed/added later), but currently CA's do NOT verify them (bad - crap placed in by the identity owner is still crap). Thus, you can prove that you are Hubert - and add a whole bunch of stuff about you (the tallest man in Germany, undercover assistant of UN Secretary General, whatever). Resulting cert will contain a mix of true statements with something uncertain. A solution can be Attribute Certificate. I dont know if it makes sense to you - running your own CA you're free to do what's right regardless of what VeriSign is doing. Sorry I didn't answer your question - somebody more knowledgeable about OpenSSL will explain why it exhibits what I consider a bug (whatever is placed in the CSR must be signed IMHO). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Quarantel, Hubert Sent: Wednesday, September 06, 2006 08:46 To: openssl-users@openssl.org Subject: Including attributes in the signed certificate Hi ! I'm trying to include attributes/fields in a signed certificate. I've first issued a CSR with some extra attributes in it, here's what the CSR looks like with openssl req -in test.csr -text -noout : Certificate Request: Data: Version: 0 (0x0) Subject: O=TEST, OU=Support, CN=TEST/[EMAIL PROTECTED] Subject Public Key Info: Public Key Algorithm: dsaEncryption DSA Public Key: pub: (snip) P: (snip) Q: (snip) G: (snip) Attributes: countryName :FR localityName :Paris uidNumber:4321 gidNumber:1234 uid :test Signature Algorithm: dsaWithSHA1 (snip) I'm very happy so far, as I the attributes/fields countryName, uid, uidNumber, ... I added in the [req_attribute] of the default openssl.cnf file, along with their respective OIDs in the [new_oids] section. But, when I sign the certificate request with that same openssl.cnf file, either with openssl ca or with openssl x509, the produced certificate does not include those attributes, as shown by openssl x509 -text -in test.crt -noout Certificate: Data: Version: 3 (0x2) Serial Number: 2 (0x2) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=TEST CA, O=TEST/[EMAIL PROTECTED] Validity Not Before: Sep 6 11:09:06 2006 GMT Not After : Sep 7 11:09:06 2006 GMT Subject: O=TEST, OU=Support, CN=TEST/[EMAIL PROTECTED]Subject Public Key Info: Public Key Algorithm: dsaEncryption DSA Public Key: pub: (snip) P: (snip) Q: (snip) G: (snip) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 19:88:DF:ED:6C:82:86:BA:91:81:AA:1A:A4:55:A7:5C:20:7B:5A:62 X509v3 Authority Key Identifier: keyid:CF:A8:E1:B1:BD:5C:B2:55:9B:20:F5:44:8E:36:D2:F4:E6:E9:10:FF Signature Algorithm: sha1WithRSAEncryption (snip) Would anyone help me ? or at least tell me where I got wrong ? Thanks for any kind of help, Hubert, UNIX is user friendly. It's just selective about who its friends are. Ce message et les pièces jointes sont confidentiels et établis à l'attention exclusive de ses destinataires. Toute utilisation ou diffusion, même partielle, non autorisée est interdite. Tout message électronique est susceptible d'altération. Brink's décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas le destinataire de ce message, merci de le détruire et d'avertir l'expéditeur. This message and any attachments are confidential and intended solely for the addressees. Any unauthorized use or disclosure, either whole or partial is prohibited. E-mails are susceptible to alteration. Brink's shall not be liable for the message if altered, changed or falsified. If you are not
RE: extending a PKCS12 certificate
No, I didn't think of using Attribute Certificate not for authentication per se - but to ascertain certain properties of the authenticated entities. Your visa example is excellent - it illustrates my point very well. As for who manages AC - that's a different question, because AT THIS TIME CA's are the only organizations that both have public trust to provide this service (certifying something about public keys) and have the necessary experience and position to do that. I'm thinking of industrial deployment - for that I believe we need some company framework already established. I see no reason (besides possible unwillingness) who CA's would not want the extra business of certifying things other than raw indentities. Verification process isn't that different (if at all), and they are already verifying some attributes - so why not more. Thanks for PERMIS reference - I wasn't aware of it, will check. Regards, Uri -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitrij Mironov Sent: Monday, August 07, 2006 01:44 To: openssl-users@openssl.org Subject: RE: extending a PKCS12 certificate IMHO Attribute Certificates (AC) must be issued not by CA's, but by other institutions (if I remember correctly this is stated in RFC3181). PKC (public key cert.) in this situation is like passport and AC is like visa. If you are planning to use AC for authentification, then only you must manage AC issuance and revocation process. So, you need not a certificates from cert. providers, but AC infrastructure solution. Give some attention to openPERMIS or PERMIS projects, probably this helps. Regards, Dmitrij -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mouse Sent: Friday, August 04, 2006 5:10 PM To: openssl-users@openssl.org Subject: RE: extending a PKCS12 certificate It doesn't makes much sense to add attributes to certs if values of those attributes can't be verified. Attribute Certificate seems the right way to go (thanks, Vijay!). The question is - do our mainstream CA's (such as VeriSign, etc.) support Attribute Certificate? Tnx! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sascha Kiefer Sent: Friday, August 04, 2006 10:00 To: openssl-users@openssl.org Subject: RE: extending a PKCS12 certificate Hi Gerd, It will. But as Dmitrij already pointed out that there are Attribute Certificates. Those attributes are not part of the signed data, so they can be change (but also by anybody). But inside a PKCS there are at least safe and for internal use, it might work. (But you do not want to send login information that maybe stored in a public certificate send to the outside world, so for my understanding, it will no longer be a public certificate, would it?) So long, --sk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Freitag, 4. August 2006 17:24 To: openssl-users@openssl.org Subject: RE: extending a PKCS12 certificate Hello Sascha, wouldn't this invalidate the digest and therefor the entire certificate? If changing the arbitrary data does not invalidate the certificate, it must not be part of the digest, but then everybody would be able to change it. And just adding the arbitrary data to the PKCS12 file would not make those data more trustworthy either. If this is possible at all. With kind regards Gerd -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sascha Kiefer Sent: Friday, August 04, 2006 2:11 PM To: openssl-users@openssl.org Subject: RE: extending a PKCS12 certificate As far as i know, PKCS12 is just a combination of your private key and the public certificate. So, it should be possible to extract the certificate, make the changes and pack it together with the private key again. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Theodore Olen Sent: Freitag, 4. August 2006 15:31 To: openssl-users@openssl.org Subject: extending a PKCS12 certificate Hello all, I would like to ask a question about PKCS12 certificates. Is it possible to extend a PKCS12 certificate with arbitral data? I would like to extend a given certificate with user data (such as login and password) in such a way that the output certificate is still a valid certificate. If so, can this be done with OpenSSL? How do I extract the extensions? Thanks in advance. Kind regards, Theodore _ Meer ruimte
RE: extending a PKCS12 certificate
It doesn't makes much sense to add attributes to certs if values of those attributes can't be verified. Attribute Certificate seems the right way to go (thanks, Vijay!). The question is - do our mainstream CA's (such as VeriSign, etc.) support Attribute Certificate? Tnx! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sascha Kiefer Sent: Friday, August 04, 2006 10:00 To: openssl-users@openssl.org Subject: RE: extending a PKCS12 certificate Hi Gerd, It will. But as Dmitrij already pointed out that there are Attribute Certificates. Those attributes are not part of the signed data, so they can be change (but also by anybody). But inside a PKCS there are at least safe and for internal use, it might work. (But you do not want to send login information that maybe stored in a public certificate send to the outside world, so for my understanding, it will no longer be a public certificate, would it?) So long, --sk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Freitag, 4. August 2006 17:24 To: openssl-users@openssl.org Subject: RE: extending a PKCS12 certificate Hello Sascha, wouldn't this invalidate the digest and therefor the entire certificate? If changing the arbitrary data does not invalidate the certificate, it must not be part of the digest, but then everybody would be able to change it. And just adding the arbitrary data to the PKCS12 file would not make those data more trustworthy either. If this is possible at all. With kind regards Gerd -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sascha Kiefer Sent: Friday, August 04, 2006 2:11 PM To: openssl-users@openssl.org Subject: RE: extending a PKCS12 certificate As far as i know, PKCS12 is just a combination of your private key and the public certificate. So, it should be possible to extract the certificate, make the changes and pack it together with the private key again. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Theodore Olen Sent: Freitag, 4. August 2006 15:31 To: openssl-users@openssl.org Subject: extending a PKCS12 certificate Hello all, I would like to ask a question about PKCS12 certificates. Is it possible to extend a PKCS12 certificate with arbitral data? I would like to extend a given certificate with user data (such as login and password) in such a way that the output certificate is still a valid certificate. If so, can this be done with OpenSSL? How do I extract the extensions? Thanks in advance. Kind regards, Theodore _ Meer ruimte nodig? Maak nu je eigen Space http://spaces.msn.nl/ __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: What does PEM mean?
PEM = Privacy-Enhanced Mail. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bo Xie Sent: Monday, July 31, 2006 20:08 To: openssl-users@openssl.org Subject: What does PEM mean? I know openSSL supports .pem format. But what does PEM mean? Persoanl Encrypto Management? Thanks! Best Regards, Xie, Bo __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Using OpenSSL over a high level peer-to-peer middleware
The security work in SNMPv3 is old and outdated and years behind current practice. Some of that is understandable, but but even back then we knew enough to know that raw UDP is almost architecturally flawed. Not quite on the list topic - but if you were aware of the constraints placed on SNMP protocol and its security model, you probably wouldn't be so rash in judgement. P.S. I'm sure Marshall Rose would love to hear your arguments against UDP. :-) And so would DTLS crowd. :-) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Using OpenSSL over a high level peer-to-peer middleware
openSSL 0.9.8 comes with support for DTLS, which is TLS over UDP. Another point for the original poster to keep in mind is that SSL/TLS can require multiple read/writes for a single application-level packet exchange. SA establishment cost... This isn't always obvious to folks starting out. I think the DTLS spec discusses some of the implications. You might also want to look at the security in SNMPv3. Means what? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
