Re: SubjectAltName verification

["Bob Jueneman" <bjueneman@xxxxxxxxxx>]

Let me offer some comments on what I believe is a very important,
and obviously contentious issue.

In the past, the IETF has been primarily concerned with issues of 
over-the-wire protocol and structures, and the syntactic definitions 
of those fields.

Other issues, and in particular issues that pertained to commercial
business practices and/or various (potential) legal issues have generally 
been left to the relevant experts in those fields to define.

In particular, the tradition within the IETF has been to espouse only 
purely technical issues, regardless of their potential business impact --
indeed, sometimes amazingly oblivious to such issues.

As a result, the PKIX WG (and X.509) is, at least in my mind, notorious 
for failing to adequately come to grips with the precise semantic meaning 
of many of the terms that are defined.  As a case in point, I would cite 
the complete lack of any agreement whatsoever as to the 
semantic meaning of the "nonrepudiation" key usage, either from a legal 
perspective or a narrower, but still useful set of do/don't do perspectives that
would apply to end user software, either the CA, the originator, or the relying 
party.

As a result, the term is neither defined, nor deprecated.  Apparently the 
consensus was to let commercial practice sort out the issue, and perhaps 
this is in fact the best course.

The PKIX WG, has long since departed from the traditional IETF practice 
of "rough consensus and running code".  Now we are institutionalizing 
some of the most disliked features of ISO and we have become a 
"design-by-committee" organization.  Unlike ISO, however, where various 
countries explicitly take into account various national objectives, and weigh, 
or at least try to weigh, the various commercial interests before coming to
agreement, we generally fail to do so.

The IETF lacks any form of institutional representation of business interests --
every contributor's comment or vote is treated exactly the same as every other,
regardless of how small or how large the contributor's company's stake might
be the in the outcome.

That's of course very democratic, and everyone has a more or less equal chance 
to carry the day based on their individual fervor and ability to persuade. Unfortunately,
this tends to mean that anyone can propose his own pet rock for standards 
consideration, regardless of the commercial viability of that approach.  

I am particularly thinking of the blatant anti-intellectual property preferences 
of the IESG, and their instance on including as mandatory features encryption 
algorithms which have not been well accepted in the marketplace. The various 
working groups then exacerbate the problem by adding more and more features and 
algorithms to the list of "approved" or "standard" featured, often at the behest of
a very small community of interest.  Yet every one of these additional features takes 
some amount of additional coding (generally not too large) to implement, plus 
significantly more in terms of GUIs and documentation, and an exponentially 
increasing amount of testing, all for little or no consumer benefit.

But because of the importance of standards per se, the products are under a 
considerable amount of pressure to be "conforming" to requirements that have 
not been validated by the user community, and to which the user community had little or 
no say so, and the cost and complexity inevitably leads to both buggy and 
expensive software

On the other hand, existing commercial practices may suddenly be deemed to be 
inappropriate or nonconforming, sometimes despite a considerable body of commercial 
acceptance, in a rather high-handed "father knows best" attitude.  Since the commercial 
entities may have only a few representatives, they may not be able to offset the 
opinions offered by others with competing interests.

I believe this is an increasingly unsatisfactory state of affairs, and may eventually lead 
to the IETF being regarded as more or less irrelevant to both the vendor and the 
user community, particularly if existing commercial practices are suddenly, and perhaps 
rather capriciously, labeled as being non-conforming.

Now, how does this apply to the current controversy?

By not adopting either an opt-out indication that certain perhaps useful
information has not been explicitly validated by the CA, perhaps because it isn't 
economically feasible to do so, the implication is that everything in the certificate
is God's own BINARY truth.  And if you don't believe that, go off and read 80 
or more pages of legalese to determine exactly what is meant. Of course computer
programs can't do that, so we will resort to more and more complex schemes of
policy OIDs, policy constraints, name constraints, etc., until we have no interoperability
at all, or otherwise the relying parties will decide to limit the amount of trust that 
they put in a certificate to a lowest common denominator across the entire
industry.

I would submit that neither approach is very helpful.

We don't even seem to be able to agree as to what the problem is.

Denis Pinckas says:

>In RFC 2459, section 4.1.2.6  Subject, we currently have:

>   Where it is non-empty, the subject field MUST contain an X.500
>   distinguished name (DN). The DN MUST be unique for each subject
>   entity certified by the one CA as defined by the issuer name field. A
>   CA may issue more than one certificate with the same DN to the same
>  subject entity.

>Let us suppose that we use an *empty* distinguished name (which is
>allowed by the standard). Should the above property also apply to
>the alternative name ? I would think so and I understood 
>"definitively bound" as equivalent to "unique". In other words the
>subject Alternative name once assigned must never be re-assigned for
>a different entity by the CA. To this respect, the other fields that
>where mentioned are not "definitively bound". So you now understand
>the rational of the change that was made.

I won't say that Denis' argument doesn't make any sense at all, but 
equating "definitively bound" to "unique" seems to me to be a very great
leap.

At least to me, "definitively bound" inherently implies the "correctness" of the 
attribute that is bound to the key, and by implication to the persona who is 
affiliated with that attribute in some fashion.

Granted, if the name is merely a e-mail address or post office box, it is very difficult
and perhaps impossible to correlate that name to any particular real person, even if 
(especially if) it is Bill_Clinton@aol.com. 

On the other hand, if the DN (or any other field in the certificate) does presumably
uniquely define an organizational or residential person by a globally unique name, 
then a reasonable inference to be drawn from the certificate which binds both 
the DN and subjectAltName to the same key is that they same persona is somehow
involved.

Does that mean that the identified user has sole and exclusive access to that 
e-mail address (i.e., his spouse and kids don't share the same mail box), or that he 
even bothers to read his mail there?  Not necessarily.

Then exactly what does "validate", much less "definitively bound" mean in this 
circumstance?  I don't like to have to say so, but the only option at this point is to
say "go read the CP/CPS".

The biggest problem, I believe, is that we are attempting to apply rather 
Procrustean binary logic to a problem that inherently involves shades of gray.

We can say "This value is either a 1 or a 0, and that's that.", but this is subject
to potentially hidden provisos in the CP or CPS, "for suitably defined values of 1 
and/or 0".

Trying to say that something is "right" or "not right", regardless of existing 
commercial practice would seem to pretend to a moral and/or legal
authority that the IETF simply doesn't command, unless the Pope has suddenly 
become a silent co-chair.

On the other hand, saying nothing at all, and leaving it up to a completely laissez faire
interpretation a la nonrepudiation isn't very helpful or useful either.

That's one reason why in the Novell Security Attributes extension we include in 
all of our certificates, we define a "Certificate Class" that ranges from 0 to 255,
in an attempt to define some shades of gray between a completely anonymous user
and a sovereign government. 

Cf. http://developer.novell.com/repository/attributes/certattrs_v10.htm .

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.



>>> Al Arsenault <awa1@home.com> 05/28/00 07:27PM >>>
Peter,

	In a word, "No".  Details below:

Peter Williams wrote:
> 
> User includes account name in the subject DN. A Private
> organization's CA service services a closed intranet and
> extranet community. It issues a certificate including
> the account name. This circumstance is common in the Internet
> community today.
>

> CA has a policy, which is partially disclosed. The disclosed
> Policy Elements are made available only to subscribers. This
> circumstance is common in the Internet community today.
> 
> The motivations for establishing the extent
> of a field verification policy are beyond the understanding
> level of the CA's subscribers.  This  circumstance is common
> in the Internet community today.
> 

I won't argue with any of these; I'll simply state that the fact that
it's common in the Internet community today doesn't make it the right
thing to do.  

> The CA does disclose a policy element to susbcribers to
> procedurally follow a  "limited"  technical verification procedure
> concerning account names. The procedure establishes that an account
> of that name "exists" - in an account management system acceptable
> to the CA - at the time of certificate issuance.
> 

In other words:  the CA verified that there was someone named "Bill
Clinton" purporting to reside at 1600 Pennsylvania Avenue, Washington,
DC at the time of certificate issuance, so I'll put that in the
certificate.  I make no representation that the subject of this
certificate is the same "Bill Clinton" as the one you might be thinking
of, but I'll put it in the cert anyway.  All other data in the
certificate are verified as per the CP/CPS/other appropriate document.

Is this useful?  To what relying party?

> All other data in a certificate is "verified", according
> to other per-CA policy criteria and/or PKIX mandates.
> 
> Does the resulting certificate, when issued
> under the above scenario, conform with the
> proposed PKIX standards for field verification?
>

Not according to the ones I'm recommending.  :-)
 
> A fourth party undertakes a private PKIX-audit of
> the CA for the benefit of the CA.  Should it
> determine the CA is acting according to the spirit
> of the proposal concerning field verification
> when executing this scenario?
>

Again, in a word:  "NO".  The presence of an "attribute" whose value has
not been verified - either directly or indirectly - by the CA is at best
misleading, and at worst openly harmful to the relying party.
 

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.