Dave Botsch wrote:
> I am looking at the userCertificate schema in our directory ..
First thanks a lot that I can have a look on to your Directoryserver.
> Description: Standard Attribute
> OID: 2.5.4.36
> Usage: User applications
> Syntax {length} 1.3.6.1.4.1466.115.121.1.5
>
> As you can see, all is the same minus the ";binary required" comment and the last
>digit of the syntax being a 5 and not an 8.
Hey, that's a good observation. I start searching the RFCs.
I found the following in the RFCs:
################################################
RFC 2252
4.3.1 Binary Transfer of Values
This encoding format is used if the binary encoding is requested by
the client for an attribute, or if the attribute syntax name is
"1.3.6.1.4.1.1466.115.121.1.5". The contents of the LDAP
AttributeValue or AssertionValue field is a BER-encoded instance of
the attribute value or a matching rule assertion value ASN.1 data
type as defined for use with X.500. (The first byte inside the OCTET
STRING wrapper is a tag octet. However, the OCTET STRING is still
encoded in primitive form.)
All servers MUST implement this form for both generating attribute
values in search responses, and parsing attribute values in add,
compare and modify requests, if the attribute type is recognized and
the attribute syntax name is that of Binary. Clients which request
that all attributes be returned from entries MUST be prepared to
receive values in binary (e.g. userCertificate;binary), and SHOULD
NOT simply display binary or unrecognized values to users.
6.5. Certificate
( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
Because of the changes from X.509(1988) and X.509(1993) and
additional changes to the ASN.1 definition to support certificate
extensions, no string representation is defined, and values in this
syntax MUST only be transferred using the binary encoding, by
requesting or returning the attributes with descriptions
"userCertificate;binary" or "caCertificate;binary". The BNF notation
in RFC 1778 for "User Certificate" is not recommended to be used.
RFC 2256
5.37. userCertificate
This attribute is to be stored and requested in the binary form, as
'userCertificate;binary'.
( 2.5.4.36 NAME 'userCertificate'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
RFC 2798
2.5.4.36
NAME 'userCertificate'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
################################################
So could you please check the schemas of your directoryserver? The
Syntax MUST end with an 8! Please change the number and start again or
did I misinterpret the RFCs?
If you performed the changes then the attribute should be
"userCertificate;binary" and the value should be $cert->getDER() without
any conversions.
> The Usersmimecertificate field is the same as above except for an OID of
>2.16.840.1.113730.3.1.40
userSMIMECertificate requires a PKCS#7-structure. So you cannot use it
with a normal certificate.
Cheers,
Michael
--
----------------------------------------------------------------------------
Michael Bell Email: [EMAIL PROTECTED]
Rechenzentrum - Datacenter Email (work):
[EMAIL PROTECTED]
Humboldt-University of Berlin Tel.(work): +49 (0)30-2093 2482
Unter den Linden 6 Fax.(work): +49 (0)30-2093 2959
10099 Berlin
Germany [OpenCA Core
Developer]
http://openca.sourceforge.net
_______________________________________________
Openca-Users mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/openca-users
