Any UK-like PKI laws in Canda?
This is sorta tangentially off-topc, but I'm not sure where else to ask. As many of you probably heard, the UK is activating a portion of a 6-year-old law that allows them to sieze private keys: http://news.zdnet.com/2100-1009_22-6073654.html?tag=nl http://news.zdnet.com/2100-1009_22-6105680.html I'm wondering if anyone has heard of similar happenings in Canada (yes, I'm aware of the increasingly rediculous PKI stance the US gov't has taking). Looking through their laws: http://www.solutions.gc.ca/pki-icp/guidedocs/guidedocs_e.asp And specifically, their PKI Confidentiality Certificate Policy: http://www.cra-arc.gc.ca/eservices/pki/ext-cp-conf-e.html And things seem pretty sane... but I thought I'd see if anyone out there had heard of any existing or purposed the gov't can request your private keys at any time in Canada. Thanks, -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com I don't need a reference, I have you! - Pippenger, to me. signature.asc Description: OpenPGP digital signature
[Fwd: Re: CAs and SubjectAltNames]
This didn't go through the first time. Re-sending. Original Message Subject: Re: CAs and SubjectAltNames Date: Wed, 12 Jul 2006 22:23:14 -0700 From: Phil Dibowitz [EMAIL PROTECTED] To: openssl-users@openssl.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] On Thu, Jun 08, 2006 at 04:21:52PM -0700, Dr. Stephen Henson wrote: On Thu, Jun 08, 2006, Phil Dibowitz wrote: Dr. Stephen Henson wrote: You have to explicitly enable copying extensions from a certificate request to a certificate in the config file. This is off by default because it is potentially dangerous for the unwary. See the docs for more info. Thanks, though I'm not sure which docs you're referring to - don't see anything to that effect in 'man ca'... Hmmm I think the 'noemailDN' option will do what I want upon more perusing of the man page... Look for the copy_extensions option in the ca manual page. You need OpenSSL 0.9.8 or later for that. Gotcha. OK, so here's what I did to make this work. However, it seems like I did a bit more work than I had to... so I'd like some feedback. In order to get my req (and thus the Issuer of my self-signed certificate) correct, under [ req ], I set: req_extensions = v3_req And then under [ v3_req ], I set: subjectAltName = email:move With any other setting req didn't have the email ONLY in SubjectAltNames. Then, to get it right in the final certificate, under [ CA_default ], I set: copy_extensions = copyall And under [ v3_ca ], I set: subjectAltName=email:move And the commands I used were: openssl req -new -keyout private/cakey.pem -out careq.pem -config \ ./openssl.cnf openssl ca -create_serial -out cacert.pem -days 365 -batch -keyfile \ private/cakey.pem -selfsign -extensions v3_ca -config ./openssl.cnf \ -infiles careq.pem Note here, I'm forcing use of the v3_ca section when I do the self-sign. Now, 1. It seems silly I have to set copy_extensions to copyall, but if I don't (if I just set it to copy), SubjectAltNames ends up being empty. This is presumably because subjectAltName=email:move is moving it out of the DN, and then copy_extensions has nothing to copy in. 2. Given #1, wouldn't that mean that subjectAltName=email:move is accomplishing my goal? Thus it makes no sense to me I need copy_exensions. 3. It seems that I'm missing something just by virtue of the fact I'm having to use copyall... Thoughts? -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com I don't need a reference, I have you! - Pippenger, to me. signature.asc Description: OpenPGP digital signature
Re: CAs and SubjectAltNames
This didn't go through either. Resending. Original Message Subject: Re: CAs and SubjectAltNames Date: Wed, 12 Jul 2006 22:46:27 -0700 From: Phil Dibowitz [EMAIL PROTECTED] To: openssl-users@openssl.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] On Wed, Jul 12, 2006 at 10:23:14PM -0700, Phil Dibowitz wrote: On Thu, Jun 08, 2006 at 04:21:52PM -0700, Dr. Stephen Henson wrote: On Thu, Jun 08, 2006, Phil Dibowitz wrote: Dr. Stephen Henson wrote: You have to explicitly enable copying extensions from a certificate request to a certificate in the config file. This is off by default because it is potentially dangerous for the unwary. See the docs for more info. Thanks, though I'm not sure which docs you're referring to - don't see anything to that effect in 'man ca'... Hmmm I think the 'noemailDN' option will do what I want upon more perusing of the man page... Look for the copy_extensions option in the ca manual page. You need OpenSSL 0.9.8 or later for that. Gotcha. OK, so here's what I did to make this work. However, it seems like I did a bit more work than I had to... so I'd like some feedback. Sorry to reply to myself, I need to make a correction. I can set copy_extensions = copy if I remove subjectAltName=email:move from v3_ca. Given that _this_ works, it leads me to ask the question... shouldn't subjectAltName=email:move only apply when there is something to move? It'd be nice to have a config that says, basically If the email is in SubjectAltName, like PKIX wants, just copy that extension. However, if it's in the DN, move it from the DN to the subjectAltName extension. I seem unable to do this, though I seem to be much closer. Thanks for all your help. -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com I don't need a reference, I have you! - Pippenger, to me. signature.asc Description: OpenPGP digital signature
CAs and SubjectAltNames
Didn't see a response to this the first time around, thought I'd give it another shot. I'm trying to create a CA that has the email address _only_ in SubjectAltNames (to follow PKIX valid certificate recommendations). This seems to be a bit tricky. Currently, I can get a req that looks right, but when I self-sign, it gets messed up. My config looks like: ... [ req ] req_extensions = v3_req ... [ v3_req ] subjectAltName = email:move [ v3_ca ] subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always basicConstraints = CA:true subjectAltName=email:move I create the key and csr like this: openssl req -new -keyout private/cakey.pem -out careq.pem -config \ ./openssl.cnf Then I self-sign it like this: openssl ca -create_serial -out cacert.pem -days 365 -batch -keyfile \ private/cakey.pem -selfsign -extensions v3_ca -config ./openssl.cnf \ -infiles careq.pem The req looks like this: Requested Extensions: X509v3 Subject Alternative Name: email:[EMAIL PROTECTED] The cert however looks like this: X509v3 extensions: X509v3 Subject Key Identifier: 19:FA:AB:62:DA:7D:7F:DA:A1:B1:F2:A7:51:7C:0B:DE:35:16:13:F2 X509v3 Authority Key Identifier: keyid:19:FA:AB:62:DA:7D:7F:DA:A1:B1:F2:A7:51:7C:0B:DE:35:16:13:F2 X509v3 Basic Constraints: CA:TRUE As you can see, it's disappeared. I've also tried setting subjectAltName=email:copy in v3_ca and then I get this in the cert: X509v3 Subject Alternative Name: EMPTY Which is unexpected. openssl 0.9.8b, Debian unstable Any help would be appreciated. -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
Re: CAs and SubjectAltNames
Dr. Stephen Henson wrote: You have to explicitly enable copying extensions from a certificate request to a certificate in the config file. This is off by default because it is potentially dangerous for the unwary. See the docs for more info. Thanks, though I'm not sure which docs you're referring to - don't see anything to that effect in 'man ca'... Hmmm I think the 'noemailDN' option will do what I want upon more perusing of the man page... -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
Re: CAs and SubjectAltNames
Phil Dibowitz wrote: Dr. Stephen Henson wrote: You have to explicitly enable copying extensions from a certificate request to a certificate in the config file. This is off by default because it is potentially dangerous for the unwary. See the docs for more info. Thanks, though I'm not sure which docs you're referring to - don't see anything to that effect in 'man ca'... Hmmm I think the 'noemailDN' option will do what I want upon more perusing of the man page... Upon trying this, it doesn't work. It works for the Subject but not the Issuer. They should match... :/ I'll keep looking for the doc you mention -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
Question on serial numbers
In some cases I see serial numbers as octet strings, i.e.: Serial Number: ef:e1:73:da:b3:6a:cf:ad:6b:18:dd:58:7f:6b:49:fe And other cases as an integer, i.e.: Serial Number: 2 (0x2) In openssl's case, self-signed certs use an octet-string (though this seems to not be true in all versions), while all certs signed by the CA seem to use an incrimenting serial number. I work with both openssl and the RSA Keon solution. The laster seems to use octet strings everywhere. What is the difference between these two types of serial numbers? Does one deprecate the other? I didn't see anything in RFC 2459 that addressed this. Thanks, -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
Re: Question on serial numbers
Goetz Babin-Ebell wrote: Phil Dibowitz schrieb: Hello Phil, In some cases I see serial numbers as octet strings, i.e.: Serial Number: ef:e1:73:da:b3:6a:cf:ad:6b:18:dd:58:7f:6b:49:fe And other cases as an integer, i.e.: Serial Number: 2 (0x2) The only difference is the size of the number. The moment processors (and C libraries) support 128 bit sized integers you will see both serial numbers printed in decimal... It is only a representation in the output functions. In the real data both are represented as an ASN1 integer, one with 1 byte length, the other with 16 byte length... Thanks for the quick reply. Hmm. Then why is it when I create a self-signed CA with openssl I get the former displayed, but when when I then sign a cert with that CA, I get the latter? I don't understand why it is using different byte lengths? -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
Re: Question on serial numbers
Dr. Stephen Henson wrote: On Wed, May 17, 2006, Phil Dibowitz wrote: Thanks for the quick reply. Hmm. Then why is it when I create a self-signed CA with openssl I get the former displayed, but when when I then sign a cert with that CA, I get the latter? I don't understand why it is using different byte lengths? Depends how the CA is set up. Some cookbook guides from various sources manually set up the OpenSSL serial number file to a small number. The standard OpenSSL tools such as CA.pl use a 64 bit random number for the serial number file. Ah. OK. CA.pl -newca takes a random 64-bit number for the serial number of the CA, and then auto-incriments that for all of the certs it signs. Why random? Why not start at 64-bits of 0s? Is there some benefit here? Thanks. -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
Re: Question on serial numbers
Dr. Stephen Henson wrote: On Wed, May 17, 2006, Phil Dibowitz wrote: CA.pl -newca takes a random 64-bit number for the serial number of the CA, and then auto-incriments that for all of the certs it signs. Why random? Why not start at 64-bits of 0s? Is there some benefit here? The serial number is an integer. 64 bits of 0s is 0 which is an illegal serial number. OK, fine, 63 bits of 0's and a 1. =P The reason for the random nature is so that OpenSSL by default makes it very unlikely to duplicate issuer names and serial numbers, which is a standard violation and can cause peculiar hard to trace errors in common web browsers. That can be very confusing for beginners. Wait - just to make sure I understand this... the concern is there might be another CA with the same DN out there, and thus we don't want to start with the same serial numbers as them? Thanks, -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
Re: Intermediate CA extension problems.
Dr. Stephen Henson wrote: Your problem is that you are telling OpenSSL to include the AKID extension by copying the SKID from the issuing CA. That CA doesn't have an SKID extension so it gives the error. Either remove that extension from the config file or include SKID in the root CA. So as I mentioned previously, I saw a proprietary solution doing this (generating an AKID keyID without a parent SKID), even though I realized it made no sense. So I called them on it. I asked how they were getting a keyID for AKID when the parent CA had no SKID. They informed me they're calculating a hash of the public key of the parent public key for the AKID... in other words - they're generating a SKID for the parent even though it doesn't have one. Intuitively, this kinda seems wrong to me, but reading the RFC it seems to comply. AKID keyId just needs to uniquely identify the parent public key. I'm curious what your thoughts on this are. Is this a reasonable thing to do? Are there problems with this? In the case where I have this, I plan to re-sign the parent to have SKID, but I'll be in this configuration for a bit before I can do that. Is this AKID bad in any way? Thanks. -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
Intermediate CA extension problems.
OpenSSL folks, I'm having an issue when making an intermediate CA. As I understand the specs (and please, correct me if I'm wrong), a root (i.e. self-signed) CA can be a v1 certificate, but intermediate CAs must: (a) be v3 (b) have SubjectKeyIdentifier (c) have AuthorityKeyIdentifier (d) have BasicKeyConstraints Based on that I have a CA that is self-signed with only crlDistributionPoint in it. I'm trying to create an intermediate CA with the above extensions in it and I'm having a problem. I have this in my config: [ v3_ca ] basicConstraints = CA:TRUE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always But when I run: openssl ca -config openssl.cnf -extensions v3_ca -infiles \ certreqs/sub_ca.csr I get: Using configuration from openssl.cnf Check that the request matches the signature Signature ok ERROR: adding extensions in section usr_cert 32587:error:2207707B:X509 V3 routines:V2I_AUTHORITY_KEYID:unable to get issuer keyid:v3_akey.c:151: 32587:error:2206B080:X509 V3 routines:X509V3_EXT_conf:error in extension:v3_conf.c:92:name=authorityKeyIdentifier, value=keyid:always I have a similar setup using a non-openssl solution, thus I'm fairly sure what I want to do is possible, I'm just missing something. Any help would be greatly appreciated. Thanks, -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
Re: otherName not supported?
Phil Dibowitz wrote: (sorry if this is a dup, I never saw my previous email come through) I was hoping to use otherName to store some information in my certificates... but it seems it's not all that supported: [EMAIL PROTECTED] tmp]$ openssl x509 -in test.crt -noout -text ... X509v3 Subject Alternative Name: othername:unsupported ... Is this a known bug, or am I missing something? I lost the reply but Stephen Henson noted: Currently the otherName component isn't displayed with the X509 print routines. You can however include arbitrary otherName data by specifying the appropriate ASN1 syntax in the config file. You'll need OpenSSL 0.9.8 to do that. This is documented in the x509v3_config manual page. Erm - is there plans to add support for the printing of this? -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
otherName not supported?
(sorry if this is a dup, I never saw my previous email come through) I was hoping to use otherName to store some information in my certificates... but it seems it's not all that supported: [EMAIL PROTECTED] tmp]$ openssl x509 -in test.crt -noout -text ... X509v3 Subject Alternative Name: othername:unsupported ... Is this a known bug, or am I missing something? -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
Re: Question on a good attribute for local information
Phil Dibowitz wrote: Bear Giles wrote: Issuer DN and serial number are unique. Yes, but we have a central identity system that uses GUIDs to ... everything. We want to do it for cerificates as well. We want said GUID to be in the certificate. Serial number is typically used for renewals, I don't want to step on that. Any suggestions for attributes for that? We'll only be dealing with our internal CA, so I have control over all of that. No references on places to look? Suggestions on extensions to use? For reference, the original question was: We'd like to tie all of our certificates to a unique identifier in a DB... is there an attribute out there, perhaps in the PKIX extensions or x509v3 extensions or somewhere else that would be a reasonable place for this? -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
Question on a good attribute for local information
We'd like to tie all of our certificates to a unique identifier in a DB... is there an attribute out there, perhaps in the PKIX extensions or x509v3 extensions or somewhere else that would be a reasonable place for this? Thanks, -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
Re: Question on a good attribute for local information
Bear Giles wrote: Issuer DN and serial number are unique. Yes, but we have a central identity system that uses GUIDs to ... everything. We want to do it for cerificates as well. We want said GUID to be in the certificate. Serial number is typically used for renewals, I don't want to step on that. Any suggestions for attributes for that? We'll only be dealing with our internal CA, so I have control over all of that. -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
