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

From: Alan Lloyd <[email-masked]>
Date: Mon, 26 Apr 1999 14:08:53 +1000

snip

> >
> >	If this is the approach to logical debate - that is also used to
> >debate technology issues , then one can see why these lists have
> >difficulty.
> 
> Yes, this is a logical approach to debate.  Sorry if my choice of
> terms was
> confusing, but I fear the real problem is deeper.
> 
	Yes it is. It is the general issue that 2459 is a massive amount
of paper which repeats much of X.509 and at the same time in some
(important) places confuses its implementation - specifically as the
text relates to CA management policies and certificate using system
validation. Yes I am very well aware that standards do not cover all
things or are correct. Thats why standards evolve and get bug fixes -
and then get profiled.

	Profiles on the other hand should not be tutorial or vague or in
error. As it is these documents that people will commit implementation
to. And in the case of X.509 and security - that wont be cheap.

	Let me highlight some issues with 2459.

	1. Section 2 second para - last sentence - what does that mean?

	2. Section 2 should also state that where certificate using
systems (signer and relying party) need to validate information without
a shared directory service, then the means and protocols by which they
perform this sharing is a local matter and outside the scope of this
profile. ie this situation does create ambiguity.

	3. Section 4.1.2.4  -last para page 19 - " The Telexstring and
Universal string ... Certificate Users SHOULD" .. this magic word
"Should".. 
	There is no sure way of knowing what encoding is being rxd by an
implementation and if they do not decode strings correctly the
implementations will fail or crash. If building a commercial robust PKIX
implementation - one would expect a profile - if there are known uses of
the scheme out there, to say all recieving certificate using systems
must support this. ie a profile must dictate robustness to current
implementations - not leave an implementor with a guess and bugs.

	4. Section 4.1.2.4 para "standard sets of (naming) attributes
... same as above.

	5. Section 4.1.2.4 (not a good section) Name comparison rules.
	X.500 relaxes name comparison on different
syntaxes/normalisation  to permit directory searching as the author of
the info may use a different syntax when storing to that from a user who
is searching. ie X.500 provides relaxation (approximate matching, etc)
to provide Search utility.

	I find it odd that certficate validation proposed by PKIX - in
which a cert cryptographically binds names to key material permits name
relaxation in the validation process?. In fact why verify a certificate
signature - if the means one finds its issuer with a relaxed name form.?
Isnt this weak and open to threats.
	IMHO the DN of the Issuer MUST be the CA - Case exact match.
	This name form relaxation text is repeated in subsequent
sections.

	6. Section 4.2.1.1 Authority Key Id (and Subject Key Id)
	The text mandates the use of this extension by ALL PKIX
certficates. However the ASN.1 seems to permit the choice of Issuer and
SN and or with Key Id . In the case of Key Id one  SHOULD use one of the
two Key Id methods proposed (as well as a third option as "sequence of
numbers" )

	It is unclear if Issuer and SN are compatible in developing
paths with the other methods, that the distinction between 160 bit sha
and the other is by saying by length - (20 bytes or 8 bytes) but if a
sequence of integers is used and its 8 or 20 bytes long (an Octet
String) - what happens?
	I would have thought that fwd and reverse certificate path
management/determination  is a critical piece of engineering - but the
text is not very clear about use for implicit interoperability.

	7. Section 4.2.5.1 Cert Policies
	The CPS pointer - a health warning should be provided in that
the CSP is not cryptographically bound to the certificate and can be
changed without referring to the certificate issuer.

	A small matter .. The User notice. "is intended for display to a
relying party." although this may have some utility - is it informative,
interactive, affect validation or provided before or after path
validation.

	8. Section 4.2.1.7 Subject Alt Names 
	I have difficulty with this thing - simply because of what is
the trust mechanism. If there is no Subject in the cert and Subject Alt
Name is used and is critical , then it is up to the certficate using
system to verify the subject. For instance if the "message" to be
verified / originator authentication is via "IP", and the IP form is
used in the subject alt name, then the certificate using system Must
validate the source IP address, ditto X.400, ditto smtp.
	If implementations do not do this  - all they are doing is
verifying a certficate path from something that cannot verify when it
has been deemed by the certficate issuer to be critical. (see also name
constraints).

	Part of the PKIX profile should highlight interfaces and
mechanisms when using certs with cert fields described in this way.
Otherwise interoperability and trust will not be achieved.

	9. Section 4.2.1.8 Issuer Alt name  - same as above - whats the
validation process - ie when reading certs for path validation from the
CA (eg via smtp or IP ) do I check its originating details are as
defined in the issuer alt name.

	10. Section 4.2.1.10 Basic Constraints - already discussed and
text offered - should cover certificate using system usage. ie an EE
cert cannot be used for cert signature verification.

	11. Section 4.2.1.11 Naming Constraints - 
	Text is unclear if this extension is mandated in PKIX CA
certificates or as X.509 says it can only be used in CA certs.
	If it is mandated and critical this will add a lot of complexity
to client/user/certficate using systems. re name types, alt names and
name relaxation (if used).. 

	12. Section 5.2.1. CRL Auth key Id
	I would like to see text that helps the implementor understand
there may a different between the Certificate signing key and the CRL
signing key and that the certs used to verify the CRL may have a
different auth key Id to that of the CA cert signing and that the
management of these must be maintained in the cert path validation.

	In closing, a profile should assist where it can the operational
implementation of a function. Specifically the thrust of the profile is
to get consistent trusted validation paths going. The issues raised
above affect interfaces, interpretation and choices.

	regards alan.

> Steve

---

From: Moshe Litvin <[email-masked]>
Date: Tue, 27 Apr 1999 11:29:23 +0300

Alan Lloyd wrote:

<snip>

>         Let me highlight some issues with 2459.

<snip>

> implementations - not leave an implementor with a guess and bugs.

I disagree. Security software should always check its inputs carefully
(assuming it may be hostile). No need to for special treatment here in
regards for crashes.

regards,

    Moshe

---

From: Paul Koning <[email-masked]>
Date: Tue, 27 Apr 1999 11:58:37 -0400

>>>>> "Moshe" == Moshe Litvin <[email-masked]> writes:

 Moshe> I disagree. Security software should always check its inputs
 Moshe> carefully (assuming it may be hostile). No need to for special
 Moshe> treatment here in regards for crashes.

I'd go further.  ALL protocol code must be implemented in that way.
If there is any bit pattern that I can send to a box that causes that
box to break (crash, or otherwise malfunction in a way that doesn't
straighten itself out after I stop harrassing it) then that
implementation is defective.  Full stop.  No excuses accepted.

I suppose there is no harm in mentioning that general principle in a
few places, but it shouldn't be described as specific to security
protocols, let alone PKIX profiles.

	paul