Subject: RE: SubjectAltName verification

From: Peter Williams <[email-masked]>
Date: Fri, 26 May 2000 20:17:58 -0700

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.

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.

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?

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?

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Friday, May 26, 2000 8:29 AM
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: SubjectAltName verification

Denis,

The latter part of your message gets at the contentious point in this 
discussion.

Some of us believe that ALL data in a certificate is definitively 
bound to the public key.  After much debate the WG rejected the 
notion of marking data in a cert as non-verified.  So, the current 
posture is that the EXTENT to which data is verified is a matter of 
CA policy, but the basic notion is that the CA has verified all of 
the data.

Warwick gave some examples that he felt supported the notion that not 
all certificate data is verified, but my response argued that these 
examples were either not a violation of the verification notion 
(e.g., OUs), or were anomalous (pseudonyms).

So, while I agree with your suggestions re pluralizing the references 
in the cited text, I don't agree with the suggestion to limit the 
scope of the comment to just the subject alternate name.

Steve

---

From: Al Arsenault <[email-masked]>
Date: Sun, 28 May 2000 21:27:15 -0400

Peter,

	In a word, "No".  Details below:

> 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.  

> 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?

> proposed PKIX standards for field verification?

Not according to the ones I'm recommending.  :-)
 
> 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: Ed Gerck <[email-masked]>
Date: Mon, 29 May 2000 00:17:52 -0700

Al Arsenault wrote:

[snip]

> 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:

I agree entirely with what you wrote above. The devil is -- what do we
mean by "verifying"?  Of course, the word "verifying" must be understood
according to both the PKIX standard AND the CA's CPS. This means that
such certificates are essentially statements from a CA, not fact, and that
meaning and trust on a certificate (like beauty) is in the eyes of the beholder,
i.e., depends on each relying-party.

And certificates also contain fields which are not very intuitively defined or
even coherent with their names, such as the Distinguished Name field, which
is neither always distinguished nor necessarily contains the subject's name.
And, the SerialNumber field, etc.  So, data fields themselves are not clear in
*their* names -- more or less like a CA making no representation that the
subject "Bill Clinton" of a certificate is the same "Bill Clinton" as the one
you might be thinking of, but they put it in the cert anyway ;-)

Yes,  in legal reliance terms one may trust the confirmation procedures of the
CA during certificate reliance, but one cannot rely upon them for other than
their value as a representation of the CA's authentication management act
expressed in the CA's own terms and rules -- therefore, a PKIX certificate is
neither necessarily meaningful nor valid in a r-p's reference frame or for the
r-p's purposes. To pretend otherwise is at best misleading and at worst openly
naive.

To see a graphical birds's eye view of my comment, with a less terse treatment,
the reader can visit the "unabridged inside view of a typical X.509 certificate"
in http://www.mcg.org.br/x509cert.htm

Cheers,

Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Mon, 29 May 2000 09:30:37 -0400

Peter,

>the account name. This circumstance is common in the Internet

As Al said, just because people do it doesn't mean it's right or 
should be condoned by our standards.  But, to continue with your 
example, let's assume that the CA finds an acceptable way to embed 
the account name in the cert somewhere.

>circumstance is common in the Internet community today.

partially disclosed?  partially trusted? partially useful?

>in the Internet community today.

Greed?

>to the CA - at the time of certificate issuance.

I would not want to rely on this CA, and I expect most people would 
feel the same way.  I would "naturally" expect the CA to verify that 
the account name is bound to the user in question, not merely that 
the account name exists. This is the danger of adopting too liberal 
an interpretation of the "verified by whatever rules the CA wants to 
use" approach.

>to other per-CA policy criteria and/or PKIX mandates.

Based on the disclosed part of the "verification" process, I can't be 
too comfortable with what the CA may be doing for the rest of the 
data.

>proposed PKIX standards for field verification?

I think not.

>when executing this scenario?

The auditor should issue a negative report.

Steve

---

From: Bruno Salgueiro <[email-masked]>
Date: Mon, 29 May 2000 20:56:37 +0100

Hi to all. I'm just a reader in this mailing list but this subject is
of great concern to our organisation (which is a TTP) so here are my 2
cents. Let me start to say that Al has touched a very important point
which I didn't see quite addressed yet.

The thing here that has a great influence in business is the ratio bet-
ween the verifying effort in certificate data and the risk that a CA
wants to have in its business. This ratio has to be improved by increa-
sing the verify effort and lessening the risk factor.

The problem I see in this discussion is that you are going to the limit
of "all or nothing" and this worries me and I hope all the listeners
that
play in the same field (or please tel me why I shouldn't!).

I would like to know how this discussion fits in the EU Directive on
digi-
tal signatures and the ETSI/EESSI efforts which will really influence
how
a certificate has legal quality. I would also like to see more PKI
business
players influencing standards (because if standards are to be used they
ha-
ve to be realistic) than just vendors (not trying to flame anyone,
please).

Besides this and despite the heat of this discussion I think that "both
sides"
are presenting high quality comments.

Best regards,

-- 
=======================================================
Bruno Salgueiro       (mailto:[email-masked])
                   
SIBS - Sociedade Interbancária de Serviços
Rua Soeiro Pereira Gomes, Lote 1, 1600 Lisboa, Portugal

Tel: + 351 21 791 88 33
Fax: + 351 21 794 24 40
http://www.sibs.pt

Esta mensagem foi assinada com certificado MULTIcert.
Para obter o certificado da Autoridade de Certificação
PILOTO MULTIcert dirija-se ao site
            http://www.sibs.multicert.com

"Computers are useless. They can only give you answers."
                                        --Pablo Picasso
=======================================================

---

From: Stephen Kent <[email-masked]>
Date: Tue, 30 May 2000 11:04:53 -0400

Bruno,

it is worth noting that TTPs, like you company, are not the only 
types of CAs, and thus not the only focus of these standards. 
Organizational and geopolitical CAs are of interest too.  Such CAs 
have the advantage of being authoritative for the data they put into 
certs, if they limit themselves to what they really know.  A problem 
faced by TTPs, who are generally authoritative for no data, is how to 
make the financial tradeoff you allude to.  Maybe this is another 
reason not to favor PKI models based on TTPs :-).

Steve

---

From: Bruno Salgueiro <[email-masked]>
Date: Tue, 30 May 2000 20:08:24 +0100

Stephen,

  I can agree to that in the extent that the CAs MUST verify every data
in the certificate that they physically can. In case of closed user
groups
this is particularly true but on the Internet is this feasible?

  When the PKIX group addresses these "verify" and "compliance"
definitions
in a "all or nothing" way, will undoubtedly opt out, as Bob Jueneman
explained
very well, all the TTPs out there. But this of course will only happen
if we
mean by verify the same as having a written and legally binding document
that
says that a certain attribute in the certificate really
belongs/represents the
applying entity. But, on the other hand, in Peter William's email I
assumed
that the class 1 (or equivalent) Verisign policy is a PKIX conforming
policy which
is unacceptable in the view of the EU Directive! You see, until someone
really
defines what verify means and what kind of quality in certificate data
we are
aiming for, nobody will understand each other, or I won't understand
you! :)

  So, how do we solve this? I believe that there are really some issues
that 
IETF won't be able to enforce in its standards. If you want to include
TTPs
that cannot, will not verify everything which depends greatly on the
respon-
sability of RAs and end users (risk management), then the word RECOMMEND
should be used throughout the document regarding these issues and make
an
explicit reference to the CPS and CP of the certificate and the local
legislation
where the PKI is issuing certificates. Remember that in closed user
groups other
issues arise, i.e., confidentiality on the policies used.

  Is this too awkward?

Regards,

                   

Tel: + 351 21 791 88 33
Fax: + 351 21 794 24 40
http://www.sibs.pt