Subject: Re: SubjectAltName verification

From: "Al Arsenault" <[email-masked]>
Date: Wed, 17 May 2000 13:25:38 -0400

Bob,

    I think that in general Steve and Paul have addressed this issue well -
PKIX should not support the presence of an "unverified" attribute in a
certificate.  To the extent that a CPS specifies, a CA should make every
attempt to validate that a subject is entitled to claim some attribute -
such as an e-mail address - the CA puts in a certificate.  Such validation
will typically include interaction with the name authority responsible for
that particular namespace - e.g., with whomever issues e-mail accounts at
the particular mail server.

    Specific comments:

>
> -----Original Message-----
> From: Robert Moskowitz <[email-masked]>
> To: Al Arsenault <[email-masked]>; 'Paul Koning' <[email-masked]>
> Cc: [email-masked] <[email-masked]>; [email-masked]
> <[email-masked]>
> Date: Monday, May 15, 2000 3:10 PM
> Subject: RE: SubjectAltName verification
>
>
> >At 02:50 PM 5/15/2000 -0400, Al Arsenault wrote:
> >>I have to disagree with Bob on this. To me, the words imply what they
> say -
> >>that if the CA is going to issue a certificate that says that my
> >>subjectAltName of the form rfc822Name is "[email-masked]", the CA
> >>must have taken some steps to verify that that is indeed the case.
(e.g.,
> >>the CA could have a notarized letter from the authority responsible for
> >>assigning those e-mail addresses.)  To do otherwise is false or
misleading
> >>behavior on the part of the CA.
> >
> >First question:
> >
> >What are we going to use as the SubjectAltName in your Netopia box on
your
> >DSL line in your house, Al?  Shouldn't be YOUR email address, Al.  What
> >FQDN?  Remember there is no static IP address for you, everytime you boot
> >the Netopia, it can get a new IP address from the ISP.
> >

AWA:  Let's suppose hypothetically that my cable modem provider uses DHCP,
and issues me a new IP address every time I power on my computer.  To me, it
would be foolish for any CA to issue me a certificate with an IP address in
a subjectAltName, since the certificate would become invalid every time I
powered off the computer.  On the other hand, since my e-mail address
doesn't change very often, it's perfectly OK for a CA, after checking with
the account administrator, to issue me a cert with rfc822Name =
[email-masked].

> >Taking the FQDN further, these are internal boxes, getting a third party
> >cert.  The CA cannot do a DNS query on the internal DNS server.
> >
> >This all comes down to the CP and CPS.  Here is where is stated the
method
> >use to establish the content of SubjectAltName.  Now it would be really
> >nice if there were a KEYNOTE object in the cert that would express the
> >method of validation...
> >

    Al Arsenault
    Chief Security Architect
    Diversinet Corp.

---

From: "Yutzy, Murray" <[email-masked]>
Date: Thu, 18 May 2000 08:41:30 -0400

Denis Pinkas wrote:
> 
> Hum !!! Interesting discussion between the two co-chairs.  :-)
> 

I agree with Steve on this one.

> Whatever information is contained in a certificate, there are
> various degrees of verification that can apply. The verification
> level may even be different for each field. To this respect, Warwick
> is right to say that a flag would not be adequate.
> 
> A certificate must contain a name that may be carried in the DN
> field or the SubjectAltName extension. That name must be unique and
> is assigned by the CA. The name, wherever it is placed, must be
> verified (well with the exception of pseudonyms that can only be
> verified not to collide) with some *reasonable* degree of
> verification.
> 
> All other extra fields related to the user that we allow to be
> present in a certificate are not mandated. If a phone number is
> included does that means that the CA has simply accepted the phone
> number that was included in the registration form ? or that the CA
> has requested a proof from a telephone company that the applicant
> was the legitimate subscriber of the phone line ? or that the CA has
> made a phone call to that number to get the person on the phone ?
> 

In general, if the CA is not also the RA, the CA accepts the RA's
assertion that the RA is either authoritative for all information to go
in the certificate, or that the RA has verified the information with
whomever is authoritative.  That is, the RA has certified that "this is
Al's e-mail address, because I issued it", and "this is Al's phone
number, which I ran around to his desk and verified or called the
company phone office to verify or ..."  If the CA is also acting as the
RA, then it is the CA's job to do this verification.

Of course, how well this job is done is a function of the CPS (or other
policy document which serves in place of the CPS, as I was reminded at a
meeting yesterday :-), but it needs to be done.  Giving me a certificate
with a subjectAltName, OtherName type, of Phone_number =
the_White_House_switchboard is somewhat irresponsible on the part of the
CA, and should not be condoned by PKIX.

> The answer to the issue raised is not black or white. Today there
> exists (free) certificates where no verification (except uniqueness
> of name) is performed. There are used for testing purposes, and
> should be recognized as such (but they are not). A next level is to
> verify very loosely the name, in particular when it is an E-mail
> address, by sending back an E-mail to that address. A next level is
> to use some background check with a data base to make sure of the
> information that is provided. A next level is to ask for one proof
> of identity and other related information. A next level is to ask
> for two proofs of identity and other related information. I will
> stop here these examples.
> 
> The industry has introduced the concept of classes of certificates.
> The problem is that each CA issuer has made its own definition of
> what such a class is.
> 
> Maybe it is now the right time to raise the question whether we
> should standardize the concept of classes of certificates.
>

For PKIX, I would vote "NO" to this question. Maybe the PKI Forum or
somebody else should pick it up.

Murray> I agree with refraining from attaching a level of class to a
certificate.
We went through iterations of trying to implement levels of trust based on
CA hierarchy. Basically a root CA over n Sub CA's, each having a level of
assurance.
We moved away from it due to consuming applications not really comprehending
the
difference and that they all chain to a common root.  We are hoping that a
user will
be issued a primary identification certificate, which does exactly that
identifies who
they are not what they can or can't do, and then depend on either  policy
OID's or
attribute certificates to provide capabilities.
 
> In this way we would recognize various levels of verification. We
> would also need to say how the express the concept of class in the
> certificate. We do not necessarily need a new extension for this.
> Let us keep certificates slim.  :-).
> 
> Denis
> 

		Al Arsenault
		Chief Security Architect
		Diversinet Corp.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 18 May 2000 16:19:01 +0200 (MET DST)

> > 'Unique' does seem the right word to me. You can have more than one
> > 'name' for the same object, like a pseudonym and a 'real' name.
> > 
> > Are you talking about 'non-ambigous names'?
> 
> No. Unique means that a name, once given to one entity, must not be
> given to a different entity (in short not issued twice to two
> different entities).

Hm, that's unique (= the only one/sole cf Webster's dict) attribution
of a name to an object. Which makes the name unambiguous. 

X.501 (88) 8.1 d:

  (directory) name: a construct that singles out a particular object from
  all other objects. A name must be unambiguous (that is denote just one object),
  however it need not be unique (that is, be the only name which unambigously
  denotes the object);

This definition seems to be conformant the definition 1 found in Webster's dictionary
unique = the only one 'sole'. 

But rfc1439: 

   This RFC provides information that may be useful when selecting a
   method to use for assigning unique identifiers to people.

But in fact this RFC talks about the uniqueness of the assignment of
an identifier to an entity. Or, 'unique identifier' is used as a new term
but not using 'unique' as an attribute of the identifier. 

The sentence:
   'In general, these identifiers must be unique.' 

is not consistent with the rest of the text, explaining that the
attribution of an identifier to an object must be unique/sole, which is
a quality of the inverse relation.

Or, uniqueness is the opposite of unambiguous, it just
depends from which part of the relation you see it. 

Combining this all, you can still consider a term 'unique name' as a term that
describes what you say, but then you cannot necessarily say that a
'unique name' is 'unique' since the object may have several names; a very
unfortunate wording problem. 

Thus, the reason I mentioned that was not to comment the statement about the
subject of the message, rather a comment to the paragraph in 2.4 the qualified
certificate draft. 

In the context of a single DIT *the distinguished names* form a subset
of name, where each name is unique (since you can only have one distinguished
name for an object.); it is unambiguous because it is a name (X.501) and not
because it is a distinguished name. 

Or, maybe one should rename 2.4 to 'uniqueness of name assignments'. 

   In the context of qualified certificates, a distinguished name
   denotes a set of attribute values [X.501] which forms a name that is
   unambiguous within a certain domain 

Well, sorry for any misunderstanding that my comments may or may not have caused.

Peter
PS: My English has always been *very* bad, anyway.

---

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 19 May 2000 15:47:22 -0600

Not really, Peter -- at least I don't look at it that way.  The certificate class 
is just one of four elements within a field that is used to describe the
"Quality" of the certificate itself, intended to answer the question of 
"why should I believe this certificate?". The other parameters deal with 
where and how the keys were generated, where they are going to be 
used, and where they are stored in the meantime.

The other portion of the Novell Security Attributes extension is a three tiered, 
hierarchical, mandatory access control label that is intended to convey what
 _rights_  the subject of the certificate possesses, at least according to the 
issuer of the certificate.

The result is effectively a multi-dimensional policy statement, if you want
to look at it that way, that permits a very rapid calculation of the equivalent
of the name subordination rules, policy OID constraints, certificate classes, 
and something like the ESS security label supported S/MIME v3.

Take a read -- I think you'll find it interesting.

Bob

>>> "Peter Lipp" <[email-masked]> 05/19/00 10:55AM >>>

> That's why we include an explicit encoding of a certificate class
> (from 0 to 255, with a rather rich set of definitions) in the
> Novell Security Attributes in all of the certificate we create.

Honestly, isn't that a shortcut for a possible policy-Id like
Novell.sercurtityAttributes.policies.0 -
Novell.sercurtityAttributes.policies.255?

Peter

---

From: [email-masked]
Date: Thu, 25 May 2000 11:00:31 -0400

I agree that the text you cite is in RFC 2459, and presumably
represents WG consensus.  However, I don't think that what it says is quite
what you seem to think it means.  First, the statement that communities may
replace the profile would appear to be a recognition that the basic
standard involved here is X.509 and a community may well find it
appropriate to build their own profile directly from X.509 without using
the PKIX profile, in which case no question of conformity to PKIX can
arise.  Second, a community may supplement the profile.  A new profile may
certainly be created from this one by adding new features using one of the
extensible mechanisms (extensions, attributes, OTHER-NAME's, etc.) or by
imposing constraints not found in this profile (such as limitations on the
range of DN attributes or the allowable types of alternate name).  Taking
one of the explicit requirements of this profile (say, that private key
usage period MUST NOT be critical) and eliminating it is not supplementing
the profile, but dispensing from specific requirements within it.  Building
a new profile by doing this might well be valid, but the resulting profile
would not be conformant to RFC 2459 or a supplement to RFC 2459, and should
not be described as such.

          Tom Gindin

Peter Williams <[email-masked]> on 05/24/2000 10:46:20 PM

To:   "'Stephen Kent'" <[email-masked]>
cc:   [email-masked]
Subject:  RE: SubjectAltName verification

Steve:

Perhaps comment.

(1) You should realize that the text I quoted, repeated below from your
reply, is from RFC 2459.

(2) The text quoted is not some bullshit from Peter's English pen.

     (2.1) The text is the work of Ford et al., NIST/NSA, PKIX WG,
          PKIX mailing list, IESG et al., and a PKIX WG and IETF Final
call.

     (2.2) The text has been present in the I-Ds leading to RFC 2459 from
          very early moments of our mailing-list deliberations.

(3) You do not agree that the cited paragraph (from RFC 2459) represents
group consensus. That the same paragraph remains in son-of-2459 I-D is not
relevant to you, presumably.

(4) You view the "supplement/replace" assumption stated by the authors
of RFC 2459, as stated in the 1st quoted sentence (from RFC 2459),
to be "out of the question".

(5) You view the second sentence of the same quote (from RFC 2459) as
"confusing."

(6) And...despite your repeated misdirections as chair, you will perhaps
now agree that Peter did not write a word of the cited text that you
criticise so severely. THIS WG wrote and reviewed the text...

(7) The text, which was discussed in mailing list discussions, also
passed Final Call in both PKIX WG and IETF Final Call.

(8) IETF Final call is a conventional signal of consensus. But perhaps
not in PKIX WG, under the rules of our chairs.

(9) The use of quote symbols around text is an accepted practice to
denote a quotation.

(10) The appendage of [RFC 2459, http://www.ietf.org/rfc/rfc2459.txt] after
a quoted passage represents an accepted practice to clearly identify the
source of a quotation.

Peter.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, May 24, 2000 8:42 AM
To: Peter Williams
Cc: [email-masked]
Subject: RE: SubjectAltName verification

Peter,

>    "Some communities will need to supplement, or possibly replace, this
>    profile in order to meet the requirements of specialized application
>    domains or environments with additional authorization, assurance, or
>    operational requirements.  However, for basic applications, common
>    representations of frequently used attributes are defined so that
>    application developers can obtain necessary information without
>    regard to the issuer of a particular certificate or certificate revo-
>    cation list (CRL)." [RFC 2459, http://www.ietf.org/rfc/rfc2459.txt]
>
>Do you affirm the above to be group consensus?

No, I do not agree.

It seems out of place to insert text into a standard saying that "we
understand if you don't want to use this standard."  So the first
sentence is out of the question.

The second sentence confuses me.  What do you mean by "common
representations of frequently used attributes?"  The "representation"
of an attribute is its syntax, which is certainly part of the
standard, but not the focus of this discussion.

Steve

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 25 May 2000 12:56:18 -0400 (EDT)

Peter,

You seem intent on reaffirming the validity of the text quoted from
RFC2459.  But to what end?

> Internet CAs are free, and must be free, to operate public-key
> certification according to wholly-private practices. This includes 
> acting in PKIX-non-conforming or other PKIX opt-out manners, where
> (nationally-regulated) CAs and such CA's alone designate such practices 
> to be appropriate to meet their interworking communities security needs.

There is not much to disagree with in the above, except for the first
word.  If your interpretation of "Internet CA" is merely a private CA
which uses the Internet as a common carrier to communicate with its
customers, no problem.  But if an "Internet CA" is one which complies
with (i.e. does not opt-out from) Internet standards, it is perverse
to argue that:

  1) CA X acts in a PKIX-non-conforming manner, i.e. by performing
      no validation on some fields of its issued certificates
  2) RFC 2459 says "some communities may replace this profile ..."
  3) ergo CA X complies with RFC 2459 and is thus entitled to
     describe itself as an "Internet CA".

Surely you weren't pursuing that line of reasoning.

But in case you were, you will need to demonstrate that including
NVI in certificates meets the test of RFC 2459 to support
"additional authorization, assurance, or operational requirements".

In other words, RFC 2459 says you can do more than the basics.  But
you can't do less and still validly claim to be an Internet CA.

Dave

> From: Peter Williams <[email-masked]>
>

---

From: Warwick Ford <[email-masked]>
Date: Fri, 26 May 2000 12:53:47 -0700

So what is the difference between "bound" and "definitively bound" (in a
standard isn't everything definitive)?  Also, what is the semantic
difference when the remaining words are simplified?  I fear you might be
reading in some meaning that is not there.

Warwick

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Thursday, May 25, 2000 7:28 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: SubjectAltName verification

Echoing Paul Hoffman's comment...  I find Steve's text to be
preferable.  For one thing, retaining "definitively" seems a good
thing to do.

      paul

>>>>> "Warwick" == Warwick Ford <[email-masked]> writes:

 Warwick> With Steve's concurrence, I propose the following modified
 Warwick> wording to the clause of concern:

 Warwick> "The subject alternative name, like all other fields in a
 Warwick> certificate and all certificate extensions, is considered to
 Warwick> be bound to the public key.  Thus the CA MUST verify (in
 Warwick> accordance with the applicable certificate policy and/or the
 Warwick> CPS) all subject alternative names."

 Steve> I worry that we are unduly singling out this attribute, even
 Steve> though ALL the attributes have the same sort of
 Steve> requirement. How about:

 Steve> "The subject alternative name, like all other fields in a
 Steve> certificate and all certificate extensions, is considered to
 Steve> be definitively bound to the public key. Thus the CA MUST
 Steve> verify (directly or indirectly) all subject alternative
 Steve> names. The precise nature of the verification is detailed in
 Steve> the certificate policy and/or the CPS."

---

From: Peter Williams <[email-masked]>
Date: Tue, 30 May 2000 09:01:46 -0700

Al,

could you add a little, just a little, technical 
argument to your mails, please?
 
The matters at hand are very important
issues of conformance, and represent a major
change in policy.

You ask if ACES was referred to.

No! ACES was NOT the "national" infrastructure
referred to, in the parenthesis. Stop inventing spurious 
denials and protestation on matters that I simply have 
not introduced. It is simply not fair to the ACES people
who have no voice here to deny your assertions.

NO! VeriSign's commercial work in support of ACES was not
mentioned, implied, and should NOT be inferred. No,
ACES is not the only (major) "national" CA infrastructure
in the world, Al. But thankyou for the opportunity
to correct a US-centric view of the Internet.

Forgive me if I do not name the government; it
is for similar reasons as you feel when
you censure VeriSign. Forgive me
if I avoid responding a whole series
of erroneous assertions drawn from
your false assumption. They confuse the 
conformance issue - which is nicely framed for 
legitimate community discussion, if any.

To the valuable element of your contribution:

Nobody (at ValiCert) is writing standards to
benefit VeriSign, unelss we all win in the usual
open standards way! We are trying to ensure tha
the deployed PKI (compliant with RFC 2459) continues 
to grow, if possible. 

If we collectively decide that 
systems that were conforming with a draft standard's 
version X must now be declared non-conforming with
verison Y, then its perfectly proper to specifically
call out this for explicit endorsement by the WG. At
least it must be discussed in the next WG meeting;
of such magnitude is the change. 

Persoally I vote against: VeriSign's
PCS Class 1  contribution to the general internet should 
continue to be incorporated in PKIX, not cast out.

What we saw happen here last week was quite an
extraordinary event.

-----Original Message-----
From: Al Arsenault [mailto:[email-masked]]
Sent: Tuesday, May 30, 2000 8:33 AM
To: Peter Williams
Cc: 'Denis Pinkas'; [email-masked]
Subject: Re: SubjectAltName verification

I'll try to step lightly here, because the company is question is a
partner of my own employer.  However, I'm in complete disagreement with
one of Peter's central points:

Peter Williams wrote:
><snip>
> 
> Some or all of VeriSign's Class 1 offering
> of its Public Certification Service(s) is/are
> apparently no longer PKIX-conforming, if one applies
> the conformance principles now proposed by Steve. It
> was conforming, last week. 
> 
<snip>
> 
> This seems an excessive impact of your
> suggestion. I, as one of its co-designers, would
> like to include VeriSign PCS's current Class 1
> offering within the PKIX family of conforming CAs.

In general, writing requirements in any standard to ensure that a
particular product or implementation succeeds is a really bad idea.
(Else I'd be proposing requirements to ensure that Diversinet's products
suddenly become PKIX-conformant, even though we currently rely heavily
on an unpublished proprietary protocol for communication between RAs and
CAs.)  While we should not single out any company's product or
implementation unfairly, neither should we tailor a requirement or set
of requirements to fit a particular product or implmentation.  Thus, if
VeriSign's Class 1 service is not "PKIX-conformant", my response would
be to question why.  If it's because VeriSign has chosen not to meet a
requirement that this group deems useful, then that's too bad - VeriSign
loses.  If it's because we're imposing a requirement that's not really
important, okay, I could see deleting the requirement, but I don't
believe that that's the case.

As for

>(A "national"
> ie governmental CA service to residents also suddenly
> became non-conforming last week, also, because
> of other subtle tweaks)

okay, I'll bite.  I'll assume that you're alluding to ACES here, since
that's the only major "national" program that fits your description.  I
know how ACES policy says that information in certs is to be verified -
it's done indirectly, using existing Government databases to provide
verification of data to the approved CAs.  However, I'm confused, since
(a) VeriSign's class 1 service was never and will never be "good enough"
for ACES; and (b) I'm not sure what tweaks killed any existing PKIX
conformance for the ACES vendors.  (BTW:  did just one ACES vendor
become non-conformant, or all three of them?)

And if there's something else you're talking about here, please be less
obtuse.  Be specific, even.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

---

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 30 May 2000 11:43:24 -0600

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 [email-masked]. 

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 <[email-masked]> 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.

---

From: [email-masked]
Date: Tue, 30 May 2000 14:51:09 -0400

I am not sure that VeriSign class 1's E-mail address usage is
unverified, as opposed to rather weakly verified, because the
challenge/response serves as a form of POP.  Whether this is an adequate
POP is more questionable.
     Furthermore, a number of fields which are placed in certificates are
restrictions on usage and cannot be verified by the CA.  The most obvious
such fields are the KeyUsage and ExtendedKeyUsage extensions.
     This does not, however, necessarily mean that the CA can avoid
responsibility for verifying identity fields and other fields that are
verifiable, such as Subject, SubjectPublicKey, SubjectAltName, and
SubjectDirectoryAttributes.

          Tom Gindin

---

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 30 May 2000 15:29:44 -0600

Tom,

>>> <[email-masked]> 05/30/00 12:51PM >>>

E-mail distribution of the certificate tied to a PIN presumably provides a 
weak proof that at least someone who has access to that mailbox also has 
access to the key pair. Unfortunately neither the mailbox nor the key can be 
shown to be under the exclusive control of the putative user, whoever that 
may be.

Well, that isn't quite so clear.  At least some cryptographic implementations, e.g., 
NICI and CDSA, together with most smart cards, implement strong typing
of such attributes, and hence could reasonable be relied upon to enforce such
restrictions.

The fact that most CAs fail to check on what kind of end-user software is in 
use, or place any constraints or even education requirements on their 
end-users is another problem, and one that is symptomatic of the over-reliance 
on CA policies, and a conspicuous lack of attention to the requirements for 
end-user implementations.

It's beginning to sound as though the CA doesn't really have to verify anything except
those things for which it is naturally authoritative, e.g., the uniqueness of the DN within 
the CA's own domain, etc.

Does it make sense to talk about "verifying" uniqueness only, without somehow verifying
the _correctness_ (i.e., in meat-space) of the attributes?

In this regard I am in general agreement with Bruno Salgueiro.  RECOMMEND or SHOULD
would convey the general sense of the technical community (for whatever good 
that will do with respect to legislative and regulatory authorities) without having to 
strip off the epaulets and drum the offending CA out of the corps if they don't comply with 
our infinite wisdom because of their individual business requirements.

Regards,

Bob

---

From: [email-masked]
Date: Tue, 30 May 2000 19:19:27 -0400

"Bob Jueneman" <[email-masked]> on 05/30/2000 05:29:44 PM

To:   Tom Gindin/Watson/IBM@IBMUS, <[email-masked]>
cc:   <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject:  RE: SubjectAltName verification

Tom,

E-mail distribution of the certificate tied to a PIN presumably provides a
weak proof that at least someone who has access to that mailbox also has
access to the key pair. Unfortunately neither the mailbox nor the key can
be
shown to be under the exclusive control of the putative user, whoever that
may be.

[Tom Gindin] Are we in disagreement here?  I said "rather weakly verified"
and questionably adequate.

Well, that isn't quite so clear.  At least some cryptographic
implementations, e.g.,
NICI and CDSA, together with most smart cards, implement strong typing
of such attributes, and hence could reasonable be relied upon to enforce
such
restrictions.

The fact that most CAs fail to check on what kind of end-user software is
in
use, or place any constraints or even education requirements on their
end-users is another problem, and one that is symptomatic of the
over-reliance
on CA policies, and a conspicuous lack of attention to the requirements for
end-user implementations.

[Tom Gindin] Actually, I'm asking whether a CA is supposed to refuse to
place such attributes in a certificate if it has no reason to believe that
the user's software package enforces them.  I know that some software does
enforce them.  In any case, if keys can be exported from their original
software packages and reimported elsewhere, the CA has no way of being sure
that they won't be differently used.

It's beginning to sound as though the CA doesn't really have to verify
anything except
those things for which it is naturally authoritative, e.g., the uniqueness
of the DN within
the CA's own domain, etc.

[Tom Gindin] Well, that definition would include not doing a POP on the
user's private key, so it's pretty extreme.  RP's certainly want more from
a CA than that.

Does it make sense to talk about "verifying" uniqueness only, without
somehow verifying
the _correctness_ (i.e., in meat-space) of the attributes?

In this regard I am in general agreement with Bruno Salgueiro.  RECOMMEND
or SHOULD
would convey the general sense of the technical community (for whatever
good
that will do with respect to legislative and regulatory authorities)
without having to
strip off the epaulets and drum the offending CA out of the corps if they
don't comply with
our infinite wisdom because of their individual business requirements.

[Tom Gindin] Now I'm going to ask what the minimum level of verification
is.  What sort of verification is implied by a true statement that "the
subject claimed X (say, that he operates http://www.random.net/~user40),
and we put X in the certificate (in this case, under subjectAltName)"?  Is
that level so low that we need a separate place to put statements like
that, or rule them out of the certificate?  I doubt that any CA puts things
in a certificate with less evidence than that.

Regards,

Bob

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 31 May 2000 10:59:34 -0400 (EDT)

Bob,

In the case of cert field verification, there is a clear binary
distinction between explicitly endorsing placing NVI in certificates
and explicitly deprecating the practice.  That debate happened some
time ago.  It was decided at that time that NVI belongs somewhere
other than in PK certificates (such as directories, LAN management
databases, subject-signed Attribute certificates, or ...), that using PK  
certificates as a transport mechanism for such fluff simply because
it's convenient is bad practice, and that defining an NVI flag would
encourage the practice.

There may be disagreement over the decision itself, or over
the process by which it was made.  There may be a request to debate
the whole thing again and perhaps come to a different decision.
But it cannot be said that the decision was made last week, and
that a CA which was PKIX-conforming two weeks ago is not
PKIX-conforming today.  CAs which adhered to the RFC 2459 profile
two weeks ago will adhere to RFC 2459bis regardless of whether it
contains a statement of the obvious: that some communities may
choose to replace the PKIX profile with something else.

And given that CAs which choose not to conform with section
4.2.1.7 of RFC 2459 (January 1999) have a fig leaf (specifying in
the CPS some minimal gesture that could plausibly, or even
implausibly, pass for verification), the assertion that there was
some substantive change within the last week related to NVI and
PKIX conformance is pure horsewater.

- - - - - -

On the topic of non-repudiation, I admit to being disappointed that the
WG couldn't reach agreement on my point of view :-)!  (that key usage
bit 1 means "Persistent Data Origin Authentication With Third Party
Proof", that "technical non-repudiation" is an acceptable term
for PDOAWTPP, and that there are objective processing and handling
differences between PDOAWTPP keys, Entity Authentication keys, and
Key Establishment keys which make it inadvisable to deprecate the
bit entirely).  But given that PKIX could not reach agreement after
interminable months of discussion, I don't see what could be done
other than punt and let individual communities (individually and
cooperatively) profile use of the bit as they see fit.

If that is what you meant by "letting commercial practice sort
out the issue", we agree that no obviously better course of action
is apparent.

Regards,
Dave

> Date: Tue, 30 May 2000 11:43:24 -0600
> From: "Bob Jueneman" <[email-masked]>
> Cc: <[email-masked]>