RE: ;binary and userCertificate (Was: Private email ...)

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Hi,
 
Regarding 6.5, this is actually a feature of English, not of the spec. One
may request an attribute or return an attribute (though not both at the same
time) and in each case ;binary should (MUST) be used.
 
Regarding the supertype issue, the new version of the specs propose that
;binary is a transfer ooption and is not related to normal attribute
subtyping. The radicals on the list would like ;binary to be dropped as it
appears to be solving a problem that doesn't actually exist.
 
Ron.

-----Original Message-----
From: Christopher Oliva [mailto:Chris.Oliva@entrust.com]
Sent: Friday, 22 February 2002 13:50
To: 'Kurt D. Zeilenga'; Christopher Oliva
Cc: 'mcs@netscape.com'; Ramsay, Ron; Christopher Oliva; LDAP BIS
Subject: RE: ;binary and userCertificate (Was: Private email ...)




If you yourself have made this error ... it is very possible that some
vendor has made the same error and might explain broken implementations.

I for one think the spec is ambiguous ... let me explain: 

RFC 2251, clause 4.1.5 defines attribute descriptions as subtypes of the
attribute without any options. Neither this clause nor clause 4.1.5.1 says
anything special about this not holding for ";binary". The first problem is
that subtypes are not defined in this RFC. As it turns out, the X.501
definition explicitly says that values can be accessed via the "supertype"
as well as the subtype (I'm paraphrasing).

Now, clause 4.1.5.1 says that "clients MUST NOT expect servers to return an
attribute in binary format if the client requested that attribute by name
without the binary option". The implication is that servers may infact,
return the binary encoding even if the binary option was not used by the
client since the clause says nothing about the behaviour of the servers in
this instance.

So who's wrong here? The server for generating the binary encoding? Not
according to the RFC. 

This is in my opinion, sufficient proof that there is ambiguity. There is
sufficient grounds to say that servers should be allowed to return binary
encodings if a client makes a request without ";binary".

Now look at RFC 2252. 

Clause 6.5 defining the certificate syntax says this: 

  "... 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 main point being stressed by the MUST is the transfer encoding. One
could argue that the MUST only applies to the transfer using the binary
encoding but not necessarily to the following clause that talks about the
attribute descriptions.

Now look at the word "or" between 'requesting' and 'returning'. It is
possible that the word "or" was used instead of the word "and" in order to
account for the fact that clients might request userCertificates without the
;binary option. This directly conflicts with the MUST NOT of 4.1.5.1 from
RFC 2251 above. This same thing could be used to justify a server returning
userCertificate instead of userCertificate;binary.

Chris. 



> -----Original Message----- 
> From: Kurt D. Zeilenga [ mailto:Kurt@OpenLDAP.org
<mailto:Kurt@OpenLDAP.org> ] 
> Sent: Thursday, February 21, 2002 1:50 PM 
> To: Christopher Oliva 
> Cc: 'mcs@netscape.com'; Ramsay Ron; Christopher Oliva; LDAP BIS 
> Subject: RE: ;binary and userCertificate (Was: Private email ...) 
> 
> 
> At 10:20 AM 2002-02-21, Kurt D. Zeilenga wrote: 
> >Additionally, client 
> >developer's would have to be warned that some 
> >servers might use ;binary transfer even though 
> >the native string was requested.  As this is a 
> >behavior which the existing specification allowed 
> >(due to an ambiguity in the specification which, 
> >I hope, will be removed). 
> 
> I mispoke.  The ambiguity I refer to above doesn't 
> does apply in the certificate case as the existing 
> specification mandates use of ;binary for certificate 
> syntaxes.  Hence, this warning would not be needed. 
> 
> My apologies for any confusion caused by my error. 
> 
> Kurt 
> 
>