I slightly misspoke myself.
We do have a syntax setting, however it has choices like "Case Ignore String" and
"Binary" . .
On Wed, Aug 22, 2001 at 04:46:27PM +0200, Michael Bell wrote:
> 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
--
********************************
David William Botsch
[EMAIL PROTECTED]
********************************
_______________________________________________
Openca-Users mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/openca-users
