RE: SEIS: RE: Certificates, Directories, and Distinguished Names

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

Stephen - in all your words you never seem to come to grips with the
fact that X.509 is not ambigious in so far that it permits systems to be
built without certificate extensions - and for those build such systems
to determine by local means or imply what is a EE or a CA cert and what
use that cert has (eg for message verification or cert verification)..
X.509 - was written some years ago and it correctly (a a standard
should) provided a transition path to the use of cert extensions.

RFC 2459 came along some time later as a profile and just the fact that
people are discussing the issue in 2459 and it is unclear - means there
is a problem - in the Profile.

Just the fact you added this to your response says something about the
issue.

	Because 2459 requires inclusion of the extension in a CA cert,
there is no
	ambiguity.  If a CA chose to insert the extension in an EE cert,
despite
	the RFC's admonition, it would be redundant in the 2459 context,
but not
	cause an error.  You should refer to RFC 2119 to gain a better
understanding of the term "SHOULD" as used in RFCs.


and as for 2119 the extract: who can understand this stuff when applied
to a real system specification or profile?


4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.


Work that one out if you can when building large scale trusted system in
which many EE/clients will access many CA domains and do trusted
processing ....

Groan..............In my book Profiles have Musts (mandated),
Conditionals with the condition applied,  or Dont Use or Dont
Care/Ignore

shall, shall not or may or could ... mean an ambigious mess.

Sorry Stephen - use all the words you like - even throw a dictionary at
me -- but 2459 + 2119 = what??    in terms of trusted, consistent
engineering ????

As said X.509 is a Standard that permits transition to using certificate
extensions for CAs and EEs  - and describes this as a local issue ..
thats pretty clear in my mind.

2459 and 2119  its unclear and ambigious - and that is the last thing
you want in an engineering PROFILE that will be used to make products
with.



regards alan

PS why are the words different in 509 Basic Contsraints to that of 2459
Basic Constraints? as they do introduce the ambiguity about EEs and what
they can do re cert validation?







> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Saturday, April 10, 1999 6:29 AM
> To:	Alan Lloyd
> Cc:	ietf-pkix@imc.org; list@seis.nc-forum.com
> Subject:	RE: SEIS:  RE: Certificates, Directories, and
> Distinguished Names
> 
> Alan,
> 
> >Thats the same as 509 or near enough. Its not too informative as its
> >abstract theory rather than operational policy. Oh well.
> 
> indefinate antecedent, error ...
> 
> >
> >As a question on basic constrains why is the text in 509 different
> from
> >RFC 2459
> >
> >X.509 - 12.4.2.1 Basic Constraints
> >This field indicates if the subject may act as a CA, with the
> certified
> >public key being used to verify certificate signatures. If so, a
> >certification path length constraint may also be specified. This
> field
> >is defined as follows....
> >
> >
> >rfc 2459 -4.2.1.10  Basic Constraints
> >
> >   The basic constraints extension identifies whether the subject of
> the
> >   certificate is a CA and how deep a certification path may exist
> >   through that CA.
> >........
> >
> >   This extension MUST appear as a critical extension in all CA
> >   certificates.  This extension SHOULD NOT appear in end entity
> >   certificates.
> >
> >It strikes me that 2459 is ambigious simply because it did not
> embrase
> >the X.509 text re "certificate using system" and the fact 2459 uses
> >SHOULD NOT without actuallly defining the conditions if it is or is
> not
> >there in EE - as X.509 states.
> 
> Because 2459 requires inclusion of the extension in a CA cert, there
> is no
> ambiguity.  If a CA chose to insert the extension in an EE cert,
> despite
> the RFC's admonition, it would be redundant in the 2459 context, but
> not
> cause an error.  You should refer to RFC 2119 to gain a better
> understanding of the term "SHOULD" as used in RFCs.
> 
> steve