Re: Kerberos/PKINIT compliant subjectAltName?
On Tue, Feb 11, 2003, Dr. Stephen Henson wrote: > > When this is patched (probably the next snapshot) then this might work > (I'm just writing this on the fly from the draft so no guarantees!): > > > subjectAltName=otherName:1.3.6.1.5.2.2;ASN1:SEQUENCE:principal_seq > Made a typo above, it shouldn't have the "ASN1" bit and should instead say: subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:principal_seq also I've now added GeneralString to the mini ASN1 compiler. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Kerberos/PKINIT compliant subjectAltName?
Dr. Stephen Henson wrote: On Tue, Feb 11, 2003, Thomas Anders wrote: Hello, the Kerberos/PKINIT Internet draft (http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-16.txt, chapter 3.2.2.2) requires the KDC certificates to specify Kerberos realm and principal name in the subjectAltName extension with type-id 1.3.6.1.5.2.2. Is there a way to specify such a subjectAltName extension in openssl.cnf? If this can only be done by specifying "subjectAltName=DER:...", how can I create the appropriate DER data? Thats a rather weird extension: it uses an odd type and some unnecessary tagging. Creating it manually would be rather difficult. You could use the mini-ASN1 compiler in OpenSSL 0.9.8 but it doesn't currently directly handle GeneralString (its not apparent why the draft should use that as opposed to UTF8String) I'll fix it so it does. Kerberos is ASN.1 based. The Realm names in the current protocol specifications use GeneralString to represent REALM names. GeneralString is being replaced with a new type, KerberosString, in the next revision of the protocol. If you want to read the gory details, read Section 5.2.1 of http://www.isi.edu/people/bcn/krb-revisions/krbclar5-4.html As for PKINIT, I will predict that the current draft will not survive in its current form. The reason it is at revision 16 is not because there have been numerous revisions but because the I-D has simply been republished for years while the Kerberos Working Group is focused on getting out revisions to the core protocols.
Re: Kerberos/PKINIT compliant subjectAltName?
On Tue, Feb 11, 2003 at 10:06:29AM +0100, Thomas Anders wrote: > Hello, > > the Kerberos/PKINIT Internet draft > (http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-16.txt, > chapter 3.2.2.2) requires the KDC certificates to specify Kerberos realm and > principal name in the subjectAltName extension with type-id 1.3.6.1.5.2.2. Hi, This is connected somewhat. So if your considering using OpenSSL with Kerberos 5 with LDAP. Is that doable as yet? I had thought it was. Best Regards, [EMAIL PROTECTED] -- /* Security is a work in progress - dreamwvr */ # # Note: To begin Journey type man afterboot,man help,man hier[.] # // "Who's Afraid of Schrodinger's Cat?" /var/(.)?mail/me \? ;-] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Kerberos/PKINIT compliant subjectAltName?
On Tue, Feb 11, 2003, Jeffrey Altman wrote: > Dr. Stephen Henson wrote: > > > > >Creating it manually would be rather difficult. You could use the mini-ASN1 > >compiler in OpenSSL 0.9.8 but it doesn't currently directly handle > >GeneralString (its not apparent why the draft should use that as opposed to > >UTF8String) I'll fix it so it does. > > > > > Kerberos is ASN.1 based. The Realm names in the current protocol > specifications use GeneralString to represent REALM names. A quick perusal of the spec suggest that the GeneralString might contain a text representaion of a DN from RFC2253 which would be UTF8, requiring some painful character set shifting. > GeneralString is being replaced with a new type, KerberosString, in the > next revision of the protocol. If you want to read the gory details, > read Section 5.2.1 of > http://www.isi.edu/people/bcn/krb-revisions/krbclar5-4.html > Gory indeed, almost all the tagging is unnecessary AFAICS. The restraint on GeneralString may end up meaning that some DNs can't be represented. I think I'll have to go any lie down for a bit now... Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Kerberos/PKINIT compliant subjectAltName?
Dr. Stephen Henson wrote: subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:principal_seq also I've now added GeneralString to the mini ASN1 compiler. Once the proper subjectAltName is constructed, is/will there be a way to get sth. more meaningful than X509v3 Subject Alternative Name: othername: from "openssl x509 -noout -text ..." (latest snapshot)? How can I print out the DER value (in hex) that can later be used in openssl.cnf (subjectAltName=DER:...) to put the same extension into new certificates? Kind regards, Thomas -- Thomas Anders (thomas.anders at blue-cable.de) __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Kerberos/PKINIT compliant subjectAltName?
On Tue, Feb 18, 2003, Thomas Anders wrote: > Dr. Stephen Henson wrote: > >subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:principal_seq > > > >also I've now added GeneralString to the mini ASN1 compiler. > > Once the proper subjectAltName is constructed, is/will there be > a way to get sth. more meaningful than > > X509v3 Subject Alternative Name: > othername: > > from "openssl x509 -noout -text ..." (latest snapshot)? > This is tricky. It will need some fairly major changes to the way extensions are printed to handle this case. At best it will just print out the asn1parsed result for non supported extensions. > How can I print out the DER value (in hex) that can later be > used in openssl.cnf (subjectAltName=DER:...) to put the > same extension into new certificates? > > You don't need to do that with OpenSSL 0.9.8. If you need compatiblity with earlier versions of OpenSSL and the DER option then you need to extract the raw encoding of the extension. Start with: openssl asn1parse -in cert.pem look for an OBJECT with subject alternative name in it. Then look for an OCTET STRING immediately after it, note the number at the start of that line. Then do: openssl asn1parse -in cert.pem -strparse -out ext.der this text form BTW is the kind of thing OpenSSL might be able to do for unsupported otherName extensions. This will put the binary form of the extension in "ext.der". You now need to convert it to hex and put the result after DER: in the openssl config file. The Unix utility xxd with the -p option does a good job of this. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
