RE: ;binary migration solution

[Hallvard B Furuseth <[e-mail]>]

Steven Legg writes:
> As things stand today, we have a significant body of LDAPv3 compliant
> implementations that expect to get back "userCertificate;binary" from
> a request for "*".

I can think of a few ways to handle that, all of them ugly:

- Go back to my first suggestion.
  If an attribute is added with ;binary, it is returned with ;binary.
  Possibly unless it is asked for without ;binary, which causes
  the server to strip away ;binary in the result.
  Thus, the administrator can add certificates with ;binary if he
  has such clients.

  If the same site also has clients that wants userCertificate without
  ;binary, they lose.

- Treat ;binary as a normal tagging option.  Add userCertificate;binary
  and get userCertificate;binary back.  If there are also clients that
  want it without ;binary, add plain userCertificate as well.

- Let the attribute syntax handle ;binary.  If an attribute has a
  "binary syntax", it is returned with ;binary.

  This breaks clients which do not want ;binary added.

How common are clients like you describe, compared to
(a) clients that do not want ;binary and ask for userCertificate,
(b) clients that do not want ;binary and ask for *?

> In any phased migration away from the use of ";binary",
> at some point compliant directory servers will have to change from
> returning userCertificate;binary to just returning userCertificate and
> this will break currently conformant clients.
>
> David Chadwick is the only one who has proposed a safe way to
> effect a migration (using controls). However, since such a migration
> delivers no practical benefit to conformant PKI clients (just a different
> way of asking for the same thing), I think the pain of migration is
> not justified.

Yes, it may be just as well to keep asking for ;binary.

BTW, as far as I can tell, my and David's proposal make migration
more or less equally hard:

Client side:
- update to try DontUseBinary (David's) or to ask for ;binary (mine).
Server side:
- update to let syntaxes ensure binary transfer.
- update to handle DontUseBinary or no-op ;binary
Client side, when serveres have been upgraded:
- remove DontUseBinary (David's) or remove ;binary (mine).
Server side, when clients have been upgraded:
- remove support for DontUseBinary and ;binary.

-- 
Hallvard



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAUJpdX22895 for ietf-pkix-bks; Sat, 30 Nov 2002 11:51:39 -0800 (PST)
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAUJpag22886 for <[e-mail]>; Sat, 30 Nov 2002 11:51:37 -0800 (PST)
Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18IDeC-0006a4-00; Sat, 30 Nov 2002 20:51:28 +0100
Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18IDeA-0007cM-00; Sat, 30 Nov 2002 20:51:26 +0100
From: Hallvard B Furuseth <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: ;binary migration solution
In-Reply-To: <005001c294d7$2e2ee560$[e-mail]>
References: <[e-mail]> <005001c294d7$2e2ee560$[e-mail]>
X-Mailer: VM 6.37 under Emacs 19.34.1
Date: Sat, 30 Nov 2002 20:51:26 +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steven Legg writes:
> As things stand today, we have a significant body of LDAPv3 compliant
> implementations that expect to get back "userCertificate;binary" from
> a request for "*".

I can think of a few ways to handle that, all of them ugly:

- Go back to my first suggestion.
  If an attribute is added with ;binary, it is returned with ;binary.
  Possibly unless it is asked for without ;binary, which causes
  the server to strip away ;binary in the result.
  Thus, the administrator can add certificates with ;binary if he
  has such clients.

  If the same site also has clients that wants userCertificate without
  ;binary, they lose.

- Treat ;binary as a normal tagging option.  Add userCertificate;binary
  and get userCertificate;binary back.  If there are also clients that
  want it without ;binary, add plain userCertificate as well.

- Let the attribute syntax handle ;binary.  If an attribute has a
  "binary syntax", it is returned with ;binary.

  This breaks clients which do not want ;binary added.

How common are clients like you describe, compared to
(a) clients that do not want ;binary and ask for userCertificate,
(b) clients that do not want ;binary and ask for *?

> In any phased migration away from the use of ";binary",
> at some point compliant directory servers will have to change from
> returning userCertificate;binary to just returning userCertificate and
> this will break currently conformant clients.
>
> David Chadwick is the only one who has proposed a safe way to
> effect a migration (using controls). However, since such a migration
> delivers no practical benefit to conformant PKI clients (just a different
> way of asking for the same thing), I think the pain of migration is
> not justified.

Yes, it may be just as well to keep asking for ;binary.

BTW, as far as I can tell, my and David's proposal make migration
more or less equally hard:

Client side:
- update to try DontUseBinary (David's) or to ask for ;binary (mine).
Server side:
- update to let syntaxes ensure binary transfer.
- update to handle DontUseBinary or no-op ;binary
Client side, when serveres have been upgraded:
- remove DontUseBinary (David's) or remove ;binary (mine).
Server side, when clients have been upgraded:
- remove support for DontUseBinary and ;binary.

-- 
Hallvard


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAUEKeA03603 for ietf-pkix-bks; Sat, 30 Nov 2002 06:20:40 -0800 (PST)
Received: from junker.stroeder.com (krl9-d9bb4ee5.pool.mediaWays.net [217.187.78.229]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAUEKbg03599 for <[e-mail]>; Sat, 30 Nov 2002 06:20:37 -0800 (PST)
Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 967CE1579D3; Sat, 30 Nov 2002 15:20:25 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 30 Nov 2002 15:20:25 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: Acceptance of DC-style DNs (was: OCSP I-Ds going forward)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.71.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:
> 
> Without wanting to get into a long debate on this, the existence of one or two
> certs with DCs doesn't indicate their general acceptance

Without defining what "general acceptance" is we can't tell whether DC-style 
DNs are generally accepted or not. I guess we won't agree on a definition 
therefore it's worthless debating it at all.

In practice when deploying PKI with some sort of certificate profile you 
generally have to check whether all the components you're gonna use will 
handle these certificates correctly (without crashing, etc.). Looking at 
discussions here I doubt that the on-going "standardization" efforts of PKIX 
will significantly change this situation.

> (for example your cert is one produced by your own CA!).

So what?

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAU23mX02918 for ietf-pkix-bks; Fri, 29 Nov 2002 18:03:48 -0800 (PST)
Received: from localhost.localdomain (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAU23jg02914 for <[e-mail]>; Fri, 29 Nov 2002 18:03:45 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by localhost.localdomain (8.12.4/8.12.4) with ESMTP id gAU23XAT019883; Sat, 30 Nov 2002 15:03:34 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA293578; Sat, 30 Nov 2002 15:03:31 +1300 (NZDT) (sender [e-mail])
Date: Sat, 30 Nov 2002 15:03:31 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Acceptance of DC-style DNs (was: OCSP I-Ds going forward)
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David Chadwick <[e-mail]> writes:

>This is completely the opposite of my experience from giving public PKI and
>LDAP courses in London. People immediately see the benefit of leveraging the
>DNS name registration scheme to give them globally unique X500/LDAP DNs

It may be a cultural thing.  The person I mentioned who'd had OSI experience
was from the UK, and his reaction to DCs was (uhh, without trying to pick on
people from there :-) "This was the sort of thing they were doing there when I
left" (he may have used a word other than "thing" in the sentence).

Without wanting to get into a long debate on this, the existence of one or two
certs with DCs doesn't indicate their general acceptance (for example your
cert is one produced by your own CA!).  I have a whole pile of certs with
various oddities in them (I have one from my CA with a cat MPEG), none of
which are in widespead use.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gATJMc310772 for ietf-pkix-bks; Fri, 29 Nov 2002 11:22:38 -0800 (PST)
Received: from junker.stroeder.com (krl9-d9bb4f01.pool.mediaWays.net [217.187.79.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gATJMZg10768 for <[e-mail]>; Fri, 29 Nov 2002 11:22:35 -0800 (PST)
Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 06FD21579D3; Fri, 29 Nov 2002 20:22:21 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 29 Nov 2002 20:22:21 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
Cc: [e-mail]
Subject: Re: No-op LDAP ;binary option
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.71.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley wrote:
> 
> I already have concerns about consistency when the certificate is stored 
> in a subordinate entry, with the various certificate fields extracted to 
> create searchable attributes.  If we allow the certificate to be stored 
> in many different places, how do we ensure consistency?

Exactly like we most times ensure consistency of any other attribute of an 
LDAP entry containing something meaningful: We don't.

The certificate is downloaded completely as a whole. The entity actually 
using the certificate MUST check the validity of the certificate and the 
applicability for a certain crypto protocol.

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gATHSlT05701 for ietf-pkix-bks; Fri, 29 Nov 2002 09:28:47 -0800 (PST)
Received: from iapetus.salford.ac.uk (iapetus.salford.ac.uk [146.87.255.98]) by above.proper.com (8.11.6/8.11.3) with SMTP id gATHSjg05694 for <[e-mail]>; Fri, 29 Nov 2002 09:28:45 -0800 (PST)
Received: (qmail 84702 invoked by alias); 29 Nov 2002 17:28:44 -0000
Received: (qmail 84684 invoked from network); 29 Nov 2002 17:28:44 -0000
Received: from unknown (HELO salford.ac.uk) (146.87.80.124) by iapetus.salford.ac.uk with SMTP; 29 Nov 2002 17:28:44 -0000
Message-ID: <[e-mail]>
Date: Fri, 29 Nov 2002 17:33:51 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Acceptance of DC-style DNs (was: OCSP I-Ds going forward)
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------018CFA458F7A3274B3FCFC4E"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------018CFA458F7A3274B3FCFC4E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Peter Gutmann wrote:
> 
> =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]> writes:
> 
> >Peter, I disagree with your opinion about acceptance of DC-style DNs. Usage
> >of DNs according to RFC 2247 is getting very common in today's LDAP
> >deployment.
> 
> I've never seen one, and I have a fairly wide-ranging cert collection from all
> sorts of sources... there may be one in there somewhere that I've forgotten
> about and I don't want to search the whole lot to find it, but from what I've
> seen, usage is practically nonexistant.  You're probably correct in that usage
> is necessary for LDAP deployment, but that doesn't mean that they're in common
> use anywhere.

Peter 

Here is one attached to this message.

> 
> >The main problem with PKI deployment is that most PKI-enabled software does
> >not support this kind of DNs.
> 
> I think the real problem is that DCs are a weird artifact of X.500 ideology
> rather than any real-world issue [0].  People don't even know what to do with
> a "locality" or "organisationalUnit", let alone a DC.  Even if the software
> supported it, no-one would know what to do with them apart from treating them
> as yet another odd blob ID.
> 

Its not really much more weird than DNS names is it? The only difference
is that DNS name components are typeless, whereas X.500 ones are typed.

> Peter.
> 
> [0] I've tried explaning DCs to one or two people in the past when doing one
>     of the PKI tutorials on my home page, and the reaction was generally head-
>     shaking and comments involving the terms "OSI", "reality", and "out of
>     touch with".  One guy (who had worked in an OSI environment in the past)
>     asked whether 2247 was an April 1 RFC.


This is completely the opposite of my experience from giving public PKI
and LDAP courses in London. People immediately see the benefit of
leveraging the DNS name registration scheme to give them globally unique
X500/LDAP DNs
Even Microsoft see the sense in this :-)

David

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------018CFA458F7A3274B3FCFC4E
Content-Type: application/pkcs7-mime;
 name="D.W.Chadwick.p7c"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="D.W.Chadwick.p7c"

MIILpAYJKoZIhvcNAQcCoIILlTCCC5ECAQExADALBgkqhkiG9w0BBwGgggt5MIID+DCCA2Gg
AwIBAgIEPKLzuTANBgkqhkiG9w0BAQUFADBtMRIwEAYKCZImiZPyLGQBGRYCVUsxEjAQBgoJ
kiaJk/IsZAEZFgJhYzEXMBUGCgmSJomT8ixkARkWB3NhbGZvcmQxEzARBgoJkiaJk/IsZAEZ
FgNpc2kxFTATBgoJkiaJk/IsZAEZFgVpc3NyZzAeFw0wMjAzMjgxNjI0MjFaFw0wNTAzMjgx
NjU0MjFaMIGQMRIwEAYKCZImiZPyLGQBGRYCdWsxEjAQBgoJkiaJk/IsZAEZFgJhYzEXMBUG
CgmSJomT8ixkARkWB3NhbGZvcmQxEzARBgoJkiaJk/IsZAEZFgNpc2kxFTATBgoJkiaJk/Is
ZAEZFgVpc3NyZzEhMAgGA1UEBRMBMDAVBgNVBAMTDkRhdmlkIENoYWR3aWNrMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQDRGkBUF5zKcDqhBZggiXPI5XAw2xGr92Im0GVYsqoYfcPb
OyhrnbnefngsJWYwnOuS4+BVe2H++SIG++qDoX9kYTsnq+Q1aL80mkqzcxlx63ekqNC+KSEP
QOg1idZRl74y6BWEJsTY/acjfMHrYjRzIHKzMlkATAG6uBscQloZ8wIDAQABo4IBfzCCAXsw
CwYDVR0PBAQDAgeAMCsGA1UdEAQkMCKADzIwMDIwMzI4MTYyNDIxWoEPMjAwNDA1MDMyMDU0
MjFaMCUGA1UdEQQeMByBGmQudy5jaGFkd2lja0BzYWxmb3JkLmFjLnVrMBsGA1UdCQQUMBIw
EAYJKoZIhvZ9B0QdMQMCAQAwgZQGA1UdHwSBjDCBiTCBhqCBg6CBgKR+MHwxEjAQBgoJkiaJ
k/IsZAEZFgJVSzESMBAGCgmSJomT8ixkARkWAmFjMRcwFQYKCZImiZPyLGQBGRYHc2FsZm9y
ZDETMBEGCgmSJomT8ixkARkWA2lzaTEVMBMGCgmSJomT8ixkARkWBWlzc3JnMQ0wCwYDVQQD
EwRDUkwxMB8GA1UdIwQYMBaAFP1z2UV30MtQMr07wAtOhFA1EuYoMB0GA1UdDgQWBBS2oQJI
A+3fta0fmS2Yduzgo0Uz0jAJBgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY2LjADAgSw
MA0GCSqGSIb3DQEBBQUAA4GBAIzafle7tj7rSkc+6KZKUUJuURVZg/DgAduHRDpGH+lOeh+1
erPiYoO5JpODLZ2tVxDzRR1r73aok4qAwhIvs2mJOTsxehnFJ1UNnO5Ix5/L6DKGl7gLbEts
P3Jm8E2Pj2zOMWEto9ebMCyKb1JyIcJSnCPeT7vjy/i94jd/+7UCMIIDyzCCAzSgAwIBAgIE
PKLzujANBgkqhkiG9w0BAQUFADBtMRIwEAYKCZImiZPyLGQBGRYCVUsxEjAQBgoJkiaJk/Is
ZAEZFgJhYzEXMBUGCgmSJomT8ixkARkWB3NhbGZvcmQxEzARBgoJkiaJk/IsZAEZFgNpc2kx
FTATBgoJkiaJk/IsZAEZFgVpc3NyZzAeFw0wMjAzMjgxNjI0MjJaFw0wNTAzMjgxNjU0MjJa
MIGQMRIwEAYKCZImiZPyLGQBGRYCdWsxEjAQBgoJkiaJk/IsZAEZFgJhYzEXMBUGCgmSJomT
8ixkARkWB3NhbGZvcmQxEzARBgoJkiaJk/IsZAEZFgNpc2kxFTATBgoJkiaJk/IsZAEZFgVp
c3NyZzEhMAgGA1UEBRMBMDAVBgNVBAMTDkRhdmlkIENoYWR3aWNrMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQC9nLZwwX6K09ySYgkU1ogiJVFq4Y4TF5MUY1BOoFWmCIqgItD+rx2L
hCfMaWNiQ5ZlNaDlXh23VEdXLORRKkXzO0udv+hjDKmOOjYxO60+zytvg5VD2wX/6BjsWwv8
SKS5hZSnfN5xqzsrnQebudd90NAdHaA2l+iGSgPMP3pb0QIDAQABo4IBUjCCAU4wJQYDVR0R
BB4wHIEaZC53LmNoYWR3aWNrQHNhbGZvcmQuYWMudWswGwYDVR0JBBQwEjAQBgkqhkiG9n0H
RB0xAwIBADCBlAYDVR0fBIGMMIGJMIGGoIGDoIGApH4wfDESMBAGCgmSJomT8ixkARkWAlVL
MRIwEAYKCZImiZPyLGQBGRYCYWMxFzAVBgoJkiaJk/IsZAEZFgdzYWxmb3JkMRMwEQYKCZIm
iZPyLGQBGRYDaXNpMRUwEwYKCZImiZPyLGQBGRYFaXNzcmcxDTALBgNVBAMTBENSTDEwCwYD
VR0PBAQDAgUgMB8GA1UdIwQYMBaAFP1z2UV30MtQMr07wAtOhFA1EuYoMB0GA1UdDgQWBBQ5
1HfRmH6Q+NJvXOGPBxn4sIrkjjAJBgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY2LjAD
AgSQMA0GCSqGSIb3DQEBBQUAA4GBABfn4dIbtHoalCj3DYRjSFhmVJ38YHJd1Ltaqxrr5JzN
nAsdv84hB4LHBzGxz4CBSyJ6fEN2jeKDLmi3Kyk5aD4+bs2HI2dsohN0o0wXyoOJAcEBs+87
5bJIjozopoR6yMMcbWgHRbIA6yKy71p3SBA06fp4MTLl/0wJAxKJTOicMIIDqjCCAxOgAwIB
AgIEPKLzjTANBgkqhkiG9w0BAQUFADBtMRIwEAYKCZImiZPyLGQBGRYCVUsxEjAQBgoJkiaJ
k/IsZAEZFgJhYzEXMBUGCgmSJomT8ixkARkWB3NhbGZvcmQxEzARBgoJkiaJk/IsZAEZFgNp
c2kxFTATBgoJkiaJk/IsZAEZFgVpc3NyZzAeFw0wMjAzMjgxMDEyMjJaFw0yMjAzMjgxMDQy
MjJaMG0xEjAQBgoJkiaJk/IsZAEZFgJVSzESMBAGCgmSJomT8ixkARkWAmFjMRcwFQYKCZIm
iZPyLGQBGRYHc2FsZm9yZDETMBEGCgmSJomT8ixkARkWA2lzaTEVMBMGCgmSJomT8ixkARkW
BWlzc3JnMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1ERrCdO5WuPnjaeulBiNl92hh
2SQy5COVq63FArIhcngWZhpDnR7T6JkHK7qEy8vZ8Il80Teu4FyyF6zD4EV2R7gkiM8akmoa
d61BRX3z6SCFvq/xBwGsPmmqOdjwk5uPtRHXWmECD8t3V+Yp1Dl+a3ejVg/9dxvOjN/0sT+r
tQIDAQABo4IBVTCCAVEwEQYJYIZIAYb4QgEBBAQDAgAHMIGUBgNVHR8EgYwwgYkwgYaggYOg
gYCkfjB8MRIwEAYKCZImiZPyLGQBGRYCVUsxEjAQBgoJkiaJk/IsZAEZFgJhYzEXMBUGCgmS
JomT8ixkARkWB3NhbGZvcmQxEzARBgoJkiaJk/IsZAEZFgNpc2kxFTATBgoJkiaJk/IsZAEZ
FgVpc3NyZzENMAsGA1UEAxMEQ1JMMTArBgNVHRAEJDAigA8yMDAyMDMyODEwMTIyMlqBDzIw
MTgwMzI4MTA0MjIyWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAU/XPZRXfQy1AyvTvAC06E
UDUS5igwHQYDVR0OBBYEFP1z2UV30MtQMr07wAtOhFA1EuYoMAwGA1UdEwQFMAMBAf8wHQYJ
KoZIhvZ9B0EABBAwDhsIVjYuMDo0LjADAgSQMA0GCSqGSIb3DQEBBQUAA4GBAGXlnMUQyW7s
1b9HTOt4EWsVrfNqUw/GmT3AOO2wwFHSLmSH+7+COC88jHZTmQ7m+rtpebFwpNO7XG+/sCFc
g09EEWfqBRrrNJtVJgXJNA6/Ko0XxedN59qhX9ypIUZzrGafB3dJaVfMQDqo5osa4i1EfWtY
HFRXWjH7PfHvmB2yMQA=
--------------018CFA458F7A3274B3FCFC4E
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------018CFA458F7A3274B3FCFC4E--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gATHIia04439 for ietf-pkix-bks; Fri, 29 Nov 2002 09:18:44 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id gATHIgg04433 for <[e-mail]>; Fri, 29 Nov 2002 09:18:42 -0800 (PST)
Received: (qmail 7249 invoked from network); 29 Nov 2002 17:18:26 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.217.215) by woodstock.binhost.com with SMTP; 29 Nov 2002 17:18:26 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 27 Nov 2002 08:53:14 -0500
To: David Chadwick <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: No-op LDAP ;binary option
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David:

I already have concerns about consistency when the certificate is stored in 
a subordinate entry, with the various certificate fields extracted to 
create searchable attributes.  If we allow the certificate to be stored in 
many different places, how do we ensure consistency?

Russ

At 12:27 AM 11/27/2002 +0000, David Chadwick wrote:


>"Housley, Russ" wrote:
> >
> > Steve:
> >
> > I think that you misunderstood my point.  The discussion has covered
> > ";binary" and schema issues.  I was only commenting on the schema
> > issue.  Sorry, I was not clear about the scope of my comments.
> >
> > We are considering two proposals.  First, we can store certificates as an
> > attribute of the subject.  Second, we can store certificates as an
> > attribute of dummy entities that are subordinates to the subject, one dummy
> > entity per certificate.
> >
> > We MUST NOT allow both!  Clients MUST know where to find the
> > certificates.  These two are incompatible, and we must pick just ONE of 
> them.
> >
>
>Russ
>
>I disagree with you on this one. We should allow both. For clients who
>know precisely where to go to and how to pick up certificates and choose
>the right one, we can store them in a multivalued attribute in the
>user's entry. For clients that dont know where the certificates are
>(dont know the DN of the user's entry) then searching is the only way
>they can find the ceritificate they want, and the child (dummy) entry
>will be the best way for this, at least in the short to medium term.
>
>Our implementation with OpenLDAP will actually allow both as an optional
>configuration parameter
>
>David
>
>
>
> > Russ
> >
> > At 04:59 PM 11/20/2002 -0500, Steve Hanna wrote:
> >
> > >Russ Housley wrote:
> > > >I do not really care as long as we agree on ONE way to do it.  We 
> can come
> > > >up with a transition strategy once there is an agreed to standard.  I
> > > >cannot accept multiple ways to ask for the same stuff.
> > >
> > >We need to support userCertificate;binary because that's what
> > >the current spec and implementations support. The LDAPBIS
> > >working group wants to transition to userCertificate.
> > >
> > >I don't think it's possible to meet both of these requirements
> > >without having two ways to access the attribute. Why is it so
> > >important to only have one way? Wouldn't a smooth transition
> > >from userCertificate;binary to userCertificate be preferable?
> > >Do you have some better idea? If so, please present it.
> > >
> > >Otherwise, I suggest we use Hallvard's simplest solution:
> > >New servers MUST support userCertificate or userCertificate;binary
> > >and treat them as identical. Clients SHOULD use userCertificate;binary.
> > >Once the old servers are gone, we can say that clients SHOULD
> > >use userCertificate.
> > >
> > >-Steve
>
>--
>*****************************************************************
>
>David W. Chadwick, BSc PhD
>Professor of Information Systems Security
>IS Institute, University of Salford, Salford M5 4WT
>Tel: [phone]  Fax [phone]
>Mobile: [phone]
>Email: [e-mail]
>Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
>Research Projects: http://sec.isi.salford.ac.uk
>Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
>X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
>Entrust key validation string: MLJ9-DU5T-HV8J
>PGP Key ID is 0xBC238DE5
>
>*****************************************************************



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAT43Sx23623 for ietf-pkix-bks; Thu, 28 Nov 2002 20:03:28 -0800 (PST)
Received: from junker.stroeder.com (ccxcii.yapay.inka.de [193.197.185.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAT43Og23616 for <[e-mail]>; Thu, 28 Nov 2002 20:03:24 -0800 (PST)
Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 736BD157491; Fri, 29 Nov 2002 05:03:18 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 29 Nov 2002 05:03:18 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: [e-mail]
Cc: "'Steve Hanna'" <[e-mail]>, [e-mail]
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
References: <000901c29759$9f4d1df0$[e-mail]>
In-Reply-To: <000901c29759$9f4d1df0$[e-mail]>
X-Enigmail-Version: 0.71.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steven Legg wrote:
> 
> Michael Str der wrote:
> 
>>Steve Hanna wrote:
>>
>>>>I support the proposal made by Peter Gietz since it seems
>>>>like an fairly easy solution to me solving some real-world
>>>>problems.
>>>
>>>Can't certificateMatch do as well?
>>
>>Yes, off course. But it requires implementing it in the 
>>server which will 
>>take quite some time if ever implemented at all.
> 
> Both solutions require implementation effort. The question is
> whether the burden of the implementation falls mainly on the
> server or the client. The matching rule approach puts the burden
> on the server, while the child entry approach puts the burden on
> the clients.

The 2. is less of an issue.

Hint: I can even imagine to use good old Navigator 4.5+ to search for the 
recipient's certificate for a given e-mail address.

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAT3u5Q23471 for ietf-pkix-bks; Thu, 28 Nov 2002 19:56:05 -0800 (PST)
Received: from junker.stroeder.com (ccxcii.yapay.inka.de [193.197.185.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAT3u1g23467 for <[e-mail]>; Thu, 28 Nov 2002 19:56:02 -0800 (PST)
Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id BAF5B157491; Fri, 29 Nov 2002 04:55:06 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 29 Nov 2002 04:55:06 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: Acceptance of DC-style DNs (was: OCSP I-Ds going forward)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.71.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:
> =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]> writes:
> 
>>Peter, I disagree with your opinion about acceptance of DC-style DNs. Usage
>>of DNs according to RFC 2247 is getting very common in today's LDAP
>>deployment.
> 
> I've never seen one, and I have a fairly wide-ranging cert collection from all
> sorts of sources... there may be one in there somewhere that I've forgotten
> about and I don't want to search the whole lot to find it, but from what I've
> seen, usage is practically nonexistant.
 >  You're probably correct in that usage
 > is necessary for LDAP deployment, but that doesn't mean that they're in
 > common use anywhere.

Not true. I know at least two PKIs where DC-style DNs are used. Both with a 
1:1 mapping subject DNs to LDAP DNs.

>>The main problem with PKI deployment is that most PKI-enabled software does
>>not support this kind of DNs.
> 
> I think the real problem is that DCs are a weird artifact of X.500 ideology
> rather than any real-world issue [0].  People don't even know what to do with
> a "locality" or "organisationalUnit", let alone a DC.  Even if the software
> supported it, no-one would know what to do with them apart from treating them
> as yet another odd blob ID.

I won't jump into the debate about whether hierarchical names making sense 
or not. That's rather a philosophical question.

The issue raised here was that DNs have to be unique. Therefore the point is 
that DNS has a world-wide operational system of naming registries. In 
opposite there's no working world-wide system of naming authorities for 
X.521 names (except some small islands in the academic community).

> [0] I've tried explaning DCs to one or two people in the past when doing one
>     of the PKI tutorials on my home page, and the reaction was generally head-
>     shaking and comments involving the terms "OSI", "reality", and "out of
>     touch with".  One guy (who had worked in an OSI environment in the past)
>     asked whether 2247 was an April 1 RFC.

Well, usually in my LDAP workshops people pick up the point quite fast. And 
I would not claim to be a better teacher than you. Usually people are more 
aware of DNS domains.

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAT3jiM23248 for ietf-pkix-bks; Thu, 28 Nov 2002 19:45:44 -0800 (PST)
Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id gAT3jfg23244 for <[e-mail]>; Thu, 28 Nov 2002 19:45:41 -0800 (PST)
Received: (qmail 19591 invoked from network); 29 Nov 2002 03:36:21 -0000
Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 29 Nov 2002 03:36:21 -0000
Reply-To: <[e-mail]>
From: "Steven Legg" <[e-mail]>
To: "'Michael Str der'" <[e-mail]>, "'Steve Hanna'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
Date: Fri, 29 Nov 2002 14:44:28 +1100
Message-ID: <000901c29759$9f4d1df0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,

Michael Str der wrote:
> Steve Hanna wrote:
> >>I support the proposal made by Peter Gietz since it seems
> >>like an fairly easy solution to me solving some real-world
> >>problems.
> > 
> > Can't certificateMatch do as well?
> 
> Yes, off course. But it requires implementing it in the 
> server which will 
> take quite some time if ever implemented at all.

Both solutions require implementation effort. The question is
whether the burden of the implementation falls mainly on the
server or the client. The matching rule approach puts the burden
on the server, while the child entry approach puts the burden on
the clients.

Regards,
Steven



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAT3gcY23219 for ietf-pkix-bks; Thu, 28 Nov 2002 19:42:38 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAT3gZg23215 for <[e-mail]>; Thu, 28 Nov 2002 19:42:36 -0800 (PST)
Subject: Re: draft-ietf-pkix-warranty-extn-01.txt
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 28 Nov 2002 20:41:56 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 11/28/2002 10:45:00 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

random semi-related points are the "extended" warrenties that you can
purchase for just about any product these days. they effectively operate as
form of insurance .... at least from the standpoint that the consumer is
paying a premium and the entities selling the "extended" warrenties are
calculating their risk exposure very much like insurance companies
calculate their premiums and risks.

there has also been some amount of discussions about the consumer disk
industry cutting in half the warrenty period for disks ... presumably
primarily as a means of reducing the cost of doing business. this
potentially could go to the companies bottom line ... and/or result in a
lower cost product.

whether it is insurance in the form of insurance or insurance in the form
of warrenties ... it represents a business cost and somebody has to pay.
furthermore the associate premiums/pricing calculations are based on the
expected resulting costs that will be incured by the warrenties and/or
insurance.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAT3Fmw22384 for ietf-pkix-bks; Thu, 28 Nov 2002 19:15:48 -0800 (PST)
Received: from localhost.localdomain (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAT3Fjg22379 for <[e-mail]>; Thu, 28 Nov 2002 19:15:45 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by localhost.localdomain (8.12.4/8.12.4) with ESMTP id gAT3FgAT005281; Fri, 29 Nov 2002 16:15:42 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA285912; Fri, 29 Nov 2002 16:15:42 +1300 (NZDT) (sender [e-mail])
Date: Fri, 29 Nov 2002 16:15:42 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  Acceptance of DC-style DNs (was: OCSP I-Ds going forward)
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

=?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]> writes:

>Peter, I disagree with your opinion about acceptance of DC-style DNs. Usage
>of DNs according to RFC 2247 is getting very common in today's LDAP
>deployment.

I've never seen one, and I have a fairly wide-ranging cert collection from all
sorts of sources... there may be one in there somewhere that I've forgotten
about and I don't want to search the whole lot to find it, but from what I've
seen, usage is practically nonexistant.  You're probably correct in that usage
is necessary for LDAP deployment, but that doesn't mean that they're in common
use anywhere.

>The main problem with PKI deployment is that most PKI-enabled software does
>not support this kind of DNs.

I think the real problem is that DCs are a weird artifact of X.500 ideology
rather than any real-world issue [0].  People don't even know what to do with
a "locality" or "organisationalUnit", let alone a DC.  Even if the software
supported it, no-one would know what to do with them apart from treating them
as yet another odd blob ID.

Peter.

[0] I've tried explaning DCs to one or two people in the past when doing one
    of the PKI tutorials on my home page, and the reaction was generally head-
    shaking and comments involving the terms "OSI", "reality", and "out of
    touch with".  One guy (who had worked in an OSI environment in the past)
    asked whether 2247 was an April 1 RFC.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAT3BgH22251 for ietf-pkix-bks; Thu, 28 Nov 2002 19:11:42 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAT3Bcg22246 for <[e-mail]>; Thu, 28 Nov 2002 19:11:39 -0800 (PST)
Subject: Re: draft-ietf-pkix-warranty-extn-01.txt
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 28 Nov 2002 20:11:15 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 11/28/2002 10:14:03 PM
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gAT3Bdg22247
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

note also that warrenties/insurance tend to be between parties in a
business relationship. that has been one of the problems with certificates.
A certification authority can have a relationship with the end-user that
purchases the certificate.

A certification authority can warrenty/insure something with respect to the
person that purchases the certificate. Such warrenty/insurance might be if
a relying-party happens to sue the person that purchases the certificate
... then that person has coverage from the certification authority. If
something bad happens to a relying-party because of some certificate
related thing ... then for the relying-party to be able to collect ...
there typically has to be a business relationship between the relying party
and the institution providing the warrenty/insurance.  possibly the
relying-party can sue the end-user ... and then have the certification
authority insurance/warrenty cover the cost of that litigation. This is
possibly somewhat like home insurance that has a rider covering workers
hired by the home owner that are injured while at the home.

i presume this is the case somewhat of the previously mentioned reference
to GSA certificates .... certification authorities are providing
certificates as a business agent of the GSA ... and relying parties have
contracts with GSA. Presumably such contracts could include payment by the
relying parties to the GSA for the cost of any insurance/warrenties. It is
frequently difficult for a business entity to provide a service like
insurance or warrenties ... when there hasn't been any fees and/or other
funding which would cover the cost of providing such a service. Possibly
the only kinds of insurance and warrenties that don't require any funding
are the kind that nobody figures on ever having to make good on (totally
w/o substance or concrete validity).

not having any warrenties or insurance (or liability) somewhat implies that
there is no incremental upfront cost of doing business if something goes
wrong.

warrenties or insurance typically are related to some liability that might
be incured if something goes wrong.

warrenties and insurance are an incremental cost of doing business and must
be covered by some sort of revenue associated with doing that business.
furthermore the entities underwriting the insurance will want to understand
the parameters of the insurance risk ... in order to set the premiums. this
is something that the insurance industry is revising in the wake of 9/11
... there were possibly significant amount of unanticipated risk for which
the premiums are insufficient to cover the risk exposure. this is analogous
to security proportional to risk (in this case, insurance can be considered
a form of security):
http://www.garlic.com/~lynn/2001h.html#61

warrenties and insurance associated with some liability of doing business
is typically with respect to entities that have some business relationship.
For a typical TTP environment with respect to a relying party ... it is
frequently not possible to show a business relationship between the TTP and
the relying party (i think that in part is the purpose of the various GSA
legal instruments).





anders.rundgren <[e-mail] on 11/28/2002 2:19 pm wrote:

Alice,

I do sympathize with the idea, but I maintain that it is not fully
recommendable to mix warranties and liabilities as they are at least are
perceived as different.

CA liability do address a serious commercial aspect.  Very few CAs are
likely to go beyond liability due to the following reasons:

A problem with a "warranty" worth its name, is that it must cope with
transaction-accumulation, which is technically impossible to support.  An
identity thief performing massive parallel attacks of some kind, like
sending fake purchase orders to different parties, will erode any valid
reason for having a warranty in the form we usually define it.

A car can only break down once at a time, while PKI break-downs can be like
forest-fire.

Another problem with "warranties" is that not everything have an a priori
known value.  Like authentication.

Also I don't think this is how PKI is actually used (or even should be used
for that matter), you'd rather accept a CA or not.

If you split the ID in two pieces I'm sure that at least the liability-ID
could be a real success.  If lawyers accept the liability extensions (it is
really reductions...) in case of a lawsuit that is.  Otherwise
the whole thing gets redundant.

cheers,
Anders

PS It must be a challenge to be "Alice" in the world of PKI where "Bob and
Alice" are the two main players :-) DS



----- Original Message -----
From: "Alice Sturgeon" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Thursday, November 28, 2002 20:36
Subject: RE: draft-ietf-pkix-warranty-extn-01.txt


Anders,

I respectfully disagree.  You're right that a CA is not like GM or Ford,
but why can a CA not offer a warranty?  Perhaps what is missing here is a
definition of warranty, which, in insurance terms, is attestation of the
intent to provide compensation for harm incurred by using a certificate
(that is, a certificate that is faulty in some way).  Warranty is not the
same as liability; warranty is something that the CA can control, whereas
it cannot completely control liability.  The CA (or indeed any product- or
service-offering company) may try to limit its liability, but regardless of
this attempt, the extent of liability will ultimately be decided by the
courts.

You seem to be defining warranty rather narrowly, as replacement or refund
in the event of an inherent flaw.

Similarly, it seems to me that I define risk management more broadly than
you suggest.  Every time an RP enters into a transaction, or considers
doing so, the RP makes a risk management decision.  This can be quite a
natural and intuitive process, or it can be explicitly defined; either way,
the decision is made, and it will be based on more or less information.
The more information an RP has, the more informed the risk management
decision will be.  If a certificate contains information pertaining to the
existence of compensation in the event of harm, then the RP has more
information on which to make a risk decision.  Armed with this information,
as well as information about other factors of the transaction, such as
value, sensitivity of information, parties to the transaction (e.g., known
or unknown), etc., the RP's risk is reduced by virtue of knowing more about
all of the risk factors - including warranty.  If there is a TTP involved,
this again becomes a factor in the RP's risk management decision.

My 2 Canadian cents again.

Alice



Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     [phone]
Cell:         613-291-0331



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Anders Rundgren
Sent: November 28, 2002 12:29 PM
To: [e-mail]
Subject: Re: draft-ietf-pkix-warranty-extn-01.txt


Hi,

After reading this draft I believe the name "warranty" is a bit misleading.
It is, (or should IMHO at least be), focused on CA liability issues as a CA
cannot be compared to a car maker, as the only the latter will repair or
replace their products in case of faults.  Well, to get a "replacement"
certificate would be the equivalence but that is sort of taken for granted
anyway. :-)

                  CA-liability-extn

seems to be closer to what we are actually dealing with.

I would also be very cautious about RP "risk management" because that's
rather fictional.  The risk you take by accepting an unknown[*] business
partner is likely to be magnitudes bigger than accepting their
certificates.   If the CA is unknown as well you have nothing to build PKI
trust on either.

For TTP CAs OTOH, "risk management" with respect to client-certificates is
a part of their daily bread.

Just my 2 öres

Anders

*] with respect to performance, trustworthiness, credibility etc.





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gASLrMA06936 for ietf-pkix-bks; Thu, 28 Nov 2002 13:53:22 -0800 (PST)
Received: from mta05-svc.ntlworld.com (mta05-svc.ntlworld.com [62.253.162.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gASLrKg06931 for <[e-mail]>; Thu, 28 Nov 2002 13:53:20 -0800 (PST)
Received: from salford.ac.uk ([80.5.216.110]) by mta05-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <[e-mail]>; Thu, 28 Nov 2002 21:53:16 +0000
Message-ID: <[e-mail]>
Date: Thu, 28 Nov 2002 21:58:21 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve Hanna <[e-mail]>
CC: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>, [e-mail]
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------E03FA9F901D6DCBF027EB137"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------E03FA9F901D6DCBF027EB137
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Steve Hanna wrote:
>
> I was hoping for more than a "hint". Here are a few common
> scenarios where I *don't* think you'll need to search for
> user certificates:
> 
> 1) SSL/TLS
> 2) IPsec
> 3) Verifying signed email
> 
> In all of these cases, you will already have the user's
> certificate in hand. 

Agreed

>The primary use case where I expect
> you will need to find someone's user certificate would be
> when you want to send an encrypted email to someone whose
> user certificate you don't already have.

I believe this is the majority case for PKI certs.

> If you have other
> use cases, please describe them explicitly.

Here's another one. For PMI use, our PERMIS infrastructure wants to
collect the RBAC ACs for the user whose DN it has been given. Currently
we mandate that the DN is the same in the PKC and ACs so that we can
read the ACs, as we cant search for them. But it might be the case that
different AAs have issued ACs to the same user, using different DNs
according to their own naming schemes, and the email address
subjectAltName (or some other field) is the only common feature of the
PKC and the ACs. In this case we would need to search for ACs that
matched the common field.

> A broad comment
> that something might be useful is not a compelling argument
> for change.
> 
> > I support the proposal made by Peter Gietz since it seems
> > like an fairly easy solution to me solving some real-world
> > problems.
> 
> Can't certificateMatch do as well?

Yes it can, providing it is implemented in the client and server (along
with extensible match). certificateMatch is a better solution than the
child entry approach, but I believe that LDAP servers wont support it
for a long time, since it requires component matching to be implemented
as well. That is why we are currently implementing Peter Geitz's
approach.

David

> 
> > Sorry, unfortunately I have currently no time to wade
> > through all the responses in this thread piling in my Inbox.
> 
> I understand that! The email is a bit thick now. But we
> have a new subject line for this thread now, so that may help.
> 
> Thanks,
> 
> Steve

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------E03FA9F901D6DCBF027EB137
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------E03FA9F901D6DCBF027EB137--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gASLQrI06491 for ietf-pkix-bks; Thu, 28 Nov 2002 13:26:53 -0800 (PST)
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gASLQmg06487 for <[e-mail]>; Thu, 28 Nov 2002 13:26:49 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailc.telia.com (8.12.5/8.12.5) with SMTP id gASLQn8P015742; Thu, 28 Nov 2002 22:26:49 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <018201c29723$cd1e74d0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: draft-ietf-pkix-warranty-extn-01.txt
Date: Thu, 28 Nov 2002 22:19:13 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alice,

I do sympathize with the idea, but I maintain that it is not fully
recommendable to mix warranties and liabilities as they are
at least are perceived as different.

CA liability do address a serious commercial aspect.  Very few
CAs are likely to go beyond liability due to the following reasons:

A problem with a "warranty" worth its name, is that it must cope
with transaction-accumulation, which is technically impossible
to support.  An identity thief performing massive parallel attacks
of some kind, like sending fake purchase orders to different parties,
will erode any valid reason for having a warranty in the form we
usually define it.

A car can only break down once at a time, while PKI break-downs
can be like forest-fire.

Another problem with "warranties" is that not everything have an
a priori known value.  Like authentication.

Also I don't think this is how PKI is actually used (or even should be
used for that matter), you'd rather accept a CA or not.

If you split the ID in two pieces I'm sure that at least the liability-ID
could be a real success.  If lawyers accept the liability extensions
(it is really reductions...) in case of a lawsuit that is.  Otherwise
the whole thing gets redundant.

cheers,
Anders

PS It must be a challenge to be "Alice" in the world of PKI
where "Bob and Alice" are the two main players :-) DS



----- Original Message -----
From: "Alice Sturgeon" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Thursday, November 28, 2002 20:36
Subject: RE: draft-ietf-pkix-warranty-extn-01.txt


Anders,
I respectfully disagree.  You're right that a CA is not like GM or Ford, but
why can a CA not offer a warranty?  Perhaps what is missing here is a
definition of warranty, which, in insurance terms, is attestation of the
intent to provide compensation for harm incurred by using a certificate
(that is, a certificate that is faulty in some way).  Warranty is not the
same as liability; warranty is something that the CA can control, whereas it
cannot completely control liability.  The CA (or indeed any product- or
service-offering company) may try to limit its liability, but regardless of
this attempt, the extent of liability will ultimately be decided by the
courts.
You seem to be defining warranty rather narrowly, as replacement or refund
in the event of an inherent flaw.

Similarly, it seems to me that I define risk management more broadly than
you suggest.  Every time an RP enters into a transaction, or considers doing
so, the RP makes a risk management decision.  This can be quite a natural
and intuitive process, or it can be explicitly defined; either way, the
decision is made, and it will be based on more or less information.  The
more information an RP has, the more informed the risk management decision
will be.  If a certificate contains information pertaining to the existence
of compensation in the event of harm, then the RP has more information on
which to make a risk decision.  Armed with this information, as well as
information about other factors of the transaction, such as value,
sensitivity of information, parties to the transaction (e.g., known or
unknown), etc., the RP's risk is reduced by virtue of knowing more about all
of the risk factors - including warranty.  If there is a TTP involved, this
again becomes a factor in the RP's risk management decision.

My 2 Canadian cents again.

Alice



Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     [phone]
Cell:         613-291-0331



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Anders Rundgren
Sent: November 28, 2002 12:29 PM
To: [e-mail]
Subject: Re: draft-ietf-pkix-warranty-extn-01.txt


Hi,

After reading this draft I believe the name "warranty" is a bit
misleading.  It is, (or should IMHO at least be), focused on
CA liability issues as a CA cannot be compared to a car maker,
as the only the latter will repair or replace their products in case
of faults.  Well, to get a "replacement" certificate would be the
equivalence but that is sort of taken for granted anyway. :-)

                  CA-liability-extn

seems to be closer to what we are actually dealing with.

I would also be very cautious about RP "risk management"
because that's rather fictional.  The risk you take by accepting
an unknown[*] business partner is likely to be magnitudes bigger
than accepting their certificates.   If the CA is unknown as well
you have nothing to build PKI trust on either.

For TTP CAs OTOH, "risk management" with respect to
client-certificates is a part of their daily bread.

Just my 2 öres

Anders

*] with respect to performance, trustworthiness, credibility etc.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gASJYtu27066 for ietf-pkix-bks; Thu, 28 Nov 2002 11:34:55 -0800 (PST)
Received: from mx4.magma.ca (mx4.magma.ca [206.191.0.253]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gASJYrg27061 for <[e-mail]>; Thu, 28 Nov 2002 11:34:54 -0800 (PST)
Received: from mail6.magma.ca (mail6 [206.191.0.248]) by mx4.magma.ca (Magma's Mail Server) with ESMTP id gASJYKYZ014630; Thu, 28 Nov 2002 14:34:21 -0500
Received: from asturgeonpc (ottawa-dial-206-191-1-27.d-ip.magma.ca [206.191.1.27]) by mail6.magma.ca (Magma's Mail Server) with SMTP id gASJYIRZ001690; Thu, 28 Nov 2002 14:34:19 -0500 (EST)
Reply-To: <[e-mail]>
From: "Alice Sturgeon" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
Subject: RE: draft-ietf-pkix-warranty-extn-01.txt
Date: Thu, 28 Nov 2002 14:36:47 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <009701c29703$9edf5e10$0500a8c0@arport>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,
I respectfully disagree.  You're right that a CA is not like GM or Ford, but
why can a CA not offer a warranty?  Perhaps what is missing here is a
definition of warranty, which, in insurance terms, is attestation of the
intent to provide compensation for harm incurred by using a certificate
(that is, a certificate that is faulty in some way).  Warranty is not the
same as liability; warranty is something that the CA can control, whereas it
cannot completely control liability.  The CA (or indeed any product- or
service-offering company) may try to limit its liability, but regardless of
this attempt, the extent of liability will ultimately be decided by the
courts.
You seem to be defining warranty rather narrowly, as replacement or refund
in the event of an inherent flaw.

Similarly, it seems to me that I define risk management more broadly than
you suggest.  Every time an RP enters into a transaction, or considers doing
so, the RP makes a risk management decision.  This can be quite a natural
and intuitive process, or it can be explicitly defined; either way, the
decision is made, and it will be based on more or less information.  The
more information an RP has, the more informed the risk management decision
will be.  If a certificate contains information pertaining to the existence
of compensation in the event of harm, then the RP has more information on
which to make a risk decision.  Armed with this information, as well as
information about other factors of the transaction, such as value,
sensitivity of information, parties to the transaction (e.g., known or
unknown), etc., the RP's risk is reduced by virtue of knowing more about all
of the risk factors - including warranty.  If there is a TTP involved, this
again becomes a factor in the RP's risk management decision.

My 2 Canadian cents again.

Alice



Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     [phone]
Cell:         613-291-0331



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Anders Rundgren
Sent: November 28, 2002 12:29 PM
To: [e-mail]
Subject: Re: draft-ietf-pkix-warranty-extn-01.txt


Hi,

After reading this draft I believe the name "warranty" is a bit
misleading.  It is, (or should IMHO at least be), focused on
CA liability issues as a CA cannot be compared to a car maker,
as the only the latter will repair or replace their products in case
of faults.  Well, to get a "replacement" certificate would be the
equivalence but that is sort of taken for granted anyway. :-)

                  CA-liability-extn

seems to be closer to what we are actually dealing with.

I would also be very cautious about RP "risk management"
because that's rather fictional.  The risk you take by accepting
an unknown[*] business partner is likely to be magnitudes bigger
than accepting their certificates.   If the CA is unknown as well
you have nothing to build PKI trust on either.

For TTP CAs OTOH, "risk management" with respect to
client-certificates is a part of their daily bread.

Just my 2 öres

Anders

*] with respect to performance, trustworthiness, credibility etc.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gASHjts22743 for ietf-pkix-bks; Thu, 28 Nov 2002 09:45:55 -0800 (PST)
Received: from junker.stroeder.com (krl9-d9bb4d18.pool.mediaWays.net [217.187.77.24]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gASHjqg22739 for <[e-mail]>; Thu, 28 Nov 2002 09:45:53 -0800 (PST)
Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id ED2161573CC; Thu, 28 Nov 2002 18:45:51 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 28 Nov 2002 18:45:51 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Steve Hanna <[e-mail]>
Cc: [e-mail]
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.71.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve Hanna wrote:
> 
> Here are a few common
> scenarios where I *don't* think you'll need to search for
> user certificates:
> [..]
> 3) Verifying signed email
> 
> In all of these cases, you will already have the user's
> certificate in hand.

Not necessarily. Depends on the S/MIME settings in the sender's MUA.

> The primary use case where I expect
> you will need to find someone's user certificate would be
> when you want to send an encrypted email to someone whose
> user certificate you don't already have.

Note that also in this case the component searching the certificate might 
not be the same component using the certificate. Therefore the searching 
component might not be capable of parsing certificates at all.

>>I support the proposal made by Peter Gietz since it seems
>>like an fairly easy solution to me solving some real-world
>>problems.
> 
> Can't certificateMatch do as well?

Yes, off course. But it requires implementing it in the server which will 
take quite some time if ever implemented at all.

I'd prefer a solution which can be easily deployed with today's LDAP server 
products (see also section 2 in draft-klasen-ldap-x509certificate-schema-01).

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gASHaUq22491 for ietf-pkix-bks; Thu, 28 Nov 2002 09:36:30 -0800 (PST)
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gASHaSg22487 for <[e-mail]>; Thu, 28 Nov 2002 09:36:28 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailc.telia.com (8.12.5/8.12.5) with SMTP id gASHaS8P014730 for <[e-mail]>; Thu, 28 Nov 2002 18:36:28 +0100 (CET)
X-Original-Recipient: <[e-mail]>
Message-ID: <009701c29703$9edf5e10$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Re: draft-ietf-pkix-warranty-extn-01.txt
Date: Thu, 28 Nov 2002 18:28:52 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

After reading this draft I believe the name "warranty" is a bit
misleading.  It is, (or should IMHO at least be), focused on
CA liability issues as a CA cannot be compared to a car maker,
as the only the latter will repair or replace their products in case
of faults.  Well, to get a "replacement" certificate would be the
equivalence but that is sort of taken for granted anyway. :-)

                  CA-liability-extn

seems to be closer to what we are actually dealing with.

I would also be very cautious about RP "risk management"
because that's rather fictional.  The risk you take by accepting
an unknown[*] business partner is likely to be magnitudes bigger
than accepting their certificates.   If the CA is unknown as well
you have nothing to build PKI trust on either.

For TTP CAs OTOH, "risk management" with respect to
client-certificates is a part of their daily bread.

Just my 2 öres

Anders

*] with respect to performance, trustworthiness, credibility etc.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gASGJwk18477 for ietf-pkix-bks; Thu, 28 Nov 2002 08:19:58 -0800 (PST)
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gASGJtg18473 for <[e-mail]>; Thu, 28 Nov 2002 08:19:56 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailc.telia.com (8.12.5/8.12.5) with SMTP id gASGJr8P007983; Thu, 28 Nov 2002 17:19:53 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <007601c296f8$ec02af90$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Hicks, Mack" <[e-mail]>, <[e-mail]>
Subject: Re: Update of RFC 2527 - opposed
Date: Thu, 28 Nov 2002 17:12:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mack,
Some notable bank-originated PKI-schemes requires RPs
to sign contracts before they get a copy of the CA root
certificate and can start to "rely".   I assume that these
contracts are simply declarations that the RP is not
going to held the CA liable for errors.

So what good does CP/CPS extensions do in this case?

I'm actually wondering if the proposed warranty extensions
maybe are not as bad as I originally thought.  You may actually
need a way to in a machine-readable way be able to say: 
"Trust this certificate at your own risk" or
"Total liability is limited to $X for this certificate"

But will lawyers accept this as a *replacement* for an
explicit agreement?  If not, it seems as redundant as the
CP/CPS stuff that BTW hardly any user understands.

cheers,
Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gASC57L28286 for ietf-pkix-bks; Thu, 28 Nov 2002 04:05:07 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gASC54g28272 for <[e-mail]>; Thu, 28 Nov 2002 04:05:04 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA10302; Thu, 28 Nov 2002 13:05:56 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id NAA24314; Thu, 28 Nov 2002 13:05:12 +0100
Message-ID: <[e-mail]>
Date: Thu, 28 Nov 2002 13:04:58 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: Peter Gutmann <[e-mail]>, Michael Myers <[e-mail]>, [e-mail]
Subject: Re: OCSP I-Ds going forward
References: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gASC56g28280
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

I picked up your e-mail but this e-mail is responding to many other e-mails 
from others on the same topic. So it is a very loooong e-mail.

>       Denis:
> 
>       I had not read the entire draft in detail (I was responding to Mike's
> message), and now I see why you did this.  

:-)

 > However, IMHO expecting a
> hash-only signature verification to be carried out in the OCSP responder is
> overweight for its stated purpose (verifying the hash of either the issuing
> certificate or the issuing key is sufficient) and involves extra
> difficulties of implementation.  I will go into detail on both points.


>       The responder needs to identify the applicable one of multiple CA
> certificates with the same DN, but that does not require him to verify the
> signature of the certificate.  To quote your own draft "When the OCSP
> responder ..., it shall make sure that it is the right certificate."  One
> can construct several cases in which the combination of issuer with serial
> number does not uniquely identify a certificate.  

Correct.

> Some relatively plausible
> ones are: the operation of two independent CA's with the same DN, 

This single example is sufficient.

 > the
> resumption of operation by a CA which has lost its record of serial numbers
> issued while issuing them in (usually closely packed) ascending order, and
> the coincidence of serial numbers between separate processes of a CA
> running simultaneously.  These last two conditions are defects in the
> operation of the CA, and they make it IMPOSSIBLE to distinguish revocation
> of one of these two certificates from revocation of the other using CRL's.
> All other scenarios in which the same issuer duplicates serial numbers (and
> there are other though less plausible possibilities) will share this
> problem.  So, irrespective of the other standards which rely on the
> uniqueness of Issuer/Serial, only the case where there are two independent
> CA's with the same DN permits any meaningful verification which would be
> helped by further specification of the certificate.  

 > Using a hash of either
> the issuer's key or of his certificate is more efficient than performing a
> signature verification, and just as effective in distinguishing between the
> two conflicting CA's.

You are missing a point here. The main idea is to allow better performances.

With OCSP v1 the client needs first to build the path and then to check the 
revocation status of the certificate.

With OCSP v2 (using certIdWithSignature), the client may first check the 
revocation status of the certificate and then build the path, or can do both 
operations in parallel.

>       The implementation difficulty is that some verification engines may
> not have entry points to take a pre-computed hash, which would cause your
> suggested technique to not be executable.  The java.security.Signature
> class (as a prominent example) does not recommend support for using a hash
> as the input data to signature or signature verification, and some
> cryptographic providers follow those recommendations - although you could
> write a provider that would support this mode of operation while complying
> with that API.

In order to understand the arguments, it is important to concentrate on what 
the OCSP responder does with the information from the request and what the 
client needs to do as well.

Let us first address the problem of the non-uniqueness of CA DNs
(not for you, but for the whole list).

Currently RFC 3280 does not say much about the issuer field:

    The issuer field MUST contain a non-empty distinguished name (DN).

  . (…)

    As noted above, distinguished names are composed of attributes.
    This specification does not restrict the set of attribute types
    that may appear in names.  However, conforming implementations
    MUST be prepared to receive certificates with issuer names
    containing the set of attribute types defined below.

This means that there is no constraints for a CA for the attributes that 
compose its DN.

So it is perfectly valid for a CA to have a DN with a single attribute and 
thus a DN with a common name like “Platinium CA”. Then two CAs around the 
world may perfectly pick that DN.

Of course a *single* immediately “superior CA” will never accept to issue 
two certificates for two CAs that are indeed different, but two different 
“superior” CAs can perfectly do it.

There are two possible ways to realize that these CAs, with the same DN name 
are different:

1° to consider the chain of DNs names formed by a certification path 
starting from a root CA and finishing with “Platinium CA”. It is similar to 
identify two files with the same name, but placed in a different directory. 
This technique is not optimum since the full path would need to be 
constructed first, and since additionally Peter objected to have a SEQUENCE 
of DNs, it has been discarded).

2° to consider the fact that the two “Platinium CAs” will necessarily get 
their certificates from two different superior CAs that have necessarily two 
different private keys. Hence the combination of the issuing key of superior 
CA + the DN of the CA is unique. This feature is used in OCSP v1, and this 
is not by accident.

CertID          ::=     SEQUENCE {
        hashAlgorithm       AlgorithmIdentifier,
        issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
        issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
        serialNumber        CertificateSerialNumber }

issuerKeyHash, which is mandatory, allows the OCSP responder to uniquely 
identify the certificate. Certainly explanations are missing in RFC 2560 to 
say what should/shall be done with this field by the OCSP responder, but its 
presence is of primary importance (I believe that few people, except OCSP 
implementers, had paid attention to the reason for the presence of that 
field and to what should be done with it).

In OCSP v1, issuerKeyHash is used in combination with issuerNameHash and 
serialNumber.

We could also use the following combination:
issuerKeyHash + IssuerAndSerialNumber.

Let me explain, why this structure has *not* been proposed in the OCSP v2 draft.

Inserting issuerKeyHash in the request mandates the client to first build 
the certification path, so that it can know the value of the issuing public 
key of the certificate. This process may be quite long.

The idea is thus to allow to check first if the certificate is not revoked, 
without the need to build first the certification path. If the certificate 
is revoked, then it does not make sense to build the path.

Another way to look at the problem is in terms of performances, and to allow 
a client to check the certificate revocation status and to build the 
certification path in parallel.

In fact the burden of the path construction goes first on the OCSP responder.

Now let me explain again why certIdWithSignature is being used. It is 
following the same spirit like OCSP v1 where the OCSP responder has to make 
sure that the right issuer key is being used for the certificate that 
corresponds to a given IssuerSerial as defined in RFC2634 section 5.4.1.

This is obtained by verifying the digital signature of the certificate by 
providing the hash value of it and the signature value (and algorithm 
identifier). So the OCSP responder picks what it believes might be the right 
key and thus makes the signature verification of the certificate (full 
explanations are in my previous e-mail on that topic).

Now, ESSCertID is not a good vehicle either, because it mandates the client 
to build the path first. For that reason (and another one pointed by 
Ambarish when we were co-editing OCSP v2 about the use of CRLs in the back 
office) it has *not* been included either.

Finally let us go back to the signer’s point of view. A signer has always 
access to its certificate, but not necessarily relying parties. In RFC 3126 
ESSCertID was being used. The advantage is a short structure that uniquely 
identifies the certificate and can be easily locally computed by a signer 
and placed as a signed attribute. The disadvantage is that it mandates the 
relying party to first build the path.

So a new idea would be to recommend to include as a signed attribute of CMS: 
CertIdWithSignature instead of ESSCertD.

Note: there is a side advantage to this structure: there is no more a choice 
for the hash function. The one that is used is the one included in the 
signature algorithm of the certificate.

CertIdWithSignature can easily be locally computed by a signer and placed as 
a signed attribute. The other major arguments are :

   a) it also preserves the privacy of the signer, since the full
      certificate is not transmitted, and

   b) it is much shorter than the full certificate.

CONCLUSION

certIdWithSignature is flexible, since it allows a client to check first the 
revocation status of the certificate and then build the path, to do both 
operations in parallel or even in thd reverse order.

What has been mentioned above works in any case, including the case where an 
OCSP responder is a front-end of several OCSP responders or is only using 
CRLs and of course including the case where two CAs have the same DN.

If, and if only if [with a single if, the world could be rebuilt] we were 
considering different kinds of OCSP responders (and would be able to know in 
which category they play) then they are cases where IssuerAndSerialNumber is 
enough. At present, we have no feature in the protocol that allows to make 
this distinction, but this could be added.

Sorry for this long e-mail, but it seemed that theses explanations were needed.

Denis

>             Tom Gindin
> 
> 
> Denis Pinkas <[e-mail]> on 11/26/2002 07:26:14 AM
> 
> To:    Tom Gindin/Watson/IBM@IBMUS, Peter Gutmann
>        <[e-mail]>
> cc:    Michael Myers <[e-mail]>, [e-mail]
> Subject:    Re: OCSP I-Ds going forward
> 
> 
> Tom, Peter (Gutmann) and the list,
> 
> Explanations are provided in the draft (see after).
> 
> Peter, this mail also answers to the mail you just posted.
> 
> 
>>      Mike:
>>
>>      If the purpose of CertIdWithSignature is to extend IssuerSerial in
> 
> a
> 
>>way which is both unambiguous and compact, why are both the
> 
> signatureValue
> 
>>field and tbsCertificateHash present?  Either the signatureValue field or
>>the signatureAlgorithm/tbsCertificateHash combination should be unique.
>>IMHO there isn't much point in doing a signature validation based on an
>>asserted hash without access to the base certificate.
>>
>>            Tom Gindin
> 
> 
> draft-ietf-pkix-ocspv2&ext-00.txt specifies:
> 
> certIdWithSignature is a more compact way to specify *unambiguously* a
> certificate.
> 
>     CertIdWithSignature ::= SEQUENCE {
>          issuerSerial              IssuerSerial,
>          tbsCertificateHash        BIT STRING,
>          certSignature             CertSignature
>     }
> 
> Page 19 contains the following text when using CertIdWithSignature:
> 
>      (...)
>                                              However, two CAs
>      might have the same DN and be certified under different
>      branches of a certification tree.
> 
>      (...)
> 
>      When the OCSP responder does not have access to the data base
>      of the issuer, then it may use either *CRLs* or the OCSP
>      responder designated by the CA that has issued the certificate.
> 
>      When the OCSP responder does *not* have access to the data base
>      of the issuers, then it *shall* first make sure that it is the
>      right certificate.
> 
>      In the general case, this can be done by verifying the
>      signature over that certificate.  For doing this, the OCSP
>      responder first needs to build a certification path up to one
>      of its trust anchors (without necessarily verifying the
>      revocation status of the CAs from the path).  The presumed
>      issuer key is then used to verify the signature of the
>      certificate using both the tbsCertificateHash and the signature
>      value. That issuer key will then be used to verify that this
>      key is used to sign the *CRL* or the OCSP response, or the
>      certificates issued to designate the CRL issuer or the OCSP
>      responder.
> 
> So the answer to the question "why are both the signatureValue
> field and tbsCertificateHash present" is:
> 
> It is needed when the OCSP responder is *only* using CRLs in the back
> office. signatureValue field and tbsCertificateHash MUST be both present so
> 
> that the OCSP responder can verify the signature of the certificate. By
> doing this, possible ambiguities between identical CA names vanish: the
> right CA is being used by the fact that two CAs can't have the same issuing
> 
> key.
> 
> This means that the OCSP responder must first find out the value of the
> issuing key. If it got the wrong value, the verification of the signature
> of
> the certificate will fail and the OCSP responder will either look for
> another one, or will say that it does not know.
> 
> Now, Peter, I am very sorry that you invested time to write
> draft-ietf-pkix-ocsp-sensible-id-00.txt "Sensible Identifiers for OCSP".
> 
> The big mistake is the text that you claim to be extracted from RFC 3369
> and
> which is not:
> 
>     issuerAndSerialNumber uniquely identifies a certificate by the
>     distinguished name of the certificate issuer and an issuer-specific
>     certificate serial number [RFC 3369]
> 
> The right text is:
> 
> 10.2.4  IssuerAndSerialNumber
> 
>     The IssuerAndSerialNumber type identifies a certificate, and thereby
>     an entity and a public key, by the distinguished name of the
>     certificate issuer and an issuer-specific certificate serial number.
> 
> RFC 3369 does NOT use the wording "uniquely identifies".
> 
> IssuerAndSerialNumber used alone does not work.
> 
> Now, let me also explain why using certHash alone does not work: it cannot
> work when the OCSP responder is *only* using CRLs, since certHash cannot be
> 
> computed in that case (there is simply no access to the full certificate
> !).
> 
> Since clients are ignorant of the information used by the OCSP responder in
> 
> the back office, they MUST always provide an unambiguous reference.
> 
> Your draft is not yet available on the IETF web server, but you will
> probably be a lucky winner anyway, since you might get a PKIX or an IETF
> record: the draft with the shortest life time in the history of PKIX and
> even, maybe, the IETF !  :-)
> 
> Now, I concur that these explanations are not straightforward for
> everybody.
> 
> So my question: the security considerations section already contains
> the above explanations (and much more !). Are they insufficient ?
> If insufficient, I would be happy to improve them. Text proposals are
> welcome.
> 
> Denis
> 
> 
> 
> 
> 
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gASAWl321862 for ietf-pkix-bks; Thu, 28 Nov 2002 02:32:47 -0800 (PST)
Received: from junker.stroeder.com (krl9-d9bb4d18.pool.mediaWays.net [217.187.77.24]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gASAWig21851 for <[e-mail]>; Thu, 28 Nov 2002 02:32:45 -0800 (PST)
Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 58A181573CC; Thu, 28 Nov 2002 11:32:41 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 28 Nov 2002 11:32:39 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Acceptance of DC-style DNs (was: OCSP I-Ds going forward)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.71.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:
> 
>>I can think of only one way that that might happen: require every CA that
>>wants to join the "Unbroken PKI" to have an RFC 2247 (DC) distinguished name
>>instead of the old C=x, O=y.
>>
>>Do you think that's likely to happen?
> 
> Nope (I don't recall ever talking to anyone other than PKI people who even
> know DCs exist).

Peter, I disagree with your opinion about acceptance of DC-style DNs. Usage 
of DNs according to RFC 2247 is getting very common in today's LDAP deployment.

The main problem with PKI deployment is that most PKI-enabled software does 
not support this kind of DNs.

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAS6ppW18165 for ietf-pkix-bks; Wed, 27 Nov 2002 22:51:51 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAS6pmg18160 for <[e-mail]>; Wed, 27 Nov 2002 22:51:49 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gAS6p8Na016974; Thu, 28 Nov 2002 19:51:08 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id TAA278794; Thu, 28 Nov 2002 19:51:06 +1300 (NZDT) (sender [e-mail])
Date: Thu, 28 Nov 2002 19:51:06 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: OCSP I-Ds going forward
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Phillip H. Griffin" <[e-mail]> writes:

>And this from http://www.normos.org/ietf/rfc/rfc3126.txt September 2001
>
>[...]
>
>   OtherHash ::= CHOICE {
>       sha1Hash OtherHashValue,  -- This contains a SHA-1 hash
>       otherHash OtherHashAlgAndValue
>   }
>
>   OtherHashValue ::= OCTET STRING
>
>   OtherHashAlgAndValue ::= SEQUENCE {
>     hashAlgorithm  AlgorithmIdentifier,
>     hashValue      OtherHashValue
>   }
>
>The later is what is now used in X9.73 CMS, soon to be published. It is the
>only choice alternative supported in OASIS XCBF and X9.84.

That's a nice form, since it simplifies to an OCTET STRING SIZE(20) for the
most common (let's face it, probably the only) case.  That'd get my grunt of
approval.

>And please use OCTET STRING instead of BIT STRING or REAL or some other type
>for this value.

Naah, UniversalString in an EMBEDDED PDV!  They don't get nearly enough use,
for some reason.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAS6ZiT17855 for ietf-pkix-bks; Wed, 27 Nov 2002 22:35:44 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAS6Zfg17850 for <[e-mail]>; Wed, 27 Nov 2002 22:35:41 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gAS6ZLNa016774; Thu, 28 Nov 2002 19:35:21 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id TAA278674; Thu, 28 Nov 2002 19:35:21 +1300 (NZDT) (sender [e-mail])
Date: Thu, 28 Nov 2002 19:35:21 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: OCSP I-Ds going forward
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[CC'd to the list since it's of general relevance]

Stephen Kent <[e-mail]> writes:

>My suggestion is that you try to get the OCSPv2 authors to adopt your
>suggestions, as a way of getting this into the standards track document.

As my "Eddie the Shipboard Computer" comment pointed out, I'm not optimistic
about this happening :-(.  The consensus of the debate on the newsgroup a
month or two back was that we needed a simple, straightforward cert identifier
to resolve the interop problems caused by the complex v1 identifier.  The
authors' response was to invent a new identifier just as complex as the v1
one, only different.  In other words instead of simplifying things as the WG
asked for, they did the opposite and made things worse rather than better - we
now have two unworkable identifiers instead of one to deal with.

All we need is a single, simple, universal ID which will be present in
requests which uniquely IDs all certs.  The smorgasbord in my pseudo-draft
isn't strictly necessary (it was mostly for compatiblity with existing
standards), just a certID will do.  I don't really want to get involved in
ideological debates on identifying certs or PKI design, I just want to be able
to ship code where I can guarantee that it'll talk to everything else without
weeks of hair-pulling and finger-pointing between vendors of incompatible
products.

A workable compromise, I think, is to have:

v2CertID ::= SEQUENCE {
  certHash   OCTET STRING,
  <whatever> ANY OPTIONAL
  }

where <whatever> can include as many DNs and hashes and bits of keys and
serial numbers and FFTs of the cert and MPEGs of cats and whatever as required
to make people happy.  I've picked the certHash as the one MUST because it's
the only guaranteed-unique single value for a cert (vs. issuerAndSerialNumber,
keyIdentifier, etc etc, which everyone is going to nitpick endlessly) so it
should be beyond reproach.  It also works nicely with the case of dropping the
value into a pre-built query that I mentioned earlier, and is the most compact
ID form for bandwidth-limited environments.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAS5imD15437 for ietf-pkix-bks; Wed, 27 Nov 2002 21:44:48 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAS5ijg15430 for <[e-mail]>; Wed, 27 Nov 2002 21:44:45 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gAS5ihNa016027; Thu, 28 Nov 2002 18:44:43 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA278311; Thu, 28 Nov 2002 18:44:43 +1300 (NZDT) (sender [e-mail])
Date: Thu, 28 Nov 2002 18:44:43 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: OCSP I-Ds going forward
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"David P. Kemp" <[e-mail]> writes:

>You are, of course, correct.  I'm just surprised to see an ideological
>principle being articulated by a pragmatist such as yourself.

It's being realistic: If you're working with an ideology that requires that
all DNs be unique or your ideology collapses, you have to live with that, in
the same manner that it's not a good idea to have the pope declare infallibly
(ex cathedra) that the world is flat without causing problems for your
religion.

That doesn't mean I agree with it.  I've seen DNs as a lost cause since day
one, and my code has always used a certID (code-internal name for an SHA-1
hash of the cert) to uniquely ID certs when it needs that.  It's a compact,
fixed-length, easy-to-use ID which just works.  I don't care what's in the
cert, the certID will manage it.

I also put an extension into all PKI protocol messages I generate which
contains the certID, and my code will ignore whatever other ID may be present
if it finds a certID in a message.  This is both a strength and a weakness:

Advantage: It just works, no matter what sort of junk is in the cert (I could
  do OCSP queries on SPKI certs if necessary without batting an eyelid).  This
  is great, since you can get any two cryptlib implementations to work out-of-
  the-box without having to fiddle with DN formats and who knows what else.
  There's at least one case (probably more) where my code ended up being used
  solely because they couldn't get another implementation to work - I don't
  know what the problem was, broken DNs or something, they didn't know enough
  about PKI to diagnose the problem themselves, and I wasn't going to go out
  of my way to fix someone else's code :-).

Disadvantage: It stops working when interoperating (or not, in this case) with
  sites using broken code or doing weird things with certs.  The standard
  response is that they user doesn't care whether the software they're using
  is non-standards-compliant (for example getting the OCSPv1 ID wrong, which
  isn't that rare), they just want it to work.  The end result is that they
  deploy the broken stuff on both sides of the link, and don't care about
  standards-compliance or interoperability, as long as it works for them.
  
  This is not a good situation to put users in, unless you're the vendor of
  the broken software.

>One problem, even within a centrally-administered PKI such as the DoD's, is
>that there are advocates for putting local (non-unique) distinguished names
>in certificates.

That's the approach I advocated (without claiming to have invented it, BTW :-)
in things like "PKI: It's not dead, just resting" - the name only has to be
meaningful within the COI to be useful.

>I can think of only one way that that might happen: require every CA that
>wants to join the "Unbroken PKI" to have an RFC 2247 (DC) distinguished name
>instead of the old C=x, O=y.
>
>Do you think that's likely to happen?

Nope (I don't recall ever talking to anyone other than PKI people who even
know DCs exist).

>Do you think there's a different coordination mechanism that's likely to
>happen?

Nope.

>Do you really think OCSP (and S/MIME) should just shrug their shoulders and
>say "not my problem"?

I'll answer that one indirectly:

* X.500 theology requires that DNs be unique.  If you want to live within the
  theology (for example using CRLs or feeding your OCSP responder with CRLs,
  which assume unique DNs to ID CAs), you need to play by the X.500 rules.

* If you don't want to play by the rules, you have to make some concessions,
  like using the certID to ID certs.  In other words if you're using non-
  unique DNs, you can't use CRLs which assume DNs are unique.  It's as simple
  as that.

You can't have your cake and eat it too.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAS53oe12610 for ietf-pkix-bks; Wed, 27 Nov 2002 21:03:50 -0800 (PST)
Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAS53ig12597 for <[e-mail]>; Wed, 27 Nov 2002 21:03:44 -0800 (PST)
Received: from sesione (12-230-105-28.client.attbi.com[12.230.105.28]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <2002112805034100200t4200e>; Thu, 28 Nov 2002 05:03:42 +0000
From: "Khaja Ahmed" <[e-mail]>
To: "Richard Levitte - VMS Whacker" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Non unique CA DNs - WAS: RE: OCSP I-Ds going forward
Date: Wed, 27 Nov 2002 21:03:44 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> dpkemp> One problem, even within a centrally-administered PKI such as
> dpkemp> the DoD's, is that there are advocates for putting local
> dpkemp> (non-unique) distinguished names in certificates.

I wonder if these advocates are just trying to see if the boys are awake and
paying attention :-)  Jokes aside if there is a case to be made for allowing
this, I would love to see it made on the list.

Absent that, in the spirit of warnings not to pour hot coffee in your lap or
immerse printers in water we should consider explicitly prohibiting this
behavior.  i.e. we PKIX should make uniqueness of CA DNs in a hierarchy a
MUST.  Conformant applications and services also should be required to have
unique CA DNs in their trust list.  Something for the authors of the new
2527 to consider would be addition of some language covering this.

Khaja

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Richard Levitte - VMS
> Whacker
> Sent: Wednesday, November 27, 2002 2:12 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: OCSP I-Ds going forward
>
>
>
> In message <[e-mail]> on
> Wed, 27 Nov 2002 09:22:17 -0500, "David P. Kemp"
> <[e-mail]> said:
>

> dpkemp> Unfortunately, what are two local contexts one month can
> dpkemp> become a single context with colliding DNs the next, so if a
> dpkemp> PKI is to remain un-broken when that happens, it must ensure
> dpkemp> not only its own name uniqueness but the uniqueness of all
> dpkemp> other PKIs with which any RP might expect it to interoperate.
>
> Let's make it really easy: as far as I understand how a PKI built upon
> X.500 (that is, where X.509 certificates are used), if there are two
> separate entities having the same DN, you have a problem (to put it
> kindly.  Peter is more accurate when saying "broken").  I can see
> that as a reason to actually use RDNs like ST= and L=.
>
> And this doesn't just become a problem for OCSP, it becomes a problem
> any time you want to do path construction and validation that has a
> higher complexity that checking among a bunch of certificate that
> happen to be in a local database or in memory.
>
> dpkemp> X.509 provides the tools (name constraints) to enforce
> dpkemp> uniqueness across cooperating but independent PKIs.  But how
> dpkemp> many of the CAs in just the Microsoft and Netscape trust lists
> dpkemp> subscribe to the idea that they must cooperate to the extent
> dpkemp> of using DNs only from a global DIT?
>
> I just took a quick peek at the list of roots in IE, and I saw no
> conflicts (although some DNs are horrible).  I would believe that
> anyone who can read and understand what a PKI is supposed to look like
> will choose a DN that has a great chance of being unique in a global
> namespace.  I think that would fall within the concept of self-
> preservation.
>
> dpkemp> I can think of only one way that that might happen:
> require every CA
> dpkemp> that wants to join the "Unbroken PKI" to have an RFC 2247 (DC)
> dpkemp> distinguished name instead of the old C=x, O=y.
>
> Or use L=, ST= and so on.  Someone with a name like C=x, O=y is rather
> bold, or big enough to warrant such a DN.
>
> dpkemp> Do you really think OCSP (and S/MIME) should just shrug
> their shoulders
> dpkemp>   and say "not my problem"?
>
> Yes.
>
> --
> Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
> Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
> T: [phone] |                             | SWEDEN
>      "Price, performance, quality...  choose the two you like"



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gARMDph20284 for ietf-pkix-bks; Wed, 27 Nov 2002 14:13:51 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gARMDlg20271 for <[e-mail]>; Wed, 27 Nov 2002 14:13:48 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX F5.3 VnHj) with ESMTP; Wed, 27 Nov 2002 23:11:18 +0100
Date: Wed, 27 Nov 2002 23:12:03 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: OCSP I-Ds going forward
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 2.2
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Wed, 27 Nov 2002 09:22:17 -0500, "David P. Kemp" <[e-mail]> said:

dpkemp> One problem, even within a centrally-administered PKI such as
dpkemp> the DoD's, is that there are advocates for putting local
dpkemp> (non-unique) distinguished names in certificates.
dpkemp> Unfortunately, what are two local contexts one month can
dpkemp> become a single context with colliding DNs the next, so if a
dpkemp> PKI is to remain un-broken when that happens, it must ensure
dpkemp> not only its own name uniqueness but the uniqueness of all
dpkemp> other PKIs with which any RP might expect it to interoperate.

Let's make it really easy: as far as I understand how a PKI built upon
X.500 (that is, where X.509 certificates are used), if there are two
separate entities having the same DN, you have a problem (to put it
kindly.  Peter is more accurate when saying "broken").  I can see
that as a reason to actually use RDNs like ST= and L=.

And this doesn't just become a problem for OCSP, it becomes a problem
any time you want to do path construction and validation that has a
higher complexity that checking among a bunch of certificate that
happen to be in a local database or in memory.

dpkemp> X.509 provides the tools (name constraints) to enforce
dpkemp> uniqueness across cooperating but independent PKIs.  But how
dpkemp> many of the CAs in just the Microsoft and Netscape trust lists
dpkemp> subscribe to the idea that they must cooperate to the extent
dpkemp> of using DNs only from a global DIT? 

I just took a quick peek at the list of roots in IE, and I saw no
conflicts (although some DNs are horrible).  I would believe that
anyone who can read and understand what a PKI is supposed to look like
will choose a DN that has a great chance of being unique in a global
namespace.  I think that would fall within the concept of self-
preservation.

dpkemp> I can think of only one way that that might happen: require every CA
dpkemp> that wants to join the "Unbroken PKI" to have an RFC 2247 (DC)
dpkemp> distinguished name instead of the old C=x, O=y.

Or use L=, ST= and so on.  Someone with a name like C=x, O=y is rather
bold, or big enough to warrant such a DN.

dpkemp> Do you really think OCSP (and S/MIME) should just shrug their shoulders
dpkemp>   and say "not my problem"?

Yes.

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gARLcWg18061 for ietf-pkix-bks; Wed, 27 Nov 2002 13:38:32 -0800 (PST)
Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gARLcTg18052 for <[e-mail]>; Wed, 27 Nov 2002 13:38:30 -0800 (PST)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18H9t1-0004rq-00; Wed, 27 Nov 2002 16:38:23 -0500
Message-ID: <[e-mail]>
Date: Wed, 27 Nov 2002 16:37:45 -0500
From: "Phillip H. Griffin" <[e-mail]>
Organization: http://asn-1.com
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Phillip H. Griffin" <[e-mail]>
CC: Michael Myers <[e-mail]>, Peter Gutmann <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: OCSP I-Ds going forward
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,

Also, ...

Phillip H. Griffin wrote:

>
> Michael,
>
> Please include the certHash choice alternative or optional component of
> this type in the OCSP solution. Others depend on this alternative in the
> definition as an easy means of identifying a certificate. And please use
> OCTET STRING instead of BIT STRING or REAL or some other
> type for this value.


> SNIP

>
> Michael Myers wrote:
>
>> Peter,
>>
>> I agree with your views re: issuerAndSerialNumber.  In general,
>> since this is an IETF WG after all, we should be first focused
>> on supporting other IETF work that relies on PKI and PKIX.
>> Conversely, I think it only fair that the consituency Denis'
>> formulation addresses deserves WG consideration as well.  That's
>> why, in the draft-ietf-pkix-ocsp-core-00.txt document I recently
>> sent to Internet Drafts there's
>>
>> ReqCert ::= CHOICE {
>>   certID                    CertID,
>>   issuerSerial              [0] IssuerAndSerialNumber,
>>   fullCert                  [1] FullCertificate,
>>   certIdWithSignature       [2] CertIdWithSignature }
>>
>> Perhaps, as you say, it should be SEQUENCE.  The only issue I
>> have with that is that to my recollection and understanding of
>> ASN.1 details the above CHOICE allows backwards interoperability
>> with v1 envirionments via use of the CertID choice because
>> there's no change in ASN.1 type tags in that instance.  
>
Yes, you can add new tagged choice alternatives without impacting the
existing encodings. Each tag must be unique for the ASN.1 to be valid.
Often, uniqueness can be achieved most easily using context specific
tagging such as [0], [1], and [2] shown above.

>> I'm no
>> ASN.1 expert.  I mostly fake it from worked examples.  But might
>> the following achieve both objectives?
>>
>> ReqCert ::= CHOICE {
>>   certID                    CertID,
>>   other                     [0] SEQUENCE . . . }
>
This would work too for the certID choice alternative to be undisturbed,
but this adds an additional layer of tagging for the issuerSerial 
alternative.

Phil



>>
>> Meanwhile I'm putting the finishing touches on the Servives and
>> Extensions document (i.e. draft-ietf-pkix-ocsp-services-00.txt).
>> That delay is mostly a systems engineering matter of parsing
>> through the DPV/DPD requirements in RFC3379 to ensure
>> compliance.
>>
>> With any luck at all, this work will bring a degree of coherence
>> and closure to our invention of this wheel.
>>
>> Mike
>>
>>
>>  
>>
>
>
>




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gARKAsL12501 for ietf-pkix-bks; Wed, 27 Nov 2002 12:10:54 -0800 (PST)
Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gARKAng12494 for <[e-mail]>; Wed, 27 Nov 2002 12:10:49 -0800 (PST)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gARKAfWC022540; Wed, 27 Nov 2002 15:10:42 -0500
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gARKAdfr183182; Wed, 27 Nov 2002 13:10:39 -0700
Importance: Normal
Sensitivity: 
Subject: Re: OCSP I-Ds going forward
To: "Phillip H. Griffin" <[e-mail]>, Peter Gutmann <[e-mail]>
Cc: Michael Myers <[e-mail]>, [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Wed, 27 Nov 2002 15:10:25 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11  |July 29, 2002) at 11/27/2002 03:10:39 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Phil, Peter:

      Since OCSP might be considered to have a special responsibility
because it's hiding the CRL's from the consumer, and thus hiding the fact
that the certificate and the CRL come from different actual authorities, it
probably should allow a client to use more than just IssuerSerial.  If an
S/MIME application picks up the wrong certificate because of two issuer's
using the same DN, it gets a false negative ("this wasn't signed by that
cert at all"), while OCSP could produce a false positive ("this cert is
still valid").
      Denis' suggested processing model for OCSP responders would work
better with the issuer key or certificate as the base of the hash rather
than the subject certificate.  My own temporary draft for this purpose,
which reduces to IssuerSerial if you don't use the extra fields, was:
      IssuerBasedID     SEQUENCE ::= {
            COMPONENTS OF IssuerSerial,
            issuerCertHash    OCTET STRING OPTIONAL,
            hashAlg     AlgorithmIdentifier DEFAULT { id-sha1, NULL }
      }

      The difference between this and ESSCertID with IssuerSerial present
is small enough that in the interests of standardization taking ESSCertID
from RFC 2634 might be better.

            Tom Gindin


"Phillip H. Griffin" <[e-mail]>@mail.imc.org on 11/27/2002
02:31:06 PM

Sent by:    [e-mail]


To:    Michael Myers <[e-mail]>
cc:    Peter Gutmann <[e-mail]>, [e-mail],
       Tom Gindin/Watson/IBM@IBMUS, [e-mail]
Subject:    Re: OCSP I-Ds going forward



Michael,

Please include the certHash choice alternative or optional component of
this type in the OCSP solution. Others depend on this alternative in the
definition as an easy means of identifying a certificate. And please use
OCTET STRING instead of BIT STRING or REAL or some other
type for this value.

This from http://www.normos.org/ietf/rfc/rfc2634.txt in 1999

   ESSCertID ::=  SEQUENCE {
        certHash                 Hash,
        issuerSerial             IssuerSerial OPTIONAL
   }

   Hash ::= OCTET STRING -- SHA1 hash of entire certificate


And this from http://www.normos.org/ietf/rfc/rfc3126.txt September 2001

   OtherCertID ::= SEQUENCE {
        otherCertHash            OtherHash,
        issuerSerial             IssuerSerial OPTIONAL
   }

   OtherHash ::= CHOICE {
       sha1Hash OtherHashValue,  -- This contains a SHA-1 hash
       otherHash OtherHashAlgAndValue
   }

   OtherHashValue ::= OCTET STRING

   OtherHashAlgAndValue ::= SEQUENCE {
     hashAlgorithm  AlgorithmIdentifier,
     hashValue      OtherHashValue
   }

The later is what is now used in X9.73 CMS, soon to be
published. It is the only choice alternative supported in
OASIS XCBF and X9.84.

Phil





Michael Myers wrote:

>Peter,
>
>I agree with your views re: issuerAndSerialNumber.  In general,
>since this is an IETF WG after all, we should be first focused
>on supporting other IETF work that relies on PKI and PKIX.
>Conversely, I think it only fair that the consituency Denis'
>formulation addresses deserves WG consideration as well.  That's
>why, in the draft-ietf-pkix-ocsp-core-00.txt document I recently
>sent to Internet Drafts there's
>
>ReqCert ::= CHOICE {
>   certID                    CertID,
>   issuerSerial              [0] IssuerAndSerialNumber,
>   fullCert                  [1] FullCertificate,
>   certIdWithSignature       [2] CertIdWithSignature }
>
>Perhaps, as you say, it should be SEQUENCE.  The only issue I
>have with that is that to my recollection and understanding of
>ASN.1 details the above CHOICE allows backwards interoperability
>with v1 envirionments via use of the CertID choice because
>there's no change in ASN.1 type tags in that instance.  I'm no
>ASN.1 expert.  I mostly fake it from worked examples.  But might
>the following achieve both objectives?
>
>ReqCert ::= CHOICE {
>   certID                    CertID,
>   other                     [0] SEQUENCE . . . }
>
>Meanwhile I'm putting the finishing touches on the Servives and
>Extensions document (i.e. draft-ietf-pkix-ocsp-services-00.txt).
>That delay is mostly a systems engineering matter of parsing
>through the DPV/DPD requirements in RFC3379 to ensure
>compliance.
>
>With any luck at all, this work will bring a degree of coherence
>and closure to our invention of this wheel.
>
>Mike
>
>
>
>









Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gARJfVA10338 for ietf-pkix-bks; Wed, 27 Nov 2002 11:41:31 -0800 (PST)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gARJfSg10331 for <[e-mail]>; Wed, 27 Nov 2002 11:41:28 -0800 (PST)
Received: from MMyersLapTop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by mail.coastside.net  with SMTP id gARJfMPP002336; Wed, 27 Nov 2002 11:41:22 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Phillip H. Griffin" <[e-mail]>
Cc: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: OCSP I-Ds going forward
Date: Wed, 27 Nov 2002 11:37:11 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Phil,

Thanks for the attention.  I will put this into what is quickly
becoming core-01.  By the way, is my ASN.1 reasoning correct?

Mike

> -----Original Message-----
> From: Phillip H. Griffin [mailto:[e-mail]]
> Sent: Wednesday, November 27, 2002 11:31 AM
> To: Michael Myers
> Cc: Peter Gutmann; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: OCSP I-Ds going forward
>
>
> Michael,
>
> Please include the certHash choice alternative or
> optional component of
> this type in the OCSP solution. Others depend on this
> alternative in the
> definition as an easy means of identifying a
> certificate. And please use
> OCTET STRING instead of BIT STRING or REAL or some other
> type for this value.
>
> This from http://www.normos.org/ietf/rfc/rfc2634.txt in 1999
>
>    ESSCertID ::=  SEQUENCE {
>         certHash                 Hash,
>         issuerSerial             IssuerSerial OPTIONAL
>    }
>
>    Hash ::= OCTET STRING -- SHA1 hash of entire certificate
>
>
> And this from
> http://www.normos.org/ietf/rfc/rfc3126.txt September 2001
>
>    OtherCertID ::= SEQUENCE {
>         otherCertHash            OtherHash,
>         issuerSerial             IssuerSerial OPTIONAL
>    }
>
>    OtherHash ::= CHOICE {
>        sha1Hash OtherHashValue,  -- This contains a SHA-1 hash
>        otherHash OtherHashAlgAndValue
>    }
>
>    OtherHashValue ::= OCTET STRING
>
>    OtherHashAlgAndValue ::= SEQUENCE {
>      hashAlgorithm  AlgorithmIdentifier,
>      hashValue      OtherHashValue
>    }
>
> The later is what is now used in X9.73 CMS, soon to be
> published. It is the only choice alternative supported in
> OASIS XCBF and X9.84.
>
> Phil
>
>
>
>
>
> Michael Myers wrote:
>
> >Peter,
> >
> >I agree with your views re: issuerAndSerialNumber.
> In general,
> >since this is an IETF WG after all, we should be
> first focused
> >on supporting other IETF work that relies on PKI and PKIX.
> >Conversely, I think it only fair that the consituency Denis'
> >formulation addresses deserves WG consideration as
> well.  That's
> >why, in the draft-ietf-pkix-ocsp-core-00.txt
> document I recently
> >sent to Internet Drafts there's
> >
> >ReqCert ::= CHOICE {
> >   certID                    CertID,
> >   issuerSerial              [0] IssuerAndSerialNumber,
> >   fullCert                  [1] FullCertificate,
> >   certIdWithSignature       [2] CertIdWithSignature }
> >
> >Perhaps, as you say, it should be SEQUENCE.  The only issue I
> >have with that is that to my recollection and
> understanding of
> >ASN.1 details the above CHOICE allows backwards
> interoperability
> >with v1 envirionments via use of the CertID choice because
> >there's no change in ASN.1 type tags in that
> instance.  I'm no
> >ASN.1 expert.  I mostly fake it from worked
> examples.  But might
> >the following achieve both objectives?
> >
> >ReqCert ::= CHOICE {
> >   certID                    CertID,
> >   other                     [0] SEQUENCE . . . }
> >
> >Meanwhile I'm putting the finishing touches on the
> Servives and
> >Extensions document (i.e.
> draft-ietf-pkix-ocsp-services-00.txt).
> >That delay is mostly a systems engineering matter of parsing
> >through the DPV/DPD requirements in RFC3379 to ensure
> >compliance.
> >
> >With any luck at all, this work will bring a degree
> of coherence
> >and closure to our invention of this wheel.
> >
> >Mike
> >
> >
> >
> >
>
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gARJVtW09729 for ietf-pkix-bks; Wed, 27 Nov 2002 11:31:55 -0800 (PST)
Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gARJVog09725 for <[e-mail]>; Wed, 27 Nov 2002 11:31:51 -0800 (PST)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 18H7uR-0002ts-00; Wed, 27 Nov 2002 14:31:43 -0500
Message-ID: <[e-mail]>
Date: Wed, 27 Nov 2002 14:31:06 -0500
From: "Phillip H. Griffin" <[e-mail]>
Organization: http://asn-1.com
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: Peter Gutmann <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: OCSP I-Ds going forward
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,

Please include the certHash choice alternative or optional component of
this type in the OCSP solution. Others depend on this alternative in the
definition as an easy means of identifying a certificate. And please use
OCTET STRING instead of BIT STRING or REAL or some other
type for this value.

This from http://www.normos.org/ietf/rfc/rfc2634.txt in 1999

   ESSCertID ::=  SEQUENCE {
        certHash                 Hash,
        issuerSerial             IssuerSerial OPTIONAL
   }

   Hash ::= OCTET STRING -- SHA1 hash of entire certificate


And this from http://www.normos.org/ietf/rfc/rfc3126.txt September 2001

   OtherCertID ::= SEQUENCE {
        otherCertHash            OtherHash,
        issuerSerial             IssuerSerial OPTIONAL
   }

   OtherHash ::= CHOICE {
       sha1Hash OtherHashValue,  -- This contains a SHA-1 hash
       otherHash OtherHashAlgAndValue
   }

   OtherHashValue ::= OCTET STRING

   OtherHashAlgAndValue ::= SEQUENCE {
     hashAlgorithm  AlgorithmIdentifier,
     hashValue      OtherHashValue
   }

The later is what is now used in X9.73 CMS, soon to be
published. It is the only choice alternative supported in
OASIS XCBF and X9.84.

Phil





Michael Myers wrote:

>Peter,
>
>I agree with your views re: issuerAndSerialNumber.  In general,
>since this is an IETF WG after all, we should be first focused
>on supporting other IETF work that relies on PKI and PKIX.
>Conversely, I think it only fair that the consituency Denis'
>formulation addresses deserves WG consideration as well.  That's
>why, in the draft-ietf-pkix-ocsp-core-00.txt document I recently
>sent to Internet Drafts there's
>
>ReqCert ::= CHOICE {
>   certID                    CertID,
>   issuerSerial              [0] IssuerAndSerialNumber,
>   fullCert                  [1] FullCertificate,
>   certIdWithSignature       [2] CertIdWithSignature }
>
>Perhaps, as you say, it should be SEQUENCE.  The only issue I
>have with that is that to my recollection and understanding of
>ASN.1 details the above CHOICE allows backwards interoperability
>with v1 envirionments via use of the CertID choice because
>there's no change in ASN.1 type tags in that instance.  I'm no
>ASN.1 expert.  I mostly fake it from worked examples.  But might
>the following achieve both objectives?
>
>ReqCert ::= CHOICE {
>   certID                    CertID,
>   other                     [0] SEQUENCE . . . }
>
>Meanwhile I'm putting the finishing touches on the Servives and
>Extensions document (i.e. draft-ietf-pkix-ocsp-services-00.txt).
>That delay is mostly a systems engineering matter of parsing
>through the DPV/DPD requirements in RFC3379 to ensure
>compliance.
>
>With any luck at all, this work will bring a degree of coherence
>and closure to our invention of this wheel.
>
>Mike
>
>
>  
>




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gARHSU602720 for ietf-pkix-bks; Wed, 27 Nov 2002 09:28:30 -0800 (PST)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gARHSRg02716 for <[e-mail]>; Wed, 27 Nov 2002 09:28:27 -0800 (PST)
Received: from MMyersLapTop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by mail.coastside.net  with SMTP id gARHSIPP016411; Wed, 27 Nov 2002 09:28:19 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSP I-Ds going forward
Date: Wed, 27 Nov 2002 09:24:08 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

I agree with your views re: issuerAndSerialNumber.  In general,
since this is an IETF WG after all, we should be first focused
on supporting other IETF work that relies on PKI and PKIX.
Conversely, I think it only fair that the consituency Denis'
formulation addresses deserves WG consideration as well.  That's
why, in the draft-ietf-pkix-ocsp-core-00.txt document I recently
sent to Internet Drafts there's

ReqCert ::= CHOICE {
   certID                    CertID,
   issuerSerial              [0] IssuerAndSerialNumber,
   fullCert                  [1] FullCertificate,
   certIdWithSignature       [2] CertIdWithSignature }

Perhaps, as you say, it should be SEQUENCE.  The only issue I
have with that is that to my recollection and understanding of
ASN.1 details the above CHOICE allows backwards interoperability
with v1 envirionments via use of the CertID choice because
there's no change in ASN.1 type tags in that instance.  I'm no
ASN.1 expert.  I mostly fake it from worked examples.  But might
the following achieve both objectives?

ReqCert ::= CHOICE {
   certID                    CertID,
   other                     [0] SEQUENCE . . . }

Meanwhile I'm putting the finishing touches on the Servives and
Extensions document (i.e. draft-ietf-pkix-ocsp-services-00.txt).
That delay is mostly a systems engineering matter of parsing
through the DPV/DPD requirements in RFC3379 to ensure
compliance.

With any luck at all, this work will bring a degree of coherence
and closure to our invention of this wheel.

Mike



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gARGvqs01348 for ietf-pkix-bks; Wed, 27 Nov 2002 08:57:52 -0800 (PST)
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gARGvmg01336 for <[e-mail]>; Wed, 27 Nov 2002 08:57:49 -0800 (PST)
Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20208; Wed, 27 Nov 2002 08:57:37 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARGvb9x000659; Wed, 27 Nov 2002 11:57:37 -0500 (EST)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.11.6+Sun/8.9.0) with ESMTP id gARGvZ624943; Wed, 27 Nov 2002 11:57:35 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 27 Nov 2002 11:56:47 -0500
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
CC: [e-mail]
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Ströder wrote:
> Steve Hanna wrote:
> > When (and how) do you think I will want to search for user
> > certificates? I expect that the common case will be "get
> > me the S/MIME certs for [e-mail]",
> 
> Steve, there sure are more use-cases.
> 
> Hint: You might wanna search for other types of certificates.
> And not every component doing the LDAP search does the ASN.1
> parsing as well.

I was hoping for more than a "hint". Here are a few common
scenarios where I *don't* think you'll need to search for
user certificates:

1) SSL/TLS
2) IPsec
3) Verifying signed email

In all of these cases, you will already have the user's
certificate in hand. The primary use case where I expect
you will need to find someone's user certificate would be
when you want to send an encrypted email to someone whose
user certificate you don't already have. If you have other
use cases, please describe them explicitly. A broad comment
that something might be useful is not a compelling argument
for change.

> I support the proposal made by Peter Gietz since it seems
> like an fairly easy solution to me solving some real-world
> problems.

Can't certificateMatch do as well?

> Sorry, unfortunately I have currently no time to wade
> through all the responses in this thread piling in my Inbox.

I understand that! The email is a bit thick now. But we
have a new subject line for this thread now, so that may help.

Thanks,

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gARENO918840 for ietf-pkix-bks; Wed, 27 Nov 2002 06:23:24 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id gARENMg18835 for <[e-mail]>; Wed, 27 Nov 2002 06:23:22 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id gAREKGa28064 for <[e-mail]>; Wed, 27 Nov 2002 09:20:16 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 27 Nov 2002 09:22:17 -0500
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP I-Ds going forward
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-H-S-Loop-Check-Ejzfr: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

You are, of course, correct.  I'm just surprised to see an ideological
principle being articulated by a pragmatist such as yourself.

One problem, even within a centrally-administered PKI such as the DoD's,
is that there are advocates for putting local (non-unique) distinguished
names in certificates.  Unfortunately, what are two local contexts one
month can become a single context with colliding DNs the next, so if a
PKI is to remain un-broken when that happens, it must ensure not only
its own name uniqueness but the uniqueness of all other PKIs with which
any RP might expect it to interoperate.

X.509 provides the tools (name constraints) to enforce uniqueness across
cooperating but independent PKIs.  But how many of the CAs in just the
Microsoft and Netscape trust lists subscribe to the idea that they
must cooperate to the extent of using DNs only from a global
DIT?  To avoid defective PKIs, there must be a global namespace even
though there will never be a Global Directory.

I can think of only one way that that might happen: require every CA
that wants to join the "Unbroken PKI" to have an RFC 2247 (DC)
distinguished name instead of the old C=x, O=y.

Do you think that's likely to happen?
Do you think there's a different coordination mechanism that's likely
  to happen?
Do you really think OCSP (and S/MIME) should just shrug their shoulders
  and say "not my problem"?


Dave


 

Peter Gutmann wrote:
> 
> Denis Pinkas <[e-mail]> writes:
> 
> >                                             However, two CAs
> >     might have the same DN and be certified under different
> >     branches of a certification tree.
> 
> There is a special name for a PKI of this kind.  It's called "Broken" or
> "Defective".
> 
> It is not the job of OCSP to fix defective PKIs.
>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAR76q126200 for ietf-pkix-bks; Tue, 26 Nov 2002 23:06:52 -0800 (PST)
Received: from mail.dataphone.se (mail04.mail.se.dataphone.net [212.37.1.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAR76mg26179 for <[e-mail]>; Tue, 26 Nov 2002 23:06:49 -0800 (PST)
Received: from salford.ac.uk (p27d1.du.dataphone.se [212.37.2.90]) by mail.dataphone.se (Postfix) with ESMTP id 4AAEA11D30B; Wed, 27 Nov 2002 08:06:33 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 27 Nov 2002 00:27:55 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: No-op LDAP ;binary option
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------9982AD6F0158CCD33A735C5A"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------9982AD6F0158CCD33A735C5A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



"Housley, Russ" wrote:
> 
> Steve:
> 
> I think that you misunderstood my point.  The discussion has covered
> ";binary" and schema issues.  I was only commenting on the schema
> issue.  Sorry, I was not clear about the scope of my comments.
> 
> We are considering two proposals.  First, we can store certificates as an
> attribute of the subject.  Second, we can store certificates as an
> attribute of dummy entities that are subordinates to the subject, one dummy
> entity per certificate.
> 
> We MUST NOT allow both!  Clients MUST know where to find the
> certificates.  These two are incompatible, and we must pick just ONE of them.
> 

Russ

I disagree with you on this one. We should allow both. For clients who
know precisely where to go to and how to pick up certificates and choose
the right one, we can store them in a multivalued attribute in the
user's entry. For clients that dont know where the certificates are
(dont know the DN of the user's entry) then searching is the only way
they can find the ceritificate they want, and the child (dummy) entry
will be the best way for this, at least in the short to medium term.

Our implementation with OpenLDAP will actually allow both as an optional
configuration parameter

David



> Russ
> 
> At 04:59 PM 11/20/2002 -0500, Steve Hanna wrote:
> 
> >Russ Housley wrote:
> > >I do not really care as long as we agree on ONE way to do it.  We can come
> > >up with a transition strategy once there is an agreed to standard.  I
> > >cannot accept multiple ways to ask for the same stuff.
> >
> >We need to support userCertificate;binary because that's what
> >the current spec and implementations support. The LDAPBIS
> >working group wants to transition to userCertificate.
> >
> >I don't think it's possible to meet both of these requirements
> >without having two ways to access the attribute. Why is it so
> >important to only have one way? Wouldn't a smooth transition
> >from userCertificate;binary to userCertificate be preferable?
> >Do you have some better idea? If so, please present it.
> >
> >Otherwise, I suggest we use Hallvard's simplest solution:
> >New servers MUST support userCertificate or userCertificate;binary
> >and treat them as identical. Clients SHOULD use userCertificate;binary.
> >Once the old servers are gone, we can say that clients SHOULD
> >use userCertificate.
> >
> >-Steve

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------9982AD6F0158CCD33A735C5A
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------9982AD6F0158CCD33A735C5A--





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAR6NB422483 for ietf-pkix-bks; Tue, 26 Nov 2002 22:23:11 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAR6N7g22479 for <[e-mail]>; Tue, 26 Nov 2002 22:23:08 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gAR6MRNa023654; Wed, 27 Nov 2002 19:22:27 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id TAA269990; Wed, 27 Nov 2002 19:22:26 +1300 (NZDT) (sender [e-mail])
Date: Wed, 27 Nov 2002 19:22:26 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: OCSP I-Ds going forward
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas <[e-mail]> writes:

>                                             However, two CAs
>     might have the same DN and be certified under different
>     branches of a certification tree.

There is a special name for a PKI of this kind.  It's called "Broken" or
"Defective".

It is not the job of OCSP to fix defective PKIs.

>IssuerAndSerialNumber used alone does not work.

You'd better quickly tell the S/MIME guys that the universal cert ID they've
been using for 10+ years doesn't work then.  Since it's been deployed to
almost every desktop on the planet (via Outlook, Netscape, etc etc), it'll
come as quite a shock to them.

I'm sure all the other standards authors and implementors will also be quite
surprised to find that the IDs they've been using for years don't work.

>Now, let me also explain why using certHash alone does not work: it cannot
>work when the OCSP responder is *only* using CRLs, since certHash cannot be
>computed in that case (there is simply no access to the full certificate !).

But it works just fine when the responder also uses cert hashes.

>Since clients are ignorant of the information used by the OCSP responder in
>the back office, they MUST always provide an unambiguous reference.

Actually few clients are ignorant of who they're talking to (I can't say *all*
clients are, but the deployments I know of, the clients know exactly who/what
the responder is and is capable of).  In cases like this, you don't need a
great pile of gobbledigook, just a simple, standard ID.

To explain the purpose behind the pseudo-draft:

Originally I posted it to point out my exasperation at the fact that after
2(?) years of work on this, OCSPv2 still hadn't quite managed to do a
cut&paste reference to a few widely-used cert IDs from other standards.
However, having now received private mail from a few people with similar
sentiments, I'll go ahead and post it as a real draft.  It's only a little
informational thing, so people can use that while they wait a few more years
until OCSPv2 in its infinite perfection and slendor finally appears.

Since it wasn't meant as a real draft, I'll go through and clean it up a bit
to make it publishable.  One thing which someone pointed out is that the IDs
should really be a SEQUENCE rather than a CHOICE, so that the responder can
choose which it wants to use if the client supplies more than one ID.  For
example, one tinkertoy device I know of (and whose developers better not be on
this list :-) uses the certHash (that's the example I used which populates a
pre-generated ID with a fixed hash value, because it can't do anything else),
whereas others may be able to supply more ID values.  The new text is attached
at the end of this message.

Someone also took me to task over the validity of my HHGTG reference.  For
those not familiar with it, asking Eddie the Shipboard Computer for tea
produces something almost, but not quite, entirely unlike what was asked for,
now matter how many times you ask for it.  Their opinion was that this was
more like watching the Golgafrinchans trying to invent the wheel.  After some
consideration I agree with this point of view.

Peter (arrghh!  All I want is a standard cert ID to use with OCSP queries.
       How hard can that possibly be, it's something that every other
       cert-using standard has had sorted out for years).

-- Snip --

2. SensibleIdentifier

This OCSP extension is used to identify the certificate being queried in a
simple, straightforward, and standard manner.  When a compliant
implementations encounters a request containing this identifier, it SHOULD
ignore whatever gobbledigook may be present in the OCSP reqCert field (it's
hard to tell what this will be, since it changes at random on every draft) and
use the SensibleIdentifier instead.

id-pkix-sensibleIdentifier OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 3029 3 1 4 }

SensibleIdentifier ::= SEQUENCE {
    issuerSerial      IssuerandSerialNumber,
    keyIdentifier [0] KeyIdentifier OPTIONAL,
    certificate       Certificate OPTIONAL,
    certHash          OCTET STRING OPTIONAL,
    ...
    }

2.1. SensibleIdentifier usage

The identifier is composed of a sequence of values, not all of which need to
be provided.  The sole mandatory identifier is the issuer and serial number
combination, because of its wide deployment and acceptance via S/MIME and
because the combination of issuer DN and certificate serial number allows CRL-
based responders to locate the certificate.

The remaining values are optional and may be provided for the responder to use
on an opportunistic basis.  In cases where the client is aware that the
responder will utilise a particular identifier or requires certain properties
(for example those of the keyIdentifier), they are encouraged to use the
appropriate ID.  Conversely, if the client capabilities or bandwidth are
limited, unneeded fields may be omitted.

[I'm not entirely happy with that any more, since it breaks the dump-a-
 certhash-in-a-prebuilt-query model.  This also breaks the requirement that
 "The responder SHOULD include the identifier used in its signed response to
 allow the client to verify that the correct identifier has been used" since
 the issuerAndSerialNumber may not be available at the responder.
 Suggestions?]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAQN49403594 for ietf-pkix-bks; Tue, 26 Nov 2002 15:04:09 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAQN46g03590 for <[e-mail]>; Tue, 26 Nov 2002 15:04:06 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX F5.3 VnHj) with ESMTP; Wed, 27 Nov 2002 00:01:29 +0100
Date: Wed, 27 Nov 2002 00:02:18 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: OCSP I-Ds going forward
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 2.2
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Tue, 26 Nov 2002 16:36:24 +0100, Denis Pinkas <[e-mail]> said:

Denis.Pinkas> > The first working document will be the "core".  It's primary
Denis.Pinkas> > purpose is to enable consideration of alternative certificate
Denis.Pinkas> > identification mechanisms.  It will propose a ReqCert syntax
Denis.Pinkas> > that provides a CHOICE of: legacy-interoperable support for
Denis.Pinkas> > 2560's certID; full certificate (including ACs); the
Denis.Pinkas> > CertIdWithSignature syntax as recently proposed; and
Denis.Pinkas> > issuerAndSerialNumber as recently advocated by Peter Gutman.
Denis.Pinkas> 
Denis.Pinkas> I don't think that it will include issuerAndSerialNumber
Denis.Pinkas> as recently advocated by Peter Gutman, since this form
Denis.Pinkas> of identifier is insecure.

Except for the case when two different CAs have exactly the same DN,
I'm not really sure I see the problem with issuerAndSerialNumber,
except if things have been done around it that makes it insecure.

I don't recall exactly how OCSP is supposed to be handled re this, but  I
would imagine that having the request contain the issuerAndSerialNumber
plus a keyID would be enough to identify the requested certificate.
And if that is enough, perhaps one need to enforce such combinations
of information, or suffer the consequences of ambiguity (which I agree
with is insecure and possibly prone to forged answers)...

I believe that blaming issuerAndSerialNumber for lack of security is
missing the point.

If there are other cases that I can't currently see (it's 1am, and my
brain may not be as turned on as I believe), please inform me.  I have
no problem with standing corrected :-).

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAQHKqw11949 for ietf-pkix-bks; Tue, 26 Nov 2002 09:20:52 -0800 (PST)
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAQHKlg11939 for <[e-mail]>; Tue, 26 Nov 2002 09:20:47 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gAQHK14Z184318; Tue, 26 Nov 2002 12:20:02 -0500
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAQHJuVO037988; Tue, 26 Nov 2002 12:19:57 -0500
Importance: Normal
Sensitivity: 
Subject: Re: OCSP I-Ds going forward
To: Denis Pinkas <[e-mail]>
Cc: Peter Gutmann <[e-mail]>, Michael Myers <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Tue, 26 Nov 2002 12:19:24 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11  |July 29, 2002) at 11/26/2002 12:19:59 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Denis:

      I had not read the entire draft in detail (I was responding to Mike's
message), and now I see why you did this.  However, IMHO expecting a
hash-only signature verification to be carried out in the OCSP responder is
overweight for its stated purpose (verifying the hash of either the issuing
certificate or the issuing key is sufficient) and involves extra
difficulties of implementation.  I will go into detail on both points.
      The responder needs to identify the applicable one of multiple CA
certificates with the same DN, but that does not require him to verify the
signature of the certificate.  To quote your own draft "When the OCSP
responder ..., it shall make sure that it is the right certificate."  One
can construct several cases in which the combination of issuer with serial
number does not uniquely identify a certificate.  Some relatively plausible
ones are: the operation of two independent CA's with the same DN, the
resumption of operation by a CA which has lost its record of serial numbers
issued while issuing them in (usually closely packed) ascending order, and
the coincidence of serial numbers between separate processes of a CA
running simultaneously.  These last two conditions are defects in the
operation of the CA, and they make it IMPOSSIBLE to distinguish revocation
of one of these two certificates from revocation of the other using CRL's.
All other scenarios in which the same issuer duplicates serial numbers (and
there are other though less plausible possibilities) will share this
problem.  So, irrespective of the other standards which rely on the
uniqueness of Issuer/Serial, only the case where there are two independent
CA's with the same DN permits any meaningful verification which would be
helped by further specification of the certificate.  Using a hash of either
the issuer's key or of his certificate is more efficient than performing a
signature verification, and just as effective in distinguishing between the
two conflicting CA's.
      The implementation difficulty is that some verification engines may
not have entry points to take a pre-computed hash, which would cause your
suggested technique to not be executable.  The java.security.Signature
class (as a prominent example) does not recommend support for using a hash
as the input data to signature or signature verification, and some
cryptographic providers follow those recommendations - although you could
write a provider that would support this mode of operation while complying
with that API.

            Tom Gindin


Denis Pinkas <[e-mail]> on 11/26/2002 07:26:14 AM

To:    Tom Gindin/Watson/IBM@IBMUS, Peter Gutmann
       <[e-mail]>
cc:    Michael Myers <[e-mail]>, [e-mail]
Subject:    Re: OCSP I-Ds going forward


Tom, Peter (Gutmann) and the list,

Explanations are provided in the draft (see after).

Peter, this mail also answers to the mail you just posted.

>       Mike:
>
>       If the purpose of CertIdWithSignature is to extend IssuerSerial in
a
> way which is both unambiguous and compact, why are both the
signatureValue
> field and tbsCertificateHash present?  Either the signatureValue field or
> the signatureAlgorithm/tbsCertificateHash combination should be unique.
> IMHO there isn't much point in doing a signature validation based on an
> asserted hash without access to the base certificate.
>
>             Tom Gindin

draft-ietf-pkix-ocspv2&ext-00.txt specifies:

certIdWithSignature is a more compact way to specify *unambiguously* a
certificate.

    CertIdWithSignature ::= SEQUENCE {
         issuerSerial              IssuerSerial,
         tbsCertificateHash        BIT STRING,
         certSignature             CertSignature
    }

Page 19 contains the following text when using CertIdWithSignature:

     (...)
                                             However, two CAs
     might have the same DN and be certified under different
     branches of a certification tree.

     (...)

     When the OCSP responder does not have access to the data base
     of the issuer, then it may use either *CRLs* or the OCSP
     responder designated by the CA that has issued the certificate.

     When the OCSP responder does *not* have access to the data base
     of the issuers, then it *shall* first make sure that it is the
     right certificate.

     In the general case, this can be done by verifying the
     signature over that certificate.  For doing this, the OCSP
     responder first needs to build a certification path up to one
     of its trust anchors (without necessarily verifying the
     revocation status of the CAs from the path).  The presumed
     issuer key is then used to verify the signature of the
     certificate using both the tbsCertificateHash and the signature
     value. That issuer key will then be used to verify that this
     key is used to sign the *CRL* or the OCSP response, or the
     certificates issued to designate the CRL issuer or the OCSP
     responder.

So the answer to the question "why are both the signatureValue
field and tbsCertificateHash present" is:

It is needed when the OCSP responder is *only* using CRLs in the back
office. signatureValue field and tbsCertificateHash MUST be both present so

that the OCSP responder can verify the signature of the certificate. By
doing this, possible ambiguities between identical CA names vanish: the
right CA is being used by the fact that two CAs can't have the same issuing

key.

This means that the OCSP responder must first find out the value of the
issuing key. If it got the wrong value, the verification of the signature
of
the certificate will fail and the OCSP responder will either look for
another one, or will say that it does not know.

Now, Peter, I am very sorry that you invested time to write
draft-ietf-pkix-ocsp-sensible-id-00.txt "Sensible Identifiers for OCSP".

The big mistake is the text that you claim to be extracted from RFC 3369
and
which is not:

    issuerAndSerialNumber uniquely identifies a certificate by the
    distinguished name of the certificate issuer and an issuer-specific
    certificate serial number [RFC 3369]

The right text is:

10.2.4  IssuerAndSerialNumber

    The IssuerAndSerialNumber type identifies a certificate, and thereby
    an entity and a public key, by the distinguished name of the
    certificate issuer and an issuer-specific certificate serial number.

RFC 3369 does NOT use the wording "uniquely identifies".

IssuerAndSerialNumber used alone does not work.

Now, let me also explain why using certHash alone does not work: it cannot
work when the OCSP responder is *only* using CRLs, since certHash cannot be

computed in that case (there is simply no access to the full certificate
!).

Since clients are ignorant of the information used by the OCSP responder in

the back office, they MUST always provide an unambiguous reference.

Your draft is not yet available on the IETF web server, but you will
probably be a lucky winner anyway, since you might get a PKIX or an IETF
record: the draft with the shortest life time in the history of PKIX and
even, maybe, the IETF !  :-)

Now, I concur that these explanations are not straightforward for
everybody.

So my question: the security considerations section already contains
the above explanations (and much more !). Are they insufficient ?
If insufficient, I would be happy to improve them. Text proposals are
welcome.

Denis








Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAQGC9906515 for ietf-pkix-bks; Tue, 26 Nov 2002 08:12:09 -0800 (PST)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAQGC7g06508 for <[e-mail]>; Tue, 26 Nov 2002 08:12:07 -0800 (PST)
Received: from MMyersLapTop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by mail.coastside.net  with SMTP id gAQGC3PP020181; Tue, 26 Nov 2002 08:12:03 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSP I-Ds going forward
Date: Tue, 26 Nov 2002 08:07:54 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

> I don't think that it will include issuerAndSerialNumber
> as recently advocated by Peter Gutman, since this form of
> identifier is insecure.

I'm pretty sure it will as a working document that attempts to
aggregate the inputs of all WG members who care to voice an
opinion.  Whether such technical content survives WG consensus
and WG last call is a totally separate matter.

I'm doing what I can to create a rough semblance of coherence.
In that regard, I'm most interested in the outcome of an open
discussion between you, Peter and others in the WG as to whether
or not issuerAndSerialNumber is an insecure form of certificate
identifier.  I do note that the S/MIME WG, from whom this syntax
is/will be imported, has gotten along fine with it.

> > Following resolution of the DPV/DPD issue, both
> > these working documents will be reintegrated
> > into a final I-D for WG last call on what we
> > want to call OCSPv2.
>
> Certainly not !

In general regarding the content of "core" vs. the "S&E" I-Ds,
keep in mind that I'm producing them to make it easy for the WG
to consider two parallel issues in a separable, non-contingent
manner.  Whatever comes of that consensus formation process
will, I'm planning, find it's way back into a single I-D.  If
however it turns out that it's best to keep them separate, I'm
happy to accomodate that collective view as well.

Mike



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAQFaXS03977 for ietf-pkix-bks; Tue, 26 Nov 2002 07:36:33 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAQFaUg03969 for <[e-mail]>; Tue, 26 Nov 2002 07:36:30 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA30664; Tue, 26 Nov 2002 16:37:22 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id QAA19428; Tue, 26 Nov 2002 16:36:37 +0100
Message-ID: <[e-mail]>
Date: Tue, 26 Nov 2002 16:36:24 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP I-Ds going forward
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike,

My comments are embeded.

> FYI all,
> 
> As many of you know, in March 2001 Carlisle, Stephen and I
> proposed two OCSP-based services.  We called them Delegated Path
> Validation (DPV) and Delegated Path Discovery (DPD).  That I-D
> was allowed to lapse pending WG resolution of the DPV/DPD
> requirements.  In Atlanta, I committed to the chairs to refresh
> that I-D.
> 
> However, that I-D also addressed the separable need to expand
> the certificate identification mechanisms.  This changed changed
> core syntax, hence a v2 version number (i.e. OCSPv2).  To
> complicate matters further, given that the original OCSPv2 I-D
> was allowed to lapse, the certID/v2 issue has recently been
> refreshed with yet another OCSP-based I-D that once more speaks
> to v2-ness but also introduced yet another proposed
> extension--the CRL Locator.
> 
> So to simplify matters for all of those in the WG that continue
> to have the patience to review and comment on these things, two
> new, unifying I-Ds are being produced and will be available
> shortly.  This work will enable parallel and non-conflicting
> consideration of the cert identification and DPV/DPD issues.
> 
> The first working document will be the "core".  It's primary
> purpose is to enable consideration of alternative certificate
> identification mechanisms.  It will propose a ReqCert syntax
> that provides a CHOICE of: legacy-interoperable support for
> 2560's certID; full certificate (including ACs); the
> CertIdWithSignature syntax as recently proposed; and
> issuerAndSerialNumber as recently advocated by Peter Gutman.

I don't think that it will include issuerAndSerialNumber as recently
advocated by Peter Gutman, since this form of identifier is insecure.

> The second working document will be a "Services and Extensions"
> document.  It will include: the basic service of revocation
> checking; 

I don't think that it should include the basic service of revocation 
checking since this belongs to the core document.

> all extensions as currently documented in 2560; 

I don't think that it should include all extensions as currently
documented since they belong to the core document.

> the new proposed CRL Locator extension; 

I don't think that it should include the CRL Locator extension since it 
belongs to the core document.

 > and the definition of DPV  and DPD services as originally proposed.

I am (and have been) quite surprised to see that your proposal to expand 
OCSP v2 functionality is still there, since it has only be advertised to the 
list on November 15, i.e. the Friday before the Atlanta meeting, by Tim in 
the agenda, but not by yourself, prior to the meeting. :-(

> Thus, for OCSPv2, the upcoming DPV/DPD question reduces to whether 
 > or not to retain that related text in the S&E working document.

> Following resolution of the DPV/DPD issue, both these working
> documents will be reintegrated into a final I-D for WG last call
> on what we want to call OCSPv2.

Certainly not !

All people today know that OCSP means "on-line certificate status revocation
checking" as an alternative to CRLs, and not anything else. We are not going 
to change this.

Re-creating confusion once again with DPV or DPD would be very bad.

Everybody is not necessarilly interested by having more functionality.
If someone wants to comply with OCSP v2, it has to comply with the core
functionality. So extensions that are not related to certificate status
revocation checking, should not be placed in the core document.

The core document of OCSP v2 can progress to Draft Standard without
waiting the yet-to-be-written-"Services and Extensions" document.

Denis

> Mike



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAQCQTj19118 for ietf-pkix-bks; Tue, 26 Nov 2002 04:26:29 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAQCQMg19101 for <[e-mail]>; Tue, 26 Nov 2002 04:26:23 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA05510; Tue, 26 Nov 2002 13:27:12 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id NAA12150; Tue, 26 Nov 2002 13:26:22 +0100
Message-ID: <[e-mail]>
Date: Tue, 26 Nov 2002 13:26:14 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>, Peter Gutmann <[e-mail]>
CC: Michael Myers <[e-mail]>, [e-mail]
Subject: Re: OCSP I-Ds going forward
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom, Peter (Gutmann) and the list,

Explanations are provided in the draft (see after).

Peter, this mail also answers to the mail you just posted.

>       Mike:
> 
>       If the purpose of CertIdWithSignature is to extend IssuerSerial in a
> way which is both unambiguous and compact, why are both the signatureValue
> field and tbsCertificateHash present?  Either the signatureValue field or
> the signatureAlgorithm/tbsCertificateHash combination should be unique.
> IMHO there isn't much point in doing a signature validation based on an
> asserted hash without access to the base certificate.
> 
>             Tom Gindin

draft-ietf-pkix-ocspv2&ext-00.txt specifies:

certIdWithSignature is a more compact way to specify *unambiguously* a 
certificate.

    CertIdWithSignature ::= SEQUENCE {
         issuerSerial              IssuerSerial,
         tbsCertificateHash        BIT STRING,
         certSignature             CertSignature
    }

Page 19 contains the following text when using CertIdWithSignature:

     (...)
                                             However, two CAs
     might have the same DN and be certified under different
     branches of a certification tree.

     (...)

     When the OCSP responder does not have access to the data base
     of the issuer, then it may use either *CRLs* or the OCSP
     responder designated by the CA that has issued the certificate.

     When the OCSP responder does *not* have access to the data base
     of the issuers, then it *shall* first make sure that it is the
     right certificate.

     In the general case, this can be done by verifying the
     signature over that certificate.  For doing this, the OCSP
     responder first needs to build a certification path up to one
     of its trust anchors (without necessarily verifying the
     revocation status of the CAs from the path).  The presumed
     issuer key is then used to verify the signature of the
     certificate using both the tbsCertificateHash and the signature
     value. That issuer key will then be used to verify that this
     key is used to sign the *CRL* or the OCSP response, or the
     certificates issued to designate the CRL issuer or the OCSP
     responder.

So the answer to the question "why are both the signatureValue
field and tbsCertificateHash present" is:

It is needed when the OCSP responder is *only* using CRLs in the back 
office. signatureValue field and tbsCertificateHash MUST be both present so 
that the OCSP responder can verify the signature of the certificate. By 
doing this, possible ambiguities between identical CA names vanish: the 
right CA is being used by the fact that two CAs can't have the same issuing 
key.

This means that the OCSP responder must first find out the value of the 
issuing key. If it got the wrong value, the verification of the signature of 
the certificate will fail and the OCSP responder will either look for 
another one, or will say that it does not know.

Now, Peter, I am very sorry that you invested time to write 
draft-ietf-pkix-ocsp-sensible-id-00.txt "Sensible Identifiers for OCSP".

The big mistake is the text that you claim to be extracted from RFC 3369 and 
which is not:

    issuerAndSerialNumber uniquely identifies a certificate by the
    distinguished name of the certificate issuer and an issuer-specific
    certificate serial number [RFC 3369]

The right text is:

10.2.4  IssuerAndSerialNumber

    The IssuerAndSerialNumber type identifies a certificate, and thereby
    an entity and a public key, by the distinguished name of the
    certificate issuer and an issuer-specific certificate serial number.

RFC 3369 does NOT use the wording "uniquely identifies".

IssuerAndSerialNumber used alone does not work.

Now, let me also explain why using certHash alone does not work: it cannot 
work when the OCSP responder is *only* using CRLs, since certHash cannot be 
computed in that case (there is simply no access to the full certificate !).

Since clients are ignorant of the information used by the OCSP responder in 
the back office, they MUST always provide an unambiguous reference.

Your draft is not yet available on the IETF web server, but you will 
probably be a lucky winner anyway, since you might get a PKIX or an IETF 
record: the draft with the shortest life time in the history of PKIX and 
even, maybe, the IETF !  :-)

Now, I concur that these explanations are not straightforward for everybody.

So my question: the security considerations section already contains
the above explanations (and much more !). Are they insufficient ?
If insufficient, I would be happy to improve them. Text proposals are welcome.

Denis



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAQ5EHr28560 for ietf-pkix-bks; Mon, 25 Nov 2002 21:14:17 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAQ5EEg28554 for <[e-mail]>; Mon, 25 Nov 2002 21:14:15 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gAQ5EBNa030310 for <[e-mail]>; Tue, 26 Nov 2002 18:14:11 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA254481 for [e-mail]; Tue, 26 Nov 2002 18:14:10 +1300 (NZDT) (sender [e-mail])
Date: Tue, 26 Nov 2002 18:14:10 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: OCSPv2: It's like asking Eddie the Shipboard Computer for tea!
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Network Working Group                                          P.Gutmann
draft-ietf-pkix-ocsp-sensible-id-00.txt           University of Auckland
Target category: Informational                             November 2002
Expires in 6 months

                   X.509 Internet Public Key Infrastructure
                        Sensible Identifiers for OCSP

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups.  Note that other groups may also
distribute working documents as Internet- Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may
be updated, replaced, or obsoleted by other documents at any time.  It is
inappropriate to use Internet- Drafts as reference material or to cite them
other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Copyright Notice

Copyright (C) The Internet Society (1999-2002).  All Rights Reserved.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in
uppercase, as shown) are to be interpreted as described in [RFC2119].

1. Abstract

Ever since its inception, the OCSP protocol has attracted an array of strange
and bizarre ways of identifying certificates, none of which are even remotely
compatible with existing practice such as issuerAndSerialNumber (CMS and
S/MIME), keyIdentifier (X.509 and PKIX), and certificate "fingerprints" or
"thumbprints" (widely used in practice to uniquely identify certificates).
This document defines a simple, straightforward certificate identifier
mechanism which reflects industry standards and established practice.

The document specifies a single item, SensibleIdentifier.

2. SensibleIdentifier

This OCSP extension is used to identify the certificate being queried in a
simple, straightforward, and standard manner.  When a compliant
implementations encounters a request containing this identifier, it SHOULD
ignore whatever gobbledigook may be present in the OCSP reqCert field (it's
hard to tell what this will be, since it changes at random on every draft) and
use the SensibleIdentifier instead.

id-pkix-ocsp-sensibleIdentifier OBJECT IDENTIFIER ::= { TBD }

SensibleIdentifier ::= CHOICE {
    issuerSerial      IssuerandSerialNumber,
    keyIdentifier [0] KeyIdentifier,
    certificate   [1] Certificate,
    certHash          OCTET STRING
    ...
    }

   issuerAndSerialNumber uniquely identifies a certificate by the
   distinguished name of the certificate issuer and an issuer-specific
   certificate serial number [RFC 3369].  This identifier is widely used in
   CMS and S/MIME, and may be trivially generated from any X.509 certificate.
   
   The keyIdentifier extension provides a means of identifying certificates
   that contain a particular public key [RFC 3280].  This identifier is not
   widely used (issuerAndSerialNumber is used in its place), but is mandatory
   in [RFC 3280] and present in a majority of certificates, so it is included
   here.  Note that this identifier has special semantics, see the Security
   Considerations and [RFC 3280] for more information.

   certificate is the entire certificate.  This identifier type is
   tautological, and may be required in cases where the recipient is expected
   to extract identification information itself.
   
   certHash is an SHA-1 hash of the certificate.  Almost everything implements
   this (variously as "fingerprint" or "thumbprint" or some other name), the
   ID type is widely recognised, and interoperability/correctness checking is
   trivial to achieve.  This type may be used where the overhead of sending
   the full certificate is not desired, for example in crypto tokens or mobile
   devices which don't have the resources to handle a full OCSP implementation
   and which merely populate a pre-generated query with a fresh nonce and
   20-byte certHash.
   
References

[RFC 3369] "Cryptographic Message Syntax (CMS)", Russ Housley, August 2002.

[RFC 3280] "Internet X.509 Public Key Infrastructure: Certificate and CRL
            Profile", RFC 3280, Russ Housley, Warwick Ford, Tim Polk and
            David Solo, April 2002.

3. Security considerations

The semantics for KeyIdentifier are somewhat different from the other
identifier types.  The keyIdentifier uniquely identifies a key rather than a
certificate.  Implementors should be aware that the use of this identifier
will indicate that a certificate for the corresponding key is not-revoked, but
not necessarily the certificate they have.  In other words, it may be used to
determine that the *key* is not-revoked, not the particular certificate.  See
[RFC 3280] for more details on the use of KeyIdentifiers.

The outer DER wrapper of a certificate may use multiple encodings which result
in the same inner content having a different overall hash value.  By varying
the encoding, it's possible to convert a "revoked" into an "unknown" status
(although not a "not-revoked" status).  The same effect may be obtained by
changing a bit or two in other parts of the message or certificate.  In case
this is a security concern (that is, if for some reason the implementation
treats an "unknown" response as "certificate is valid" rather than
"certificate is invalid") then implementations should avoid the use of
certHash.

Author Address

Peter Gutmann
University of Auckland
Private Bag 92019
Auckland, New Zealand

EMail: [e-mail]

Full Copyright Statement

Copyright (C) The Internet Society (1999).  All Rights Reserved.

This document and translations of it may be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist in its
implementation may be prepared, copied, published and distributed, in whole or
in part, without restriction of any kind, provided that the above copyright
notice and this paragraph are included on all such copies and derivative
works.  However, this document itself may not be modified in any way, such as
by removing the copyright notice or references to the Internet Society or
other Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined in the
Internet Standards process must be followed, or as required to translate it
into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by
the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS"
basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS
OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAPNln413161 for ietf-pkix-bks; Mon, 25 Nov 2002 15:47:49 -0800 (PST)
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAPNllg13157 for <[e-mail]>; Mon, 25 Nov 2002 15:47:48 -0800 (PST)
Received: from Chokhani ([12.91.132.17]) by mtiwmhc13.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20021125234737.VMSQ24110.mtiwmhc13.worldnet.att.net@Chokhani>; Mon, 25 Nov 2002 23:47:37 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>, "'Ramsay, Ron'" <[e-mail]>
Cc: "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
Date: Mon, 25 Nov 2002 18:48:14 -0500
Message-ID: <001c01c294dd$1fe68700$11845b0c@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve:

I do not disagree with your conclusions.  But, depending on organization
policy to publish signature certificates or not, depending on different
certificates issued for different certificate policies, and certificates
due to re-key, there could be several certificates for an user entry.

You definitely need to store the latest encryption certificate or all
latest encryption certificates for the various policies.

If you decide to publish signature certificates, you need to store all
unexpired (in order to verify signatures) signature certificates.  These
could be multiple due to re-key and/or due to different certificate
policies.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Steve Hanna
Sent: Monday, November 25, 2002 4:10 PM
To: Ramsay, Ron
Cc: Housley, Russ; [e-mail]
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)



"Ramsay, Ron" wrote:
> The problem with this method is that you must retrieve all the 
> certificates in the entry even if you want only one. You also must 
> scan each certificate looking for the one you want (using your ASN.1 
> tools?). If certificates are stored in subordinate entries, a search 
> will return only those certificates that match the search criteria 
> (doesn't require ASN.1 tools).

How many certificates will one user generally have in their LDAP
directory entry? I suspect that the average will be between one and two
(omitting those users that don't have any certificates). A few users
might have five or more certificates, but I suspect that will be very
rare.

So downloading all the certificates in a user's directory
entry doesn't seem like a big problem to me. Certainly, I
don't see why we need to make big changes to solve it.

As for the need to parse ASN.1, why is that a problem?
If you're going to use the certificates, you generally need
to parse them.

> Also, storing certificates in user entries limits your scope in 
> searching for them. You cannot use auxiliary attributes for 
> serialNumber, etc. You have to use a ceriticate matching rule. I think

> your clients are going to have some trouble with this! However, if you

> are going to recode them to use matching rules, why not also change 
> the base-object search to a whole-subtree search and then it will be 
> transparent to the application whether the certificate is in the entry

> or in a subordinate entry.

When (and how) do you think I will want to search for user certificates?
I expect that the common case will be "get me the S/MIME certs for
[e-mail]", which would be handled by searching on the mail
attribute. Then I could download the certificates from the
userCertificate attribute and see which ones I wanted. In general, it
seems unlikely that I would need to search by a certificate field that
is not in inetOrgPerson.

If this is a solution without a real problem, I think we
all have better things to do.

Thanks,

Steve



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAPNZQ612560 for ietf-pkix-bks; Mon, 25 Nov 2002 15:35:26 -0800 (PST)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAPNZOg12555 for <[e-mail]>; Mon, 25 Nov 2002 15:35:24 -0800 (PST)
Received: from MMyersLapTop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by mail.coastside.net  with SMTP id gAPNZNPP027514; Mon, 25 Nov 2002 15:35:24 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Cc: "Tom Gindin" <[e-mail]>
Subject: RE: OCSP I-Ds going forward
Date: Mon, 25 Nov 2002 15:31:14 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: Tom Gindin [mailto:[e-mail]]
> 
> If the purpose of CertIdWithSignature is to 
> extend IssuerSerial in a way which is both
> unambiguous and compact, why are both the
> signatureValue field and tbsCertificateHash
> present?
> 


Tom,

What would you prefer?

Mike


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAPN73O09976 for ietf-pkix-bks; Mon, 25 Nov 2002 15:07:03 -0800 (PST)
Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id gAPN6vg09967 for <[e-mail]>; Mon, 25 Nov 2002 15:06:58 -0800 (PST)
Received: (qmail 25410 invoked from network); 25 Nov 2002 22:57:55 -0000
Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 25 Nov 2002 22:57:55 -0000
Reply-To: <[e-mail]>
From: "Steven Legg" <[e-mail]>
To: "'Hallvard B Furuseth'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: ;binary migration solution
Date: Tue, 26 Nov 2002 10:05:42 +1100
Message-ID: <005001c294d7$2e2ee560$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

Hallvard B Furuseth wrote:
> - If a search requested an attribute with the "binary" option,
>   it is added to that attribute in the search result (if that
>   attribute is returned).

It is all well and good to propose that ";binary" be in the returned
attribute description if and only if ";binary" is in the original request
but what if the original request was for all user attributes (i.e. "*") ?
This facility is being ignored in all this discussion about ";binary".

As things stand today, we have a significant body of LDAPv3 compliant
implementations that expect to get back "userCertificate;binary" from
a request for "*". In any phased migration away from the use of ";binary",
at some point compliant directory servers will have to change from returning
userCertificate;binary to just returning userCertificate and this will
break currently conformant clients.

David Chadwick is the only one who has proposed a safe way to
effect a migration (using controls). However, since such a migration
delivers no practical benefit to conformant PKI clients (just a different
way of asking for the same thing), I think the pain of migration is
not justified.

Regards,
Steven



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAPMZmd08597 for ietf-pkix-bks; Mon, 25 Nov 2002 14:35:48 -0800 (PST)
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAPMZdg08593 for <[e-mail]>; Mon, 25 Nov 2002 14:35:40 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gAPMZVRG077330; Mon, 25 Nov 2002 17:35:31 -0500
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAPMZNjo027732; Mon, 25 Nov 2002 17:35:27 -0500
Importance: Normal
Sensitivity: 
Subject: Re: OCSP I-Ds going forward
To: "Michael Myers" <[e-mail]>
Cc: <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 25 Nov 2002 17:35:08 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11  |July 29, 2002) at 11/25/2002 05:35:28 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Mike:

      If the purpose of CertIdWithSignature is to extend IssuerSerial in a
way which is both unambiguous and compact, why are both the signatureValue
field and tbsCertificateHash present?  Either the signatureValue field or
the signatureAlgorithm/tbsCertificateHash combination should be unique.
IMHO there isn't much point in doing a signature validation based on an
asserted hash without access to the base certificate.

            Tom Gindin

"Michael Myers" <[e-mail]>@mail.imc.org on 11/25/2002 01:51:41
PM

Sent by:    [e-mail]


To:    <[e-mail]>
cc:
Subject:    OCSP I-Ds going forward



FYI all,

As many of you know, in March 2001 Carlisle, Stephen and I
proposed two OCSP-based services.  We called them Delegated Path
Validation (DPV) and Delegated Path Discovery (DPD).  That I-D
was allowed to lapse pending WG resolution of the DPV/DPD
requirements.  In Atlanta, I committed to the chairs to refresh
that I-D.

However, that I-D also addressed the separable need to expand
the certificate identification mechanisms.  This changed changed
core syntax, hence a v2 version number (i.e. OCSPv2).  To
complicate matters further, given that the original OCSPv2 I-D
was allowed to lapse, the certID/v2 issue has recently been
refreshed with yet another OCSP-based I-D that once more speaks
to v2-ness but also introduced yet another proposed
extension--the CRL Locator.

So to simplify matters for all of those in the WG that continue
to have the patience to review and comment on these things, two
new, unifying I-Ds are being produced and will be available
shortly.  This work will enable parallel and non-conflicting
consideration of the cert identification and DPV/DPD issues.

The first working document will be the "core".  It's primary
purpose is to enable consideration of alternative certificate
identification mechanisms.  It will propose a ReqCert syntax
that provides a CHOICE of: legacy-interoperable support for
2560's certID; full certificate (including ACs); the
CertIdWithSignature syntax as recently proposed; and
issuerAndSerialNumber as recently advocated by Peter Gutman.

The second working document will be a "Services and Extensions"
document.  It will include: the basic service of revocation
checking; all extensions as currently documented in 2560; the
new proposed CRL Locator extension; and the definition of DPV
and DPD services as originally proposed.  Thus, for OCSPv2, the
upcoming DPV/DPD question reduces to whether or not to retain
that related text in the S&E working document.

Following resolution of the DPV/DPD issue, both these working
documents will be reintegrated into a final I-D for WG last call
on what we want to call OCSPv2.

Mike





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAPMYAO08573 for ietf-pkix-bks; Mon, 25 Nov 2002 14:34:10 -0800 (PST)
Received: from junker.stroeder.com (krl9-d9bb4efb.pool.mediaWays.net [217.187.78.251]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAPMY3g08564 for <[e-mail]>; Mon, 25 Nov 2002 14:34:04 -0800 (PST)
Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id AC89E1573CC; Mon, 25 Nov 2002 23:34:01 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 25 Nov 2002 23:34:00 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Steve Hanna <[e-mail]>
Cc: [e-mail]
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
References: <[e-mail]> <[e-mail]>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve Hanna wrote:
> When (and how) do you think I will want to search for user
> certificates? I expect that the common case will be "get
> me the S/MIME certs for [e-mail]",

Steve, there sure are more use-cases.

Hint: You might wanna search for other types of certificates. And not every 
component doing the LDAP search does the ASN.1 parsing as well.

I support the proposal made by Peter Gietz since it seems like an fairly 
easy solution to me solving some real-world problems.

Sorry, unfortunately I have currently no time to wade through all the 
responses in this thread piling in my Inbox.

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAPLB7j06220 for ietf-pkix-bks; Mon, 25 Nov 2002 13:11:07 -0800 (PST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAPLB4g06216 for <[e-mail]>; Mon, 25 Nov 2002 13:11:05 -0800 (PST)
Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09017; Mon, 25 Nov 2002 14:11:04 -0700 (MST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPLB49x006729; Mon, 25 Nov 2002 16:11:04 -0500 (EST)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.11.6+Sun/8.9.0) with ESMTP id gAPLB3621590; Mon, 25 Nov 2002 16:11:03 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 25 Nov 2002 16:10:15 -0500
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ramsay, Ron" <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, [e-mail]
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Ramsay, Ron" wrote:
> The problem with this method is that you must retrieve all the
> certificates in the entry even if you want only one. You also
> must scan each certificate looking for the one you want (using
> your ASN.1 tools?). If certificates are stored in subordinate
> entries, a search will return only those certificates that match
> the search criteria (doesn't require ASN.1 tools).

How many certificates will one user generally have in their
LDAP directory entry? I suspect that the average will be
between one and two (omitting those users that don't have
any certificates). A few users might have five or more
certificates, but I suspect that will be very rare.

So downloading all the certificates in a user's directory
entry doesn't seem like a big problem to me. Certainly, I
don't see why we need to make big changes to solve it.

As for the need to parse ASN.1, why is that a problem?
If you're going to use the certificates, you generally need
to parse them.

> Also, storing certificates in user entries limits your scope
> in searching for them. You cannot use auxiliary attributes for
> serialNumber, etc. You have to use a ceriticate matching rule.
> I think your clients are going to have some trouble with this!
> However, if you are going to recode them to use matching rules,
> why not also change the base-object search to a whole-subtree
> search and then it will be transparent to the application
> whether the certificate is in the entry or in a subordinate entry.

When (and how) do you think I will want to search for user
certificates? I expect that the common case will be "get
me the S/MIME certs for [e-mail]", which would be
handled by searching on the mail attribute. Then I could
download the certificates from the userCertificate attribute
and see which ones I wanted. In general, it seems unlikely that
I would need to search by a certificate field that is not
in inetOrgPerson.

If this is a solution without a real problem, I think we
all have better things to do.

Thanks,

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAPL22T04900 for ietf-pkix-bks; Mon, 25 Nov 2002 13:02:02 -0800 (PST)
Received: from mtiwmhc14.worldnet.att.net (mtiwmhc14.worldnet.att.net [204.127.131.114]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAPL1xg04889 for <[e-mail]>; Mon, 25 Nov 2002 13:01:59 -0800 (PST)
Received: from Chokhani ([12.91.130.220]) by mtiwmhc14.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20021125210142.UZGB21264.mtiwmhc14.worldnet.att.net@Chokhani>; Mon, 25 Nov 2002 21:01:42 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Khaja Ahmed'" <[e-mail]>, "'Terwilliger, Ann'" <[e-mail]>, <[e-mail]>
Subject: RE: Update of RFC 2527 - opposed
Date: Mon, 25 Nov 2002 16:02:19 -0500
Message-ID: <005701c294c5$f1e28e60$dc825b0c@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Khaja:

Please see my responses in-line in [].

-----Original Message-----
From: Khaja Ahmed [mailto:[e-mail]] 
Sent: Monday, November 25, 2002 12:35 PM
To: Santosh Chokhani; 'Terwilliger, Ann'; [e-mail]
Subject: RE: Update of RFC 2527 - opposed


Santosh,

I think my point is being colored with points made by others.

I have not said or implied that 2527 is not / has not been useful.  It
has
been quite useful to me.   Clearly it has been useful to many others.
My
point is just that there are some uses / models of PKI which are
substantially different from that discussed in 2527.

[Santosh Says: When we drafted 2527 and its successor, we were
intentionally model and usage neutral.  Based on your comment, I looked
at the document again.  I did not find any constraints on the usage or
model.  VeriSign folks have used this framework for commercial offering
and small and large Enterprises have used the model for their Enterprise
PKI.  If you point out any limitations or constraints that we have
imposed, the authors will be glad to consider removing those, if
appropriate.  Again, any time, specific actionable comments on a
document are helpful.  That becomes even more imperative so late in the
game when the document should have been published a year ago and just
fell through the cracks due to some snafu] 

Ill try to address your question on what changes are needed in the
document to cater to this need.  I don't think this is a matter of any
particular change to any particular section.  It isn't even just that
certificate subscribers are customers or employees.  It is (or so it
seems to me) a fundamentally different way of using PKI and I am trying
to figure out how we can have a document analogous to 2527 to help with
that.

The fact that subscribers are employees or customers is only one part of
the difference.  In the case of employee-subscriber scenario, depending
on the application and role of employee,  the certificate issuer, user
and subscriber may be one legal entity.  However, the particular case I
am thinking of is one in which the CA is the sole relying party.  I have
seen this in at least two reasonable sized applications.

In the canonical version of this model, a business has an application
that is used by it's customers.  The business issues certificates (and
perhaps
SmartCards) to these customers.  These tokens are used to authenticate
the customers when they connect to the service provided by the business.

What would otherwise be a CP simply does not exist in this scenario.
Certainly not in the shape that the 2527 frame work envisions it.  Why
would one be needed?

[Santosh Says: It is up to the business whether they have a CP or not.
If they assert a policy OID in the certificate, they should have a
policy.  The framework makes this clear that if some sections are not
applicable, you can claim no stipulation.  However, I assume that the
business will state how they perform initial registration of the
customers, how they revoke customers, how customers should care for
their token, etc. etc.  All of these should be in a CP.  If the business
decides to run a PKI without any policy and not assert policy OID, I do
not think the framework says you must have one.  But, in this case, I
see a value to addressing some of the issues that the customer and
business will be concerned with and the 2527 framework covers them]

The CPS does exist but in a distributed fashion.  It is scattered
between application standards, operations guide for the application (of
which PKI is simply seen as the auth/security component), the customer
registration process and the customer agreement.  There is no distinct
document called the CPS.  This makes part of the CPS very private
(operations manual) and parts of it very public (customer agreement).

[Santosh Says: I am not sure what to make of your jumping from CP to
CPS.  In either case, be it a CP or CPS, it is always distributed.  I
have applied or advised several Enterprises (private and public) and
commercial service offerers.  Invariably, the components are
distributed, typically: one or more CA (with some trust relationship
among them), RAs, trusted agents, repositories, relying parties,
subscribers and their tokens.  Generally, these components are
physically and logically distributed and are under administrative
control of multiple parties.  I have not seen any problem in applying
the framework to them.  It is upto you whether to have one CP and one
CPS or multiple.  Typically, for compliance audit reasons, we have used
multiple CPS.  But, I know one customer uses one CPS.]

In another application under development, in addition to the CA relying
on subscribers certificates, the subscribers rely on certificates of the
service.  Subscribers do not have to rely on each others certificates.
The CA organization is a sort of a trusted communication hub.  All
customers only trust assertions signed by the hub.  The hub needs to
have subscribers make signed (NR) assertions to it.  To some, these are
critically important applications and uses and need to be put together.

If you feel that the 2527 adequately address this do let me know.  I
realize also that you may feel that this is too specific or non standard
a matter for the document to address.  It is also likely that the list
will feel that this model is not in scope and need not be addressed at
all.  All I would say that that this is very much a needed solution and
each implementation is cutting it's own path now.  Even a BCP would be
helpful at this point.

[Santosh Says: I do not feel these are too specific.  The RFC does not
say that a CA can or can not be a subscriber or replying party.  I think
RFC accommodates these models.]

Khaja

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Santosh Chokhani
Sent: Thursday, November 21, 2002 4:23 AM
To: 'Khaja Ahmed'; 'Terwilliger, Ann'; [e-mail]
Subject: RE: Update of RFC 2527 - opposed



Khaja:

You state:

"It is not very helpful in setting up a CA used internally by an
organization, or one setup for use by an organization to secure
communication with it's employees or customers.  Perhaps that should be
a separate document.  If there are any updates to the RFC I hope these
distinctions will be properly dealt with."

Can you elaborate what needs to be changed in the document for dealing
with employees and customers?

I would like to know more of technical and policy aspects as opposed to
legal aspects and how old Section 2 and new Section 9 needs to address
employees and customers since the whole thread began with the claim that
we do not want to make this too much of a legal document.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Khaja Ahmed
Sent: Thursday, November 21, 2002 2:03 AM
To: Terwilliger, Ann; [e-mail]
Subject: RE: Update of RFC 2527 - opposed



Ann,

2527 does seem to be built on the assumption that the CA, subscribers
and relying parties are distinct legal entities.  This seemed clear to
me although, to the best of my recollection, this is not explicitly
stated anywhere.  (Please let me know if I am incorrect about either of
the two foregoing points.)  As Mack has pointed out, it is increasingly
common to have CA's setup for internal use by an organization or for a
closed community like an organization and it's customers.  For these
situation 2527 can be problematic in the hands of auditors (internal or
external) and even implementers who do not understand this. It is not
always/fully appreciated that this is an informational RFC.

Your point about it being helpful as a checklist is very valid for
public CAs. It is not very helpful in setting up a CA used internally by
an organization, or one setup for use by an organization to secure
communication with it's employees or customers.  Perhaps that should be
a separate document.  If there are any updates to the RFC I hope these
distinctions will be properly dealt with.

Khaja

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Terwilliger, Ann
Sent: Wednesday, November 20, 2002 3:50 PM
To: [e-mail]
Subject: RE: Update of RFC 2527 - opposed



Another country is heard from......

Like Mack, I do not believe that automated review of a CP or CPS is
practical (even though it might be desirable).  I also agree that in
many, if not most, instances the CPS will not be made public.  However,
I have to disagree with his conclusion that RFC 2527 is not relevant.

RFC 2527 does provide a checklist for what areas need to be covered in
establishing and operating a CA.  The fact that some of the questions
are not as relevant today as they might have been when it was first
drafted only reinforces the fact that it should be updated to reflect
current conditions. There are other standards that address CA operation
(e.g., X9.79, WebTrust Audit for CA, the ABA document) but virtually all
reference RFC 2527.

I would like to believe that all CA operators are knowledgeable about
PKI and adhere to best practices for operating their CA.  However, that
is a fairy tale--something on a par with the tooth fairy--and there
needs to be some process to ensure that the CA has established good
security practices and follows them.  Hence audits become necessary.

Audits by their very nature are comparing something against a checklist
or standard.  Auditors who are familiar with PKI are capable of adhering
to the spirit of the standard rather than the exact letter if parts of a
standard do not apply.  Unfortunately auditors who are not familiar with
PKI may perform audits more or less by rote.  To me this makes it more
important, not less so, that we continue to update RFC 2527.


-----Original Message-----
From: Hicks, Mack [mailto:[e-mail]]
Sent: Wednesday, November 20, 2002 1:10 PM
To: [e-mail]
Subject: Update of RFC 2527 - opposed



I have not posted on this list for some time, lurking has been fun
though. I will say something that some might consider radical.

I thought you might like to know how some of the business world is
looking at RFC 2527 and its impact on the PKI business.

RFC 2527 is being used as a template and checklist by auditors and
associations to perform reviews on certificate authorities. Each entry
and topic of RFC 2527 must be covered by the CA or one gets an "audit
exception" or operations questions. This is done as a rote exercise.
Back when CAs were new, the checklist made sense - now some of the
questions and sections is RFC 2527 are not as relevant to all CAs.

I know of no use of the certificate policy in a business application;
the policy is only there to tell any relying party that they should have
a contract with someone before trusting this certificate. The meaning,
impact, legality, effectiveness, application, etc. of a certificate is
addressed in contract (and subject to contract law - as I understand
it). There is no detailed policy in the CP anymore.

The practice among most banks I talk to is that the certificate practice
statement (CPS) is an internal document about the operation of the CA
and related software (OCSP, CRL, LDAP); the CPS is not made public.
Therefore the original goal of automated or assisted examination of a CP
and CPS by a relying party is thwarted. (I supported the automation
goal, but it is not
achievable.)

It is useful that a certificate has a reference to a policy - but the
construction and content of that policy is no longer relevant in the
businesses that I see.  There is no use to a CPS except as an internal
checklist on CA construction and operation and acts as a mill stone
around the neck of CA operators - a barrier to entry into PKI. Therefore
RFC 2527 is purely informational to constructing a CA; I would prefer
that it move toward elimination as standard.



Mack Hicks, SVP
Bank of America  760-318-9345



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAPKELQ02382 for ietf-pkix-bks; Mon, 25 Nov 2002 12:14:21 -0800 (PST)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAPKEIg02378 for <[e-mail]>; Mon, 25 Nov 2002 12:14:19 -0800 (PST)
Received: from MMyersLapTop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by mail.coastside.net  with SMTP id gAPKEIPP025707 for <[e-mail]>; Mon, 25 Nov 2002 12:14:18 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: OCSP for DPV/DPD
Date: Mon, 25 Nov 2002 12:10:09 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I believed that the "battle" with OCSPv2 was over
> since, we (Ambarish, you and me) agreed to restrict
> its use to the checking of the revocation status
> of a certificate, but in no way to validate a
> certificate against a policy.
>
> Now, I can see that you do not agree any more with
> that position.


Denis,

I have never agreed to this structural limitation in OCSP scope.
Rather, I took and continue to accomodate a phased approach. Had
you been in Atlanta you would have heard me repeat myself for
the umpteenth time on this.  My response to you is essentially
the "OCSP for DPV/DPD" pitch I gave in Atlanta, so here it is in
amended form for those WG members unable to attend.

I'm doing so with a view towards the upcoming DPV/DPD vote as
Peter Sylvester did so recently for DVCS.  I respectfully
suggest you do likewise regarding CVP rather than to continue to
argue this point.  The outcome of Atlanta was clear.  We have
argued enough.  It is time to put this issue to the list.

[BEGIN PITCH]

What we now refer to as DPV was the original intent of the I-D
that ultimately became RFC 2560. That, and doing something about
CRL latency and the diversity of CRL retrieval mechanisms.
However, in the formative phases of RFC 2560, the needs of the
financial community were successfully persuasive in deferring
action on path validation due to its rathole potential in favor
of at least addressing the more easily resolvable revocation
issues.  A middle ground was achieved via the use of service and
extension hooks, these being:

1. requestExtensions in TBSRequest syntax;

2. singleRequestExtensions in Request syntax;

3. responseType in Response syntax;

4. the name id-pkix-ocsp-basic as a response type;

5. the AcceptableResponses extension which includes
   in its definition the text: "An OCSP client MAY
   wish to specify the kinds of response types it
   understands."; and

6. responseExtensions in Response syntax.

One can also see evidence of the original intent throughout
2560's text.  For example:

"There is one basic type of OCSP response that MUST be
supported by all OCSP servers and clients. The rest of
this section pertains only to this basic response type."

PKIX succeeded with RFC 2560 in establishing a framework for
online certificate status services.  There now exists a critical
mass of deployed and supported OCSP servers and OCSP-enabled
clients.  It's time we go back and finish the job of engineering
a DNS for PKI.

[END PITCH]


Mike



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAPItsk26836 for ietf-pkix-bks; Mon, 25 Nov 2002 10:55:54 -0800 (PST)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAPItpg26831 for <[e-mail]>; Mon, 25 Nov 2002 10:55:51 -0800 (PST)
Received: from MMyersLapTop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by mail.coastside.net  with SMTP id gAPItnPP012199 for <[e-mail]>; Mon, 25 Nov 2002 10:55:50 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: OCSP I-Ds going forward
Date: Mon, 25 Nov 2002 10:51:41 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <002701c29492$fffe57f0$6801a8c0@SJOSEPH>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

FYI all,

As many of you know, in March 2001 Carlisle, Stephen and I
proposed two OCSP-based services.  We called them Delegated Path
Validation (DPV) and Delegated Path Discovery (DPD).  That I-D
was allowed to lapse pending WG resolution of the DPV/DPD
requirements.  In Atlanta, I committed to the chairs to refresh
that I-D.

However, that I-D also addressed the separable need to expand
the certificate identification mechanisms.  This changed changed
core syntax, hence a v2 version number (i.e. OCSPv2).  To
complicate matters further, given that the original OCSPv2 I-D
was allowed to lapse, the certID/v2 issue has recently been
refreshed with yet another OCSP-based I-D that once more speaks
to v2-ness but also introduced yet another proposed
extension--the CRL Locator.

So to simplify matters for all of those in the WG that continue
to have the patience to review and comment on these things, two
new, unifying I-Ds are being produced and will be available
shortly.  This work will enable parallel and non-conflicting
consideration of the cert identification and DPV/DPD issues.

The first working document will be the "core".  It's primary
purpose is to enable consideration of alternative certificate
identification mechanisms.  It will propose a ReqCert syntax
that provides a CHOICE of: legacy-interoperable support for
2560's certID; full certificate (including ACs); the
CertIdWithSignature syntax as recently proposed; and
issuerAndSerialNumber as recently advocated by Peter Gutman.

The second working document will be a "Services and Extensions"
document.  It will include: the basic service of revocation
checking; all extensions as currently documented in 2560; the
new proposed CRL Locator extension; and the definition of DPV
and DPD services as originally proposed.  Thus, for OCSPv2, the
upcoming DPV/DPD question reduces to whether or not to retain
that related text in the S&E working document.

Following resolution of the DPV/DPD issue, both these working
documents will be reintegrated into a final I-D for WG last call
on what we want to call OCSPv2.

Mike







Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAPHmp222145 for ietf-pkix-bks; Mon, 25 Nov 2002 09:48:51 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAPHmmg22137 for <[e-mail]>; Mon, 25 Nov 2002 09:48:49 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12631; Mon, 25 Nov 2002 12:46:07 -0500 (EST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: Internet X.509 Public Key Infrastructure Permanent  Identifier to Proposed Standard
Reply-to: [e-mail]
Date: Mon, 25 Nov 2002 12:46:07 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the Public-Key Infrastructure 
(X.509) Working Group to consider Internet X.509 Public Key 
Infrastructure Permanent Identifier <draft-ietf-pkix-pi-05.txt> as a 
Proposed Standard.  

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
[e-mail] or [e-mail] mailing lists by 2002-12-9.

Files can be obtained via 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-05.txt





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAPHZMV20389 for ietf-pkix-bks; Mon, 25 Nov 2002 09:35:22 -0800 (PST)
Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAPHZFg20381 for <[e-mail]>; Mon, 25 Nov 2002 09:35:15 -0800 (PST)
Received: from sesione (12-230-105-28.client.attbi.com[12.230.105.28]) by rwcrmhc53.attbi.com (rwcrmhc53) with SMTP id <20021125173455053004ap4je>; Mon, 25 Nov 2002 17:34:56 +0000
From: "Khaja Ahmed" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "'Terwilliger, Ann'" <[e-mail]>, <[e-mail]>
Subject: RE: Update of RFC 2527 - opposed
Date: Mon, 25 Nov 2002 09:34:45 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <000b01c29158$c85a0ed0$3300a8c0@Chokhani>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

I think my point is being colored with points made by others.

I have not said or implied that 2527 is not / has not been useful.  It has
been quite useful to me.   Clearly it has been useful to many others.  My
point is just that there are some uses / models of PKI which are
substantially different from that discussed in 2527.

Ill try to address your question on what changes are needed in the document
to cater to this need.  I don't think this is a matter of any particular
change to any particular section.  It isn't even just that certificate
subscribers are customers or employees.  It is (or so it seems to me) a
fundamentally different way of using PKI and I am trying to figure out how
we can have a document analogous to 2527 to help with that.

The fact that subscribers are employees or customers is only one part of the
difference.  In the case of employee-subscriber scenario, depending on the
application and role of employee,  the certificate issuer, user and
subscriber may be one legal entity.  However, the particular case I am
thinking of is one in which the CA is the sole relying party.  I have seen
this in at least two reasonable sized applications.

In the canonical version of this model, a business has an application that
is used by it's customers.  The business issues certificates (and perhaps
SmartCards) to these customers.  These tokens are used to authenticate the
customers when they connect to the service provided by the business.

What would otherwise be a CP simply does not exist in this scenario.
Certainly not in the shape that the 2527 frame work envisions it.  Why would
one be needed?

The CPS does exist but in a distributed fashion.  It is scattered between
application standards, operations guide for the application (of which PKI is
simply seen as the auth/security component), the customer registration
process and the customer agreement.  There is no distinct document called
the CPS.  This makes part of the CPS very private (operations manual) and
parts of it very public (customer agreement).

In another application under development, in addition to the CA relying on
subscribers certificates, the subscribers rely on certificates of the
service.  Subscribers do not have to rely on each others certificates.  The
CA organization is a sort of a trusted communication hub.  All customers
only trust assertions signed by the hub.  The hub needs to have subscribers
make signed (NR) assertions to it.  To some, these are critically important
applications and uses and need to be put together.

If you feel that the 2527 adequately address this do let me know.  I realize
also that you may feel that this is too specific or non standard a matter
for the document to address.  It is also likely that the list will feel that
this model is not in scope and need not be addressed at all.  All I would
say that that this is very much a needed solution and each implementation is
cutting it's own path now.  Even a BCP would be helpful at this point.


Khaja

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Santosh Chokhani
Sent: Thursday, November 21, 2002 4:23 AM
To: 'Khaja Ahmed'; 'Terwilliger, Ann'; [e-mail]
Subject: RE: Update of RFC 2527 - opposed



Khaja:

You state:

"It is not very helpful in setting up a CA used internally by an
organization, or one setup for use by an organization to secure
communication with it's employees or customers.  Perhaps that should be
a separate document.  If there are any updates to the RFC I hope these
distinctions will be properly dealt with."

Can you elaborate what needs to be changed in the document for dealing
with employees and customers?

I would like to know more of technical and policy aspects as opposed to
legal aspects and how old Section 2 and new Section 9 needs to address
employees and customers since the whole thread began with the claim that
we do not want to make this too much of a legal document.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Khaja Ahmed
Sent: Thursday, November 21, 2002 2:03 AM
To: Terwilliger, Ann; [e-mail]
Subject: RE: Update of RFC 2527 - opposed



Ann,

2527 does seem to be built on the assumption that the CA, subscribers
and relying parties are distinct legal entities.  This seemed clear to
me although, to the best of my recollection, this is not explicitly
stated anywhere.  (Please let me know if I am incorrect about either of
the two foregoing points.)  As Mack has pointed out, it is increasingly
common to have CA's setup for internal use by an organization or for a
closed community like an organization and it's customers.  For these
situation 2527 can be problematic in the hands of auditors (internal or
external) and even implementers who do not understand this. It is not
always/fully appreciated that this is an informational RFC.

Your point about it being helpful as a checklist is very valid for
public CAs. It is not very helpful in setting up a CA used internally by
an organization, or one setup for use by an organization to secure
communication with it's employees or customers.  Perhaps that should be
a separate document.  If there are any updates to the RFC I hope these
distinctions will be properly dealt with.

Khaja

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Terwilliger, Ann
Sent: Wednesday, November 20, 2002 3:50 PM
To: [e-mail]
Subject: RE: Update of RFC 2527 - opposed



Another country is heard from......

Like Mack, I do not believe that automated review of a CP or CPS is
practical (even though it might be desirable).  I also agree that in
many, if not most, instances the CPS will not be made public.  However,
I have to disagree with his conclusion that RFC 2527 is not relevant.

RFC 2527 does provide a checklist for what areas need to be covered in
establishing and operating a CA.  The fact that some of the questions
are not as relevant today as they might have been when it was first
drafted only reinforces the fact that it should be updated to reflect
current conditions. There are other standards that address CA operation
(e.g., X9.79, WebTrust Audit for CA, the ABA document) but virtually all
reference RFC 2527.

I would like to believe that all CA operators are knowledgeable about
PKI and adhere to best practices for operating their CA.  However, that
is a fairy tale--something on a par with the tooth fairy--and there
needs to be some process to ensure that the CA has established good
security practices and follows them.  Hence audits become necessary.

Audits by their very nature are comparing something against a checklist
or standard.  Auditors who are familiar with PKI are capable of adhering
to the spirit of the standard rather than the exact letter if parts of a
standard do not apply.  Unfortunately auditors who are not familiar with
PKI may perform audits more or less by rote.  To me this makes it more
important, not less so, that we continue to update RFC 2527.


-----Original Message-----
From: Hicks, Mack [mailto:[e-mail]]
Sent: Wednesday, November 20, 2002 1:10 PM
To: [e-mail]
Subject: Update of RFC 2527 - opposed



I have not posted on this list for some time, lurking has been fun
though. I will say something that some might consider radical.

I thought you might like to know how some of the business world is
looking at RFC 2527 and its impact on the PKI business.

RFC 2527 is being used as a template and checklist by auditors and
associations to perform reviews on certificate authorities. Each entry
and topic of RFC 2527 must be covered by the CA or one gets an "audit
exception" or operations questions. This is done as a rote exercise.
Back when CAs were new, the checklist made sense - now some of the
questions and sections is RFC 2527 are not as relevant to all CAs.

I know of no use of the certificate policy in a business application;
the policy is only there to tell any relying party that they should have
a contract with someone before trusting this certificate. The meaning,
impact, legality, effectiveness, application, etc. of a certificate is
addressed in contract (and subject to contract law - as I understand
it). There is no detailed policy in the CP anymore.

The practice among most banks I talk to is that the certificate practice
statement (CPS) is an internal document about the operation of the CA
and related software (OCSP, CRL, LDAP); the CPS is not made public.
Therefore the original goal of automated or assisted examination of a CP
and CPS by a relying party is thwarted. (I supported the automation
goal, but it is not
achievable.)

It is useful that a certificate has a reference to a policy - but the
construction and content of that policy is no longer relevant in the
businesses that I see.  There is no use to a CPS except as an internal
checklist on CA construction and operation and acts as a mill stone
around the neck of CA operators - a barrier to entry into PKI.
Therefore RFC 2527 is purely informational to constructing a CA; I would
prefer that it move toward elimination as standard.



Mack Hicks, SVP
Bank of America  760-318-9345



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAPF0Fo10445 for ietf-pkix-bks; Mon, 25 Nov 2002 07:00:15 -0800 (PST)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAPF08g10436 for <[e-mail]>; Mon, 25 Nov 2002 07:00:09 -0800 (PST)
Received: from SJOSEPH (pcp237593pcs.elictc01.md.comcast.net [68.55.160.224]) by mtaout01.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) with SMTP id <[e-mail]> for [e-mail]; Mon, 25 Nov 2002 09:58:14 -0500 (EST)
Date: Mon, 25 Nov 2002 09:57:39 -0500
From: Al Arsenault <[e-mail]>
Subject: Re: Update of RFC 2527 - opposed
To: Roger Younglove <[e-mail]>, [e-mail]
Message-id: <002701c29492$fffe57f0$6801a8c0@SJOSEPH>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: multipart/alternative; boundary="Boundary_(ID_4gzGrMu354h8Z8+2fcYKEA)"
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

--Boundary_(ID_4gzGrMu354h8Z8+2fcYKEA)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

RE: Update of RFC 2527 - opposedA minor point:  I realize that the =
"State of Washington's requirements" was most likely meant as an example =
here, but I want to make it explicit.  The audit must be done following =
the requirements of whatever authority is controlling.  For example, a =
CA in Hong Kong must be audited to the requirements of the HKSAR =
Electronic Transactions Ordinance (ETO); they really don't give a rat's =
rear end about the "State of Washington".  :-) I suspect other =
jurisdictions and/or business regulators have similar views.

(Also:  I haven't looked at the Washington requirements in a few years, =
but in about 1998 or 1999 they had a couple of things I considered =
silly.  Is there a handy URL I can take a quick look at? Thanks.)

            Al Arsenault
            Chief Security Architect
            Diversinet Corp.


  ----- Original Message -----=20
  From: Roger Younglove=20
  To: [e-mail]=20
  Sent: Friday, November 22, 2002 9:10 AM
  Subject: RE: Update of RFC 2527 - opposed


  Well said Richard. Certification of a PKI should be done by an =
qualified auditor following  the State of Washington's requirements. =
There must be a CP and CPS in order to audit and certify a PKI.

  =20

  Roger Younglove, CISSP

  =20

  =20

  -----Original Message-----
  From: Guida, Richard [JJCUS] [mailto:[e-mail]]=20
  Sent: Friday, November 22, 2002 5:20 AM
  To: Terwilliger, Ann; [e-mail]
  Subject: RE: Update of RFC 2527 - opposed

  =20

  I strongly agree with Ann and separate comments made by Dave =
Fillingham.  At Johnson & Johnson we have both a CP and a CPS to 2527, =
and intend to use those not only internally (as we are already doing for =
our PKI which is built and run internally) but also, when the time =
comes, to interoperate externally.  Trying to negotiate external =
interoperability without a CP/CPS to a common standard would be very =
cumbersome at best and is unlikely to be satisfying.  I fully agree that =
any external interoperability will require a contract; but the trick =
will be negotiating that contract and deciding what to include in it.  =
One might wind up with a contract that looks like a CP - in which case, =
why not start with the CP and include it as an addendum to the contract? =
 In essence, the CP to 2527 becomes standard boilerplate for a contract =
where you wish to have someone else accept your certificates.  Also note =
that under a confidentiality agreement, I would expect to have to expose =
the CPS as well to the party with whom we wish to contract - to give =
them assurance that we are indeed running our PKI as our CP prescribes.

  But even if we were never to interoperate (i.e., never ask anyone else =
to accept our certificates, or seek to accept others' certificates =
ourselves), the CP and CPS provide a comprehensive framework for running =
a PKI and are invaluable for that purpose alone.  I do not accept the =
argument that what an unknowledgeable auditor may or may not do should =
dictate what is appropriate, we should proceed to do what is sensible =
and then defend that and, where necessary, educate the auditor to =
understand and appreciate that.  Relationships with auditors should be =
at arms length - they do not have to be adversarial.  My 1 1/2 cents =
worth.

  =20

  Richard A. Guida=20
  Director, Information Security (Medical Devices and Diagnostics)=20

  Johnson & Johnson=20
  One J&J Plaza, Room WH6132=20
  New Brunswick, New Jersey  08933=20

  E-mail: [e-mail]=20
  Office:  732 524 3785=20

  =20

  -----Original Message-----=20
  From: Terwilliger, Ann [mailto:[e-mail]]=20
  Sent: Wednesday, November 20, 2002 6:50 PM=20
  To: [e-mail]=20
  Subject: RE: Update of RFC 2527 - opposed=20

  =20

  Another country is heard from......=20

  Like Mack, I do not believe that automated review of a CP or CPS is=20
  practical (even though it might be desirable).  I also agree that in =
many,=20
  if not most, instances the CPS will not be made public.  However, I =
have to=20
  disagree with his conclusion that RFC 2527 is not relevant.=20

  RFC 2527 does provide a checklist for what areas need to be covered in =

  establishing and operating a CA.  The fact that some of the questions =
are=20
  not as relevant today as they might have been when it was first =
drafted only=20
  reinforces the fact that it should be updated to reflect current =
conditions.=20
  There are other standards that address CA operation (e.g., X9.79, =
WebTrust=20
  Audit for CA, the ABA document) but virtually all reference RFC 2527.=20

  I would like to believe that all CA operators are knowledgeable about =
PKI=20
  and adhere to best practices for operating their CA.  However, that is =
a=20
  fairy tale--something on a par with the tooth fairy--and there needs =
to be=20
  some process to ensure that the CA has established good security =
practices=20
  and follows them.  Hence audits become necessary.   =20

  Audits by their very nature are comparing something against a =
checklist or=20
  standard.  Auditors who are familiar with PKI are capable of adhering =
to the=20
  spirit of the standard rather than the exact letter if parts of a =
standard=20
  do not apply.  Unfortunately auditors who are not familiar with PKI =
may=20
  perform audits more or less by rote.  To me this makes it more =
important,=20
  not less so, that we continue to update RFC 2527. =20
   =20

  -----Original Message-----=20
  From: Hicks, Mack [mailto:[e-mail]]=20
  Sent: Wednesday, November 20, 2002 1:10 PM=20
  To: [e-mail]=20
  Subject: Update of RFC 2527 - opposed=20

  =20

  I have not posted on this list for some time, lurking has been fun =
though. I=20
  will say something that some might consider radical.=20

  I thought you might like to know how some of the business world is =
looking=20
  at RFC 2527 and its impact on the PKI business.=20

  RFC 2527 is being used as a template and checklist by auditors and=20
  associations to perform reviews on certificate authorities. Each entry =
and=20
  topic of RFC 2527 must be covered by the CA or one gets an "audit =
exception"=20
  or operations questions. This is done as a rote exercise.  Back when =
CAs=20
  were new, the checklist made sense - now some of the questions and =
sections=20
  is RFC 2527 are not as relevant to all CAs.=20

  I know of no use of the certificate policy in a business application; =
the=20
  policy is only there to tell any relying party that they should have a =

  contract with someone before trusting this certificate. The meaning, =
impact,=20
  legality, effectiveness, application, etc. of a certificate is =
addressed in=20
  contract (and subject to contract law - as I understand it). There is =
no=20
  detailed policy in the CP anymore.=20

  The practice among most banks I talk to is that the certificate =
practice=20
  statement (CPS) is an internal document about the operation of the CA =
and=20
  related software (OCSP, CRL, LDAP); the CPS is not made public. =
Therefore=20
  the original goal of automated or assisted examination of a CP and CPS =
by a=20
  relying party is thwarted. (I supported the automation goal, but it is =
not=20
  achievable.)=20

  It is useful that a certificate has a reference to a policy - but the=20
  construction and content of that policy is no longer relevant in the=20
  businesses that I see.  There is no use to a CPS except as an internal =

  checklist on CA construction and operation and acts as a mill stone =
around=20
  the neck of CA operators - a barrier to entry into PKI.  Therefore RFC =
2527=20
  is purely informational to constructing a CA; I would prefer that it =
move=20
  toward elimination as standard.=20

  =20

  Mack Hicks, SVP =20
  Bank of America  760-318-9345=20


--Boundary_(ID_4gzGrMu354h8Z8+2fcYKEA)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word" xmlns:st1 = 
"urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>RE: Update of RFC 2527 - opposed</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content=Word.Document name=ProgId>
<META content="MSHTML 5.50.4134.600" name=GENERATOR>
<META content="Microsoft Word 10" name=Originator><LINK 
href="cid:filelist.xml@01C29207.0D47F080" rel=File-List><o:SmartTagType 
name="State" 
namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><o:SmartTagType 
name="place" 
namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</STYLE>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */ 
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]--></HEAD>
<BODY lang=EN-US style="tab-interval: .5in" vLink=blue link=blue 
bgColor=#ffffff>
<DIV><FONT face=Arial size=2>A minor point:&nbsp; I realize that the "State of 
Washington's requirements" was most likely meant as an example here, but I want 
to make it explicit.&nbsp; The audit must be done following the requirements of 
whatever authority is controlling.&nbsp; For example, a CA in Hong Kong must be 
audited to the requirements of the HKSAR Electronic Transactions Ordinance 
(ETO); they really don't give a rat's rear end about the "State of 
Washington".&nbsp; :-) I suspect other jurisdictions and/or business regulators 
have similar views.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>(Also:&nbsp; I haven't looked at the Washington 
requirements in a few years, but in about 1998 or 1999 they had a couple of 
things I considered silly.&nbsp; Is there a handy URL I can take a quick look 
at? Thanks.)</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; Al Arsenault</FONT></DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; Chief Security Architect</FONT></DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; Diversinet Corp.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=[e-mail] 
  href="mailto:[e-mail]">Roger Younglove</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=[e-mail] 
  href="mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Friday, November 22, 2002 9:10 
  AM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> RE: Update of RFC 2527 - 
  opposed</DIV>
  <DIV><BR></DIV>
  <DIV class=Section1>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Well said Richard. 
  Certification of a PKI should be done by an qualified auditor <SPAN 
  class=GramE>following <SPAN style="mso-spacerun: yes">&nbsp;</SPAN>the</SPAN> 
  State of </SPAN></FONT><st1:State><st1:place><FONT face=Arial color=navy 
  size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Washington</SPAN></FONT></st1:place></st1:State><FONT 
  face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">'s requirements. 
  There must be a CP and CPS in order to audit and certify a 
  PKI.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <P class=MsoAutoSig><FONT face="Times New Roman" color=navy size=3><SPAN 
  style="FONT-SIZE: 12pt; COLOR: navy; mso-no-proof: yes">Roger Younglove, 
  CISSP<o:p></o:p></SPAN></FONT></P>
  <P class=MsoAutoSig><FONT face="Times New Roman" color=navy size=3><SPAN 
  style="FONT-SIZE: 12pt; COLOR: navy; mso-no-proof: yes"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Tahoma size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Original 
  Message-----<BR><B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> Guida, 
  Richard [JJCUS] [mailto:[e-mail]<SPAN class=GramE>] <BR><B><SPAN 
  style="FONT-WEIGHT: bold">Sent</SPAN></B></SPAN><B><SPAN 
  style="FONT-WEIGHT: bold">:</SPAN></B> Friday, November 22, 2002 5:20 
  AM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> Terwilliger, Ann; 
  [e-mail]<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> 
  RE: Update of RFC 2527 - opposed</SPAN></FONT></P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" 
  size=3><SPAN style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">I strongly agree with Ann and separate comments made 
  by Dave Fillingham.&nbsp; At Johnson &amp; Johnson we have both a CP and a CPS 
  to 2527, and intend to use those not only internally (as we are already doing 
  for our PKI which is built and run internally) but also, when the time comes, 
  to interoperate externally.&nbsp; Trying to negotiate external 
  interoperability without a CP/CPS to a common standard would be very 
  cumbersome at best and is unlikely to be satisfying.&nbsp; I fully agree that 
  any external interoperability will require a contract; but the trick will be 
  negotiating that contract and deciding what to include in it.&nbsp; One might 
  wind up with a contract that looks like a CP - in which case, why not start 
  with the CP and include it as an addendum to the contract?&nbsp; In essence, 
  the CP to 2527 becomes standard boilerplate for a contract where you wish to 
  have someone else accept your certificates.&nbsp; Also note that under a 
  confidentiality agreement, I would expect to have to expose the CPS as well to 
  the party with whom we wish to contract - to give them assurance that we are 
  indeed running our PKI as our CP prescribes.</SPAN></FONT><o:p></o:p></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">But even if we were never to interoperate (i.e., never 
  ask anyone else to accept our certificates, or seek to accept others' 
  certificates ourselves), the CP and CPS provide a comprehensive framework for 
  running a PKI and are invaluable for that purpose alone.&nbsp; I do not accept 
  the argument that what an unknowledgeable auditor may or may not do should 
  dictate what is appropriate, we should proceed to do what is sensible and then 
  defend that and, where necessary, educate the auditor to understand and 
  appreciate that.&nbsp; Relationships with auditors should be at arms length - 
  they do not have to be adversarial.&nbsp; My 1 1/2 cents 
  worth.</SPAN></FONT><o:p></o:p></P>
  <P class=MsoNormal 
  style="MARGIN-BOTTOM: 12pt; MARGIN-LEFT: 0.5in; MARGIN-RIGHT: 0in; mso-margin-top-alt: 0in"><FONT 
  face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">Richard A. Guida</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">Director, Information Security (Medical Devices and 
  Diagnostics)</SPAN></FONT> <o:p></o:p></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">Johnson &amp; Johnson</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">One J&amp;J Plaza, Room 
  WH6132</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">New 
  Brunswick, New Jersey&nbsp; 08933</SPAN></FONT> <o:p></o:p></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">E-mail: [e-mail]</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">Office:&nbsp; 732 524 3785</SPAN></FONT> 
  <o:p></o:p></P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" 
  size=3><SPAN style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">-----Original Message-----</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">From: Terwilliger, Ann [<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>]</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">Sent: Wednesday, November 20, 
  2002 6:50 PM</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">To: 
  [e-mail]</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">Subject: RE: Update of RFC 2527 - 
  opposed</SPAN></FONT> <o:p></o:p></P>
  <P class=MsoNormal 
  style="MARGIN-BOTTOM: 12pt; MARGIN-LEFT: 0.5in; MARGIN-RIGHT: 0in; mso-margin-top-alt: 0in"><FONT 
  face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">Another country is heard from......</SPAN></FONT> 
  <o:p></o:p></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">Like Mack, I do not believe that automated review of a 
  CP or CPS is</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">practical (even though it might be desirable).&nbsp; I 
  also agree that in many,</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">if not most, instances the CPS will not be made 
  public.&nbsp; However, I have to</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">disagree with his conclusion that RFC 2527 is not 
  relevant.</SPAN></FONT> <o:p></o:p></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">RFC 2527 does provide a checklist for what areas need 
  to be covered in</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">establishing and operating a CA.&nbsp; The fact that 
  some of the questions are</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">not as relevant today as they might have been when it 
  was first drafted only</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">reinforces the fact that it should be updated to 
  reflect current conditions.</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">There are other standards that address CA operation 
  (e.g., X9.79, WebTrust</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">Audit for CA, the ABA document) but virtually all 
  reference RFC 2527. </SPAN></FONT><o:p></o:p></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">I would like to believe that all CA operators are 
  knowledgeable about PKI</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">and adhere to best practices for operating their 
  CA.&nbsp; However, that is a</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">fairy tale--something on a par with the tooth 
  fairy--and there needs to be</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">some process to ensure that the CA has established 
  good security practices</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">and follows them.&nbsp; Hence audits become 
  necessary.&nbsp;&nbsp;&nbsp; </SPAN></FONT><o:p></o:p></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">Audits by their very nature are comparing something 
  against a checklist or</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">standard.&nbsp; Auditors who are familiar with PKI are 
  capable of adhering to the</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">spirit of the standard rather than the exact letter if 
  parts of a standard</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">do not apply.&nbsp; Unfortunately auditors who are not 
  familiar with PKI may</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">perform audits more or less by rote.&nbsp; To me this 
  makes it more important,</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">not less so, that we continue to update RFC 
  2527.&nbsp; </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&nbsp;</SPAN></FONT> <o:p></o:p></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">-----Original Message-----</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">From: Hicks, Mack [<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>]</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">Sent: Wednesday, November 20, 
  2002 1:10 PM</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">To: 
  [e-mail]</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">Subject: Update of RFC 2527 - opposed</SPAN></FONT> 
  <o:p></o:p></P>
  <P class=MsoNormal 
  style="MARGIN-BOTTOM: 12pt; MARGIN-LEFT: 0.5in; MARGIN-RIGHT: 0in; mso-margin-top-alt: 0in"><FONT 
  face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">I have not posted on this list for some time, lurking 
  has been fun though. I</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">will say something that some might consider 
  radical.</SPAN></FONT> <o:p></o:p></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">I thought you might like to know how some of the 
  business world is looking</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">at RFC 2527 and its impact on the PKI 
  business.</SPAN></FONT> <o:p></o:p></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">RFC 2527 is being used as a template and checklist by 
  auditors and</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">associations to perform reviews on certificate 
  authorities. Each entry and</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">topic of RFC 2527 must be covered by the CA or one 
  gets an "audit exception"</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">or operations questions. This is done as a rote 
  exercise.&nbsp; Back when CAs</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">were new, the checklist made sense - now some of the 
  questions and sections</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">is RFC 2527 are not as relevant to all 
  CAs.</SPAN></FONT> <o:p></o:p></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">I know of no use of the certificate policy in a 
  business application; the</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">policy is only there to tell any relying party that 
  they should have a</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">contract with someone before trusting this 
  certificate. The meaning, impact,</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">legality, effectiveness, application, etc. of a 
  certificate is addressed in</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">contract (and subject to contract law - as I 
  understand it). There is no</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">detailed policy in the CP anymore.</SPAN></FONT> 
  <o:p></o:p></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">The practice among most banks I talk to is that the 
  certificate practice</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">statement (CPS) is an internal document about the 
  operation of the CA and</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">related software (OCSP, CRL, LDAP); the CPS is not 
  made public. Therefore</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">the original goal of automated or assisted examination 
  of a CP and CPS by a</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">relying party is thwarted. (I supported the automation 
  goal, but it is not</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">achievable.)</SPAN></FONT> <o:p></o:p></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">It is useful that a certificate has a reference to a 
  policy - but the</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">construction and content of that policy is no longer 
  relevant in the</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">businesses that I see.&nbsp; There is no use to a CPS 
  except as an internal</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">checklist on CA construction and operation and acts as 
  a mill stone around</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">the neck of CA operators - a barrier to entry into 
  PKI.&nbsp; Therefore RFC 2527</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">is purely informational to constructing a CA; I would 
  prefer that it move</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">toward elimination as standard.</SPAN></FONT> 
  <o:p></o:p></P>
  <P class=MsoNormal 
  style="MARGIN-BOTTOM: 12pt; MARGIN-LEFT: 0.5in; MARGIN-RIGHT: 0in; mso-margin-top-alt: 0in"><FONT 
  face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">Mack Hicks, SVP&nbsp; </SPAN></FONT><BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">Bank of America&nbsp; 
  760-318-9345</SPAN></FONT> <o:p></o:p></P></DIV></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_4gzGrMu354h8Z8+2fcYKEA)--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAPErn810214 for ietf-pkix-bks; Mon, 25 Nov 2002 06:53:49 -0800 (PST)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAPErlg10209 for <[e-mail]>; Mon, 25 Nov 2002 06:53:47 -0800 (PST)
Received: from SJOSEPH (pcp237593pcs.elictc01.md.comcast.net [68.55.160.224]) by mtaout05.icomcast.net (iPlanet Messaging Server 5.1 HotFix 1.5 (built Sep 23 2002)) with SMTP id <[e-mail]> for [e-mail]; Mon, 25 Nov 2002 09:53:42 -0500 (EST)
Date: Mon, 25 Nov 2002 09:53:09 -0500
From: Al Arsenault <[e-mail]>
Subject: Re: Request for IESG consideration: CP/CPS Framework
To: [e-mail]
Message-id: <001b01c29492$5ea36da0$6801a8c0@SJOSEPH>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

(Trimming the cc: list a little; hopefully, we haven't dropped anybody
significant.)

First, for those not at the SAAG meeting in Atlanta last week, Jeff and
Steve said that they believe this document (2527bis) will eventually be
published; it's mostly a matter of educating IESG members.

Second, a couple of comments.  I guess I'm surprised at the objections to
publishing a CPS.  For a public CA, publication of a CPS is (almost)
mandatory if you want to engender confidence in your would-be customers.
That's why folks as disparate as VeriSign
(http://www.verisign.com/repository/CPS/)  and the Hongkong Post Office
(http://www.hongkongpost.gov.hk/5digital/dc4_fr.html) publish theirs.  I
don't really believe that publication of that document will reveal any
security vulnerabilities that aren't otherwise obvious.  I'd be interested
in knowing what vulnerabilities someone can glean from those.

Of course, if the PKI in question is a "private" one; e.g., for internal
company use, or use only between a company and its approved partners, it's
likely that a CPS is just like other non-public business information, and
not generally disclosed.  But that would relate more to business practices
and competitive advantage than to explicit security vulnerabilities in a
system.

That's my .02 (in any currency you'd care to name; 2 Hong Kong cents might
be its approximate worth. :-)

            Al Arsenault
            Chief Security Architect
            Diversinet Corp.


----- Original Message -----
From: "Alice Sturgeon" <[e-mail]>
To: "Adrian McCullagh" <[e-mail]>; "Fillingham, David
W." <[e-mail]>
Cc: <[e-mail]>; "Jeffrey I. Schiller" <[e-mail]>;
<[e-mail]>; "'Paul Hoffman / IMC'" <[e-mail]>;
<[e-mail]>
Sent: Friday, November 22, 2002 3:41 PM
Subject: RE: Request for IESG consideration: CP/CPS Framework


>
> And another country ...
> I completely agree with Adrian on the differences between CP and CPS, but
> not that this dictates separation of the two.  Several of us in this field
> have argued for years that a CPS should not be published, because doing so
> would introduce vulnerabilities, given that a CPS should contain details
of
> system security mechanisms in place.  And that's why I for one was happy
to
> see acceptance of the PKI Disclosure Statement, which gives evidence of
the
> existence of a CPS, and some of the high-level and most salient points of
> it, while obviating the need for publication of the CPS.
> 2527, and its revision waiting in the wings, is a framework, and a useful
> one as Rich points out for external interoperability and internal policy
and
> procedural development.  I do not see the need for two separate documents
> because a drafter should be able to glean the elements pertaining to CP or
> CPS from the framework presented.  In other words, 2527 does not give
finely
> granular (as the techs say) detail to guide drafters of CP/CPS's; it
> provides an overview, a framework.  A potential danger with separating
> CP/CPS into two standards (or guidance documents) is that they would
become
> too separate; that only one would be referenced and used, whereas their
> relationship is inherent and inextricable.
> I agree with others who have posted concerning whether 2527 should be
> informational or a proposed standard within IETF, that machine processing
> may not be the ultimate goal, and therefore rigid adherence to ASN.1
specs,
> as Santosh notes, is not provided, and was not intended to be provided.
At
> this point, it probably does not matter much whether 2527 (and its
> understudy in the wings) is informational or a proposed standard, because
it
> has been accepted globally as the standard.  Ann noted some instances.  It
> has been replicated, as well, within other standardization bodies - note,
> for example, ISO TC 215's TS 17090 (Technical Specification), PKI for
> healthcare.  Of interest to note that this TS points to 2527 as a
"normative
> reference", meaning that those complying with the TS must comply with
2527.
> Whether 2527 is itself informational or a standard becomes moot.
>
> Khaja wrote:
> 2527 does seem to be built on the assumption that the CA, subscribers
> and relying parties are distinct legal entities.  This seemed clear to
> me although, to the best of my recollection, this is not explicitly
> stated anywhere.  (Please let me know if I am incorrect about either of
> the two foregoing points.)"
> I would argue that 2527 does make this clear - one point is the roles and
> responsibilities section - and the revision, I believe, makes it even more
> clear.
>
> Finally, I agree with Ann about the PKI audit; the fact is that 2527 is
> being used as the audit base, and that therefore it must be up-to-date and
> reflect the current state of the world with respect to PKI
implementations,
> and this is real world - this is being done; 2527 is being used as the
audit
> base.  Again, whether 2527 (and daughter-of-2527) is informational or a
> proposed standard within IETF is academic; communities of interest (e.g.,
> healthcare entities in the U.S. moving towards HIPAA compliance) will
> determine whether the framework is mandatory for their own COI.  As IETF
> members working on this, it is incumbent on us to make it the best
possible
> framework.
>
> My $.02 - Canadian (i.e., about $.012 U.S.).
>
>
>
> Alice Sturgeon
> Chair
> Canadian Advisory Committee - Information Technology Security
> ISO/IEC JTC1 SC 27
> and
> System Policy Architect
> SPYRUS
> Phone:     [phone]
> Cell:         613-291-0331
>
>
>
> -----Original Message-----
> From: Adrian McCullagh [mailto:[e-mail]]
> Sent: November 22, 2002 12:58 AM
> To: Fillingham, David W.
> Cc: 'Adrian McCullagh'; [e-mail]; [e-mail]; Jeffrey
I.
> Schiller; [e-mail]; 'Paul Hoffman / IMC';
> [e-mail]
> Subject: RE: Request for IESG consideration: CP/CPS Framework
>
>
> Dear David,
>
> If one looks at the raison d'etre for a CPS it is very different to that
of
> the CP.
>
> It is my understanding, and I am open to any correction, that a CPS is a
> document that details the practices and procedures established by a CA
that
> will cover the life-cycle of certificates issued by the CA.  That is it
> covers how the certificate will be generated, suspended and revoked.  An
> internally focused document covering the internal environment of the CA.
> Much like an operations manual for a CA business as they relate to
> certificates.
>
> The CP is a very different document which will usually be relied upon by
> the relying party and to a certain extent the subscriber.  RFC 2527 states
> :
>
> 'According to X.509, a certificate policy (CP) is "a named
> set of rules that indicates the applicability of a certificate to a
> particular community and/or class of applications with common
> security requirements."
> A CP may be used by a relying party to help
> in deciding whether a certificate, and the binding therein, are
> sufficiently trustworthy and otherwise appropriate for a particular
> application.'
>
> Hence my query as to the applicability of RFC 2527 to the CP.  RFC 2527
> concentrates of the internal practices of the CA, which is really the
> function of a CPS.  I believe that a separate RFC should be established
> that specifically covers the rules that govern the use of a certificate by
> a relying party.  This RFC should be much more concise than RFC 2527.
> Hence my comment that I believe RFC 2527 to be inappropriate for a CP and
> thus overly complex.
>
> It is interesting that the Banking sector has taken the view that a CPS is
> an internal document, which I have no problem with, and therefore will not
> be published.  A CP on the other hand does need to be published otherwise
> the relying party will not be in a position to ascertain/determine any
> trust value for the transaction as it relates to the digital signature for

> verification.
>
> Dr. Adrian McCullagh Ph. D.
> Solicitor/lawyer
> Freehills, Australia
>
> Direct 61 7 3258 6603
> Telephone [phone]
> Facsimile 61 7 3258 6444
> http://www.freehills.com
>
> --------------------------------------------------------------------
> FREEHILLS
> This email is confidential.  If you are not the intended  recipient,
> you must not disclose  or  use the  information  contained in it. If
> you have received this email in error,  please notify us immediately
> by return email and delete the document.
> Freehills is not responsible for any changes made to a document other
> than those made by Freehills or for the effect of the changes on the
> document's meaning.
>
> Liability is limited by the Solicitors' Limitation of Liability Scheme,
> approved under the Professional Standards Act 1994 (NSW)
> --------------------------------------------------------------------
>
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAPDqFj06196 for ietf-pkix-bks; Mon, 25 Nov 2002 05:52:15 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAPDqCg06192 for <[e-mail]>; Mon, 25 Nov 2002 05:52:13 -0800 (PST)
Subject: Re: I-D ACTION:draft-ietf-pkix-sim-00.txt
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Mon, 25 Nov 2002 06:51:15 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 11/25/2002 08:54:37 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

and of course the (FSTC) FAST model has some authoritative agency/authority
(for the information) .... authenticating the information in a transaction
that (can) looks very much like an existing online payment authorization
transaction (aka the end-user makes some signed assertion to a RP ... and
the RP gets the real-time agreement back directly from the authoritative
agency). This somewhat makes the distinction between a certification
authority (as TTP) and an authoritative agency; where there can be
contractual and liability relationship between the RP and the agency
certifying (& responsible for) the information.

There are (at least) three issues

1) certificates originally targeted as solution for offline certified
information in an offline environment ... attempting to find a reason in an
online world

2) x.509 identity certificates creating a value proposition .... for a time
somewhat attempting to aggregate more & more privacy information ...
exasperating the identity theft and privacy leakage problems. one reaction
was institutions going to relying-party-only certificates that contained
just an account number .... which were attached to signed messages &
transactions that contained the same exact account number and transmitted
to business process that contained the account record and already contained
a copy of the public key for authenticating the transaction (trivially
showing that certificate itself was redundant and superfluous). The
existence of such certificates were technical artificial contrivance having
nothing to do with any business process.

3) the traditional online business model has had bilateral
agreements/contracts a) between the authoritative agency (like a financial
institution) and the end-user, b) the end-user and the relying party and c)
the relying party and the authoritative agency. Many of the certification
authority constructs were introduced as TTPs that would certify information
nominal the responsibility of some authoritative agency .... supposedly
because the relying-party might not have an online conduit to the
authoritative agency. However, the CA typically had no direct
contract/business relationship with either the authoritative agency or the
relying party .... any contract (implied or real) was between the end-user
and the certification authority (which could be totally unrelated to any of
the three bilateral agreements already mentioned).  I think that the GSA
has addressed this by making the CAs agents of the GSA and the RPs having
contractual relationship with the GSA (with regard to the GSA agents).

the certificate challenge then is 1) role in online world, 2) contain
useful information w/o leaking useful information, 3) some correspondence
to normal accepted business relationships (especially in a TTP scenario
where the TTP is independent of the actual authoritative agencies for the
information and all existing business relationships).

Some of the adult oriented internet has been using $1 auth for sort-of a
real-time age checking transactions. You do a something that looks like
MOTO payment transaction with a RP ... the RP does a $1 auth through the
normal network but doesn't do settlement (so nothing ever shows on your
statement). The result of the $1 auth is saved and used as implying that
you are of legal age (aka there is legal relationship between you and the
financial institution acting as an authoritative agenchy, there is legal
relationship between the RP and the financial infrastructure ... and you
are directly interacting with the RP). While there are some issues with
regard does the existance of legal relationship between you and your
financial institution actually implying legal age ... as well as the lack
of a digital signature (or other form of strong authentication) actualy
mean that you are you (say a x9.59 digitally signed transaction) ... the
control flow and the business relationships follow normal accepted
practices.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAPDMf404393 for ietf-pkix-bks; Mon, 25 Nov 2002 05:22:41 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAPDMYg04374 for <[e-mail]>; Mon, 25 Nov 2002 05:22:34 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26614; Mon, 25 Nov 2002 08:19:47 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-pkixrep-01.txt
Date: Mon, 25 Nov 2002 08:19:47 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Repository 
                          Locator Service
	Author(s)	: S. Boeyen, P. Hallam-Baker
	Filename	: draft-ietf-pkix-pkixrep-01.txt
	Pages		: 3
	Date		: 2002-11-22
	
This document defines a PKI repository locator service. The service
makes use of DNS SRV records defined in accordance with RFC 2782. The
service enables certificate using systems to locate PKI repositories 
based on a domain name, identify the protocols that can be used to 
access the repository, and obtain addresses for the servers that host 
the repository service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pkixrep-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-pkixrep-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-pkixrep-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-pkixrep-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-pkixrep-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAPDLc004234 for ietf-pkix-bks; Mon, 25 Nov 2002 05:21:38 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAPDLZg04225 for <[e-mail]>; Mon, 25 Nov 2002 05:21:36 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26430; Mon, 25 Nov 2002 08:18:53 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-08.txt
Date: Mon, 25 Nov 2002 08:18:52 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure: Logotypes in
                          X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-08.txt
	Pages		: 21
	Date		: 2002-11-21
	
This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
Please send comments on this document to the [e-mail]
mailing list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-08.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-logotypes-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-logotypes-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-logotypes-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-logotypes-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAP8pFY09937 for ietf-pkix-bks; Mon, 25 Nov 2002 00:51:15 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAP8pCg09930 for <[e-mail]>; Mon, 25 Nov 2002 00:51:13 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA15840; Mon, 25 Nov 2002 09:51:55 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id JAA11128; Mon, 25 Nov 2002 09:51:05 +0100
Message-ID: <[e-mail]>
Date: Mon, 25 Nov 2002 09:42:51 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail], Peter Gutmann <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-ocspv2-ext-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,

>>From: [e-mail]
>>[mailto:[e-mail]]On Behalf Of
>>Peter Gutmann
>>
>>What's wrong with using what was in the
>>original OCSPv2 draft, a simple cut-and-paste of
>>obvious, sensible cert identifiers?

> I think this makes sense.  It is a point on which this I-D's
> coauthors couldn't entirely agree so I left it as expressed in
> the -00 iteration anticipating this reaction.  My reasoning for
> getting this I-D out was to separate v2-ness issues away from
> the DPV/DPD issues.
> 
> What makes the most sense going forward is to have two separate
> working documents: 1) a "core framework" syntax; and 2) a
> "services and extensions" document; especially since this most
> recent I-D also proposes a new CRL Locator extension.

I strongly disagree.

I believed that the "battle" with OCSPv2 was over since, we (Ambarish, you 
and me) agreed to restrict its use to the checking of the revocation status 
of a certificate, but in no way to validate a certificate against a policy.

Now, I can see that you do not agree any more with that position.

> This approach has the benefit of fitting well against the
> upcoming DPV/DPD decision-making process while accommodating
> parallel list dialog on cert id mechanisms.  All previous and
> proposed services/extensions will be lumped together, including
> the originally proposed DPV and DPD extensions.  The DPV/DPD
> poll then determines whether or not to retain that portion of
> text in the services and extensions I-D.

I fully disagree with that approach that would take us two years back.

Denis

> Mike




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAP4nTs19183 for ietf-pkix-bks; Sun, 24 Nov 2002 20:49:29 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAP4nQg19176 for <[e-mail]>; Sun, 24 Nov 2002 20:49:26 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gAP4nOF5040116; Mon, 25 Nov 2002 04:49:27 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021124202221.03441870@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sun, 24 Nov 2002 20:48:51 -0800
To: David Chadwick <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: A plan for PKIX, LDAPv3, and ;binary
Cc: Christopher Oliva <[e-mail]>, [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <5.1.0.14.0.20021121203851.0351b190@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I guess I wasn't clear enough in what I said.  I meant:

  a) Some clients which request (using LDAPv3) "userCertificate"
     expect "userCertificate" to be returned.
  b) Some clients which request (using LDAPv3) "userCertificate"
     expect "userCertificate;binary" to be returned.

But I'll revise my conclusion a bit...

This makes it hard for a server to support both.  The
plan gives the choice of whether to support neither,
one or the other, or both to the implementor.  I list
both here because the implementor could return the
attribute twice (once as "userCertificate", once as
"userCertificate;binary").

Basically, the specification needs to detail the definitive
mechanism for requesting and transferring certificates in
LDAP.  Beyond that, we need to very careful not to disallow
implementations from being "liberal" with "non-strict" peers.

Kurt



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAP0XlB05006 for ietf-pkix-bks; Sun, 24 Nov 2002 16:33:47 -0800 (PST)
Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAP0Xdg04995 for <[e-mail]>; Sun, 24 Nov 2002 16:33:40 -0800 (PST)
Received: from salford.ac.uk ([80.5.216.114]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <[e-mail]>; Mon, 25 Nov 2002 00:33:35 +0000
Message-ID: <[e-mail]>
Date: Mon, 25 Nov 2002 00:38:31 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
CC: Christopher Oliva <[e-mail]>, [e-mail], [e-mail]
Subject: Re: A plan for PKIX, LDAPv3, and ;binary
References: <5.1.0.14.0.20021121203851.0351b190@127.0.0.1>
Content-Type: multipart/mixed; boundary="------------D95A1CCADCBC87EDADCFEB28"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------D95A1CCADCBC87EDADCFEB28
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



"Kurt D. Zeilenga" wrote:

> The current LDAPv3 technical specification [RFC 3377] does not
> state what is to be returned when "userCertificate" is requested
> (as this is a non-conformant request).  There are clients which
> expect:
>         a) return the certificate using "userCertificate;binary" or
>         b) return the certificate using "userCertificate".
> 
> (as well as clients which accept either)
> 
> As a server cannot support both at the same time, there is
> clearly an interoperability divide between implementations
> of these behaviors. 

Kurt

since servers typically must support LDAPv2 and LDAPv3 at the same time,
and LDAPv2 asks for userCertificate whilst LDAPv3 should ask for
userCertificate;binary, then clearly servers today SHOULD be able to
support both types of attribute request

David

> To preserve interoperability on either
> side of that divide, no statement is made which would require
> a server implementation to cross the divide.
> 
> That is, it is suggested that servers not be restricted in
> how they respond to a non-conformant request so as to allow
> current interoperability with ill-behaving clients.
> 
> Kurt

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------D95A1CCADCBC87EDADCFEB28
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------D95A1CCADCBC87EDADCFEB28--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAOD7Pj26386 for ietf-pkix-bks; Sun, 24 Nov 2002 05:07:25 -0800 (PST)
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAOD7Kg26372 for <[e-mail]>; Sun, 24 Nov 2002 05:07:21 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailc.telia.com (8.12.5/8.12.5) with SMTP id gAOD7J1K023804 for <[e-mail]>; Sun, 24 Nov 2002 14:07:19 +0100 (CET)
X-Original-Recipient: <[e-mail]>
Message-ID: <001d01c293b9$58bab8a0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-sim-00.txt
Date: Sun, 24 Nov 2002 13:59:37 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Guys,
You wanted some comments on this?

Korean citizens (as well as Swedish citizens) have a citizen number that
is more or less "secret" as it contains date-of-birth and gender.  To put
this number in clear in a generic ID-certificate would limit the certificate's
usability as only some relying parties (typically government-associated)
need this information.  To cope with this, you propose a method where
a user in a safe and selective way can transfer this number to an RP
that can verify its authenticity.

=====================================================
Regarding the method you suggest, I feel that it is a bit hard for the user to
have to deal with long random numbers that probably will change for each
certificate renewal.  At least as the foundation for an IETF-standard, I
would rather propose an informational or experimental RFC.
=====================================================

Actually the scope of this problem touches a more fundamental issue that
I have spent some time studying: How to combine PKI with "information"
concering the subject.   Therefore, I took the liberty to describe some
completely different methods to achieve "approximately" the same goal.

ON-LINE ASSERTIONS
-----------------------------
The following method allows *any* data to be given to RPs, and without
deploying secrets in certificates:

1. The user surfs to an on-line service that needs some additional CA-
   registered information regarding the user
2. The user is authenticated using SSL/TLS client-authentication
3. The service automatically redirects the user to a CA URL which is deducted
 from the issuer of the certificate
4. The user is authenticated by the CA using SSL/TLS client-authentication
5. The CA application informs the user that "Service XYX wants the following
   user attributes, do you agree?"
6. The user hits OK and is automatically redirected back to the service with 
   an SAML "ticket" containing the requested attributes signed by the CA

Although looking complex, it is just a couple of mouse-clicks + two
authentication PIN-code-operations for the user to perform. 

If the RP also saves the received ticket, it will not have to repeat the
request a second time, which makes this scheme both very flexible
and user-friendly.

OFF-LINE ASSERTIONS
----------------------------
A user may also surf to a CA, and after being authenticated, request
that the CA sends a CA-signed message with user-attributes to a
selected RP.  To make this a viable scheme, the user-certificate should
contain a unique and static ID in the CAs issuing-domain, in order to
to not have to repeat this process for each certificate renewal.

AUTHENTICATED RP LOOKUP
--------------------------------------
Another solution is that the service authenticates to the CA and gets
this information directly based on user certificate as input.  This
solution is based on that the CAs must "know" the RPs and their
needs which is a drawback.

MULTIPLE CERTIFICATES
---------------------------------
Multiple client-certificates (with and without the number in clear), is of
course another possible solution that has the advantage that nothing
special has to be built.  Requires a little bit more knowledge on the
user's part though and is entirely static with respect to user-attributes.

SIGNED SECRET
---------------------
Yet another solution is that user signs the secret data using his/her private
key and that there is a copy of the signature value in the certificate.  Note:
I have not made any deep crypto-analysis on this one, so it may be broken...

cheers,
Anders Rundgren







Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gANIe0U26382 for ietf-pkix-bks; Sat, 23 Nov 2002 10:40:00 -0800 (PST)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gANIdwg26372 for <[e-mail]>; Sat, 23 Nov 2002 10:39:58 -0800 (PST)
Received: from MMyersLapTop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by mail.coastside.net  with SMTP id gANIdjPP026021; Sat, 23 Nov 2002 10:39:45 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Cc: "Peter Gutmann" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-ocspv2-ext-00.txt
Date: Sat, 23 Nov 2002 10:35:38 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> Peter Gutmann
>
> What's wrong with using what was in the
> original OCSPv2 draft, a simple cut-and-paste of
> obvious, sensible cert identifiers?


I think this makes sense.  It is a point on which this I-D's
coauthors couldn't entirely agree so I left it as expressed in
the -00 iteration anticipating this reaction.  My reasoning for
getting this I-D out was to separate v2-ness issues away from
the DPV/DPD issues.

What makes the most sense going forward is to have two separate
working documents: 1) a "core framework" syntax; and 2) a
"services and extensions" document; especially since this most
recent I-D also proposes a new CRL Locator extension.

This approach has the benefit of fitting well against the
upcoming DPV/DPD decision-making process while accommodating
parallel list dialog on cert id mechanisms.  All previous and
proposed services/extensions will be lumped together, including
the originally proposed DPV and DPD extensions.  The DPV/DPD
poll then determines whether or not to retain that portion of
text in the services and extensions I-D.

Mike






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gANCX4s01942 for ietf-pkix-bks; Sat, 23 Nov 2002 04:33:04 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gANCX1g01934 for <[e-mail]>; Sat, 23 Nov 2002 04:33:01 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gANCWwF3025680; Sat, 23 Nov 2002 12:32:59 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021123071446.0441ecd8@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sat, 23 Nov 2002 07:32:25 -0500
To: Hallvard B Furuseth <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: No-op LDAP ;binary option
Cc: Jeff Jacoby <[e-mail]>, [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <5.1.0.14.0.20021123061555.0440cc58@127.0.0.1> <[e-mail]> <[e-mail]> <5.1.0.14.0.20021123061555.0440cc58@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 07:13 AM 2002-11-23, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>> Now, what some have said is, if the server recognizes an
>> odd spelling of tomatoes, it can serve the dish with that
>> old spelling.  There are odd clients which expect this.
>> Unfornately, we have also have odd clients which actually
>> expect to be able to be able to ask for the dish using an
>> odd spelling but get back the correct spelling.  So, what's
>> the server to do?
>
>Sounds like a case for leaving it to the administrator.
>That is, servers MAY do either but SHOULD do whatever causes
>least problems.  And an implementation note that the MAY
>should not be default, just an option.

I am quite leery of saying things about behaviors which
are counter to existing MUSTs.  We need to clarify that
the MUST is an absolute requirement.

Describing behaviors which are counter to non-absolute
requirements not only weaken the requirement but weaken
implementations ability to be friendly to non-conformant
implementations.

In the old saying "be liberal in what you accept, be
strict in what you send" (paraphrased), the specification
needs to be clear on how to be "strict" and vague on how
to be "liberal".

Kurt



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gANCK0o00524 for ietf-pkix-bks; Sat, 23 Nov 2002 04:20:00 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gANCJvg00518 for <[e-mail]>; Sat, 23 Nov 2002 04:19:57 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gANBsbF3025284; Sat, 23 Nov 2002 11:54:38 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021123061555.0440cc58@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sat, 23 Nov 2002 06:54:05 -0500
To: Jeff Jacoby <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: No-op LDAP ;binary option
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:47 AM 2002-11-22, Jeff Jacoby wrote:
>I think of this is the Tomato Solution:

>  You say you want a to-MAH-to?  I'll give you this red juicy thing that 
>  goes well on salads...and we'll both call it a to-MAH-to.
>  Oh, you say you'd prefer a to-MAY-to?  Then I'll give you this red
>  juicy thing that goes well on salads...and we'll both call it a
>to-MAY-to.


Well, the issue is more that you ask for "to-MAH-to" and the
waiter says "what?".  And then I ask a waitress for "to-MAY-to"
and she says "what?".

Now, in the real world, the waitress can bring out the chief.
So, I ask for "to-MAY-to"?  The chief says "to-MAT-to?" and
I reply "what?"

The problem here is that we've said that if you want to order
tomatoes you need to ask for them as "tomatoes" (in print)
and you need to server them with a label that says "tomatoes"
(in print).

Now, what some have said is, if the server recognizes an
odd spelling of tomatoes, it can serve the dish with that
old spelling.  There are odd clients which expect this.
Unfornately, we have also have odd clients which actually
expect to be able to be able to ask for the dish using an
odd spelling but get back the correct spelling.  So, what's
the server to do?   Serve two dishes, one labeled each way?
Or guess at what the client wants?  Or just refuse to server
anything unless the client learns how to spell it correctly?

The plan we've put into place realizes that many tomato
stands may be flexible in how they handle requests from odd
clients and places no new restrictions on their handling.
A server is free to recognize an odd spelling, free to
label the dish with this old spelling or the correct
spelling.  The only thing we'd like to say those, is that
the dish is to served raw (DER) regardless of how its
labeled... but that any request or dish labeling other
than the standard one is deprecated.

Kurt



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gANCE0i29504 for ietf-pkix-bks; Sat, 23 Nov 2002 04:14:00 -0800 (PST)
Received: from mons.uio.no (mons.uio.no [129.240.130.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gANCDvg29497 for <[e-mail]>; Sat, 23 Nov 2002 04:13:57 -0800 (PST)
Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18FZAW-0003pb-00; Sat, 23 Nov 2002 13:13:52 +0100
Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18FZAR-0002lc-00; Sat, 23 Nov 2002 13:13:47 +0100
From: Hallvard B Furuseth <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Kurt D. Zeilenga" <[e-mail]>
Cc: Jeff Jacoby <[e-mail]>, [e-mail], [e-mail]
Subject: Re: No-op LDAP ;binary option
In-Reply-To: <5.1.0.14.0.20021123061555.0440cc58@127.0.0.1>
References: <[e-mail]> <[e-mail]> <5.1.0.14.0.20021123061555.0440cc58@127.0.0.1>
X-Mailer: VM 6.37 under Emacs 19.34.1
Date: Sat, 23 Nov 2002 13:13:47 +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt D. Zeilenga writes:
> Now, what some have said is, if the server recognizes an
> odd spelling of tomatoes, it can serve the dish with that
> old spelling.  There are odd clients which expect this.
> Unfornately, we have also have odd clients which actually
> expect to be able to be able to ask for the dish using an
> odd spelling but get back the correct spelling.  So, what's
> the server to do?

Sounds like a case for leaving it to the administrator.
That is, servers MAY do either but SHOULD do whatever causes
least problems.  And an implementation note that the MAY
should not be default, just an option.

-- 
Hallvard


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gANCBcV29229 for ietf-pkix-bks; Sat, 23 Nov 2002 04:11:38 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gANCBZg29223 for <[e-mail]>; Sat, 23 Nov 2002 04:11:35 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gANCBUF3025442; Sat, 23 Nov 2002 12:11:31 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021123065535.043def98@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sat, 23 Nov 2002 07:10:57 -0500
To: Christopher Oliva <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: RE: A plan for PKIX, LDAPv3, and ;binary
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:44 PM 2002-11-22, Christopher Oliva wrote:
>> There are clients which expect: 

Note that I said this in a particular context.  That is,

There are clients which ask for "userCertificate" and expect either:
>>         a) return the certificate using "userCertificate;binary" or 
>>         b) return the certificate using "userCertificate". 

That is, a server which does a) won't interoperate with a client
which expects b) and a server which does b) won't interoperate
with a client which expects a).

>This sounds like a strong argument that supports updating servers to achieve interoperability with both groups.

It's a damn good argument for clients which ask for "userCertificate"
to be upgraded to ask for "userCertificate;binary" as the LDAPv3
specification has told them to do 5 years ago.

We should be careful not to add new requirements as we should
not unnecessarily require changes to deployed LDAPv3-conformant
systems.

>That's why I would prefer a solution that requires updated servers to support the native encoding of certificates (as would be returned when "userCertificate" is requested).

As noted above, a server which does a) or b) will not interoperate
with the group of clients which expect the other.  We should let
server implementors choose wether they want to support a) or b)
or say "no".  That is, we shouldn't detail non-standard behaviors.

>> As a server cannot support both at the same time, there is 
>> clearly an interoperability divide between implementations 
>
>Why is it that a server cannot support both groups ? 

Well, a server could return the attribute twice, once labelled
"userCertificate" and "userCertificate;binary".... but that
might confuse clients which expect an attribute to be returned
only once.

>If it remains the server's choice of whether or not to support group B, the interoperability divide remains unchanged.

If we force servers to support group B, then we disallow servers
from supporting group A.  If we force servers to support group
A, then we disallow servers from supporting group B.

>I believe the proposal should define the native encoding so that interoperability with group B can be attempted. This should not involve any comments about deprecation as server implementations may takes this as a reason not to support a request for "userCertificate". And there can be text indicating clients SHOULD request "userCertificate;binary".

We should require no server which is support a particular odd group
to stop supporting that odd group.  But we certainly should deprecate
both group A and B as both are odd.  That is, we should everyone in
group A and group B to the standards following group, group IETF.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAN9DvT12384 for ietf-pkix-bks; Sat, 23 Nov 2002 01:13:57 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAN9Drg12373 for <[e-mail]>; Sat, 23 Nov 2002 01:13:53 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gAN9DCwA015609; Sat, 23 Nov 2002 22:13:12 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id WAA231078; Sat, 23 Nov 2002 22:13:10 +1300 (NZDT) (sender [e-mail])
Date: Sat, 23 Nov 2002 22:13:10 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-ocspv2-ext-00.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas <[e-mail]> writes:

>- in addition to the current way to define a certificate, two new ways have
>   been defined.
>
>This is fully aligned with the discussion on the list.

Not at all, the CertIdWithSignature is a weird mutation of what was discussed,
because it piles a jumble of bits and pieces into a sequence rather than using
the straightforward IDs like issuerAndSerialNumber.  The rationale for the
different identifiers (e.g. issuerAndSerialNumber, certificate
fingerprint/thumbprint/whatever-you-want-to-call it) is fairly clear, but the
stuff in CertIdWithSignature is just plain strange, and entirely redundant.  I
can probably fix this by using only issuerAndSerialNumber and stuffing dummy
data in the other fields on the assumption that no-one else will be able to
make heads or tails of them either (experience with other PKI procotols has
shown that this works almost all of the time), but why is this stuff needed at
all?  What's wrong with using what was in the original OCSPv2 draft, a simple
cut-and-paste of obvious, sensible cert identifiers?

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAMKdau16348 for ietf-pkix-bks; Fri, 22 Nov 2002 12:39:36 -0800 (PST)
Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAMKdWg16337; Fri, 22 Nov 2002 12:39:32 -0800 (PST)
Received: from mail3.magma.ca (mail3.magma.ca [206.191.0.221]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id gAMKdUkI023724; Fri, 22 Nov 2002 15:39:30 -0500 (EST)
Received: from asturgeonpc (ottawa-dial-64-26-165-204.d-ip.magma.ca [64.26.165.204]) by mail3.magma.ca (Magma's Mail Server) with SMTP id gAMKdObb008277; Fri, 22 Nov 2002 15:39:26 -0500 (EST)
Reply-To: <[e-mail]>
From: "Alice Sturgeon" <[e-mail]>
To: "Adrian McCullagh" <[e-mail]>, "Fillingham, David W." <[e-mail]>
Cc: <[e-mail]>, "Jeffrey I. Schiller" <[e-mail]>, <[e-mail]>, "'Paul Hoffman / IMC'" <[e-mail]>, <[e-mail]>
Subject: RE: Request for IESG consideration: CP/CPS Framework
Date: Fri, 22 Nov 2002 15:41:39 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

And another country ...
I completely agree with Adrian on the differences between CP and CPS, but
not that this dictates separation of the two.  Several of us in this field
have argued for years that a CPS should not be published, because doing so
would introduce vulnerabilities, given that a CPS should contain details of
system security mechanisms in place.  And that's why I for one was happy to
see acceptance of the PKI Disclosure Statement, which gives evidence of the
existence of a CPS, and some of the high-level and most salient points of
it, while obviating the need for publication of the CPS.
2527, and its revision waiting in the wings, is a framework, and a useful
one as Rich points out for external interoperability and internal policy and
procedural development.  I do not see the need for two separate documents
because a drafter should be able to glean the elements pertaining to CP or
CPS from the framework presented.  In other words, 2527 does not give finely
granular (as the techs say) detail to guide drafters of CP/CPS's; it
provides an overview, a framework.  A potential danger with separating
CP/CPS into two standards (or guidance documents) is that they would become
too separate; that only one would be referenced and used, whereas their
relationship is inherent and inextricable.
I agree with others who have posted concerning whether 2527 should be
informational or a proposed standard within IETF, that machine processing
may not be the ultimate goal, and therefore rigid adherence to ASN.1 specs,
as Santosh notes, is not provided, and was not intended to be provided.  At
this point, it probably does not matter much whether 2527 (and its
understudy in the wings) is informational or a proposed standard, because it
has been accepted globally as the standard.  Ann noted some instances.  It
has been replicated, as well, within other standardization bodies - note,
for example, ISO TC 215's TS 17090 (Technical Specification), PKI for
healthcare.  Of interest to note that this TS points to 2527 as a "normative
reference", meaning that those complying with the TS must comply with 2527.
Whether 2527 is itself informational or a standard becomes moot.

Khaja wrote:
2527 does seem to be built on the assumption that the CA, subscribers
and relying parties are distinct legal entities.  This seemed clear to
me although, to the best of my recollection, this is not explicitly
stated anywhere.  (Please let me know if I am incorrect about either of
the two foregoing points.)"
I would argue that 2527 does make this clear - one point is the roles and
responsibilities section - and the revision, I believe, makes it even more
clear.

Finally, I agree with Ann about the PKI audit; the fact is that 2527 is
being used as the audit base, and that therefore it must be up-to-date and
reflect the current state of the world with respect to PKI implementations,
and this is real world - this is being done; 2527 is being used as the audit
base.  Again, whether 2527 (and daughter-of-2527) is informational or a
proposed standard within IETF is academic; communities of interest (e.g.,
healthcare entities in the U.S. moving towards HIPAA compliance) will
determine whether the framework is mandatory for their own COI.  As IETF
members working on this, it is incumbent on us to make it the best possible
framework.

My $.02 - Canadian (i.e., about $.012 U.S.).



Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     [phone]
Cell:         613-291-0331



-----Original Message-----
From: Adrian McCullagh [mailto:[e-mail]]
Sent: November 22, 2002 12:58 AM
To: Fillingham, David W.
Cc: 'Adrian McCullagh'; [e-mail]; [e-mail]; Jeffrey I.
Schiller; [e-mail]; 'Paul Hoffman / IMC';
[e-mail]
Subject: RE: Request for IESG consideration: CP/CPS Framework


Dear David,

If one looks at the raison d'etre for a CPS it is very different to that of
the CP.

It is my understanding, and I am open to any correction, that a CPS is a
document that details the practices and procedures established by a CA that
will cover the life-cycle of certificates issued by the CA.  That is it
covers how the certificate will be generated, suspended and revoked.  An
internally focused document covering the internal environment of the CA.
Much like an operations manual for a CA business as they relate to
certificates.

The CP is a very different document which will usually be relied upon by
the relying party and to a certain extent the subscriber.  RFC 2527 states
:

'According to X.509, a certificate policy (CP) is "a named
set of rules that indicates the applicability of a certificate to a
particular community and/or class of applications with common
security requirements."
A CP may be used by a relying party to help
in deciding whether a certificate, and the binding therein, are
sufficiently trustworthy and otherwise appropriate for a particular
application.'

Hence my query as to the applicability of RFC 2527 to the CP.  RFC 2527
concentrates of the internal practices of the CA, which is really the
function of a CPS.  I believe that a separate RFC should be established
that specifically covers the rules that govern the use of a certificate by
a relying party.  This RFC should be much more concise than RFC 2527.
Hence my comment that I believe RFC 2527 to be inappropriate for a CP and
thus overly complex.

It is interesting that the Banking sector has taken the view that a CPS is
an internal document, which I have no problem with, and therefore will not
be published.  A CP on the other hand does need to be published otherwise
the relying party will not be in a position to ascertain/determine any
trust value for the transaction as it relates to the digital signature for
verification.

Dr. Adrian McCullagh Ph. D.
Solicitor/lawyer
Freehills, Australia

Direct 61 7 3258 6603
Telephone [phone]
Facsimile 61 7 3258 6444
http://www.freehills.com

--------------------------------------------------------------------
FREEHILLS
This email is confidential.  If you are not the intended  recipient,
you must not disclose  or  use the  information  contained in it. If
you have received this email in error,  please notify us immediately
by return email and delete the document.
Freehills is not responsible for any changes made to a document other
than those made by Freehills or for the effect of the changes on the
document's meaning.

Liability is limited by the Solicitors' Limitation of Liability Scheme,
approved under the Professional Standards Act 1994 (NSW)
--------------------------------------------------------------------




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAMJi5314301 for ietf-pkix-bks; Fri, 22 Nov 2002 11:44:05 -0800 (PST)
Received: from gto-mailer1.bbn.com (gto-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAMJi2g14295 for <[e-mail]>; Fri, 22 Nov 2002 11:44:03 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03526 for <[e-mail]>; Fri, 22 Nov 2002 14:44:17 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510031cba0437f974e2@[128.89.88.34]>
Date: Fri, 22 Nov 2002 14:41:52 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: draft minutes and slides
Content-Type: multipart/alternative; boundary="============_-1174128178==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1174128178==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Folks,

The draft meeting minutes are below. Please send e-mail to me with 
comments, corrections, etc. by Monday, 12/2.

Also, I have received slides from two of the presenters. I'd like to 
receive the rest of the slides by the same date.

thanks,

Steve
--------

PKIX WG Meeting 11/20/02

Edited by Steve Kent

Chairs: Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>

The PKIX WG met once during the 55rd IETF. A total of approximately 
97 individuals participated in the meeting.


Tim Polk began with a review of the agenda and document status.
	[see slides]

Logotypes in X.509 Certificates - Stefan Santesson (AddTrust)
	Add specifications to require at least one logotype that fits 
within specified size ranges, and if audio files are present at least 
one should be within a specified time duration. Straw poll of 
attendees supports guidelines for these features, vs. compliance 
requirements relative to certificate contents. Will confirm this 
consensus via the list. Another observation is that these may be 
guidelines for certificate contents, but we ought to impose 
conformance requirements on the clients that consume certificates, to 
ensure that they can display logotypes (and play audio files) within 
some bounds. A suggestion was made that clients should be required to 
allow users to suppress playing audio files and suppress fetching the 
files that might be referenced by URIs in this extension, and the 
authors agreed to incorporate this requirement. [see slides]

Discussion of competing protocols to become the standard protocol for DPD/DPV.

CVP- Tim Polk (NIST) presenting for Denis Pinkas (Bull)
		Basically, this protocol is designed to be able to do 
more than meet the requirements defined in 3279, but Denis (as the 
author of that RFC) asserts that CVP is complaint with the 
requirements RFC. The slides compare CVP features with SCVP features. 
[see slides]


SCVP Protocol - Russ Housely (Vigil Security)
	Now on draft 10, which has been discussed extensively on the 
list. Presentation addressed open issues raised in on-list 
discussion. [see slides]


OCSP Mike Myers (TraceRoute Security)
	No slides. Strategy here is to use extension facility to 
support DPV/DPD requirements, building on OCSP. The document will be 
refreshed and reposted with the description of extensions to provide 
this support.


DCVS is the fourth candidate. It is RFC 3029, an experimental track 
RFC. It is designed to provide a wide range of services, including 
those that we now characterize as DPV/DPD.


Proxy Certificates Von Welch (Argonne Labs)
	Document is also being worked on in Global Grid Forum. The 
biggest residual problem is that the path validation algorithm 
rejects these certificates since the end users are not CAs. One 
suggestion is to validate the path up to but not including the proxy 
certificate, then invoke path validation only for the proxy 
certificate, with a temporary trust anchor based on the user 
certificate that acted as the issuer of the proxy certificate. This 
would be consistent with the RFC 3280 path validation process, and 
might be consistent with the need for the application to perform the 
additional checks specified for a proxy certificate. A possible 
concern is that one needs to ensure that the trust anchor inserted 
for this process is not retained and thus might inappropriately 
affect later path validation invocations. Audience comments support 
the principle of not modifying the RFC 3280 algorithm, though with 
varying rationales. The TLS WG chair suggests that this really should 
be done in the TLS context, i.e., using the IETF standard. [see 
slides]


LDAP Schema - Peter Gietz (DASSI International)
	LDAP lacks matching rules support to allow selection of 
certificates and CRLs based on specifying values for fields in these 
data items (when multiple certificates or CRLs are stored in the same 
LDAP entry). This approach is a metadata solution; it extracts the 
data from certificates and CRLs and replicates the data as a set of 
new attributes in the LDAP database, making them suitable as search 
parameters. Clients need to be configured with the new schema, to 
allow searching based on this approach. This is a personal draft; the 
question is whether it belongs in PKIX? A cited concern here is that 
this schema approach
We will take up the question on the list. [see slides]


Attribute Certificate - Chris Francis (WebSecure Technologies)
	A new extension for attribute certificates that explicitly 
states the policies employed on issuing the certificate, analogous to 
the certificatePolices extension in public key certificates, and uses 
similar syntax. Has policy qualifiers to allow an AA to specify that 
attributes were verified at a time that might be significantly 
earlier than the issuance date, implying that the attributes were not 
re-verified at the time of reissuance. (WG chair note: Is this a 
thing we wish to encourage by providing syntax for it?)

Certificate Warranty Extension - Alice Sturgeon (Spyrus)
	This extension provides explicit data about warranties 
provided by the CA, including an explicit declaration of no warranty. 
It's a non-critical extension. This is important, because it allows 
one to include warranty info that can be ignored, while also putting 
in critical policy info. This combination of critical and 
non-critical "policy" info could not otherwise be accommodated. A 
revised ID will be posted soon. [see slides]

OCSPv2 - Mike Myers (TraceRoute Security)
	Update of v1 document to add additional means of referring to 
a certificate and offers a means by which a client can provide a 
pointer to a CRL to check.


Subject Identification Method - Park Jong-Wook - (Korean Information 
Security Agency)
	Goal is to provide a way to represent a personal ID value 
(e.g., national ID number) in a certificate in a way that does not 
disclose its value, for privacy reasons. The proposal also includes a 
protocol for transferring this data to the CA. The proposed virtual 
ID (VID), is computed by double hashing the personal ID value with a 
160-bit random number (R), and symmetrically encrypting the result, 
using R as a key. Looking for feedback. [see slides]


"Specification Problem around Multi PKI domain Experience in 
Challenge PKI 2002"
  - Ryu Inada (Japan Network Security Association)
	This is a report on the interoperability testing activities 
in Japan, in September. This is not a PKIX activity but the results 
of testing are of interest, e.g., in terms of uncovering 
interop/specification problems with PKIX standards. Test environment 
includes CAs and VAs capable of generating data for test cases, some 
of which intentionally do not conform to PKIX standards. We are 
awaiting an English translation of the underlying documents. [see 
slides]
--============_-1174128178==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>draft minutes and slides</title></head><body>
<div>Folks,</div>
<div><br></div>
<div>The draft meeting minutes are below. Please send e-mail to me
with comments, corrections, etc. by Monday, 12/2.</div>
<div><br></div>
<div>Also, I have received slides from two of the presenters. I'd like
to receive the rest of the slides by the same date.</div>
<div><br></div>
<div>thanks,</div>
<div><br></div>
<div>Steve</div>
<div>--------</div>
<div><br></div>
<div><font face="Courier" size="+2" color="#000000">PKIX WG Meeting
11/20/02<br>
<br>
Edited by Steve Kent<br>
<br>
Chairs: Stephen Kent &lt;[e-mail]&gt;, Tim Polk
&lt;[e-mail]&gt;<br>
<br>
The PKIX WG met once during the 55rd IETF. A total of approximately 97
individuals participated in the meeting.<br>
<br>
<br>
Tim Polk began with a review of the agenda and document status.<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>[see slides]<br>
<br>
Logotypes in X.509 Certificates - Stefan Santesson (AddTrust)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Add specifications
to require at least one logotype that fits within specified size
ranges, and if audio files are present at least one should be within a
specified time duration. Straw poll of attendees supports guidelines
for these features, vs. compliance requirements relative to
certificate contents. Will confirm this consensus via the list.
Another observation is that these may be guidelines for certificate
contents, but we ought to impose conformance requirements on the
clients that consume certificates, to ensure that they can display
logotypes (and play audio files) within some bounds. A suggestion was
made that clients should be required to allow users to suppress
playing audio files and suppress fetching the files that might be
referenced by URIs in this extension, and the authors agreed to
incorporate this requirement. [see slides]<br>
<br>
Discussion of competing protocols to become the standard protocol for
DPD/DPV.<br>
</font></div>
<div><font face="Courier" size="+2" color="#000000">CVP- Tim Polk
(NIST) presenting for Denis Pinkas (Bull)</font></div>
<div><font face="Courier" size="+2"
color="#000000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Basically, this protocol is designed to be able to do more
than meet the requirements defined in 3279, but Denis (as the author
of that RFC) asserts that CVP is complaint with the requirements RFC.
The slides compare CVP features with SCVP features. [see
slides]</font></div>
<div><font face="Courier" size="+2" color="#000000"><br>
<br>
SCVP Protocol - Russ Housely (Vigil Security)<br>
<x-tab>&nbsp;&nbsp; </x-tab>Now on draft 10, which has been discussed
extensively on the list. Presentation addressed open issues raised in
on-list discussion. [see slides]<br>
<br>
<br>
OCSP Mike Myers (TraceRoute Security)<br>
<x-tab>&nbsp;&nbsp; </x-tab>No slides. Strategy here is to use
extension facility to support DPV/DPD requirements, building on OCSP.
The document will be refreshed and reposted with the description of
extensions to provide this support.<br>
<br>
<br>
DCVS is the fourth candidate. It is RFC 3029, an experimental track
RFC. It is designed to provide a wide range of services, including
those that we now characterize as DPV/DPD.</font><br>
<font face="Courier" size="+2" color="#000000"></font></div>
<div><font face="Courier" size="+2" color="#000000"><br>
Proxy Certificates Von Welch (Argonne Labs)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Document is also being worked
on in Global Grid Forum. The biggest residual problem is that the path
validation algorithm rejects these certificates since the end users
are not CAs. One suggestion is to validate the path up to but not
including the proxy certificate, then invoke path validation only for
the proxy certificate, with a temporary trust anchor based on the user
certificate that acted as the issuer of the proxy certificate. This
would be consistent with the RFC 3280 path validation process, and
might be consistent with the need for the application to perform the
additional checks specified for a proxy certificate. A possible
concern is that one needs to ensure that the trust anchor inserted for
this process is not retained and thus might inappropriately affect
later path validation invocations. Audience comments support the
principle of not modifying the RFC 3280 algorithm, though with varying
rationales. The TLS WG chair suggests that this really should be done
in the TLS context, i.e., using the IETF standard. [see slides]<br>
<br>
<br>
LDAP Schema - Peter Gietz (DASSI International)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>LDAP lacks matching
rules support to allow selection of certificates and CRLs based on
specifying values for fields in these data items (when multiple
certificates or CRLs are stored in the same LDAP entry). This approach
is a metadata solution; it extracts the data from certificates and
CRLs and replicates the data as a set of new attributes in the LDAP
database, making them suitable as search parameters. Clients need to
be configured with the new schema, to allow searching based on this
approach. This is a personal draft; the question is whether it belongs
in PKIX? A cited concern here is that this schema
approach</font></div>
<div><font face="Courier" size="+2" color="#000000">We will take up
the question on the list. [see slides]<br>
<br>
<br>
Attribute Certificate - Chris Francis (WebSecure
Technologies)</font></div>
<div><font face="Courier" size="+2"
color="#000000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>A new extension for attribute certificates that explicitly
states the policies employed on issuing the certificate, analogous to
the certificatePolices extension in public key certificates, and uses
similar syntax. Has policy qualifiers to allow an AA to specify that
attributes were verified at a time that might be significantly earlier
than the issuance date, implying that the attributes were not
re-verified at the time of reissuance. (WG chair note: Is this a thing
we wish to encourage by providing syntax for it?)</font></div>
<div><font face="Courier" size="+2" color="#000000"><br>
Certificate Warranty Extension - Alice Sturgeon (Spyrus)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>This
extension provides explicit data about warranties provided by the CA,
including an explicit declaration of no warranty. It's a
non-critical extension. This is important, because it allows one to
include warranty info that can be ignored, while also putting in
critical policy info. This combination of critical and non-critical
"policy" info could not otherwise be accommodated. A revised ID will
be posted soon. [see slides]<br>
<br>
OCSPv2 - Mike Myers (TraceRoute Security)<br>
<x-tab> </x-tab>Update of v1 document to add additional means of
referring to a certificate and offers a means by which a client can
provide a pointer to a CRL to check.<br>
<br>
<br>
Subject Identification Method - Park Jong-Wook - (Korean Information
Security Agency)<br>
<x-tab>&nbsp; </x-tab>Goal is to provide a way to represent a personal
ID value (e.g., national ID number) in a certificate in a way that
does not disclose its value, for privacy reasons. The proposal also
includes a protocol for transferring this data to the CA. The proposed
virtual ID (VID), is computed by double hashing the personal ID value
with a 160-bit random number (R), and symmetrically encrypting the
result, using R as a key. Looking for feedback. [see slides]<br>
<br>
<br>
&quot;Specification Problem around Multi PKI domain Experience in
Challenge PKI 2002&quot;<br>
&nbsp;- Ryu Inada (Japan Network Security Association)<br>
<x-tab>&nbsp;&nbsp; </x-tab>This is a report on the interoperability
testing activities in Japan, in September. This is not a PKIX activity
but the results of testing are of interest, e.g., in terms of
uncovering interop/specification problems with PKIX standards. Test
environment includes CAs and VAs capable of generating data for test
cases, some of which intentionally do not conform to PKIX standards.
We are awaiting an English translation of the underlying documents.
[see slides]</font></div>
</body>
</html>
--============_-1174128178==_ma============--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAMIcax10448 for ietf-pkix-bks; Fri, 22 Nov 2002 10:38:36 -0800 (PST)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAMIcYg10444 for <[e-mail]>; Fri, 22 Nov 2002 10:38:34 -0800 (PST)
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <XL2AS53L>; Fri, 22 Nov 2002 13:38:30 -0500
Message-ID: <[e-mail]>
From: Christopher Oliva <[e-mail]>
To: "'Kurt D. Zeilenga'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: A plan for PKIX, LDAPv3, and ;binary
Date: Fri, 22 Nov 2002 13:38:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29256.58542EF0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C29256.58542EF0
Content-Type: text/plain

To address the question of clients who request userCertificate where the
server returns userCertificate;binary ... how about this suggestion: servers
should be updated to be consistent with the native encoding (return
userCertificate). Clients that want userCertificate;binary to be returned
will need to be updated because that is the one scenario that is documented
in RFC 2251 that may not work.
 
Small clarification below:

-----Original Message-----
From: Christopher Oliva [mailto:[e-mail]]
Sent: Friday, November 22, 2002 12:44 PM
To: 'Kurt D. Zeilenga'
Cc: [e-mail]; [e-mail]
Subject: RE: A plan for PKIX, LDAPv3, and ;binary




> There are clients which 
> expect: 
>         a) return the certificate using "userCertificate;binary" or 
>         b) return the certificate using "userCertificate". 
> 

This sounds like a strong argument that supports updating servers to achieve
interoperability with both groups . That's why I would prefer a solution
that requires updated servers to support the native encoding of certificates
(as would be returned when "userCertificate" is requested). 

The two groups I refer to are clients who request userCertificate;binary and
clients who request userCertificate as I complicated this with the two
groups outlined above. Sorry for the confusion.

> As a server cannot support both at the same time, there is 
> clearly an interoperability divide between implementations 

Why is it that a server cannot support both groups ?  

If it remains the server's choice of whether or not to support group B, the
interoperability divide remains unchanged. I believe the proposal should
define the native encoding so that interoperability with group B can be
attempted. This should not involve any comments about deprecation as server
implementations may takes this as a reason not to support a request for
"userCertificate". And there can be text indicating clients SHOULD request
"userCertificate;binary".

Chris. 


------_=_NextPart_001_01C29256.58542EF0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>RE: A plan for PKIX, LDAPv3, and ;binary</TITLE>

<META content="MSHTML 5.00.3504.2500" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#000080 face=Arial size=2><SPAN class=146062418-22112002>To 
address the question of clients who request userCertificate where the server 
returns userCertificate;binary ... how about this suggestion: servers should be 
updated to be consistent with the native encoding (return userCertificate). 
Clients that want userCertificate;binary to be returned will need to be updated 
because that is the one scenario that is documented in RFC 2251 that may not 
work.</SPAN></FONT></DIV>
<DIV><FONT color=#000080 face=Arial size=2><SPAN 
class=146062418-22112002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#000080 face=Arial size=2><SPAN class=146062418-22112002>Small 
clarification below:</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Christopher Oliva 
  [mailto:[e-mail]]<BR><B>Sent:</B> Friday, November 22, 2002 
  12:44 PM<BR><B>To:</B> 'Kurt D. Zeilenga'<BR><B>Cc:</B> [e-mail]; 
  [e-mail]<BR><B>Subject:</B> RE: A plan for PKIX, LDAPv3, and 
  ;binary<BR><BR></DIV></FONT><BR>
  <P><FONT size=2>&gt; There are clients which</FONT> <BR><FONT size=2>&gt; 
  expect:</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a) return the 
  certificate using "userCertificate;binary" or</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b) return the 
  certificate using "userCertificate".</FONT> <BR><FONT size=2>&gt; </FONT></P>
  <P><FONT size=2>This sounds like a strong argument that supports updating 
  servers to achieve interoperability with both groups<SPAN 
  class=146062418-22112002><FONT color=#000080 face=Arial>&nbsp;</FONT></SPAN>. 
  That's why I would prefer a solution that requires updated servers to support 
  the native encoding of certificates (as would be returned when 
  "userCertificate" is requested).<FONT color=#000080 face=Arial><SPAN 
  class=146062418-22112002>&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#000080 face=Arial><SPAN 
  class=146062418-22112002>The two groups I refer to are clients who request 
  userCertificate;binary and clients who request userCertificate as I 
  complicated this with the two groups outlined above. Sorry for the 
  confusion.</SPAN></FONT></FONT></P>
  <P><FONT size=2>&gt; As a server cannot support both at the same time, there 
  is</FONT> <BR><FONT size=2>&gt; clearly an interoperability divide between 
  implementations</FONT> </P>
  <P><FONT size=2>Why is it that a server cannot support both groups 
  ?</FONT>&nbsp;<FONT color=#000080 face=Arial size=2><SPAN 
  class=146062418-22112002>&nbsp;</SPAN></FONT></P>
  <P><FONT size=2>If it remains the server's choice of whether or not to support 
  group B, the interoperability divide remains unchanged. I believe the proposal 
  should define the native encoding so that interoperability with group B can be 
  attempted. This should not involve any comments about deprecation as server 
  implementations may takes this as a reason not to support a request for 
  "userCertificate". And there can be text indicating clients SHOULD request 
  "userCertificate;binary".</FONT></P>
  <P><FONT size=2>Chris.</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C29256.58542EF0--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAMHifd06506 for ietf-pkix-bks; Fri, 22 Nov 2002 09:44:41 -0800 (PST)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAMHidg06502 for <[e-mail]>; Fri, 22 Nov 2002 09:44:39 -0800 (PST)
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <XL2ASZPC>; Fri, 22 Nov 2002 12:44:35 -0500
Message-ID: <[e-mail]>
From: Christopher Oliva <[e-mail]>
To: "'Kurt D. Zeilenga'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: A plan for PKIX, LDAPv3, and ;binary
Date: Fri, 22 Nov 2002 12:44:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2924E.CF0DD5D0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2924E.CF0DD5D0
Content-Type: text/plain


> There are clients which
> expect:
>         a) return the certificate using "userCertificate;binary" or
>         b) return the certificate using "userCertificate".
> 

This sounds like a strong argument that supports updating servers to achieve
interoperability with both groups. That's why I would prefer a solution that
requires updated servers to support the native encoding of certificates (as
would be returned when "userCertificate" is requested).

> As a server cannot support both at the same time, there is
> clearly an interoperability divide between implementations

Why is it that a server cannot support both groups ?

If it remains the server's choice of whether or not to support group B, the
interoperability divide remains unchanged. I believe the proposal should
define the native encoding so that interoperability with group B can be
attempted. This should not involve any comments about deprecation as server
implementations may takes this as a reason not to support a request for
"userCertificate". And there can be text indicating clients SHOULD request
"userCertificate;binary".

Chris.

------_=_NextPart_001_01C2924E.CF0DD5D0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: A plan for PKIX, LDAPv3, and ;binary</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>&gt; There are clients which</FONT>
<BR><FONT SIZE=3D2>&gt; expect:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
a) return the certificate using &quot;userCertificate;binary&quot; =
or</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
b) return the certificate using &quot;userCertificate&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>This sounds like a strong argument that supports =
updating servers to achieve interoperability with both groups. That's =
why I would prefer a solution that requires updated servers to support =
the native encoding of certificates (as would be returned when =
&quot;userCertificate&quot; is requested).</FONT></P>

<P><FONT SIZE=3D2>&gt; As a server cannot support both at the same =
time, there is</FONT>
<BR><FONT SIZE=3D2>&gt; clearly an interoperability divide between =
implementations</FONT>
</P>

<P><FONT SIZE=3D2>Why is it that a server cannot support both groups =
?</FONT>
</P>

<P><FONT SIZE=3D2>If it remains the server's choice of whether or not =
to support group B, the interoperability divide remains unchanged. I =
believe the proposal should define the native encoding so that =
interoperability with group B can be attempted. This should not involve =
any comments about deprecation as server implementations may takes this =
as a reason not to support a request for &quot;userCertificate&quot;. =
And there can be text indicating clients SHOULD request =
&quot;userCertificate;binary&quot;.</FONT></P>

<P><FONT SIZE=3D2>Chris.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2924E.CF0DD5D0--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAMHWGb06305 for ietf-pkix-bks; Fri, 22 Nov 2002 09:32:16 -0800 (PST)
Received: from lakemtao04.cox.net (lakemtao04.cox.net [68.1.17.241]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAMHWDg06301 for <[e-mail]>; Fri, 22 Nov 2002 09:32:13 -0800 (PST)
Received: from sgupta ([68.100.200.151]) by lakemtao04.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20021122173205.IJRQ1248.lakemtao04.cox.net@sgupta>; Fri, 22 Nov 2002 12:32:05 -0500
From: "Sarbari Gupta" <[e-mail]>
To: "PKIX" <[e-mail]>
Cc: "Sean Finnegan" <[e-mail]>
Subject: Question on use of AIA extension
Date: Fri, 22 Nov 2002 12:32:18 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I was reviewing the description for the AIA extension in RFC 3280, and
noticed the following text:

	"The id-ad-caIssuers OID is used when the additional information
	lists CAs that have issued certificates superior to the CA that
	issued the certificate containing this extension"

The above seems to imply that the AIA extension (if populated) within an EE
cert, should point to the "grandparent certificate" rather than the "parent
certificate". Am I interpreting this correctly?

I was under the impression that CA vendors who make use of this extension
(such as Microsoft) use the AIA extension to point to the "parent
certificate". Is this consistent with the RFC 3280 specification?

Can someone please clarify.

==============================
Sarbari Gupta
Electrosoft Services, Inc.
Tel: [phone]
Cell:[phone]
FAX: [phone]
Email:  [e-mail]
Web: <http://www.electrosoft-inc.com>
==============================



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAMFoG329545 for ietf-pkix-bks; Fri, 22 Nov 2002 07:50:16 -0800 (PST)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id gAMFoDg29539 for <[e-mail]>; Fri, 22 Nov 2002 07:50:13 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 22 Nov 2002 15:50:15 UT
Received: from tuna.rsa.com (tuna.rsa.com [10.80.211.153]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA05034; Fri, 22 Nov 2002 10:50:11 -0500 (EST)
Received: from rsasecurity.com (vanquish.rsa.com [10.81.217.242]) by tuna.rsa.com (8.8.8+Sun/8.8.8) with ESMTP id IAA06879; Fri, 22 Nov 2002 08:07:50 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 22 Nov 2002 07:47:44 -0800
From: Jeff Jacoby <[e-mail]>
Organization: RSA Security, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail], [e-mail]
Subject: Re: No-op LDAP ;binary option
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Christopher Oliva wrote:
> 
> David, I agree with the summary of the problem you've provided below ..
> in terms of basic ldapv3 interoperability, ;binary has been the number 1
> problem I've encountered.
> 
> I prefer a solution that defines "userCertificate;binary" and
> "userCertificate" to have the same meaning .. that is, a request for
> userCertificate will return the same binary encoded value as a request
> for userCertificate;binary (and the attribute description returned will
> be userCertificate;binary if userCertificate;binary was requested).
> 
> Chris.

I think of this is the Tomato Solution:

  You say you want a to-MAH-to?  I'll give you this red juicy thing that 
  goes well on salads...and we'll both call it a to-MAH-to.

  Oh, you say you'd prefer a to-MAY-to?  Then I'll give you this red
  juicy thing that goes well on salads...and we'll both call it a
to-MAY-to.

:)

Seriously,  I agree with the above proposal.

Jeff


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAMEmEw21775 for ietf-pkix-bks; Fri, 22 Nov 2002 06:48:14 -0800 (PST)
Received: from persephone.cfrq.net (www.cfrq.net [207.245.2.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAMEmCg21771 for <[e-mail]>; Fri, 22 Nov 2002 06:48:12 -0800 (PST)
Received: from elisabeth.cfrq.net (elisabeth.chk.cfrq.net [199.85.99.82]) by persephone.cfrq.net (8.12.2/8.12.2) with ESMTP id gAMEm0q2011920 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 22 Nov 2002 09:48:02 -0500
Received: from elisabeth.cfrq.net (localhost [127.0.0.1]) by elisabeth.cfrq.net (8.12.2/8.12.2) with ESMTP id gAMEluSO005091 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 22 Nov 2002 09:47:59 -0500
Received: from elisabeth.cfrq.net (chk@localhost) by elisabeth.cfrq.net (8.12.2/8.12.2/Submit) with ESMTP id gAMElmIk005084; Fri, 22 Nov 2002 09:47:59 -0500
To: [e-mail], [e-mail]
Subject: Re: A plan for PKIX, LDAPv3, and ;binary 
References: <5.1.0.14.0.20021121192156.03522c10@127.0.0.1>
In-reply-to: Kurt's message of "Thu, 21 Nov 2002 20:15:24 -0500". <5.1.0.14.0.20021121192156.03522c10@127.0.0.1> 
From: Harald Koch <[e-mail]>
Date: Fri, 22 Nov 2002 09:47:44 -0500
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>  There are clients which
> expect:
>         a) return the certificate using "userCertificate;binary" or
>         b) return the certificate using "userCertificate".
> 
> (as well as clients which accept either)

The problem is complicated by the fact that there are LDAPv3 *servers*,
some that expect 'userCertificate;binary' and some that expect
'userCertificate'.

Then there are servers that support either, and will return whichever
attribute name they think is correct, regardless of the request.

Then there are implementations that perform searches on, and return,
whichever name was used to store the certificate, without treating the
;binary transfer option specially. Requesting 'userCertificate' would
not return any 'userCertificate;binary' attribute stored in the entry,
and vice versa.

(IIRC, one older server could even store *both* userCertificate and
 userCertificate;binary in a single directory entry as separate,
 multi-valued attributes :-).

So sadly, the only thing a truly interoperable client can do is request
both and accept both; performing two searches and merging the results.
Nothing else covers all current implementations, in my implementation
experience.

-- 
Harald Koch     <[e-mail]>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAMEBYx20212 for ietf-pkix-bks; Fri, 22 Nov 2002 06:11:34 -0800 (PST)
Received: from hubie.hubbardind.com ([65.245.100.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAMEBVg20208 for <[e-mail]>; Fri, 22 Nov 2002 06:11:31 -0800 (PST)
Received: by hubie.hubbardind.com with Internet Mail Service (5.5.2653.19) id <W96JHH0J>; Fri, 22 Nov 2002 09:10:56 -0500
Message-ID: <[e-mail]>
From: Roger Younglove <[e-mail]>
To: [e-mail]
Subject: RE: Update of RFC 2527 - opposed
Date: Fri, 22 Nov 2002 09:10:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29230.F3EDD210"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C29230.F3EDD210
Content-Type: text/plain

Well said Richard. Certification of a PKI should be done by an qualified
auditor following  the State of Washington's requirements. There must be a
CP and CPS in order to audit and certify a PKI.
 
Roger Younglove, CISSP
 
 
-----Original Message-----
From: Guida, Richard [JJCUS] [mailto:[e-mail]] 
Sent: Friday, November 22, 2002 5:20 AM
To: Terwilliger, Ann; [e-mail]
Subject: RE: Update of RFC 2527 - opposed
 
I strongly agree with Ann and separate comments made by Dave Fillingham.  At
Johnson & Johnson we have both a CP and a CPS to 2527, and intend to use
those not only internally (as we are already doing for our PKI which is
built and run internally) but also, when the time comes, to interoperate
externally.  Trying to negotiate external interoperability without a CP/CPS
to a common standard would be very cumbersome at best and is unlikely to be
satisfying.  I fully agree that any external interoperability will require a
contract; but the trick will be negotiating that contract and deciding what
to include in it.  One might wind up with a contract that looks like a CP -
in which case, why not start with the CP and include it as an addendum to
the contract?  In essence, the CP to 2527 becomes standard boilerplate for a
contract where you wish to have someone else accept your certificates.  Also
note that under a confidentiality agreement, I would expect to have to
expose the CPS as well to the party with whom we wish to contract - to give
them assurance that we are indeed running our PKI as our CP prescribes.
But even if we were never to interoperate (i.e., never ask anyone else to
accept our certificates, or seek to accept others' certificates ourselves),
the CP and CPS provide a comprehensive framework for running a PKI and are
invaluable for that purpose alone.  I do not accept the argument that what
an unknowledgeable auditor may or may not do should dictate what is
appropriate, we should proceed to do what is sensible and then defend that
and, where necessary, educate the auditor to understand and appreciate that.
Relationships with auditors should be at arms length - they do not have to
be adversarial.  My 1 1/2 cents worth.
 
Richard A. Guida 
Director, Information Security (Medical Devices and Diagnostics) 
Johnson & Johnson 
One J&J Plaza, Room WH6132 
New Brunswick, New Jersey  08933 
E-mail: [e-mail] 
Office:  732 524 3785 
 
-----Original Message----- 
From: Terwilliger, Ann [mailto:[e-mail] <mailto:[e-mail]> ] 
Sent: Wednesday, November 20, 2002 6:50 PM 
To: [e-mail] 
Subject: RE: Update of RFC 2527 - opposed 
 
Another country is heard from...... 
Like Mack, I do not believe that automated review of a CP or CPS is 
practical (even though it might be desirable).  I also agree that in many, 
if not most, instances the CPS will not be made public.  However, I have to 
disagree with his conclusion that RFC 2527 is not relevant. 
RFC 2527 does provide a checklist for what areas need to be covered in 
establishing and operating a CA.  The fact that some of the questions are 
not as relevant today as they might have been when it was first drafted only

reinforces the fact that it should be updated to reflect current conditions.

There are other standards that address CA operation (e.g., X9.79, WebTrust 
Audit for CA, the ABA document) but virtually all reference RFC 2527. 
I would like to believe that all CA operators are knowledgeable about PKI 
and adhere to best practices for operating their CA.  However, that is a 
fairy tale--something on a par with the tooth fairy--and there needs to be 
some process to ensure that the CA has established good security practices 
and follows them.  Hence audits become necessary.    
Audits by their very nature are comparing something against a checklist or 
standard.  Auditors who are familiar with PKI are capable of adhering to the

spirit of the standard rather than the exact letter if parts of a standard 
do not apply.  Unfortunately auditors who are not familiar with PKI may 
perform audits more or less by rote.  To me this makes it more important, 
not less so, that we continue to update RFC 2527.  
  
-----Original Message----- 
From: Hicks, Mack [mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Wednesday, November 20, 2002 1:10 PM 
To: [e-mail] 
Subject: Update of RFC 2527 - opposed 
 
I have not posted on this list for some time, lurking has been fun though. I

will say something that some might consider radical. 
I thought you might like to know how some of the business world is looking 
at RFC 2527 and its impact on the PKI business. 
RFC 2527 is being used as a template and checklist by auditors and 
associations to perform reviews on certificate authorities. Each entry and 
topic of RFC 2527 must be covered by the CA or one gets an "audit exception"

or operations questions. This is done as a rote exercise.  Back when CAs 
were new, the checklist made sense - now some of the questions and sections 
is RFC 2527 are not as relevant to all CAs. 
I know of no use of the certificate policy in a business application; the 
policy is only there to tell any relying party that they should have a 
contract with someone before trusting this certificate. The meaning, impact,

legality, effectiveness, application, etc. of a certificate is addressed in 
contract (and subject to contract law - as I understand it). There is no 
detailed policy in the CP anymore. 
The practice among most banks I talk to is that the certificate practice 
statement (CPS) is an internal document about the operation of the CA and 
related software (OCSP, CRL, LDAP); the CPS is not made public. Therefore 
the original goal of automated or assisted examination of a CP and CPS by a 
relying party is thwarted. (I supported the automation goal, but it is not 
achievable.) 
It is useful that a certificate has a reference to a policy - but the 
construction and content of that policy is no longer relevant in the 
businesses that I see.  There is no use to a CPS except as an internal 
checklist on CA construction and operation and acts as a mill stone around 
the neck of CA operators - a barrier to entry into PKI.  Therefore RFC 2527 
is purely informational to constructing a CA; I would prefer that it move 
toward elimination as standard. 
 
Mack Hicks, SVP  
Bank of America  760-318-9345 

------_=_NextPart_001_01C29230.F3EDD210
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C29207.0D47F080">
<title>RE: Update of RFC 2527 - opposed</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Well said Richard. Certification =
of a PKI
should be done by an qualified auditor <span class=3DGramE>following =
<span
style=3D'mso-spacerun:yes'>&nbsp;</span>the</span> State of =
</span></font><st1:State><st1:place><font
  size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:navy'>Washington</span></font></st1:place></st1:State><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>'s requirements. There must be a CP and CPS in order to =
audit
and certify a PKI.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<div>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;mso-no-proof:yes'>Roger Younglove, =
CISSP<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;mso-no-proof:yes'><o:p>&nbsp;</o:p>=
</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Guida, Richard =
[JJCUS]
[mailto:[e-mail]<span class=3DGramE>] <br>
<b><span style=3D'font-weight:bold'>Sent</span></b></span><b><span
style=3D'font-weight:bold'>:</span></b> Friday, November 22, 2002 5:20 =
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Terwilliger, Ann;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Update of =
RFC 2527 -
opposed</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>I strongly agree with Ann and separate =
comments made
by Dave Fillingham.&nbsp; At Johnson &amp; Johnson we have both a CP =
and a CPS
to 2527, and intend to use those not only internally (as we are already =
doing
for our PKI which is built and run internally) but also, when the time =
comes,
to interoperate externally.&nbsp; Trying to negotiate external =
interoperability
without a CP/CPS to a common standard would be very cumbersome at best =
and is
unlikely to be satisfying.&nbsp; I fully agree that any external
interoperability will require a contract; but the trick will be =
negotiating
that contract and deciding what to include in it.&nbsp; One might wind =
up with
a contract that looks like a CP - in which case, why not start with the =
CP and include
it as an addendum to the contract?&nbsp; In essence, the CP to 2527 =
becomes
standard boilerplate for a contract where you wish to have someone else =
accept
your certificates.&nbsp; Also note that under a confidentiality =
agreement, I
would expect to have to expose the CPS as well to the party with whom =
we wish
to contract - to give them assurance that we are indeed running our PKI =
as our
CP prescribes.</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>But even if we were never to interoperate =
(i.e., never
ask anyone else to accept our certificates, or seek to accept others'
certificates ourselves), the CP and CPS provide a comprehensive =
framework for
running a PKI and are invaluable for that purpose alone.&nbsp; I do not =
accept
the argument that what an unknowledgeable auditor may or may not do =
should
dictate what is appropriate, we should proceed to do what is sensible =
and then
defend that and, where necessary, educate the auditor to understand and
appreciate that.&nbsp; Relationships with auditors should be at arms =
length -
they do not have to be adversarial.&nbsp; My 1 1/2 cents =
worth.</span></font><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:
12.0pt;margin-left:.5in'><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Richard A. Guida</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Director, Information =
Security
(Medical Devices and Diagnostics)</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Johnson &amp; Johnson</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>One J&amp;J Plaza, Room =
WH6132</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>New Brunswick, New =
Jersey&nbsp;
08933</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>E-mail: [e-mail]</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Office:&nbsp; 732 524 =
3785</span></font>
<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>-----Original Message-----</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>From: Terwilliger, Ann =
[<a
href=3D"mailto:[e-mail]">mailto:[e-mail]</a>]</span></fo=
nt> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Sent: Wednesday, =
November 20, 2002
6:50 PM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>To: =
[e-mail]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Subject: RE: Update of =
RFC 2527 -
opposed</span></font> <o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:
12.0pt;margin-left:.5in'><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Another country is heard =
from......</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Like Mack, I do not believe that automated =
review of a
CP or CPS is</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>practical (even though =
it might be
desirable).&nbsp; I also agree that in many,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>if not most, instances =
the CPS will
not be made public.&nbsp; However, I have to</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>disagree with his =
conclusion that RFC
2527 is not relevant.</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>RFC 2527 does provide a checklist for what =
areas need
to be covered in</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>establishing and =
operating a
CA.&nbsp; The fact that some of the questions are</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>not as relevant today =
as they might
have been when it was first drafted only</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>reinforces the fact =
that it should
be updated to reflect current conditions.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>There are other =
standards that
address CA operation (e.g., X9.79, WebTrust</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Audit for CA, the ABA =
document) but
virtually all reference RFC 2527. </span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>I would like to believe that all CA =
operators are
knowledgeable about PKI</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>and adhere to best =
practices for
operating their CA.&nbsp; However, that is a</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>fairy tale--something =
on a par with
the tooth fairy--and there needs to be</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>some process to ensure =
that the CA
has established good security practices</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>and follows them.&nbsp; =
Hence
audits become necessary.&nbsp;&nbsp;&nbsp; =
</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Audits by their very nature are comparing =
something
against a checklist or</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>standard.&nbsp; =
Auditors who are
familiar with PKI are capable of adhering to the</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>spirit of the standard =
rather than
the exact letter if parts of a standard</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>do not apply.&nbsp; =
Unfortunately
auditors who are not familiar with PKI may</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>perform audits more or =
less by
rote.&nbsp; To me this makes it more important,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>not less so, that we =
continue to
update RFC 2527.&nbsp; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&nbsp;</span></font> =
<o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>-----Original Message-----</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>From: Hicks, Mack [<a
href=3D"mailto:[e-mail]">mailto:Mack.Hicks@bankofame=
rica.com</a>]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Sent: Wednesday, =
November 20, 2002
1:10 PM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>To: =
[e-mail]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Subject: Update of RFC =
2527 -
opposed</span></font> <o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:
12.0pt;margin-left:.5in'><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>I have not posted on this list for some =
time, lurking
has been fun though. I</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>will say something that =
some might
consider radical.</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>I thought you might like to know how some of =
the
business world is looking</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>at RFC 2527 and its =
impact on the
PKI business.</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>RFC 2527 is being used as a template and =
checklist by
auditors and</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>associations to perform =
reviews on
certificate authorities. Each entry and</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>topic of RFC 2527 must =
be covered
by the CA or one gets an &quot;audit exception&quot;</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>or operations =
questions. This is done
as a rote exercise.&nbsp; Back when CAs</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>were new, the checklist =
made sense
- now some of the questions and sections</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>is RFC 2527 are not as =
relevant to
all CAs.</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>I know of no use of the certificate policy =
in a
business application; the</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>policy is only there to =
tell any
relying party that they should have a</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>contract with someone =
before
trusting this certificate. The meaning, impact,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>legality, =
effectiveness,
application, etc. of a certificate is addressed in</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>contract (and subject =
to contract
law - as I understand it). There is no</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>detailed policy in the =
CP anymore.</span></font>
<o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>The practice among most banks I talk to is =
that the
certificate practice</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>statement (CPS) is an =
internal
document about the operation of the CA and</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>related software (OCSP, =
CRL, LDAP);
the CPS is not made public. Therefore</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>the original goal of =
automated or
assisted examination of a CP and CPS by a</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>relying party is =
thwarted. (I
supported the automation goal, but it is not</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>achievable.)</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>It is useful that a certificate has a =
reference to a
policy - but the</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>construction and =
content of that
policy is no longer relevant in the</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>businesses that I =
see.&nbsp; There
is no use to a CPS except as an internal</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>checklist on CA =
construction and
operation and acts as a mill stone around</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>the neck of CA =
operators - a
barrier to entry into PKI.&nbsp; Therefore RFC 2527</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>is purely informational =
to
constructing a CA; I would prefer that it move</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>toward elimination as =
standard.</span></font>
<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:
12.0pt;margin-left:.5in'><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Mack Hicks, SVP&nbsp; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>Bank of America&nbsp; =
760-318-9345</span></font>
<o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C29230.F3EDD210--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAMDIOU17780 for ietf-pkix-bks; Fri, 22 Nov 2002 05:18:24 -0800 (PST)
Received: from hubie.hubbardind.com ([65.245.100.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAMDILg17772 for <[e-mail]>; Fri, 22 Nov 2002 05:18:22 -0800 (PST)
Received: by hubie.hubbardind.com with Internet Mail Service (5.5.2653.19) id <W96JHH7S>; Fri, 22 Nov 2002 08:17:46 -0500
Message-ID: <[e-mail]>
From: Roger Younglove <[e-mail]>
To: [e-mail]
Subject: RE: Request for IESG consideration: CP/CPS Framework
Date: Fri, 22 Nov 2002 08:17:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29229.8BB785D0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C29229.8BB785D0
Content-Type: text/plain

Marc,
You are correct in that the CPS is required for auditing of a CA
installation. It is some times published in a diminished form not ever
fully. The only people that should be concerned with the CP are the relying
parties and any other CA wishing to cross certify.

Roger Younglove, CISSP
Principal Consultant
NetWorks Group
O. 810.225.4800 ex. 2245
M. 810.599.0879
E. [e-mail]
www.networksgroup.com
 

-----Original Message-----
From: Marc Poulaud [mailto:[e-mail]] 
Sent: Friday, November 22, 2002 4:19 AM
To: [e-mail]
Subject: RE: Request for IESG consideration: CP/CPS Framework

David,

I agree with most of your points here. There has been much confusion over
the purpose and applicability of a CP and CPS. Even in my experience of
the banking sector/scheme space. One additional way of looking at the
difference is the CP specifies the 'what' and the CPS specifies the 'how',
and as such I think having the 2527 framework makes sense from this
perspective (although having had to write these pairs, it's not as easy as
it sounds) and I'm not convinced of the value.

Also, from my banking scheme experience, the CPS is confidential but
includes the subscribing customer, but not the relying customer. A fairly
light and common CP across both parties essentially points to a Customer
Agreement that takes into account a common set of contractual agreement
clauses. This is what binds the parties together from a legal perspective
and hence the level of trust.

In the real world, does anybody really check or care what is in a CP or
the CPS? I think it depends on the circumstances and the scheme around
this.

>From my point of view, a CPS is generally a good-practice as it focuses
the CA provider and auditors minds. A CP is good because it can point to a
legal/contractual framework.

Also to consider are signature policies - shirely any framework/changes
should take into account of these too.

Marc.
-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Adrian McCullagh
Sent: 22 November 2002 05:58
To: Fillingham, David W.
Cc: 'Adrian McCullagh'; [e-mail]; [e-mail]; Jeffrey
I. Schiller; [e-mail]; 'Paul Hoffman / IMC';
[e-mail]
Subject: RE: Request for IESG consideration: CP/CPS Framework




Dear David,

If one looks at the raison d'etre for a CPS it is very different to that
of
the CP.

It is my understanding, and I am open to any correction, that a CPS is a
document that details the practices and procedures established by a CA
that
will cover the life-cycle of certificates issued by the CA.  That is it
covers how the certificate will be generated, suspended and revoked.  An
internally focused document covering the internal environment of the CA.
Much like an operations manual for a CA business as they relate to
certificates.

The CP is a very different document which will usually be relied upon by
the relying party and to a certain extent the subscriber.  RFC 2527 states
:

'According to X.509, a certificate policy (CP) is "a named
set of rules that indicates the applicability of a certificate to a
particular community and/or class of applications with common
security requirements."
A CP may be used by a relying party to help
in deciding whether a certificate, and the binding therein, are
sufficiently trustworthy and otherwise appropriate for a particular
application.'

Hence my query as to the applicability of RFC 2527 to the CP.  RFC 2527
concentrates of the internal practices of the CA, which is really the
function of a CPS.  I believe that a separate RFC should be established
that specifically covers the rules that govern the use of a certificate by
a relying party.  This RFC should be much more concise than RFC 2527.
Hence my comment that I believe RFC 2527 to be inappropriate for a CP and
thus overly complex.

It is interesting that the Banking sector has taken the view that a CPS is
an internal document, which I have no problem with, and therefore will not
be published.  A CP on the other hand does need to be published otherwise
the relying party will not be in a position to ascertain/determine any
trust value for the transaction as it relates to the digital signature for
verification.

Dr. Adrian McCullagh Ph. D.
Solicitor/lawyer
Freehills, Australia

Direct 61 7 3258 6603
Telephone [phone]
Facsimile 61 7 3258 6444
http://www.freehills.com

--------------------------------------------------------------------
FREEHILLS
This email is confidential.  If you are not the intended  recipient,
you must not disclose  or  use the  information  contained in it. If
you have received this email in error,  please notify us immediately
by return email and delete the document.
Freehills is not responsible for any changes made to a document other
than those made by Freehills or for the effect of the changes on the
document's meaning.

Liability is limited by the Solicitors' Limitation of Liability Scheme,
approved under the Professional Standards Act 1994 (NSW)
--------------------------------------------------------------------



------_=_NextPart_001_01C29229.8BB785D0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Request for IESG consideration: CP/CPS Framework</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Marc,</FONT>
<BR><FONT SIZE=3D2>You are correct in that the CPS is required for =
auditing of a CA installation. It is some times published in a =
diminished form not ever fully. The only people that should be =
concerned with the CP are the relying parties and any other CA wishing =
to cross certify.</FONT></P>

<P><FONT SIZE=3D2>Roger Younglove, CISSP</FONT>
<BR><FONT SIZE=3D2>Principal Consultant</FONT>
<BR><FONT SIZE=3D2>NetWorks Group</FONT>
<BR><FONT SIZE=3D2>O. 810.225.4800 ex. 2245</FONT>
<BR><FONT SIZE=3D2>M. 810.599.0879</FONT>
<BR><FONT SIZE=3D2>E. [e-mail]</FONT>
<BR><FONT SIZE=3D2>www.networksgroup.com</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Marc Poulaud [<A =
HREF=3D"mailto:[e-mail]">mailto:marc.poulaud@i-solve.c=
o.uk</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Friday, November 22, 2002 4:19 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Request for IESG consideration: CP/CPS =
Framework</FONT>
</P>

<P><FONT SIZE=3D2>David,</FONT>
</P>

<P><FONT SIZE=3D2>I agree with most of your points here. There has been =
much confusion over</FONT>
<BR><FONT SIZE=3D2>the purpose and applicability of a CP and CPS. Even =
in my experience of</FONT>
<BR><FONT SIZE=3D2>the banking sector/scheme space. One additional way =
of looking at the</FONT>
<BR><FONT SIZE=3D2>difference is the CP specifies the 'what' and the =
CPS specifies the 'how',</FONT>
<BR><FONT SIZE=3D2>and as such I think having the 2527 framework makes =
sense from this</FONT>
<BR><FONT SIZE=3D2>perspective (although having had to write these =
pairs, it's not as easy as</FONT>
<BR><FONT SIZE=3D2>it sounds) and I'm not convinced of the =
value.</FONT>
</P>

<P><FONT SIZE=3D2>Also, from my banking scheme experience, the CPS is =
confidential but</FONT>
<BR><FONT SIZE=3D2>includes the subscribing customer, but not the =
relying customer. A fairly</FONT>
<BR><FONT SIZE=3D2>light and common CP across both parties essentially =
points to a Customer</FONT>
<BR><FONT SIZE=3D2>Agreement that takes into account a common set of =
contractual agreement</FONT>
<BR><FONT SIZE=3D2>clauses. This is what binds the parties together =
from a legal perspective</FONT>
<BR><FONT SIZE=3D2>and hence the level of trust.</FONT>
</P>

<P><FONT SIZE=3D2>In the real world, does anybody really check or care =
what is in a CP or</FONT>
<BR><FONT SIZE=3D2>the CPS? I think it depends on the circumstances and =
the scheme around</FONT>
<BR><FONT SIZE=3D2>this.</FONT>
</P>

<P><FONT SIZE=3D2>From my point of view, a CPS is generally a =
good-practice as it focuses</FONT>
<BR><FONT SIZE=3D2>the CA provider and auditors minds. A CP is good =
because it can point to a</FONT>
<BR><FONT SIZE=3D2>legal/contractual framework.</FONT>
</P>

<P><FONT SIZE=3D2>Also to consider are signature policies - shirely any =
framework/changes</FONT>
<BR><FONT SIZE=3D2>should take into account of these too.</FONT>
</P>

<P><FONT SIZE=3D2>Marc.</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [e-mail]</FONT>
<BR><FONT SIZE=3D2>[<A =
HREF=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail=
.imc.org</A>]On Behalf Of Adrian McCullagh</FONT>
<BR><FONT SIZE=3D2>Sent: 22 November 2002 05:58</FONT>
<BR><FONT SIZE=3D2>To: Fillingham, David W.</FONT>
<BR><FONT SIZE=3D2>Cc: 'Adrian McCullagh'; [e-mail]; =
[e-mail]; Jeffrey</FONT>
<BR><FONT SIZE=3D2>I. Schiller; [e-mail]; 'Paul =
Hoffman / IMC';</FONT>
<BR><FONT SIZE=3D2>[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Request for IESG consideration: CP/CPS =
Framework</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Dear David,</FONT>
</P>

<P><FONT SIZE=3D2>If one looks at the raison d'etre for a CPS it is =
very different to that</FONT>
<BR><FONT SIZE=3D2>of</FONT>
<BR><FONT SIZE=3D2>the CP.</FONT>
</P>

<P><FONT SIZE=3D2>It is my understanding, and I am open to any =
correction, that a CPS is a</FONT>
<BR><FONT SIZE=3D2>document that details the practices and procedures =
established by a CA</FONT>
<BR><FONT SIZE=3D2>that</FONT>
<BR><FONT SIZE=3D2>will cover the life-cycle of certificates issued by =
the CA.&nbsp; That is it</FONT>
<BR><FONT SIZE=3D2>covers how the certificate will be generated, =
suspended and revoked.&nbsp; An</FONT>
<BR><FONT SIZE=3D2>internally focused document covering the internal =
environment of the CA.</FONT>
<BR><FONT SIZE=3D2>Much like an operations manual for a CA business as =
they relate to</FONT>
<BR><FONT SIZE=3D2>certificates.</FONT>
</P>

<P><FONT SIZE=3D2>The CP is a very different document which will =
usually be relied upon by</FONT>
<BR><FONT SIZE=3D2>the relying party and to a certain extent the =
subscriber.&nbsp; RFC 2527 states</FONT>
<BR><FONT SIZE=3D2>:</FONT>
</P>

<P><FONT SIZE=3D2>'According to X.509, a certificate policy (CP) is =
&quot;a named</FONT>
<BR><FONT SIZE=3D2>set of rules that indicates the applicability of a =
certificate to a</FONT>
<BR><FONT SIZE=3D2>particular community and/or class of applications =
with common</FONT>
<BR><FONT SIZE=3D2>security requirements.&quot;</FONT>
<BR><FONT SIZE=3D2>A CP may be used by a relying party to help</FONT>
<BR><FONT SIZE=3D2>in deciding whether a certificate, and the binding =
therein, are</FONT>
<BR><FONT SIZE=3D2>sufficiently trustworthy and otherwise appropriate =
for a particular</FONT>
<BR><FONT SIZE=3D2>application.'</FONT>
</P>

<P><FONT SIZE=3D2>Hence my query as to the applicability of RFC 2527 to =
the CP.&nbsp; RFC 2527</FONT>
<BR><FONT SIZE=3D2>concentrates of the internal practices of the CA, =
which is really the</FONT>
<BR><FONT SIZE=3D2>function of a CPS.&nbsp; I believe that a separate =
RFC should be established</FONT>
<BR><FONT SIZE=3D2>that specifically covers the rules that govern the =
use of a certificate by</FONT>
<BR><FONT SIZE=3D2>a relying party.&nbsp; This RFC should be much more =
concise than RFC 2527.</FONT>
<BR><FONT SIZE=3D2>Hence my comment that I believe RFC 2527 to be =
inappropriate for a CP and</FONT>
<BR><FONT SIZE=3D2>thus overly complex.</FONT>
</P>

<P><FONT SIZE=3D2>It is interesting that the Banking sector has taken =
the view that a CPS is</FONT>
<BR><FONT SIZE=3D2>an internal document, which I have no problem with, =
and therefore will not</FONT>
<BR><FONT SIZE=3D2>be published.&nbsp; A CP on the other hand does need =
to be published otherwise</FONT>
<BR><FONT SIZE=3D2>the relying party will not be in a position to =
ascertain/determine any</FONT>
<BR><FONT SIZE=3D2>trust value for the transaction as it relates to the =
digital signature for</FONT>
<BR><FONT SIZE=3D2>verification.</FONT>
</P>

<P><FONT SIZE=3D2>Dr. Adrian McCullagh Ph. D.</FONT>
<BR><FONT SIZE=3D2>Solicitor/lawyer</FONT>
<BR><FONT SIZE=3D2>Freehills, Australia</FONT>
</P>

<P><FONT SIZE=3D2>Direct 61 7 3258 6603</FONT>
<BR><FONT SIZE=3D2>Telephone [phone]</FONT>
<BR><FONT SIZE=3D2>Facsimile 61 7 3258 6444</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.freehills.com" =
TARGET=3D"_blank">http://www.freehills.com</A></FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-----</FONT>
<BR><FONT SIZE=3D2>FREEHILLS</FONT>
<BR><FONT SIZE=3D2>This email is confidential.&nbsp; If you are not the =
intended&nbsp; recipient,</FONT>
<BR><FONT SIZE=3D2>you must not disclose&nbsp; or&nbsp; use the&nbsp; =
information&nbsp; contained in it. If</FONT>
<BR><FONT SIZE=3D2>you have received this email in error,&nbsp; please =
notify us immediately</FONT>
<BR><FONT SIZE=3D2>by return email and delete the document.</FONT>
<BR><FONT SIZE=3D2>Freehills is not responsible for any changes made to =
a document other</FONT>
<BR><FONT SIZE=3D2>than those made by Freehills or for the effect of =
the changes on the</FONT>
<BR><FONT SIZE=3D2>document's meaning.</FONT>
</P>

<P><FONT SIZE=3D2>Liability is limited by the Solicitors' Limitation of =
Liability Scheme,</FONT>
<BR><FONT SIZE=3D2>approved under the Professional Standards Act 1994 =
(NSW)</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
-----</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C29229.8BB785D0--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAMAKUQ05140 for ietf-pkix-bks; Fri, 22 Nov 2002 02:20:30 -0800 (PST)
Received: from ncsusraimge01.jnj.com (ncsusraimge01.jnj.com [148.177.2.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAMAKRg05135 for <[e-mail]>; Fri, 22 Nov 2002 02:20:28 -0800 (PST)
Received: from NCSUSRAWSC2.na.jnj.com (NCSUSRAWSC2.na.jnj.com [10.4.20.22]) by ncsusraimge01.jnj.com (Switch-3.0.0/Switch-3.0.0) with SMTP id gAMAGOxW012744 for <[e-mail]>; Fri, 22 Nov 2002 05:16:29 -0500 (EST)
Received: FROM ncsusraexims2.rar.ncsus.jnj.com BY NCSUSRAWSC2.na.jnj.com ; Fri Nov 22 05:20:11 2002 -0500
Received: by ncsusraexims2.rar.ncsus.jnj.com with Internet Mail Service (5.5.2653.19) id <W7TZ91QG>; Fri, 22 Nov 2002 05:20:16 -0500
Message-ID: <[e-mail]>
From: "Guida, Richard [JJCUS]" <[e-mail]>
To: "Terwilliger, Ann" <[e-mail]>, [e-mail]
Subject: RE: Update of RFC 2527 - opposed
Date: Fri, 22 Nov 2002 05:20:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29210.BEF0ECAC"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C29210.BEF0ECAC
Content-Type: text/plain;
	charset="iso-8859-1"

I strongly agree with Ann and separate comments made by Dave Fillingham.  At
Johnson & Johnson we have both a CP and a CPS to 2527, and intend to use
those not only internally (as we are already doing for our PKI which is
built and run internally) but also, when the time comes, to interoperate
externally.  Trying to negotiate external interoperability without a CP/CPS
to a common standard would be very cumbersome at best and is unlikely to be
satisfying.  I fully agree that any external interoperability will require a
contract; but the trick will be negotiating that contract and deciding what
to include in it.  One might wind up with a contract that looks like a CP -
in which case, why not start with the CP and include it as an addendum to
the contract?  In essence, the CP to 2527 becomes standard boilerplate for a
contract where you wish to have someone else accept your certificates.  Also
note that under a confidentiality agreement, I would expect to have to
expose the CPS as well to the party with whom we wish to contract - to give
them assurance that we are indeed running our PKI as our CP prescribes.

But even if we were never to interoperate (i.e., never ask anyone else to
accept our certificates, or seek to accept others' certificates ourselves),
the CP and CPS provide a comprehensive framework for running a PKI and are
invaluable for that purpose alone.  I do not accept the argument that what
an unknowledgeable auditor may or may not do should dictate what is
appropriate, we should proceed to do what is sensible and then defend that
and, where necessary, educate the auditor to understand and appreciate that.
Relationships with auditors should be at arms length - they do not have to
be adversarial.  My 1 1/2 cents worth.



Richard A. Guida
Director, Information Security (Medical Devices and Diagnostics)

Johnson & Johnson
One J&J Plaza, Room WH6132
New Brunswick, New Jersey  08933

E-mail: [e-mail]
Office:  732 524 3785


-----Original Message-----
From: Terwilliger, Ann [mailto:[e-mail]]
Sent: Wednesday, November 20, 2002 6:50 PM
To: [e-mail]
Subject: RE: Update of RFC 2527 - opposed



Another country is heard from......

Like Mack, I do not believe that automated review of a CP or CPS is
practical (even though it might be desirable).  I also agree that in many,
if not most, instances the CPS will not be made public.  However, I have to
disagree with his conclusion that RFC 2527 is not relevant.

RFC 2527 does provide a checklist for what areas need to be covered in
establishing and operating a CA.  The fact that some of the questions are
not as relevant today as they might have been when it was first drafted only
reinforces the fact that it should be updated to reflect current conditions.
There are other standards that address CA operation (e.g., X9.79, WebTrust
Audit for CA, the ABA document) but virtually all reference RFC 2527. 

I would like to believe that all CA operators are knowledgeable about PKI
and adhere to best practices for operating their CA.  However, that is a
fairy tale--something on a par with the tooth fairy--and there needs to be
some process to ensure that the CA has established good security practices
and follows them.  Hence audits become necessary.    

Audits by their very nature are comparing something against a checklist or
standard.  Auditors who are familiar with PKI are capable of adhering to the
spirit of the standard rather than the exact letter if parts of a standard
do not apply.  Unfortunately auditors who are not familiar with PKI may
perform audits more or less by rote.  To me this makes it more important,
not less so, that we continue to update RFC 2527.  
 

-----Original Message-----
From: Hicks, Mack [mailto:[e-mail]]
Sent: Wednesday, November 20, 2002 1:10 PM
To: [e-mail]
Subject: Update of RFC 2527 - opposed



I have not posted on this list for some time, lurking has been fun though. I
will say something that some might consider radical.

I thought you might like to know how some of the business world is looking
at RFC 2527 and its impact on the PKI business.

RFC 2527 is being used as a template and checklist by auditors and
associations to perform reviews on certificate authorities. Each entry and
topic of RFC 2527 must be covered by the CA or one gets an "audit exception"
or operations questions. This is done as a rote exercise.  Back when CAs
were new, the checklist made sense - now some of the questions and sections
is RFC 2527 are not as relevant to all CAs.

I know of no use of the certificate policy in a business application; the
policy is only there to tell any relying party that they should have a
contract with someone before trusting this certificate. The meaning, impact,
legality, effectiveness, application, etc. of a certificate is addressed in
contract (and subject to contract law - as I understand it). There is no
detailed policy in the CP anymore.

The practice among most banks I talk to is that the certificate practice
statement (CPS) is an internal document about the operation of the CA and
related software (OCSP, CRL, LDAP); the CPS is not made public. Therefore
the original goal of automated or assisted examination of a CP and CPS by a
relying party is thwarted. (I supported the automation goal, but it is not
achievable.)

It is useful that a certificate has a reference to a policy - but the
construction and content of that policy is no longer relevant in the
businesses that I see.  There is no use to a CPS except as an internal
checklist on CA construction and operation and acts as a mill stone around
the neck of CA operators - a barrier to entry into PKI.  Therefore RFC 2527
is purely informational to constructing a CA; I would prefer that it move
toward elimination as standard.



Mack Hicks, SVP  
Bank of America  760-318-9345

------_=_NextPart_001_01C29210.BEF0ECAC
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: Update of RFC 2527 - opposed</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I strongly agree with Ann and separate comments made =
by Dave Fillingham.&nbsp; At Johnson &amp; Johnson we have both a CP =
and a CPS to 2527, and intend to use those not only internally (as we =
are already doing for our PKI which is built and run internally) but =
also, when the time comes, to interoperate externally.&nbsp; Trying to =
negotiate external interoperability without a CP/CPS to a common =
standard would be very cumbersome at best and is unlikely to be =
satisfying.&nbsp; I fully agree that any external interoperability will =
require a contract; but the trick will be negotiating that contract and =
deciding what to include in it.&nbsp; One might wind up with a contract =
that looks like a CP - in which case, why not start with the CP and =
include it as an addendum to the contract?&nbsp; In essence, the CP to =
2527 becomes standard boilerplate for a contract where you wish to have =
someone else accept your certificates.&nbsp; Also note that under a =
confidentiality agreement, I would expect to have to expose the CPS as =
well to the party with whom we wish to contract - to give them =
assurance that we are indeed running our PKI as our CP =
prescribes.</FONT></P>

<P><FONT SIZE=3D2>But even if we were never to interoperate (i.e., =
never ask anyone else to accept our certificates, or seek to accept =
others' certificates ourselves), the CP and CPS provide a comprehensive =
framework for running a PKI and are invaluable for that purpose =
alone.&nbsp; I do not accept the argument that what an unknowledgeable =
auditor may or may not do should dictate what is appropriate, we should =
proceed to do what is sensible and then defend that and, where =
necessary, educate the auditor to understand and appreciate that.&nbsp; =
Relationships with auditors should be at arms length - they do not have =
to be adversarial.&nbsp; My 1 1/2 cents worth.</FONT></P>
<BR>
<BR>

<P><FONT SIZE=3D2>Richard A. Guida</FONT>
<BR><FONT SIZE=3D2>Director, Information Security (Medical Devices and =
Diagnostics)</FONT>
</P>

<P><FONT SIZE=3D2>Johnson &amp; Johnson</FONT>
<BR><FONT SIZE=3D2>One J&amp;J Plaza, Room WH6132</FONT>
<BR><FONT SIZE=3D2>New Brunswick, New Jersey&nbsp; 08933</FONT>
</P>

<P><FONT SIZE=3D2>E-mail: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Office:&nbsp; 732 524 3785</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Terwilliger, Ann [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, November 20, 2002 6:50 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Update of RFC 2527 - opposed</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Another country is heard from......</FONT>
</P>

<P><FONT SIZE=3D2>Like Mack, I do not believe that automated review of =
a CP or CPS is</FONT>
<BR><FONT SIZE=3D2>practical (even though it might be desirable).&nbsp; =
I also agree that in many,</FONT>
<BR><FONT SIZE=3D2>if not most, instances the CPS will not be made =
public.&nbsp; However, I have to</FONT>
<BR><FONT SIZE=3D2>disagree with his conclusion that RFC 2527 is not =
relevant.</FONT>
</P>

<P><FONT SIZE=3D2>RFC 2527 does provide a checklist for what areas need =
to be covered in</FONT>
<BR><FONT SIZE=3D2>establishing and operating a CA.&nbsp; The fact that =
some of the questions are</FONT>
<BR><FONT SIZE=3D2>not as relevant today as they might have been when =
it was first drafted only</FONT>
<BR><FONT SIZE=3D2>reinforces the fact that it should be updated to =
reflect current conditions.</FONT>
<BR><FONT SIZE=3D2>There are other standards that address CA operation =
(e.g., X9.79, WebTrust</FONT>
<BR><FONT SIZE=3D2>Audit for CA, the ABA document) but virtually all =
reference RFC 2527. </FONT>
</P>

<P><FONT SIZE=3D2>I would like to believe that all CA operators are =
knowledgeable about PKI</FONT>
<BR><FONT SIZE=3D2>and adhere to best practices for operating their =
CA.&nbsp; However, that is a</FONT>
<BR><FONT SIZE=3D2>fairy tale--something on a par with the tooth =
fairy--and there needs to be</FONT>
<BR><FONT SIZE=3D2>some process to ensure that the CA has established =
good security practices</FONT>
<BR><FONT SIZE=3D2>and follows them.&nbsp; Hence audits become =
necessary.&nbsp;&nbsp;&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Audits by their very nature are comparing something =
against a checklist or</FONT>
<BR><FONT SIZE=3D2>standard.&nbsp; Auditors who are familiar with PKI =
are capable of adhering to the</FONT>
<BR><FONT SIZE=3D2>spirit of the standard rather than the exact letter =
if parts of a standard</FONT>
<BR><FONT SIZE=3D2>do not apply.&nbsp; Unfortunately auditors who are =
not familiar with PKI may</FONT>
<BR><FONT SIZE=3D2>perform audits more or less by rote.&nbsp; To me =
this makes it more important,</FONT>
<BR><FONT SIZE=3D2>not less so, that we continue to update RFC =
2527.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Hicks, Mack [<A =
HREF=3D"mailto:[e-mail]">mailto:Mack.Hicks@bankofame=
rica.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, November 20, 2002 1:10 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Update of RFC 2527 - opposed</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>I have not posted on this list for some time, lurking =
has been fun though. I</FONT>
<BR><FONT SIZE=3D2>will say something that some might consider =
radical.</FONT>
</P>

<P><FONT SIZE=3D2>I thought you might like to know how some of the =
business world is looking</FONT>
<BR><FONT SIZE=3D2>at RFC 2527 and its impact on the PKI =
business.</FONT>
</P>

<P><FONT SIZE=3D2>RFC 2527 is being used as a template and checklist by =
auditors and</FONT>
<BR><FONT SIZE=3D2>associations to perform reviews on certificate =
authorities. Each entry and</FONT>
<BR><FONT SIZE=3D2>topic of RFC 2527 must be covered by the CA or one =
gets an &quot;audit exception&quot;</FONT>
<BR><FONT SIZE=3D2>or operations questions. This is done as a rote =
exercise.&nbsp; Back when CAs</FONT>
<BR><FONT SIZE=3D2>were new, the checklist made sense - now some of the =
questions and sections</FONT>
<BR><FONT SIZE=3D2>is RFC 2527 are not as relevant to all CAs.</FONT>
</P>

<P><FONT SIZE=3D2>I know of no use of the certificate policy in a =
business application; the</FONT>
<BR><FONT SIZE=3D2>policy is only there to tell any relying party that =
they should have a</FONT>
<BR><FONT SIZE=3D2>contract with someone before trusting this =
certificate. The meaning, impact,</FONT>
<BR><FONT SIZE=3D2>legality, effectiveness, application, etc. of a =
certificate is addressed in</FONT>
<BR><FONT SIZE=3D2>contract (and subject to contract law - as I =
understand it). There is no</FONT>
<BR><FONT SIZE=3D2>detailed policy in the CP anymore.</FONT>
</P>

<P><FONT SIZE=3D2>The practice among most banks I talk to is that the =
certificate practice</FONT>
<BR><FONT SIZE=3D2>statement (CPS) is an internal document about the =
operation of the CA and</FONT>
<BR><FONT SIZE=3D2>related software (OCSP, CRL, LDAP); the CPS is not =
made public. Therefore</FONT>
<BR><FONT SIZE=3D2>the original goal of automated or assisted =
examination of a CP and CPS by a</FONT>
<BR><FONT SIZE=3D2>relying party is thwarted. (I supported the =
automation goal, but it is not</FONT>
<BR><FONT SIZE=3D2>achievable.)</FONT>
</P>

<P><FONT SIZE=3D2>It is useful that a certificate has a reference to a =
policy - but the</FONT>
<BR><FONT SIZE=3D2>construction and content of that policy is no longer =
relevant in the</FONT>
<BR><FONT SIZE=3D2>businesses that I see.&nbsp; There is no use to a =
CPS except as an internal</FONT>
<BR><FONT SIZE=3D2>checklist on CA construction and operation and acts =
as a mill stone around</FONT>
<BR><FONT SIZE=3D2>the neck of CA operators - a barrier to entry into =
PKI.&nbsp; Therefore RFC 2527</FONT>
<BR><FONT SIZE=3D2>is purely informational to constructing a CA; I =
would prefer that it move</FONT>
<BR><FONT SIZE=3D2>toward elimination as standard.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Mack Hicks, SVP&nbsp; </FONT>
<BR><FONT SIZE=3D2>Bank of America&nbsp; 760-318-9345</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C29210.BEF0ECAC--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAM9JXD26205 for ietf-pkix-bks; Fri, 22 Nov 2002 01:19:33 -0800 (PST)
Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAM9JUg26201 for <[e-mail]>; Fri, 22 Nov 2002 01:19:31 -0800 (PST)
Received: from f67j40j ([80.5.45.65]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20021122091929.BQYF29094.mta06-svc.ntlworld.com@f67j40j> for <[e-mail]>; Fri, 22 Nov 2002 09:19:29 +0000
From: "Marc Poulaud" <[e-mail]>
To: <[e-mail]>
Subject: RE: Request for IESG consideration: CP/CPS Framework
Date: Fri, 22 Nov 2002 09:19:12 -0000
MIME-Version: 1.0
Message-ID: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0023_01C29208.35DF1040"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0023_01C29208.35DF1040
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

David,

I agree with most of your points here. There has been much confusion over
the purpose and applicability of a CP and CPS. Even in my experience of
the banking sector/scheme space. One additional way of looking at the
difference is the CP specifies the 'what' and the CPS specifies the 'how',
and as such I think having the 2527 framework makes sense from this
perspective (although having had to write these pairs, it's not as easy as
it sounds) and I'm not convinced of the value.

Also, from my banking scheme experience, the CPS is confidential but
includes the subscribing customer, but not the relying customer. A fairly
light and common CP across both parties essentially points to a Customer
Agreement that takes into account a common set of contractual agreement
clauses. This is what binds the parties together from a legal perspective
and hence the level of trust.

In the real world, does anybody really check or care what is in a CP or
the CPS? I think it depends on the circumstances and the scheme around
this.

>From my point of view, a CPS is generally a good-practice as it focuses
the CA provider and auditors minds. A CP is good because it can point to a
legal/contractual framework.

Also to consider are signature policies - shirely any framework/changes
should take into account of these too.

Marc.
-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Adrian McCullagh
Sent: 22 November 2002 05:58
To: Fillingham, David W.
Cc: 'Adrian McCullagh'; [e-mail]; [e-mail]; Jeffrey
I. Schiller; [e-mail]; 'Paul Hoffman / IMC';
[e-mail]
Subject: RE: Request for IESG consideration: CP/CPS Framework




Dear David,

If one looks at the raison d'etre for a CPS it is very different to that
of
the CP.

It is my understanding, and I am open to any correction, that a CPS is a
document that details the practices and procedures established by a CA
that
will cover the life-cycle of certificates issued by the CA.  That is it
covers how the certificate will be generated, suspended and revoked.  An
internally focused document covering the internal environment of the CA.
Much like an operations manual for a CA business as they relate to
certificates.

The CP is a very different document which will usually be relied upon by
the relying party and to a certain extent the subscriber.  RFC 2527 states
:

'According to X.509, a certificate policy (CP) is "a named
set of rules that indicates the applicability of a certificate to a
particular community and/or class of applications with common
security requirements."
A CP may be used by a relying party to help
in deciding whether a certificate, and the binding therein, are
sufficiently trustworthy and otherwise appropriate for a particular
application.'

Hence my query as to the applicability of RFC 2527 to the CP.  RFC 2527
concentrates of the internal practices of the CA, which is really the
function of a CPS.  I believe that a separate RFC should be established
that specifically covers the rules that govern the use of a certificate by
a relying party.  This RFC should be much more concise than RFC 2527.
Hence my comment that I believe RFC 2527 to be inappropriate for a CP and
thus overly complex.

It is interesting that the Banking sector has taken the view that a CPS is
an internal document, which I have no problem with, and therefore will not
be published.  A CP on the other hand does need to be published otherwise
the relying party will not be in a position to ascertain/determine any
trust value for the transaction as it relates to the digital signature for
verification.

Dr. Adrian McCullagh Ph. D.
Solicitor/lawyer
Freehills, Australia

Direct 61 7 3258 6603
Telephone [phone]
Facsimile 61 7 3258 6444
http://www.freehills.com

--------------------------------------------------------------------
FREEHILLS
This email is confidential.  If you are not the intended  recipient,
you must not disclose  or  use the  information  contained in it. If
you have received this email in error,  please notify us immediately
by return email and delete the document.
Freehills is not responsible for any changes made to a document other
than those made by Freehills or for the effect of the changes on the
document's meaning.

Liability is limited by the Solicitors' Limitation of Liability Scheme,
approved under the Professional Standards Act 1994 (NSW)
--------------------------------------------------------------------



------=_NextPart_000_0023_01C29208.35DF1040
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKITCCAj0w
ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH
mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF
4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d
6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix
3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR
cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy
MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL
uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj
zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw
RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD
gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h
U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1
E3LnQDGa07LEq+dWvovj+xUwggR2MIID36ADAgECAhB/l4yg+FrgmGLkay+Z3cRwMA0GCSqGSIb3
DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMTAwNzAwMDAw
MFoXDTAzMTAwNzIzNTk1OVowggEaMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW
VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0
b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs
bCBTZXJ2aWNlMRUwEwYDVQQDFAxNYXJjIFBvdWxhdWQxKTAnBgkqhkiG9w0BCQEWGm1hcmMucG91
bGF1ZEBpLXNvbHZlLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDfd3CCaom3tU0P
mdCz0ggSdD8UNJMSVDPou1CJjsLvYpwUySsSQgUdYdFjvQmheBDL2z0T3dX1mvce5WJrDg5fcWQG
aUmQbubJ0qxdK5uT4IkNJx9s1PPDfOEj4PdJExyyG0Cbsvwo8Wyq+xnRlCcMzwm4D/XNnXqkrEZw
MifX+wIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcC
AjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVm
ZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAh/j3ynKibKwqRZA4Y3KsDwboqp78AIi04ATWtK0MSq+qL2FIu7HORZrN9eJVwqkm
3lr4tNU/ld7bCqnd9zHO4FRyg17pDVwZ4/7Z3UR+wW6WLj2FXn+QPRPWuyeIpOz+LxPhn4HaBIS6
qaO6+glnQl0IX6axcAhLebO/J/hNIQAxggNWMIIDUgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp
Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52
ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx
SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv
bmEgTm90IFZhbGlkYXRlZAIQf5eMoPha4Jhi5Gsvmd3EcDAJBgUrDgMCGgUAoIIByjAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjExMjIwOTE5MDhaMCMGCSqGSIb3
DQEJBDEWBBSSqNV93+HQmnwnaUZAo0T374TCijB2BgkqhkiG9w0BCQ8xaTBnMAoGCCqGSIb3DQMH
MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC
GjAHBgUrDgMCGjAKBggqhkiG9w0CBTAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHM
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhB/l4yg+FrgmGLkay+Z3cRwMA0GCSqG
SIb3DQEBAQUABIGARABC9gN9BYzo4xWJbTE2MEhzTrkAMzKbF5KGpnKhKoh3PX1mbZFheDsbcE2r
NGQprcGPYJBI6+x531ZRyQgdv/nq8ld88KA/doUtCFY3LAN6fzRYPB10ajfUpdEeI4L4znAyKHUJ
giJiPLFjWcbF7KV+DZvqFt3jmmqTqL6PyBIAAAAAAAA=

------=_NextPart_000_0023_01C29208.35DF1040--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAM9FIO25675 for ietf-pkix-bks; Fri, 22 Nov 2002 01:15:18 -0800 (PST)
Received: from mons.uio.no (mons.uio.no [129.240.130.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAM9FGg25663 for <[e-mail]>; Fri, 22 Nov 2002 01:15:16 -0800 (PST)
Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18F9u6-00035J-00; Fri, 22 Nov 2002 10:15:14 +0100
Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18F9u5-0006nV-00; Fri, 22 Nov 2002 10:15:13 +0100
From: Hallvard B Furuseth <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: Re: No-op LDAP ;binary option
In-Reply-To: <20021121215238.VDRQ16799.mta05-svc.ntlworld.com@dwc>
References: <[e-mail]> <20021121215238.VDRQ16799.mta05-svc.ntlworld.com@dwc>
X-Mailer: VM 6.37 under Emacs 19.34.1
Date: Fri, 22 Nov 2002 10:15:13 +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] writes:

> This would be fine if userCertificate;binary was implemented by all LDAPv3 
> implementations according to the spec. But it isnt.

What else do they do?

I seem to remember some implementations think ;binary means the
attribute value should be wrapped in an extra BER envelope (I don't
remember the ASN.1 type), is that what you are talking about?

> Neither is it guaranteed that LDAP servers will treat an LDAPv2
> request for userCertificate the same as a v3 request for
> userCertificate;binary.

What do they do?

-- 
Hallvard


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAM61TM01680 for ietf-pkix-bks; Thu, 21 Nov 2002 22:01:29 -0800 (PST)
Received: from melbourne6.fhp.com.au (melbourne6.fhp.com.au [202.53.34.67]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAM61Og01669; Thu, 21 Nov 2002 22:01:25 -0800 (PST)
Subject: RE: Request for IESG consideration: CP/CPS Framework
To: "Fillingham, David W." <[e-mail]>
Cc: "'Adrian McCullagh'" <[e-mail]>, [e-mail], [e-mail], "Jeffrey I. Schiller" <[e-mail]>, [e-mail], "'Paul Hoffman / IMC'" <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.10  March 22, 2002
Message-ID: <[e-mail]>
From: "Adrian McCullagh" <[e-mail]>
Date: Fri, 22 Nov 2002 15:57:44 +1000
X-MIMETrack: Serialize by Router on Melbourne6/FHP/AU(Release 5.07a |May 14, 2001) at 22/11/2002 05:04:13 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear David,

If one looks at the raison d'etre for a CPS it is very different to that of
the CP.

It is my understanding, and I am open to any correction, that a CPS is a
document that details the practices and procedures established by a CA that
will cover the life-cycle of certificates issued by the CA.  That is it
covers how the certificate will be generated, suspended and revoked.  An
internally focused document covering the internal environment of the CA.
Much like an operations manual for a CA business as they relate to
certificates.

The CP is a very different document which will usually be relied upon by
the relying party and to a certain extent the subscriber.  RFC 2527 states
:

'According to X.509, a certificate policy (CP) is "a named
set of rules that indicates the applicability of a certificate to a
particular community and/or class of applications with common
security requirements."
A CP may be used by a relying party to help
in deciding whether a certificate, and the binding therein, are
sufficiently trustworthy and otherwise appropriate for a particular
application.'

Hence my query as to the applicability of RFC 2527 to the CP.  RFC 2527
concentrates of the internal practices of the CA, which is really the
function of a CPS.  I believe that a separate RFC should be established
that specifically covers the rules that govern the use of a certificate by
a relying party.  This RFC should be much more concise than RFC 2527.
Hence my comment that I believe RFC 2527 to be inappropriate for a CP and
thus overly complex.

It is interesting that the Banking sector has taken the view that a CPS is
an internal document, which I have no problem with, and therefore will not
be published.  A CP on the other hand does need to be published otherwise
the relying party will not be in a position to ascertain/determine any
trust value for the transaction as it relates to the digital signature for
verification.

Dr. Adrian McCullagh Ph. D.
Solicitor/lawyer
Freehills, Australia

Direct 61 7 3258 6603
Telephone [phone]
Facsimile 61 7 3258 6444
http://www.freehills.com

--------------------------------------------------------------------
FREEHILLS
This email is confidential.  If you are not the intended  recipient,
you must not disclose  or  use the  information  contained in it. If
you have received this email in error,  please notify us immediately
by return email and delete the document.
Freehills is not responsible for any changes made to a document other
than those made by Freehills or for the effect of the changes on the
document's meaning.

Liability is limited by the Solicitors' Limitation of Liability Scheme,
approved under the Professional Standards Act 1994 (NSW)
--------------------------------------------------------------------





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAM4KtI27731 for ietf-pkix-bks; Thu, 21 Nov 2002 20:20:55 -0800 (PST)
Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAM4Kqg27724 for <[e-mail]>; Thu, 21 Nov 2002 20:20:52 -0800 (PST)
Received: by aspams52.ca.com with Internet Mail Service (5.5.2656.59) id <WPAFP8AM>; Fri, 22 Nov 2002 15:20:53 +1100
Message-ID: <[e-mail]>
From: "Ramsay, Ron" <[e-mail]>
To: [e-mail], "Housley, Russ" <[e-mail]>
Cc: [e-mail]
Subject: RE: No-op LDAP ;binary option
Date: Fri, 22 Nov 2002 15:20:46 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The problem with this method is that you must retrieve all the certificates
in the entry even if you want only one. You also must scan each certificate
looking for the one you want (using your ASN.1 tools?). If certificates are
stored in subordinate entries, a search will return only those certificates
that match the search criteria (doesn't require ASN.1 tools).

Also, storing certificates in user entries limits your scope in searching
for them. You cannot use auxiliary attributes for serialNumber, etc. You
have to use a ceriticate matching rule. I think your clients are going to
have some trouble with this! However, if you are going to recode them to use
matching rules, why not also change the base-object search to a
whole-subtree search and then it will be transparent to the application
whether the certificate is in the entry or in a subordinate entry.

I note, for completeness, that you can use a matched-values control, but
again you will have to recode your clients.

Ron.

-----Original Message-----
From: Steve Hanna [mailto:[e-mail]]
Sent: Friday, 22 November 2002 14:25
To: Housley, Russ
Cc: [e-mail]
Subject: RE: No-op LDAP ;binary option



Thanks, Russ. That clears it up.

I agree with you that we should not have two ways to store user
certificates: as an attribute of the subject and as attributes of
dummy entries subordinate to the subject.

I prefer the first solution. That's how we've done it so far,
it's fairly widely deployed, and I haven't seen a lot of problems
with it. If there are problems, let's hear a clear description
and see if we can solve them without changing this storage scheme.

-Steve

>Steve:
>
>I think that you misunderstood my point.  The discussion has covered 
>";binary" and schema issues.  I was only commenting on the schema 
>issue.  Sorry, I was not clear about the scope of my comments.
>
>We are considering two proposals.  First, we can store certificates as an 
>attribute of the subject.  Second, we can store certificates as an 
>attribute of dummy entities that are subordinates to the subject, one dummy

>entity per certificate.
>
>We MUST NOT allow both!  Clients MUST know where to find the 
>certificates.  These two are incompatible, and we must pick just ONE of
them.
>
>Russ
>
>
>At 04:59 PM 11/20/2002 -0500, Steve Hanna wrote:
>
>>Russ Housley wrote:
>> >I do not really care as long as we agree on ONE way to do it.  We can
come
>> >up with a transition strategy once there is an agreed to standard.  I
>> >cannot accept multiple ways to ask for the same stuff.
>>
>>We need to support userCertificate;binary because that's what
>>the current spec and implementations support. The LDAPBIS
>>working group wants to transition to userCertificate.
>>
>>I don't think it's possible to meet both of these requirements
>>without having two ways to access the attribute. Why is it so
>>important to only have one way? Wouldn't a smooth transition
>>from userCertificate;binary to userCertificate be preferable?
>>Do you have some better idea? If so, please present it.
>>
>>Otherwise, I suggest we use Hallvard's simplest solution:
>>New servers MUST support userCertificate or userCertificate;binary
>>and treat them as identical. Clients SHOULD use userCertificate;binary.
>>Once the old servers are gone, we can say that clients SHOULD
>>use userCertificate.
>>
>>-Steve




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAM3PcJ24509 for ietf-pkix-bks; Thu, 21 Nov 2002 19:25:38 -0800 (PST)
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAM3PZg24503 for <[e-mail]>; Thu, 21 Nov 2002 19:25:35 -0800 (PST)
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA25034; Thu, 21 Nov 2002 19:25:33 -0800 (PST)
Received: from sydney.East.Sun.COM (esun1as-be21-ge0.Central.Sun.COM [129.147.60.148]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id gAM3PJJ19912; Thu, 21 Nov 2002 22:25:26 -0500 (EST)
From: Steve Hanna <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 21 Nov 2002 22:25:24 -0500
To: "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
Reply-To: <[e-mail]>
Subject: RE: No-op LDAP ;binary option
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks, Russ. That clears it up.

I agree with you that we should not have two ways to store user
certificates: as an attribute of the subject and as attributes of
dummy entries subordinate to the subject.

I prefer the first solution. That's how we've done it so far,
it's fairly widely deployed, and I haven't seen a lot of problems
with it. If there are problems, let's hear a clear description
and see if we can solve them without changing this storage scheme.

-Steve

>Steve:
>
>I think that you misunderstood my point.  The discussion has covered 
>";binary" and schema issues.  I was only commenting on the schema 
>issue.  Sorry, I was not clear about the scope of my comments.
>
>We are considering two proposals.  First, we can store certificates as an 
>attribute of the subject.  Second, we can store certificates as an 
>attribute of dummy entities that are subordinates to the subject, one dummy 
>entity per certificate.
>
>We MUST NOT allow both!  Clients MUST know where to find the 
>certificates.  These two are incompatible, and we must pick just ONE of them.
>
>Russ
>
>
>At 04:59 PM 11/20/2002 -0500, Steve Hanna wrote:
>
>>Russ Housley wrote:
>> >I do not really care as long as we agree on ONE way to do it.  We can come
>> >up with a transition strategy once there is an agreed to standard.  I
>> >cannot accept multiple ways to ask for the same stuff.
>>
>>We need to support userCertificate;binary because that's what
>>the current spec and implementations support. The LDAPBIS
>>working group wants to transition to userCertificate.
>>
>>I don't think it's possible to meet both of these requirements
>>without having two ways to access the attribute. Why is it so
>>important to only have one way? Wouldn't a smooth transition
>>from userCertificate;binary to userCertificate be preferable?
>>Do you have some better idea? If so, please present it.
>>
>>Otherwise, I suggest we use Hallvard's simplest solution:
>>New servers MUST support userCertificate or userCertificate;binary
>>and treat them as identical. Clients SHOULD use userCertificate;binary.
>>Once the old servers are gone, we can say that clients SHOULD
>>use userCertificate.
>>
>>-Steve




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAM1i4018931 for ietf-pkix-bks; Thu, 21 Nov 2002 17:44:04 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAM1i1g18927 for <[e-mail]>; Thu, 21 Nov 2002 17:44:01 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gAM1huF3011580; Fri, 22 Nov 2002 01:44:02 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021121204041.035f6848@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 21 Nov 2002 20:43:23 -0500
To: [e-mail]
From: [e-mail] (by way of "Kurt D. Zeilenga" <[e-mail]>)
Subject: A plan for PKIX, LDAPv3, and ;binary
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gAM1i2g18928
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[resent to hit both lists -Kdz]

Folks,

Three of the four Chairs (Tim Polk, Bob Morgan, Kurt Zeilenga) of the LDAPbis 
and PKIX WGs and one of the document authors (Steven Legg) met  in Atlanta to 
discuss LDAPv3 ­ PKIX issues, and we have a way forward regarding X.509 
certificate schema and ;binary transfer option.

The PKIX WG will draft a new technical specification describing the 
Certificate, Certificate List and Certificate Pair syntaxes, the value 
preservation requirements for attributes of these syntaxes, and the ;binary 
transfer option used in requesting and transferring attributes of these 
syntaxes.  (Attributes of these syntaxes include userCerificate, cACertificate, 
certificateRevocationList, authorityRevocationList, and crossCertificatePair.)  
The LDAPbis WG will provide any support the PKIX WG requires/requests.

(1) Upon review of the PKIX-LDAP “survey” we see a critical mass of PKI clients 
and LDAP servers that achieve interoperability using LDAPv3 with the ;binary 
option.  As these clients appear to be in the majority, we believe the best 
approach is to maintain this option for the transfer of X.509 certificates and 
CRLs.  Since this is the behavior documented in RFCs 2251, 2252, and 2256 (as 
well as the overarching 3377) this will require the least changes to the LDAPv3 
specifications as well.

(2) Per previous LDAPBIS discussions, the ;binary option need not be maintained 
as a general-purpose LDAP feature.  There is no need to hold up PKIX syntax and 
schema for LDAPBIS to define the general behavior of that feature.  This option 
will be defined in the PKIX syntax and schema document.

(3) The ;binary option as originally defined did not fully meet PKIX 
requirements anyway.  The real requirements are that these attribute values (a) 
be stored on the server in the same form that it was received in; and (b) are 
returned to the requester in the same form as received.  The PKIX syntax and 
schema for LDAPv3 will impose these new value preservation requirements on LDAP 
servers; this is consistent with the current LDAPBIS “Directory Information 
Models” draft.

(4) The lack of a defined LDAP-specific encoding for Certificate, Certificate 
List and Certificate Pair syntaxes is a problem, as a small percentage of 
implementations transfer these attributes without the ;binary option.  Rather 
than be silent, we suggest that the PKIX syntax and schema document state the 
LDAP-specific encoding used in transfer without the ;binary option but 
deprecate its use.  This LDAP-specific encoding has the same transfer 
representation as when the attribute is transferred with the ;binary option.

We believe this represents a straightforward path forward that meets the PKIX 
interoperability requirements while being most compatible with current PKI 
behavior, current LDAPv3 standards, and upcoming LDAPBIS documents.

Thank you,

Tim Polk, RL "Bob" Morgan, Kurt Zeilenga, and Steven Legg



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAM1dxw18842 for ietf-pkix-bks; Thu, 21 Nov 2002 17:39:59 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAM1dug18835 for <[e-mail]>; Thu, 21 Nov 2002 17:39:56 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gAM1djF3011559; Fri, 22 Nov 2002 01:39:52 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021121203851.0351b190@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 21 Nov 2002 20:39:12 -0500
To: Christopher Oliva <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: RE: A plan for PKIX, LDAPv3, and ;binary
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[repost to hit both lists]
At 06:42 PM 2002-11-21, Christopher Oliva wrote:
>I have a question about point 4. Specifically the sentence: 
>
>" Rather than be silent, we suggest that the PKIX syntax and schema document state the LDAP-specific encoding used in transfer without the ;binary option but deprecate its use. "
>
>What will be the impact of "but deprecate its use" to server implementations? 

I would hope the impact would be that ALL implementations
use "userCertficate;binary".

>I would prefer to remove the last 4 words of that sentence.
>
>I would like to see a more clear statement that servers will have to support requests for userCertificate as well as userCertificate;binary.

The current LDAPv3 technical specification [RFC 3377] does not
state what is to be returned when "userCertificate" is requested
(as this is a non-conformant request).  There are clients which
expect:
        a) return the certificate using "userCertificate;binary" or
        b) return the certificate using "userCertificate".

(as well as clients which accept either)

As a server cannot support both at the same time, there is
clearly an interoperability divide between implementations
of these behaviors.  To preserve interoperability on either
side of that divide, no statement is made which would require
a server implementation to cross the divide.

That is, it is suggested that servers not be restricted in
how they respond to a non-conformant request so as to allow
current interoperability with ill-behaving clients.

Kurt



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAM0RI415495 for ietf-pkix-bks; Thu, 21 Nov 2002 16:27:18 -0800 (PST)
Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAM0RFg15486 for <[e-mail]>; Thu, 21 Nov 2002 16:27:15 -0800 (PST)
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gAM0RBsr084692; Thu, 21 Nov 2002 19:27:11 -0500
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAM0TmvW043178; Thu, 21 Nov 2002 17:29:48 -0700
Importance: Normal
Sensitivity: 
Subject: RE: A plan for PKIX, LDAPv3, and ;binary
To: Christopher Oliva <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Thu, 21 Nov 2002 19:26:54 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11  |July 29, 2002) at 11/21/2002 07:27:09 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Why not something which favors support for both DERattribute;binary
and DERAttribute by servers but deprecates one of them (apparently the one
without ;binary) for clients?  This would include a MUST that any server
which supports both of these return the same format.
      We do want to get out of supporting two strings for the same request,
eventually.

            Tom Gindin


Christopher Oliva <[e-mail]>@mail.imc.org on 11/21/2002
06:48:43 PM

Sent by:    [e-mail]


To:    [e-mail]
cc:
Subject:    RE: A plan for PKIX, LDAPv3, and ;binary





I have a question about point 4. Specifically the sentence:


" Rather than be silent, we suggest that the PKIX syntax and schema
document state the LDAP-specific encoding used in transfer without the
;binary option but deprecate its use. "


What will be the impact of "but deprecate its use" to server
implementations?  I would prefer to remove the last 4 words of that
sentence.


I would like to see a more clear statement that servers will have to
support requests for userCertificate as well as userCertificate;binary.


Chris.





-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, November 21, 2002 3:03 PM
To: [e-mail]; [e-mail]
Subject: A plan for PKIX, LDAPv3, and ;binary






Folks,


Three of the four Chairs (Tim Polk, Bob Morgan, Kurt Zeilenga) of the
LDAPbis
and PKIX WGs and one of the document authors (Steven Legg) met  in Atlanta
to
discuss LDAPv3 - PKIX issues, and we have a way forward regarding X.509
certificate schema and ;binary transfer option.


The PKIX WG will draft a new technical specification describing the
Certificate, Certificate List and Certificate Pair syntaxes, the value
preservation requirements for attributes of these syntaxes, and the ;binary

transfer option used in requesting and transferring attributes of these
syntaxes.  (Attributes of these syntaxes include userCerificate,
cACertificate,
certificateRevocationList, authorityRevocationList, and
crossCertificatePair.)
The LDAPbis WG will provide any support the PKIX WG requires/requests.


(1) Upon review of the PKIX-LDAP "survey" we see a critical mass of PKI
clients
and LDAP servers that achieve interoperability using LDAPv3 with the
;binary
option.  As these clients appear to be in the majority, we believe the best

approach is to maintain this option for the transfer of X.509 certificates
and
CRLs.  Since this is the behavior documented in RFCs 2251, 2252, and 2256
(as
well as the overarching 3377) this will require the least changes to the
LDAPv3
specifications as well.


(2) Per previous LDAPBIS discussions, the ;binary option need not be
maintained
as a general-purpose LDAP feature.  There is no need to hold up PKIX syntax
and
schema for LDAPBIS to define the general behavior of that feature.  This
option
will be defined in the PKIX syntax and schema document.


(3) The ;binary option as originally defined did not fully meet PKIX
requirements anyway.  The real requirements are that these attribute values
(a)
be stored on the server in the same form that it was received in; and (b)
are
returned to the requester in the same form as received.  The PKIX syntax
and
schema for LDAPv3 will impose these new value preservation requirements on
LDAP
servers; this is consistent with the current LDAPBIS "Directory Information

Models" draft.


(4) The lack of a defined LDAP-specific encoding for Certificate,
Certificate
List and Certificate Pair syntaxes is a problem, as a small percentage of
implementations transfer these attributes without the ;binary option.
Rather
than be silent, we suggest that the PKIX syntax and schema document state
the
LDAP-specific encoding used in transfer without the ;binary option but
deprecate its use.  This LDAP-specific encoding has the same transfer
representation as when the attribute is transferred with the ;binary
option.


We believe this represents a straightforward path forward that meets the
PKIX
interoperability requirements while being most compatible with current PKI
behavior, current LDAPv3 standards, and upcoming LDAPBIS documents.


Thank you,


Tim Polk, RL "Bob" Morgan, Kurt Zeilenga, and Steven Legg






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALNmmX13619 for ietf-pkix-bks; Thu, 21 Nov 2002 15:48:48 -0800 (PST)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALNmkg13615 for <[e-mail]>; Thu, 21 Nov 2002 15:48:46 -0800 (PST)
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <XL2ASNSK>; Thu, 21 Nov 2002 18:48:44 -0500
Message-ID: <[e-mail]>
From: Christopher Oliva <[e-mail]>
To: [e-mail]
Subject: RE: A plan for PKIX, LDAPv3, and ;binary
Date: Thu, 21 Nov 2002 18:48:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C291B8.863BC830"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C291B8.863BC830
Content-Type: text/plain


I have a question about point 4. Specifically the sentence:

" Rather than be silent, we suggest that the PKIX syntax and schema document
state the LDAP-specific encoding used in transfer without the ;binary option
but deprecate its use. "

What will be the impact of "but deprecate its use" to server
implementations?  I would prefer to remove the last 4 words of that
sentence.

I would like to see a more clear statement that servers will have to support
requests for userCertificate as well as userCertificate;binary.

Chris.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, November 21, 2002 3:03 PM
To: [e-mail]; [e-mail]
Subject: A plan for PKIX, LDAPv3, and ;binary



Folks,

Three of the four Chairs (Tim Polk, Bob Morgan, Kurt Zeilenga) of the
LDAPbis 
and PKIX WGs and one of the document authors (Steven Legg) met  in Atlanta
to 
discuss LDAPv3 - PKIX issues, and we have a way forward regarding X.509 
certificate schema and ;binary transfer option.

The PKIX WG will draft a new technical specification describing the 
Certificate, Certificate List and Certificate Pair syntaxes, the value 
preservation requirements for attributes of these syntaxes, and the ;binary 
transfer option used in requesting and transferring attributes of these 
syntaxes.  (Attributes of these syntaxes include userCerificate,
cACertificate, 
certificateRevocationList, authorityRevocationList, and
crossCertificatePair.)  
The LDAPbis WG will provide any support the PKIX WG requires/requests.

(1) Upon review of the PKIX-LDAP "survey" we see a critical mass of PKI
clients 
and LDAP servers that achieve interoperability using LDAPv3 with the ;binary

option.  As these clients appear to be in the majority, we believe the best 
approach is to maintain this option for the transfer of X.509 certificates
and 
CRLs.  Since this is the behavior documented in RFCs 2251, 2252, and 2256
(as 
well as the overarching 3377) this will require the least changes to the
LDAPv3 
specifications as well.

(2) Per previous LDAPBIS discussions, the ;binary option need not be
maintained 
as a general-purpose LDAP feature.  There is no need to hold up PKIX syntax
and 
schema for LDAPBIS to define the general behavior of that feature.  This
option 
will be defined in the PKIX syntax and schema document.

(3) The ;binary option as originally defined did not fully meet PKIX 
requirements anyway.  The real requirements are that these attribute values
(a) 
be stored on the server in the same form that it was received in; and (b)
are 
returned to the requester in the same form as received.  The PKIX syntax and

schema for LDAPv3 will impose these new value preservation requirements on
LDAP 
servers; this is consistent with the current LDAPBIS "Directory Information 
Models" draft.

(4) The lack of a defined LDAP-specific encoding for Certificate,
Certificate 
List and Certificate Pair syntaxes is a problem, as a small percentage of 
implementations transfer these attributes without the ;binary option.
Rather 
than be silent, we suggest that the PKIX syntax and schema document state
the 
LDAP-specific encoding used in transfer without the ;binary option but 
deprecate its use.  This LDAP-specific encoding has the same transfer 
representation as when the attribute is transferred with the ;binary option.

We believe this represents a straightforward path forward that meets the
PKIX 
interoperability requirements while being most compatible with current PKI 
behavior, current LDAPv3 standards, and upcoming LDAPBIS documents.

Thank you,

Tim Polk, RL "Bob" Morgan, Kurt Zeilenga, and Steven Legg

------_=_NextPart_001_01C291B8.863BC830
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: A plan for PKIX, LDAPv3, and ;binary</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>I have a question about point 4. Specifically the =
sentence:</FONT>
</P>

<P><FONT SIZE=3D2>&quot; Rather than be silent, we suggest that the =
PKIX syntax and schema document state the LDAP-specific encoding used =
in transfer without the ;binary option but deprecate its use. =
&quot;</FONT></P>

<P><FONT SIZE=3D2>What will be the impact of &quot;but deprecate its =
use&quot; to server implementations?&nbsp; I would prefer to remove the =
last 4 words of that sentence.</FONT></P>

<P><FONT SIZE=3D2>I would like to see a more clear statement that =
servers will have to support requests for userCertificate as well as =
userCertificate;binary.</FONT></P>

<P><FONT SIZE=3D2>Chris.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, November 21, 2002 3:03 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: A plan for PKIX, LDAPv3, and ;binary</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Folks,</FONT>
</P>

<P><FONT SIZE=3D2>Three of the four Chairs (Tim Polk, Bob Morgan, Kurt =
Zeilenga) of the LDAPbis </FONT>
<BR><FONT SIZE=3D2>and PKIX WGs and one of the document authors (Steven =
Legg) met&nbsp; in Atlanta to </FONT>
<BR><FONT SIZE=3D2>discuss LDAPv3 - PKIX issues, and we have a way =
forward regarding X.509 </FONT>
<BR><FONT SIZE=3D2>certificate schema and ;binary transfer =
option.</FONT>
</P>

<P><FONT SIZE=3D2>The PKIX WG will draft a new technical specification =
describing the </FONT>
<BR><FONT SIZE=3D2>Certificate, Certificate List and Certificate Pair =
syntaxes, the value </FONT>
<BR><FONT SIZE=3D2>preservation requirements for attributes of these =
syntaxes, and the ;binary </FONT>
<BR><FONT SIZE=3D2>transfer option used in requesting and transferring =
attributes of these </FONT>
<BR><FONT SIZE=3D2>syntaxes.&nbsp; (Attributes of these syntaxes =
include userCerificate, cACertificate, </FONT>
<BR><FONT SIZE=3D2>certificateRevocationList, authorityRevocationList, =
and crossCertificatePair.)&nbsp; </FONT>
<BR><FONT SIZE=3D2>The LDAPbis WG will provide any support the PKIX WG =
requires/requests.</FONT>
</P>

<P><FONT SIZE=3D2>(1) Upon review of the PKIX-LDAP &quot;survey&quot; =
we see a critical mass of PKI clients </FONT>
<BR><FONT SIZE=3D2>and LDAP servers that achieve interoperability using =
LDAPv3 with the ;binary </FONT>
<BR><FONT SIZE=3D2>option.&nbsp; As these clients appear to be in the =
majority, we believe the best </FONT>
<BR><FONT SIZE=3D2>approach is to maintain this option for the transfer =
of X.509 certificates and </FONT>
<BR><FONT SIZE=3D2>CRLs.&nbsp; Since this is the behavior documented in =
RFCs 2251, 2252, and 2256 (as </FONT>
<BR><FONT SIZE=3D2>well as the overarching 3377) this will require the =
least changes to the LDAPv3 </FONT>
<BR><FONT SIZE=3D2>specifications as well.</FONT>
</P>

<P><FONT SIZE=3D2>(2) Per previous LDAPBIS discussions, the ;binary =
option need not be maintained </FONT>
<BR><FONT SIZE=3D2>as a general-purpose LDAP feature.&nbsp; There is no =
need to hold up PKIX syntax and </FONT>
<BR><FONT SIZE=3D2>schema for LDAPBIS to define the general behavior of =
that feature.&nbsp; This option </FONT>
<BR><FONT SIZE=3D2>will be defined in the PKIX syntax and schema =
document.</FONT>
</P>

<P><FONT SIZE=3D2>(3) The ;binary option as originally defined did not =
fully meet PKIX </FONT>
<BR><FONT SIZE=3D2>requirements anyway.&nbsp; The real requirements are =
that these attribute values (a) </FONT>
<BR><FONT SIZE=3D2>be stored on the server in the same form that it was =
received in; and (b) are </FONT>
<BR><FONT SIZE=3D2>returned to the requester in the same form as =
received.&nbsp; The PKIX syntax and </FONT>
<BR><FONT SIZE=3D2>schema for LDAPv3 will impose these new value =
preservation requirements on LDAP </FONT>
<BR><FONT SIZE=3D2>servers; this is consistent with the current LDAPBIS =
&quot;Directory Information </FONT>
<BR><FONT SIZE=3D2>Models&quot; draft.</FONT>
</P>

<P><FONT SIZE=3D2>(4) The lack of a defined LDAP-specific encoding for =
Certificate, Certificate </FONT>
<BR><FONT SIZE=3D2>List and Certificate Pair syntaxes is a problem, as =
a small percentage of </FONT>
<BR><FONT SIZE=3D2>implementations transfer these attributes without =
the ;binary option.&nbsp; Rather </FONT>
<BR><FONT SIZE=3D2>than be silent, we suggest that the PKIX syntax and =
schema document state the </FONT>
<BR><FONT SIZE=3D2>LDAP-specific encoding used in transfer without the =
;binary option but </FONT>
<BR><FONT SIZE=3D2>deprecate its use.&nbsp; This LDAP-specific encoding =
has the same transfer </FONT>
<BR><FONT SIZE=3D2>representation as when the attribute is transferred =
with the ;binary option.</FONT>
</P>

<P><FONT SIZE=3D2>We believe this represents a straightforward path =
forward that meets the PKIX </FONT>
<BR><FONT SIZE=3D2>interoperability requirements while being most =
compatible with current PKI </FONT>
<BR><FONT SIZE=3D2>behavior, current LDAPv3 standards, and upcoming =
LDAPBIS documents.</FONT>
</P>

<P><FONT SIZE=3D2>Thank you,</FONT>
</P>

<P><FONT SIZE=3D2>Tim Polk, RL &quot;Bob&quot; Morgan, Kurt Zeilenga, =
and Steven Legg</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C291B8.863BC830--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALN6WU12071 for ietf-pkix-bks; Thu, 21 Nov 2002 15:06:32 -0800 (PST)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALN6Ug12064 for <[e-mail]>; Thu, 21 Nov 2002 15:06:30 -0800 (PST)
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <XL2ASNBV>; Thu, 21 Nov 2002 18:06:27 -0500
Message-ID: <[e-mail]>
From: Christopher Oliva <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Cc: "Housley, Russ" <[e-mail]>, [e-mail], Hallvard B Furuseth <[e-mail]>, [e-mail], "Ramsay, Ron" <[e-mail]>, [e-mail]
Subject: RE: No-op LDAP ;binary option
Date: Thu, 21 Nov 2002 18:06:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C291B2.9E281B70"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C291B2.9E281B70
Content-Type: text/plain


David, I agree with the summary of the problem you've provided below .. in
terms of basic ldapv3 interoperability, ;binary has been the number 1
problem I've encountered.

I prefer a solution that defines "userCertificate;binary" and
"userCertificate" to have the same meaning .. that is, a request for
userCertificate will return the same binary encoded value as a request for
userCertificate;binary (and the attribute description returned will be
userCertificate;binary if userCertificate;binary was requested).

Chris.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, November 21, 2002 4:52 PM
To: [e-mail]; [e-mail]
Cc: Housley, Russ; [e-mail]; Hallvard B Furuseth;
[e-mail]; Ramsay, Ron
Subject: Re: No-op LDAP ;binary option



Date sent:      	Wed, 20 Nov 2002 16:39:26 -0700
From:           	Russel F Weiser <[e-mail]>
Send reply to:  	[e-mail]
Organization:   	Digital Signature Trust 
To:             	[e-mail]
Copies to:      	"Housley, Russ" <[e-mail]>,
[e-mail],
  	Hallvard B Furuseth <[e-mail]>, [e-mail],
  	"Ramsay, Ron" <[e-mail]>
Subject:        	Re: No-op LDAP ;binary option

> I strongly agree with Hallvard's solution!!!
> Cheers
> Russel F Weiser
> 

This would be fine if userCertificate;binary was implemented by all LDAPv3 
implementations according to the spec. But it isnt. Neither is it guaranteed
that 
LDAP servers will treat an LDAPv2 request for userCertificate the same as a
v3 
request for userCertificate;binary. Which they should. These are some of the

reasons why the whole topic of ;binary was re-visited by LDAPBIS earlier
this 
year. Chris Oliver from Entrust did a whole lot of interop testing and found

many bugs and problems in LDAP implementations. I would be interested in 
Chris's views of Hallvard's proposal

David

> 
> Steve Hanna wrote:
> > 
> > Russ Housley wrote:
> > >I do not really care as long as we agree on ONE way to do it.  We can
come
> > >up with a transition strategy once there is an agreed to standard.  I
> > >cannot accept multiple ways to ask for the same stuff.
> > 
> > We need to support userCertificate;binary because that's what
> > the current spec and implementations support. The LDAPBIS
> > working group wants to transition to userCertificate.
> > 
> > I don't think it's possible to meet both of these requirements
> > without having two ways to access the attribute. Why is it so
> > important to only have one way? Wouldn't a smooth transition
> > from userCertificate;binary to userCertificate be preferable?
> > Do you have some better idea? If so, please present it.
> > 
> > Otherwise, I suggest we use Hallvard's simplest solution:
> > New servers MUST support userCertificate or userCertificate;binary
> > and treat them as identical. Clients SHOULD use userCertificate;binary.
> > Once the old servers are gone, we can say that clients SHOULD
> > use userCertificate.
> > 
> > -Steve


------_=_NextPart_001_01C291B2.9E281B70
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: No-op LDAP ;binary option</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>David, I agree with the summary of the problem you've =
provided below .. in terms of basic ldapv3 interoperability, ;binary =
has been the number 1 problem I've encountered.</FONT></P>

<P><FONT SIZE=3D2>I prefer a solution that defines =
&quot;userCertificate;binary&quot; and &quot;userCertificate&quot; to =
have the same meaning .. that is, a request for userCertificate will =
return the same binary encoded value as a request for =
userCertificate;binary (and the attribute description returned will be =
userCertificate;binary if userCertificate;binary was =
requested).</FONT></P>

<P><FONT SIZE=3D2>Chris.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:d.w.chadwick@salford.a=
c.uk</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, November 21, 2002 4:52 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: Housley, Russ; [e-mail]; =
Hallvard B Furuseth;</FONT>
<BR><FONT SIZE=3D2>[e-mail]; Ramsay, Ron</FONT>
<BR><FONT SIZE=3D2>Subject: Re: No-op LDAP ;binary option</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Date sent:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Wed, 20 Nov 2002 16:39:26 =
-0700</FONT>
<BR><FONT =
SIZE=3D2>From:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Russel F Weiser =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>Send reply to:&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Organization:&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Digital Signature Trust =
</FONT>
<BR><FONT =
SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Copies to:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;Housley, Russ&quot; =
&lt;[e-mail]&gt;, [e-mail],</FONT>
<BR><FONT SIZE=3D2>&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hallvard B =
Furuseth &lt;[e-mail]&gt;, [e-mail],</FONT>
<BR><FONT SIZE=3D2>&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;Ramsay, =
Ron&quot; &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: No-op LDAP ;binary =
option</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I strongly agree with Hallvard's =
solution!!!</FONT>
<BR><FONT SIZE=3D2>&gt; Cheers</FONT>
<BR><FONT SIZE=3D2>&gt; Russel F Weiser</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>This would be fine if userCertificate;binary was =
implemented by all LDAPv3 </FONT>
<BR><FONT SIZE=3D2>implementations according to the spec. But it isnt. =
Neither is it guaranteed that </FONT>
<BR><FONT SIZE=3D2>LDAP servers will treat an LDAPv2 request for =
userCertificate the same as a v3 </FONT>
<BR><FONT SIZE=3D2>request for userCertificate;binary. Which they =
should. These are some of the </FONT>
<BR><FONT SIZE=3D2>reasons why the whole topic of ;binary was =
re-visited by LDAPBIS earlier this </FONT>
<BR><FONT SIZE=3D2>year. Chris Oliver from Entrust did a whole lot of =
interop testing and found </FONT>
<BR><FONT SIZE=3D2>many bugs and problems in LDAP implementations. I =
would be interested in </FONT>
<BR><FONT SIZE=3D2>Chris's views of Hallvard's proposal</FONT>
<BR><FONT SIZE=3D2>=0F</FONT>
<BR><FONT SIZE=3D2>David</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Steve Hanna wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Russ Housley wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;I do not really care as long as we =
agree on ONE way to do it.&nbsp; We can come</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;up with a transition strategy once =
there is an agreed to standard.&nbsp; I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;cannot accept multiple ways to ask for =
the same stuff.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; We need to support userCertificate;binary =
because that's what</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the current spec and implementations =
support. The LDAPBIS</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; working group wants to transition to =
userCertificate.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I don't think it's possible to meet both =
of these requirements</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; without having two ways to access the =
attribute. Why is it so</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; important to only have one way? Wouldn't a =
smooth transition</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; from userCertificate;binary to =
userCertificate be preferable?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Do you have some better idea? If so, =
please present it.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Otherwise, I suggest we use Hallvard's =
simplest solution:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; New servers MUST support userCertificate =
or userCertificate;binary</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and treat them as identical. Clients =
SHOULD use userCertificate;binary.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Once the old servers are gone, we can say =
that clients SHOULD</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; use userCertificate.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -Steve</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C291B2.9E281B70--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALN4Lg11804 for ietf-pkix-bks; Thu, 21 Nov 2002 15:04:21 -0800 (PST)
Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALN4Eg11788 for <[e-mail]>; Thu, 21 Nov 2002 15:04:14 -0800 (PST)
Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id gALN3o503626 for <[e-mail]>; Thu, 21 Nov 2002 15:03:52 -0800 (PST)
Received: from netscape.com ([10.169.192.65]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H5Y82E00.ESP; Thu, 21 Nov 2002 15:03:50 -0800 
Message-ID: <[e-mail]>
Date: Thu, 21 Nov 2002 18:03:48 -0500
From: [e-mail] (Mark C Smith)
Organization: Netscape Communications Corp.
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1) Gecko/20020827
X-Accept-Language: English/United States [en-US],E
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: A plan for PKIX, LDAPv3, and ;binary
References: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gALN4Jg11799
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think this is an excellent plan and the best choice given the 
situation. The installed base of LDAPv3 users will be very grateful 
(which is to say they won't kick and scream, because they will feel 
minimal pain).

-- 
Mark Smith
Netscape Directory Product Development
My words are my own, not my employer's.


[e-mail] wrote:
> Folks,
> 
> Three of the four Chairs (Tim Polk, Bob Morgan, Kurt Zeilenga) of the LDAPbis 
> and PKIX WGs and one of the document authors (Steven Legg) met  in Atlanta to 
> discuss LDAPv3 – PKIX issues, and we have a way forward regarding X.509 
> certificate schema and ;binary transfer option.
> 
> The PKIX WG will draft a new technical specification describing the 
> Certificate, Certificate List and Certificate Pair syntaxes, the value 
> preservation requirements for attributes of these syntaxes, and the ;binary 
> transfer option used in requesting and transferring attributes of these 
> syntaxes.  (Attributes of these syntaxes include userCerificate, cACertificate, 
> certificateRevocationList, authorityRevocationList, and crossCertificatePair.)  
> The LDAPbis WG will provide any support the PKIX WG requires/requests.
> 
> (1) Upon review of the PKIX-LDAP “survey” we see a critical mass of PKI clients 
> and LDAP servers that achieve interoperability using LDAPv3 with the ;binary 
> option.  As these clients appear to be in the majority, we believe the best 
> approach is to maintain this option for the transfer of X.509 certificates and 
> CRLs.  Since this is the behavior documented in RFCs 2251, 2252, and 2256 (as 
> well as the overarching 3377) this will require the least changes to the LDAPv3 
> specifications as well.
> 
> (2) Per previous LDAPBIS discussions, the ;binary option need not be maintained 
> as a general-purpose LDAP feature.  There is no need to hold up PKIX syntax and 
> schema for LDAPBIS to define the general behavior of that feature.  This option 
> will be defined in the PKIX syntax and schema document.
> 
> (3) The ;binary option as originally defined did not fully meet PKIX 
> requirements anyway.  The real requirements are that these attribute values (a) 
> be stored on the server in the same form that it was received in; and (b) are 
> returned to the requester in the same form as received.  The PKIX syntax and 
> schema for LDAPv3 will impose these new value preservation requirements on LDAP 
> servers; this is consistent with the current LDAPBIS “Directory Information 
> Models” draft.
> 
> (4) The lack of a defined LDAP-specific encoding for Certificate, Certificate 
> List and Certificate Pair syntaxes is a problem, as a small percentage of 
> implementations transfer these attributes without the ;binary option.  Rather 
> than be silent, we suggest that the PKIX syntax and schema document state the 
> LDAP-specific encoding used in transfer without the ;binary option but 
> deprecate its use.  This LDAP-specific encoding has the same transfer 
> representation as when the attribute is transferred with the ;binary option.
> 
> We believe this represents a straightforward path forward that meets the PKIX 
> interoperability requirements while being most compatible with current PKI 
> behavior, current LDAPv3 standards, and upcoming LDAPBIS documents.
> 
> Thank you,
> 
> Tim Polk, RL "Bob" Morgan, Kurt Zeilenga, and Steven Legg



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALLqdj07573 for ietf-pkix-bks; Thu, 21 Nov 2002 13:52:39 -0800 (PST)
Received: from mta05-svc.ntlworld.com (mta05-svc.ntlworld.com [62.253.162.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALLqbg07569 for <[e-mail]>; Thu, 21 Nov 2002 13:52:37 -0800 (PST)
Received: from dwc ([80.7.98.57]) by mta05-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20021121215238.VDRQ16799.mta05-svc.ntlworld.com@dwc>; Thu, 21 Nov 2002 21:52:38 +0000
From: [e-mail]
To: [e-mail], [e-mail]
Date: Thu, 21 Nov 2002 21:52:19 -0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: No-op LDAP ;binary option
CC: "Housley, Russ" <[e-mail]>, [e-mail], Hallvard B Furuseth <[e-mail]>, [e-mail], "Ramsay, Ron" <[e-mail]>
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.01a)
Message-Id: <20021121215238.VDRQ16799.mta05-svc.ntlworld.com@dwc>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Date sent:      	Wed, 20 Nov 2002 16:39:26 -0700
From:           	Russel F Weiser <[e-mail]>
Send reply to:  	[e-mail]
Organization:   	Digital Signature Trust 
To:             	[e-mail]
Copies to:      	"Housley, Russ" <[e-mail]>, [e-mail],
  	Hallvard B Furuseth <[e-mail]>, [e-mail],
  	"Ramsay, Ron" <[e-mail]>
Subject:        	Re: No-op LDAP ;binary option

> I strongly agree with Hallvard's solution!!!
> Cheers
> Russel F Weiser
> 

This would be fine if userCertificate;binary was implemented by all LDAPv3 
implementations according to the spec. But it isnt. Neither is it guaranteed that 
LDAP servers will treat an LDAPv2 request for userCertificate the same as a v3 
request for userCertificate;binary. Which they should. These are some of the 
reasons why the whole topic of ;binary was re-visited by LDAPBIS earlier this 
year. Chris Oliver from Entrust did a whole lot of interop testing and found 
many bugs and problems in LDAP implementations. I would be interested in 
Chris's views of Hallvard's proposal

David

> 
> Steve Hanna wrote:
> > 
> > Russ Housley wrote:
> > >I do not really care as long as we agree on ONE way to do it.  We can come
> > >up with a transition strategy once there is an agreed to standard.  I
> > >cannot accept multiple ways to ask for the same stuff.
> > 
> > We need to support userCertificate;binary because that's what
> > the current spec and implementations support. The LDAPBIS
> > working group wants to transition to userCertificate.
> > 
> > I don't think it's possible to meet both of these requirements
> > without having two ways to access the attribute. Why is it so
> > important to only have one way? Wouldn't a smooth transition
> > from userCertificate;binary to userCertificate be preferable?
> > Do you have some better idea? If so, please present it.
> > 
> > Otherwise, I suggest we use Hallvard's simplest solution:
> > New servers MUST support userCertificate or userCertificate;binary
> > and treat them as identical. Clients SHOULD use userCertificate;binary.
> > Once the old servers are gone, we can say that clients SHOULD
> > use userCertificate.
> > 
> > -Steve




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALLg7N06559 for ietf-pkix-bks; Thu, 21 Nov 2002 13:42:07 -0800 (PST)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id gALLg4g06550 for <[e-mail]>; Thu, 21 Nov 2002 13:42:05 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Nov 2002 21:42:07 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA22926 for <[e-mail]>; Thu, 21 Nov 2002 16:42:05 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id gALLdJC09627 for <[e-mail]>; Thu, 21 Nov 2002 16:39:19 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <W53VH0LG>; Thu, 21 Nov 2002 16:42:04 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.12]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W53VH0KX; Thu, 21 Nov 2002 16:41:51 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 21 Nov 2002 16:11:53 -0500
Subject: RE: No-op LDAP ;binary option
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve:

I think that you misunderstood my point.  The discussion has covered 
";binary" and schema issues.  I was only commenting on the schema 
issue.  Sorry, I was not clear about the scope of my comments.

We are considering two proposals.  First, we can store certificates as an 
attribute of the subject.  Second, we can store certificates as an 
attribute of dummy entities that are subordinates to the subject, one dummy 
entity per certificate.

We MUST NOT allow both!  Clients MUST know where to find the 
certificates.  These two are incompatible, and we must pick just ONE of them.

Russ


At 04:59 PM 11/20/2002 -0500, Steve Hanna wrote:

>Russ Housley wrote:
> >I do not really care as long as we agree on ONE way to do it.  We can come
> >up with a transition strategy once there is an agreed to standard.  I
> >cannot accept multiple ways to ask for the same stuff.
>
>We need to support userCertificate;binary because that's what
>the current spec and implementations support. The LDAPBIS
>working group wants to transition to userCertificate.
>
>I don't think it's possible to meet both of these requirements
>without having two ways to access the attribute. Why is it so
>important to only have one way? Wouldn't a smooth transition
>from userCertificate;binary to userCertificate be preferable?
>Do you have some better idea? If so, please present it.
>
>Otherwise, I suggest we use Hallvard's simplest solution:
>New servers MUST support userCertificate or userCertificate;binary
>and treat them as identical. Clients SHOULD use userCertificate;binary.
>Once the old servers are gone, we can say that clients SHOULD
>use userCertificate.
>
>-Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALLPu903954 for ietf-pkix-bks; Thu, 21 Nov 2002 13:25:56 -0800 (PST)
Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALLPsg03949 for <[e-mail]>; Thu, 21 Nov 2002 13:25:54 -0800 (PST)
Received: from dwc ([80.7.98.57]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20021121212554.WYUO18167.mta06-svc.ntlworld.com@dwc>; Thu, 21 Nov 2002 21:25:55 +0000
From: [e-mail]
To: ietf-pkix <[e-mail]>, Adam Theo <[e-mail]>
Date: Thu, 21 Nov 2002 21:25:36 -0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: certificates on a URI
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.01a)
Message-Id: <20021121212554.WYUO18167.mta06-svc.ntlworld.com@dwc>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Date sent:      	Thu, 21 Nov 2002 01:17:30 -0500
From:           	Adam Theo <[e-mail]>
To:             	ietf-pkix <[e-mail]>
Subject:        	certificates on a URI

> 
> Hi, all. I was wondering if it was possible to represent PKIX
> certificates on a single line, hopefully as part of a URI? 

Using LDAP URIs you can request certificates to be returned from LDAP 
servers. Is this good enough for you?

David
>I've not been
> able to find any answers for this question by Googling or skimming the
> most recent RFC's. Thanks.
> 
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALJqMG25883 for ietf-pkix-bks; Thu, 21 Nov 2002 11:52:22 -0800 (PST)
Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALJqFg25877 for <[e-mail]>; Thu, 21 Nov 2002 11:52:15 -0800 (PST)
Received: from user155.net249.fl.sprint-hsd.net ([209.26.25.155] helo=theoretic.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18ExN0-0001IW-00; Thu, 21 Nov 2002 11:52:14 -0800
Message-ID: <[e-mail]>
Date: Thu, 21 Nov 2002 14:49:21 -0500
From: Adam Theo <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.0.1) Gecko/20021119
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "McCutcheon, Mark" <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: certificates on a URI
References: <[e-mail]>
X-Enigmail-Version: 0.63.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am wanting to represent the entire certificate as long as it can be 
put into a single string (eg: no newlines, and other whitespace can be 
encoded). Length is not really an issue since machines will be dealing 
with this anyway, not humans, so it doesn't have to be very human friendly.

What I am trying to do is create an extensible naming scheme to address 
users on a system. every address will be comprised of "name@host", like 
an email address. So far the name part can either be the user's real 
username with their host, or it can be a pseodonym created by the host 
to anonymize the user and act as a "front" to their real account. I'm 
wanting to add a PKI certificate as a third option, so if the user 
wishes to be identified by their PKI certificate it looks like 
"certificate-hash-of-characters-here@host".

The host would not necissarily be the CA, so the information about the 
CA that created the certificate would have to be included in the "name" 
part of the address.

The different ways of naming the user (username, pseodonym, and 
certificate) will be designated by a uri namespace. for example:

user:[e-mail]
pseodo:[e-mail]
cert:G6ji3sDmfR570fGG6ji3sDmfR570fGG6ji3sDmfR570fG=[e-mail]

Hope this makes sense.

McCutcheon, Mark wrote:
> Hi Adam,
> 
> Depends on what you mean - do you want to have the entire content of the
> cert as part of a URi or just an unambiguous reference? Given that the
> public key and the signature represent the bulk of a certificate and are not
> much compressible, you really can't expect to shrink a cert significantly.
> On the other hand, RSA Keon CA indexes each certificate in its database
> using the MD5 hash of the cert (of the headerless base64 representation of a
> cert, as it happens) and that value is often used in a URi to retrieve a
> certificate or otherwise reference it. For instance, 
> 
> https://certs.r.us:443/get-cert.xuda?md5=a5a90b8f8a39673574da000f60f564af&do
> mainID=9234747711c9a2ca1f6784f4b8e56ea0d0d8ca88
> 
> is a retrieval string for a newly issued certificate from the enrollment
> server running on certs.r.us. The md5 value represents the certificate, the
> domainID represents a particular domain on the issuing CA.
> 
> Regards,
> 
> Mark McCutcheon
> 
> -----Original Message-----
> From: Adam Theo [mailto:[e-mail]]
> Sent: Wednesday, November 20, 2002 10:18 PM
> To: ietf-pkix
> Subject: certificates on a URI
> 
> 
> 
> Hi, all. I was wondering if it was possible to represent PKIX
> certificates on a single line, hopefully as part of a URI? I've not been
> able to find any answers for this question by Googling or skimming the
> most recent RFC's. Thanks.
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALEnKw06100 for ietf-pkix-bks; Thu, 21 Nov 2002 06:49:20 -0800 (PST)
Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALEnIg06092 for <[e-mail]>; Thu, 21 Nov 2002 06:49:18 -0800 (PST)
Received: from vivi.cc.vt.edu (IDENT:[e-mail] [10.1.1.12]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id gALEnIA306767 for <[e-mail]>; Thu, 21 Nov 2002 09:49:18 -0500 (EST)
Received: from vaio (zuni.cs.vt.edu [128.173.54.49]) by vivi.cc.vt.edu (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id AOI28066; Thu, 21 Nov 2002 09:49:17 -0500 (EST)
From: "Markus Lorch" <[e-mail]>
To: "ietf-pkix" <[e-mail]>
Subject: RE: certificates on a URI
Date: Thu, 21 Nov 2002 09:51:26 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-reply-to: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Adam,

you could take a look at the secure grid naming protocol. SGNP.
I know they have something they refer to a "location-independent object
identifier - LOID"
which uses a PK cert and/or pub. key (not standard) in the name (one string)

http://www.avaki.com/papers/index.html

Maybe it helps, no promise though

Markus

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Adam Theo
> Sent: Thursday, November 21, 2002 1:18 AM
> To: ietf-pkix
> Subject: certificates on a URI
>
>
>
> Hi, all. I was wondering if it was possible to represent PKIX
> certificates on a single line, hopefully as part of a URI? I've not been
> able to find any answers for this question by Googling or skimming the
> most recent RFC's. Thanks.
>
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALDREx25706 for ietf-pkix-bks; Thu, 21 Nov 2002 05:27:14 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALDRBg25695 for <[e-mail]>; Thu, 21 Nov 2002 05:27:11 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gALDPjF5006268; Thu, 21 Nov 2002 13:25:47 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021121080541.0296ed30@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 21 Nov 2002 08:25:13 -0500
To: <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: RE: No-op LDAP ;binary option
Cc: "Housley, Russ" <[e-mail]>, <[e-mail]>, "Hallvard B Furuseth" <[e-mail]>, <[e-mail]>, "Ramsay, Ron" <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 04:59 PM 2002-11-20, Steve Hanna wrote:
>The LDAPBIS working group wants to transition to userCertificate.

I do not believe this is a fair assessment of LDAPBIS's wants.

Please do not interpret LDAPBIS desire to separate PKI schema
and ;binary from the LDAP "core" technical specification as
a recommendation for any either choice.

No prior decision by LDAPBIS precludes either choice!

Kurt



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALCMuP23392 for ietf-pkix-bks; Thu, 21 Nov 2002 04:22:56 -0800 (PST)
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALCMsg23387 for <[e-mail]>; Thu, 21 Nov 2002 04:22:55 -0800 (PST)
Received: from Chokhani ([12.91.130.50]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20021121122220.VATE13909.mtiwmhc12.worldnet.att.net@Chokhani>; Thu, 21 Nov 2002 12:22:20 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Khaja Ahmed'" <[e-mail]>, "'Terwilliger, Ann'" <[e-mail]>, <[e-mail]>
Subject: RE: Update of RFC 2527 - opposed
Date: Thu, 21 Nov 2002 07:23:21 -0500
Message-ID: <000b01c29158$c85a0ed0$3300a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Khaja:

You state:

"It is not very helpful in setting up a CA used internally by an
organization, or one setup for use by an organization to secure
communication with it's employees or customers.  Perhaps that should be
a separate document.  If there are any updates to the RFC I hope these
distinctions will be properly dealt with."

Can you elaborate what needs to be changed in the document for dealing
with employees and customers?  

I would like to know more of technical and policy aspects as opposed to
legal aspects and how old Section 2 and new Section 9 needs to address
employees and customers since the whole thread began with the claim that
we do not want to make this too much of a legal document.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Khaja Ahmed
Sent: Thursday, November 21, 2002 2:03 AM
To: Terwilliger, Ann; [e-mail]
Subject: RE: Update of RFC 2527 - opposed



Ann,

2527 does seem to be built on the assumption that the CA, subscribers
and relying parties are distinct legal entities.  This seemed clear to
me although, to the best of my recollection, this is not explicitly
stated anywhere.  (Please let me know if I am incorrect about either of
the two foregoing points.)  As Mack has pointed out, it is increasingly
common to have CA's setup for internal use by an organization or for a
closed community like an organization and it's customers.  For these
situation 2527 can be problematic in the hands of auditors (internal or
external) and even implementers who do not understand this. It is not
always/fully appreciated that this is an informational RFC.

Your point about it being helpful as a checklist is very valid for
public CAs. It is not very helpful in setting up a CA used internally by
an organization, or one setup for use by an organization to secure
communication with it's employees or customers.  Perhaps that should be
a separate document.  If there are any updates to the RFC I hope these
distinctions will be properly dealt with.

Khaja

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Terwilliger, Ann
Sent: Wednesday, November 20, 2002 3:50 PM
To: [e-mail]
Subject: RE: Update of RFC 2527 - opposed



Another country is heard from......

Like Mack, I do not believe that automated review of a CP or CPS is
practical (even though it might be desirable).  I also agree that in
many, if not most, instances the CPS will not be made public.  However,
I have to disagree with his conclusion that RFC 2527 is not relevant.

RFC 2527 does provide a checklist for what areas need to be covered in
establishing and operating a CA.  The fact that some of the questions
are not as relevant today as they might have been when it was first
drafted only reinforces the fact that it should be updated to reflect
current conditions. There are other standards that address CA operation
(e.g., X9.79, WebTrust Audit for CA, the ABA document) but virtually all
reference RFC 2527.

I would like to believe that all CA operators are knowledgeable about
PKI and adhere to best practices for operating their CA.  However, that
is a fairy tale--something on a par with the tooth fairy--and there
needs to be some process to ensure that the CA has established good
security practices and follows them.  Hence audits become necessary.

Audits by their very nature are comparing something against a checklist
or standard.  Auditors who are familiar with PKI are capable of adhering
to the spirit of the standard rather than the exact letter if parts of a
standard do not apply.  Unfortunately auditors who are not familiar with
PKI may perform audits more or less by rote.  To me this makes it more
important, not less so, that we continue to update RFC 2527.


-----Original Message-----
From: Hicks, Mack [mailto:[e-mail]]
Sent: Wednesday, November 20, 2002 1:10 PM
To: [e-mail]
Subject: Update of RFC 2527 - opposed



I have not posted on this list for some time, lurking has been fun
though. I will say something that some might consider radical.

I thought you might like to know how some of the business world is
looking at RFC 2527 and its impact on the PKI business.

RFC 2527 is being used as a template and checklist by auditors and
associations to perform reviews on certificate authorities. Each entry
and topic of RFC 2527 must be covered by the CA or one gets an "audit
exception" or operations questions. This is done as a rote exercise.
Back when CAs were new, the checklist made sense - now some of the
questions and sections is RFC 2527 are not as relevant to all CAs.

I know of no use of the certificate policy in a business application;
the policy is only there to tell any relying party that they should have
a contract with someone before trusting this certificate. The meaning,
impact, legality, effectiveness, application, etc. of a certificate is
addressed in contract (and subject to contract law - as I understand
it). There is no detailed policy in the CP anymore.

The practice among most banks I talk to is that the certificate practice
statement (CPS) is an internal document about the operation of the CA
and related software (OCSP, CRL, LDAP); the CPS is not made public.
Therefore the original goal of automated or assisted examination of a CP
and CPS by a relying party is thwarted. (I supported the automation
goal, but it is not
achievable.)

It is useful that a certificate has a reference to a policy - but the
construction and content of that policy is no longer relevant in the
businesses that I see.  There is no use to a CPS except as an internal
checklist on CA construction and operation and acts as a mill stone
around the neck of CA operators - a barrier to entry into PKI.
Therefore RFC 2527 is purely informational to constructing a CA; I would
prefer that it move toward elimination as standard.



Mack Hicks, SVP
Bank of America  760-318-9345



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALCJjg23001 for ietf-pkix-bks; Thu, 21 Nov 2002 04:19:45 -0800 (PST)
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALCJgg22994 for <[e-mail]>; Thu, 21 Nov 2002 04:19:43 -0800 (PST)
Received: from Chokhani ([12.91.130.50]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20021121121921.QBQV20682.mtiwmhc11.worldnet.att.net@Chokhani>; Thu, 21 Nov 2002 12:19:21 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Terwilliger, Ann'" <[e-mail]>, <[e-mail]>
Subject: RE: Update of RFC 2527 - opposed
Date: Thu, 21 Nov 2002 07:19:58 -0500
Message-ID: <000a01c29158$4ff34dd0$3300a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ann:

Thanks.

If Mack and you identify specific topics in the CP and CPS Framework, we
would consider if there is a need to eliminate those topics.

The purpose of the RFC was not to automate the policy processing.  If it
was that, we would have taken it several layers down to concrete choices
and written ASN.1 for the entire hierarchy.

Part of the problem with what some of the objections are that they do
not say what is wrong and what needs to be eliminated or changed.  I
hear them saying "Democracy is the worst form of Government, let us
eliminate it and then we will see what emerges."  And of course, those
who are positive or neutral, say nothing.

May be the PKIX chairs should call a vote or this and be done with this
issue once and for all.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Terwilliger, Ann
Sent: Wednesday, November 20, 2002 6:50 PM
To: [e-mail]
Subject: RE: Update of RFC 2527 - opposed



Another country is heard from......

Like Mack, I do not believe that automated review of a CP or CPS is
practical (even though it might be desirable).  I also agree that in
many, if not most, instances the CPS will not be made public.  However,
I have to disagree with his conclusion that RFC 2527 is not relevant.

RFC 2527 does provide a checklist for what areas need to be covered in
establishing and operating a CA.  The fact that some of the questions
are not as relevant today as they might have been when it was first
drafted only reinforces the fact that it should be updated to reflect
current conditions. There are other standards that address CA operation
(e.g., X9.79, WebTrust Audit for CA, the ABA document) but virtually all
reference RFC 2527. 

I would like to believe that all CA operators are knowledgeable about
PKI and adhere to best practices for operating their CA.  However, that
is a fairy tale--something on a par with the tooth fairy--and there
needs to be some process to ensure that the CA has established good
security practices
and follows them.  Hence audits become necessary.    

Audits by their very nature are comparing something against a checklist
or standard.  Auditors who are familiar with PKI are capable of adhering
to the spirit of the standard rather than the exact letter if parts of a
standard do not apply.  Unfortunately auditors who are not familiar with
PKI may perform audits more or less by rote.  To me this makes it more
important, not less so, that we continue to update RFC 2527.  
 

-----Original Message-----
From: Hicks, Mack [mailto:[e-mail]]
Sent: Wednesday, November 20, 2002 1:10 PM
To: [e-mail]
Subject: Update of RFC 2527 - opposed



I have not posted on this list for some time, lurking has been fun
though. I will say something that some might consider radical.

I thought you might like to know how some of the business world is
looking at RFC 2527 and its impact on the PKI business.

RFC 2527 is being used as a template and checklist by auditors and
associations to perform reviews on certificate authorities. Each entry
and topic of RFC 2527 must be covered by the CA or one gets an "audit
exception" or operations questions. This is done as a rote exercise.
Back when CAs were new, the checklist made sense - now some of the
questions and sections is RFC 2527 are not as relevant to all CAs.

I know of no use of the certificate policy in a business application;
the policy is only there to tell any relying party that they should have
a contract with someone before trusting this certificate. The meaning,
impact, legality, effectiveness, application, etc. of a certificate is
addressed in contract (and subject to contract law - as I understand
it). There is no detailed policy in the CP anymore.

The practice among most banks I talk to is that the certificate practice
statement (CPS) is an internal document about the operation of the CA
and related software (OCSP, CRL, LDAP); the CPS is not made public.
Therefore the original goal of automated or assisted examination of a CP
and CPS by a relying party is thwarted. (I supported the automation
goal, but it is not
achievable.)

It is useful that a certificate has a reference to a policy - but the
construction and content of that policy is no longer relevant in the
businesses that I see.  There is no use to a CPS except as an internal
checklist on CA construction and operation and acts as a mill stone
around the neck of CA operators - a barrier to entry into PKI.
Therefore RFC 2527 is purely informational to constructing a CA; I would
prefer that it move toward elimination as standard.



Mack Hicks, SVP  
Bank of America  760-318-9345



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gALAcE215162 for ietf-pkix-bks; Thu, 21 Nov 2002 02:38:14 -0800 (PST)
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gALAcBg15157 for <[e-mail]>; Thu, 21 Nov 2002 02:38:12 -0800 (PST)
Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18Eoij-0006gU-00; Thu, 21 Nov 2002 11:38:05 +0100
Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18Eoii-0003gf-00; Thu, 21 Nov 2002 11:38:04 +0100
From: Hallvard B Furuseth <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Jim Sermersheim <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: ;binary migration solution
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 6.37 under Emacs 19.34.1
Date: Thu, 21 Nov 2002 11:38:04 +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim Sermersheim writes:
> The way the specification was written, the ;binary option is never
> stored with the value. it was only to be used to denote the transfer
> encoding format. By making the "native encoding" of userCertificate
> equivalent to the "binary" encoding, this makes "userCertificate" and
> "userCertificate;binary" equivalent. This is why I agreed with your
> proposal.

Well, I no longer agree with it, after reading David's comments.  I had
not understood how ;binary works.

I think it's better if it works just like it does today, except that it
no longer has any effect on encoding.  If I understand correctly, that
means: (pkix readers, sorry for the repeat)

- The "binary" option does nothing to encoding.
  Attribute syntaxes take care of encoding.
- The option is removed from attribute descriptions in LDAP
  operations, except
  (a) in attribute values (like DNs),
  (b) in places where options may not occur.
      I must check if (a) implies (b) so (b) can be skipped.
  Thus, attribute descriptions are stored without ;binary in
  the directory.
- If a search requested an attribute with the "binary" option,
  it is added to that attribute in the search result (if that
  attribute is returned).

Migration plan (maybe this should be added as an implementation note):

(1) Servers upgrade to the new spec, while clients continue
    using ;binary.
(2) When (1) has progressed far enough, clients quit using ;binary.
(3) When (2) has progressed far enough, ;binary is removed from
    the next revision of the standard which defines it, if/when a
    next revision happens.

-- 
Hallvard


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAL9JnG02958 for ietf-pkix-bks; Thu, 21 Nov 2002 01:19:49 -0800 (PST)
Received: from mail.be.ubizen.com (batty.be.ubizen.com [212.113.70.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAL9Jkg02946 for <[e-mail]>; Thu, 21 Nov 2002 01:19:47 -0800 (PST)
Received: (from local) by mail.be.ubizen.com id LAA26241 for <[e-mail]>; Thu, 21 Nov 2002 11:58:37 +0100
Received: from internal via SMTP by batty.netvision.be, id smtpda26233; Thu Nov 21 10:58:32 2002
Received: (qmail 18846 invoked from network); 21 Nov 2002 08:54:40 -0000
Received: from unknown (HELO ubi) (10.0.0.10) by amaya.be.ubizen.com with SMTP; 21 Nov 2002 08:54:40 -0000
Received: from be.ubizen.com (por017a.be.ubizen.com [10.0.40.67]) by ubi.be.ubizen.com (#####) with ESMTP id <[e-mail]>; Thu, 21 Nov 2002 09:54:40 +0100 (MET)
Date: Thu, 21 Nov 2002 09:59:51 +0100
From: Andreas Mitrakas <[e-mail]>
Subject: Re: Update of RFC 2527 - opposed
To: "Hicks, Mack" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <[e-mail]>
X-Sanitizer: Out
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Policy format might not  necessarily matter except for automated checks. The
important thing is to be able to convey that information to relying parties.
Some CAs just hire auditors so that they keep their policies secret while they
disclose the auditor's report.

Format does not have to be mandated but a certificate needs a reference to a
policy and that the content requirements of such policy better be agreed upon
beforehand. May be RFC 2527 can focus more on end user certificates and
applications as it is still too abstract for end users.  I guess we are far from
over in this area.

andreas mitrakas
Ubizen


"Hicks, Mack" wrote:

> I have not posted on this list for some time, lurking has been fun though. I
> will say something that some might consider radical.
>
> I thought you might like to know how some of the business world is looking
> at RFC 2527 and its impact on the PKI business.
>
> RFC 2527 is being used as a template and checklist by auditors and
> associations to perform reviews on certificate authorities. Each entry and
> topic of RFC 2527 must be covered by the CA or one gets an "audit exception"
> or operations questions. This is done as a rote exercise.  Back when CAs
> were new, the checklist made sense - now some of the questions and sections
> is RFC 2527 are not as relevant to all CAs.
>
> I know of no use of the certificate policy in a business application; the
> policy is only there to tell any relying party that they should have a
> contract with someone before trusting this certificate. The meaning, impact,
> legality, effectiveness, application, etc. of a certificate is addressed in
> contract (and subject to contract law - as I understand it). There is no
> detailed policy in the CP anymore.
>
> The practice among most banks I talk to is that the certificate practice
> statement (CPS) is an internal document about the operation of the CA and
> related software (OCSP, CRL, LDAP); the CPS is not made public. Therefore
> the original goal of automated or assisted examination of a CP and CPS by a
> relying party is thwarted. (I supported the automation goal, but it is not
> achievable.)
>
> It is useful that a certificate has a reference to a policy - but the
> construction and content of that policy is no longer relevant in the
> businesses that I see.  There is no use to a CPS except as an internal
> checklist on CA construction and operation and acts as a mill stone around
> the neck of CA operators - a barrier to entry into PKI.  Therefore RFC 2527
> is purely informational to constructing a CA; I would prefer that it move
> toward elimination as standard.
>
> Mack Hicks, SVP
> Bank of America  760-318-9345



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAL73HP10364 for ietf-pkix-bks; Wed, 20 Nov 2002 23:03:17 -0800 (PST)
Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAL73Bg10342 for <[e-mail]>; Wed, 20 Nov 2002 23:03:12 -0800 (PST)
Received: from sesione ([12.230.105.28]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20021121070310.YLZR21905.sccrmhc02.attbi.com@sesione>; Thu, 21 Nov 2002 07:03:10 +0000
From: "Khaja Ahmed" <[e-mail]>
To: "Terwilliger, Ann" <[e-mail]>, <[e-mail]>
Subject: RE: Update of RFC 2527 - opposed
Date: Wed, 20 Nov 2002 23:03:17 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ann,

2527 does seem to be built on the assumption that the CA, subscribers and
relying parties are distinct legal entities.  This seemed clear to me
although, to the best of my recollection, this is not explicitly stated
anywhere.  (Please let me know if I am incorrect about either of the two
foregoing points.)  As Mack has pointed out, it is increasingly common to
have CA's setup for internal use by an organization or for a closed
community like an organization and it's customers.  For these situation 2527
can be problematic in the hands of auditors (internal or external) and even
implementers who do not understand this. It is not always/fully appreciated
that this is an informational RFC.

Your point about it being helpful as a checklist is very valid for public
CAs. It is not very helpful in setting up a CA used internally by an
organization, or one setup for use by an organization to secure
communication with it's employees or customers.  Perhaps that should be a
separate document.  If there are any updates to the RFC I hope these
distinctions will be properly dealt with.

Khaja

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Terwilliger, Ann
Sent: Wednesday, November 20, 2002 3:50 PM
To: [e-mail]
Subject: RE: Update of RFC 2527 - opposed



Another country is heard from......

Like Mack, I do not believe that automated review of a CP or CPS is
practical (even though it might be desirable).  I also agree that in many,
if not most, instances the CPS will not be made public.  However, I have to
disagree with his conclusion that RFC 2527 is not relevant.

RFC 2527 does provide a checklist for what areas need to be covered in
establishing and operating a CA.  The fact that some of the questions are
not as relevant today as they might have been when it was first drafted only
reinforces the fact that it should be updated to reflect current conditions.
There are other standards that address CA operation (e.g., X9.79, WebTrust
Audit for CA, the ABA document) but virtually all reference RFC 2527.

I would like to believe that all CA operators are knowledgeable about PKI
and adhere to best practices for operating their CA.  However, that is a
fairy tale--something on a par with the tooth fairy--and there needs to be
some process to ensure that the CA has established good security practices
and follows them.  Hence audits become necessary.

Audits by their very nature are comparing something against a checklist or
standard.  Auditors who are familiar with PKI are capable of adhering to the
spirit of the standard rather than the exact letter if parts of a standard
do not apply.  Unfortunately auditors who are not familiar with PKI may
perform audits more or less by rote.  To me this makes it more important,
not less so, that we continue to update RFC 2527.


-----Original Message-----
From: Hicks, Mack [mailto:[e-mail]]
Sent: Wednesday, November 20, 2002 1:10 PM
To: [e-mail]
Subject: Update of RFC 2527 - opposed



I have not posted on this list for some time, lurking has been fun though. I
will say something that some might consider radical.

I thought you might like to know how some of the business world is looking
at RFC 2527 and its impact on the PKI business.

RFC 2527 is being used as a template and checklist by auditors and
associations to perform reviews on certificate authorities. Each entry and
topic of RFC 2527 must be covered by the CA or one gets an "audit exception"
or operations questions. This is done as a rote exercise.  Back when CAs
were new, the checklist made sense - now some of the questions and sections
is RFC 2527 are not as relevant to all CAs.

I know of no use of the certificate policy in a business application; the
policy is only there to tell any relying party that they should have a
contract with someone before trusting this certificate. The meaning, impact,
legality, effectiveness, application, etc. of a certificate is addressed in
contract (and subject to contract law - as I understand it). There is no
detailed policy in the CP anymore.

The practice among most banks I talk to is that the certificate practice
statement (CPS) is an internal document about the operation of the CA and
related software (OCSP, CRL, LDAP); the CPS is not made public. Therefore
the original goal of automated or assisted examination of a CP and CPS by a
relying party is thwarted. (I supported the automation goal, but it is not
achievable.)

It is useful that a certificate has a reference to a policy - but the
construction and content of that policy is no longer relevant in the
businesses that I see.  There is no use to a CPS except as an internal
checklist on CA construction and operation and acts as a mill stone around
the neck of CA operators - a barrier to entry into PKI.  Therefore RFC 2527
is purely informational to constructing a CA; I would prefer that it move
toward elimination as standard.



Mack Hicks, SVP
Bank of America  760-318-9345



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAL6KJI08879 for ietf-pkix-bks; Wed, 20 Nov 2002 22:20:19 -0800 (PST)
Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAL6KGg08875 for <[e-mail]>; Wed, 20 Nov 2002 22:20:16 -0800 (PST)
Received: from user155.net249.fl.sprint-hsd.net ([209.26.25.155] helo=theoretic.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18EkhI-0004sy-00 for [e-mail]; Wed, 20 Nov 2002 22:20:20 -0800
Message-ID: <[e-mail]>
Date: Thu, 21 Nov 2002 01:17:30 -0500
From: Adam Theo <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.0.1) Gecko/20021119
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-pkix <[e-mail]>
Subject: certificates on a URI
X-Enigmail-Version: 0.63.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi, all. I was wondering if it was possible to represent PKIX
certificates on a single line, hopefully as part of a URI? I've not been
able to find any answers for this question by Googling or skimming the
most recent RFC's. Thanks.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAL6JoY08868 for ietf-pkix-bks; Wed, 20 Nov 2002 22:19:50 -0800 (PST)
Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAL6Jlg08863 for <[e-mail]>; Wed, 20 Nov 2002 22:19:47 -0800 (PST)
Received: from user155.net249.fl.sprint-hsd.net ([209.26.25.155] helo=theoretic.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18Ekgp-0004S0-00 for [e-mail]; Wed, 20 Nov 2002 22:19:51 -0800
Message-ID: <[e-mail]>
Date: Thu, 21 Nov 2002 01:17:02 -0500
From: Adam Theo <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.0.1) Gecko/20021119
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Overview Intro to PKIX, X.509, PGP, etc
X-Enigmail-Version: 0.63.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello, all. I'm looking for a good introduction that covers all the
major PKI mechanisms out there, including PKIX, X.509, PGP, etc, and how
they relate to each other.

Was hoping someone here knew of such a doc. Thanks.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAL2gpT27639 for ietf-pkix-bks; Wed, 20 Nov 2002 18:42:51 -0800 (PST)
Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAL2gng27634 for <[e-mail]>; Wed, 20 Nov 2002 18:42:49 -0800 (PST)
Received: from [64.139.6.114] (HELO NERVANA3) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.8) with SMTP id 51287148; Wed, 20 Nov 2002 18:42:48 -0800
From: "Jean Pawluk" <[e-mail]>
To: "'Hicks, Mack'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Update of RFC 2527 - opposed
Date: Wed, 20 Nov 2002 18:41:49 -0600
Message-ID: <000e01c290f6$c7926590$6501a8c0@NERVANA3>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I concur - if this information isn't spelled out in a contract then it is
not enforceable.

The checklists are useful however is the mandatory use or automation of the
cps reasonable?

I really don't think so, it would become a burden to other business besides
banking and it doesn't
add to the final usefulness of any PKI enabled applications as a mandatory
requirement

Regards (another lurker in the mist)
Jean

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Hicks, Mack
Sent: Wednesday, November 20, 2002 3:10 PM
To: [e-mail]
Subject: Update of RFC 2527 - opposed


I have not posted on this list for some time, lurking has been fun though. I
will say something that some might consider radical.

I thought you might like to know how some of the business world is looking
at RFC 2527 and its impact on the PKI business.

RFC 2527 is being used as a template and checklist by auditors and
associations to perform reviews on certificate authorities. Each entry and
topic of RFC 2527 must be covered by the CA or one gets an "audit exception"
or operations questions. This is done as a rote exercise.  Back when CAs
were new, the checklist made sense - now some of the questions and sections
is RFC 2527 are not as relevant to all CAs.

I know of no use of the certificate policy in a business application; the
policy is only there to tell any relying party that they should have a
contract with someone before trusting this certificate. The meaning, impact,
legality, effectiveness, application, etc. of a certificate is addressed in
contract (and subject to contract law - as I understand it). There is no
detailed policy in the CP anymore.

The practice among most banks I talk to is that the certificate practice
statement (CPS) is an internal document about the operation of the CA and
related software (OCSP, CRL, LDAP); the CPS is not made public. Therefore
the original goal of automated or assisted examination of a CP and CPS by a
relying party is thwarted. (I supported the automation goal, but it is not
achievable.)

It is useful that a certificate has a reference to a policy - but the
construction and content of that policy is no longer relevant in the
businesses that I see.  There is no use to a CPS except as an internal
checklist on CA construction and operation and acts as a mill stone around
the neck of CA operators - a barrier to entry into PKI.  Therefore RFC 2527
is purely informational to constructing a CA; I would prefer that it move
toward elimination as standard.



Mack Hicks, SVP
Bank of America  760-318-9345




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKNoLs19287 for ietf-pkix-bks; Wed, 20 Nov 2002 15:50:21 -0800 (PST)
Received: from portal1.visa.com ([198.80.42.2]) by above.proper.com (8.11.6/8.11.3) with SMTP id gAKNoBg19273 for <[e-mail]>; Wed, 20 Nov 2002 15:50:11 -0800 (PST)
Received: by portal1.visa.com id PAA20134 (InterLock SMTP Gateway 4.2 for [e-mail]); Wed, 20 Nov 2002 15:50:58 -0800
Received: by portal1.visa.com (Protected-side Proxy Mail Agent-1); Wed, 20 Nov 2002 15:50:58 -0800
Message-Id: <[e-mail]>
From: "Terwilliger, Ann" <[e-mail]>
To: [e-mail]
Subject: RE: Update of RFC 2527 - opposed
Date: Wed, 20 Nov 2002 15:50:08 -0800
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Another country is heard from......

Like Mack, I do not believe that automated review of a CP or CPS is
practical (even though it might be desirable).  I also agree that in many,
if not most, instances the CPS will not be made public.  However, I have to
disagree with his conclusion that RFC 2527 is not relevant.

RFC 2527 does provide a checklist for what areas need to be covered in
establishing and operating a CA.  The fact that some of the questions are
not as relevant today as they might have been when it was first drafted only
reinforces the fact that it should be updated to reflect current conditions.
There are other standards that address CA operation (e.g., X9.79, WebTrust
Audit for CA, the ABA document) but virtually all reference RFC 2527. 

I would like to believe that all CA operators are knowledgeable about PKI
and adhere to best practices for operating their CA.  However, that is a
fairy tale--something on a par with the tooth fairy--and there needs to be
some process to ensure that the CA has established good security practices
and follows them.  Hence audits become necessary.    

Audits by their very nature are comparing something against a checklist or
standard.  Auditors who are familiar with PKI are capable of adhering to the
spirit of the standard rather than the exact letter if parts of a standard
do not apply.  Unfortunately auditors who are not familiar with PKI may
perform audits more or less by rote.  To me this makes it more important,
not less so, that we continue to update RFC 2527.  
 

-----Original Message-----
From: Hicks, Mack [mailto:[e-mail]]
Sent: Wednesday, November 20, 2002 1:10 PM
To: [e-mail]
Subject: Update of RFC 2527 - opposed



I have not posted on this list for some time, lurking has been fun though. I
will say something that some might consider radical.

I thought you might like to know how some of the business world is looking
at RFC 2527 and its impact on the PKI business.

RFC 2527 is being used as a template and checklist by auditors and
associations to perform reviews on certificate authorities. Each entry and
topic of RFC 2527 must be covered by the CA or one gets an "audit exception"
or operations questions. This is done as a rote exercise.  Back when CAs
were new, the checklist made sense - now some of the questions and sections
is RFC 2527 are not as relevant to all CAs.

I know of no use of the certificate policy in a business application; the
policy is only there to tell any relying party that they should have a
contract with someone before trusting this certificate. The meaning, impact,
legality, effectiveness, application, etc. of a certificate is addressed in
contract (and subject to contract law - as I understand it). There is no
detailed policy in the CP anymore.

The practice among most banks I talk to is that the certificate practice
statement (CPS) is an internal document about the operation of the CA and
related software (OCSP, CRL, LDAP); the CPS is not made public. Therefore
the original goal of automated or assisted examination of a CP and CPS by a
relying party is thwarted. (I supported the automation goal, but it is not
achievable.)

It is useful that a certificate has a reference to a policy - but the
construction and content of that policy is no longer relevant in the
businesses that I see.  There is no use to a CPS except as an internal
checklist on CA construction and operation and acts as a mill stone around
the neck of CA operators - a barrier to entry into PKI.  Therefore RFC 2527
is purely informational to constructing a CA; I would prefer that it move
toward elimination as standard.



Mack Hicks, SVP  
Bank of America  760-318-9345


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKNdew18892 for ietf-pkix-bks; Wed, 20 Nov 2002 15:39:40 -0800 (PST)
Received: from bach.digsigtrust.com (host65-54.digsigtrust.com [208.30.65.54]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAKNdbg18887 for <[e-mail]>; Wed, 20 Nov 2002 15:39:37 -0800 (PST)
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id gAKNdXO29560; Wed, 20 Nov 2002 16:39:33 -0700 (MST)
Received: from trustdst.com (host192-35-174-247.digsigtrust.com [192.35.174.247]) by smtp.digsigtrust.com with ESMTP id gAKNdpi08113; Wed, 20 Nov 2002 16:39:51 -0700 (MST)
Message-ID: <[e-mail]>
Date: Wed, 20 Nov 2002 16:39:26 -0700
From: Russel F Weiser <[e-mail]>
Reply-To: [e-mail]
Organization: Digital Signature Trust 
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: "Housley, Russ" <[e-mail]>, [e-mail], Hallvard B Furuseth <[e-mail]>, [e-mail], "Ramsay, Ron" <[e-mail]>
Subject: Re: No-op LDAP ;binary option
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms84DEC30A4AE64E0FFE04FCB2"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms84DEC30A4AE64E0FFE04FCB2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I strongly agree with Hallvard's solution!!!
Cheers
Russel F Weiser


Steve Hanna wrote:
> 
> Russ Housley wrote:
> >I do not really care as long as we agree on ONE way to do it.  We can come
> >up with a transition strategy once there is an agreed to standard.  I
> >cannot accept multiple ways to ask for the same stuff.
> 
> We need to support userCertificate;binary because that's what
> the current spec and implementations support. The LDAPBIS
> working group wants to transition to userCertificate.
> 
> I don't think it's possible to meet both of these requirements
> without having two ways to access the attribute. Why is it so
> important to only have one way? Wouldn't a smooth transition
> from userCertificate;binary to userCertificate be preferable?
> Do you have some better idea? If so, please present it.
> 
> Otherwise, I suggest we use Hallvard's simplest solution:
> New servers MUST support userCertificate or userCertificate;binary
> and treat them as identical. Clients SHOULD use userCertificate;binary.
> Once the old servers are gone, we can say that clients SHOULD
> use userCertificate.
> 
> -Steve
--------------ms84DEC30A4AE64E0FFE04FCB2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIUCgYJKoZIhvcNAQcCoIIT+zCCE/cCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
EgYwggcvMIIGF6ADAgECAhEAzzw044sXV7nhSQL1unM78DANBgkqhkiG9w0BAQUFADBdMQsw
CQYDVQQGEwJVUzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRAwDgYD
VQQLEwdUcnVzdElEMRYwFAYDVQQDEw1UcnVzdElEIENBIEExMB4XDTAyMDYwMzIyMTIyNloX
DTAzMDYwMzIyMTIyNlowgcoxCzAJBgNVBAYTAlVTMSQwIgYDVQQKExtESUdJVEFMIFNJR05B
VFVSRSBUUlVTVCBDTy4xJDAiBgNVBAsTG0RJR0lUQUwgU0lHTkFUVVJFIFRSVVNUIENPLjEY
MBYGA1UEAxMPUnVzc2VsIEYgV2Vpc2VyMSMwIQYJKoZIhvcNAQkBFhRyd2Vpc2VyQHRydXN0
ZHN0LmNvbTEwMC4GCgmSJomT8ixkAQETIEQwMUU0NzQyMDAwMDAwRUUzODA5MzhERjAwMDA5
OTREMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDS3Nz9nCY4Mu/Sa3x721rtLDGgNWll
G86TBlRZT/+ouDtyHQjoWOLPIe2LYMOBVvXq/PccnaKjreHZHFx/7sDJXFuyiByZyBQZJW6c
uJLy5CyMLY8UMjoZgXLede/SIkm9Bd2F7zwqCY7Lft455FPWS8cjl34+FHy8Q7k+ubuXiQID
AQABo4ID/jCCA/owDgYDVR0PAQH/BAQDAgTwMB8GA1UdIwQYMBaAFCql8H708O801Z2nKJgP
I9Ofu3MEMIIBQgYDVR0gBIIBOTCCATUwggExBgpghkgBhvkvAAYCMIIBITBHBggrBgEFBQcC
ARY7aHR0cDovL3d3dy5kaWdzaWd0cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90c2lu
ZGV4Lmh0bWwwgdUGCCsGAQUFBwICMIHIGoHFVGhpcyBUcnVzdElEIENlcnRpZmljYXRlIG1h
eSBvbmx5IGJlIHJlbGllZCB1cG9uIGJ5IEF1dGhvcml6ZWQgUmVseWluZyBQYXJ0aWVzIGlu
IGFjY29yZGFuY2Ugd2l0aCB0aGUgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQg
YXQgaHR0cDovL3d3dy5kaWdzaWd0cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90c2lu
ZGV4Lmh0bWwwgY8GA1UdHwSBhzCBhDCBgaB/oH2Ge2xkYXA6Ly9sZGFwLmRpZ3NpZ3RydXN0
LmNvbS9jbj1UcnVzdElEIENBIEExLG91PVRydXN0SUQsbz1EaWdpdGFsIFNpZ25hdHVyZSBU
cnVzdCBDby4sYz1VUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTCB1gYJYIZI
AYb4QgENBIHIFoHFVGhpcyBUcnVzdElEIENlcnRpZmljYXRlIG1heSBvbmx5IGJlIHJlbGll
ZCB1cG9uIGJ5IEF1dGhvcml6ZWQgUmVseWluZyBQYXJ0aWVzIGluIGFjY29yZGFuY2Ugd2l0
aCB0aGUgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0cDovL3d3dy5k
aWdzaWd0cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90c2luZGV4Lmh0bWwwHwYDVR0R
BBgwFoEUcndlaXNlckB0cnVzdGRzdC5jb20wHQYDVR0OBBYEFG5x5dqmNyzh9OnRvaXue7aD
+yZ5MIG2BggrBgEFBQcBAQSBqTCBpjAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AuZGlnc2ln
dHJ1c3QuY29tMHsGCCsGAQUFBzAChm9sZGFwOi8vbGRhcC5kaWdzaWd0cnVzdC5jb20vY249
VHJ1c3RJRCBDQSBBMSxvdT1UcnVzdElELG89RGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28u
LGM9dXM/Y0FjZXJ0aWZpY2F0ZTtiaW5hcnkwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF
BwMEMA0GCSqGSIb3DQEBBQUAA4IBAQApi2y/iSFApc78mCHPWRvz750RCT/FJId4zPxKm7Fh
tTpOnL8K9P0NcTasN9dNaBrQSDhjKl3hsn7Dlezb6sMqCM5YzBiI8u3bTnmTZOnK9h/BqNat
zQPKBekN00N5eTi/W8b3g17hHAfxOuy1tVhaXk4QV7uIfI5ZVlkkRanARhppO/KtYfrcUh9+
+nwHd0txn0LBpdoQaxhHLqCF9Ro0QrmZbBwxLxB42lyXfWI8C32QMJWUQ3EPmlGim2vSKBJ+
Gur3kh89g8fwADSbC0JgJ8LjOhSfLlIyyZqyIrzwm0bR0/lI3S0uHZfDDsa0RP6kLwWrlbhk
NUoeK1YrRoBjMIIHJTCCBg2gAwIBAgIRANAeRzgAAAJ8AAAAAgAAAAgwDQYJKoZIhvcNAQEF
BQAwPzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRcwFQYDVQQDEw5E
U1QgUm9vdCBDQSBYMzAeFw0wMDEwMDEwMDAwMDRaFw0wNTEwMDEwMDAwMDRaMF0xCzAJBgNV
BAYTAlVTMSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xEDAOBgNVBAsT
B1RydXN0SUQxFjAUBgNVBAMTDVRydXN0SUQgQ0EgQTEwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQC4Jz3A9TctP4JhID5AKuaJXHGnrrhTVnilm8CVN4kzjdw+sIykPP4ltEiW
8YZ72BZakfA5b7KIlNC7vYyDv7Bhn14fJ/OoUrKHvMmsxmkOjJe904J7Zu/yy05vmO7KE872
2x+u5Wo5iMVIbFGb+hjAyoxxc2kEero+RZpG9oYbqmzfyVDeTYRPweIhIDpDuOUV/7UmtJ1r
8IKCMC071CIC3ksxwPmb+mBRW1EhazSsQCkn2+CFRAQSnmgNOh5475s9AOboincoXOlVU+Lp
f/8adh7xC7ysf0212ylZXsoi51kA0A5oCVdpG9L2oxSCXolwVfzI9jYidVE213QRsYyVAgMB
AAGjggP8MIID+DAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBxjAdBgNVHSUEFjAU
BggrBgEFBQcDAgYIKwYBBQUHAwQwHwYDVR0jBBgwFoAUxKexpHsscfrb4UuQdf/EFWCFiRAw
ggJ3BgNVHSAEggJuMIICajCCATEGCmCGSAGG+S8ABgEwggEhMEcGCCsGAQUFBwIBFjtodHRw
Oi8vd3d3LmRpZ3NpZ3RydXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzaW5kZXguaHRt
bDCB1QYIKwYBBQUHAgIwgcgagcVUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgbWF5IG9ubHkg
YmUgcmVsaWVkIHVwb24gYnkgQXV0aG9yaXplZCBSZWx5aW5nIFBhcnRpZXMgaW4gYWNjb3Jk
YW5jZSB3aXRoIHRoZSBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRw
Oi8vd3d3LmRpZ3NpZ3RydXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzaW5kZXguaHRt
bDCCATEGCmCGSAGG+S8ABgIwggEhMEcGCCsGAQUFBwIBFjtodHRwOi8vd3d3LmRpZ3NpZ3Ry
dXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzaW5kZXguaHRtbDCB1QYIKwYBBQUHAgIw
gcgagcVUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgbWF5IG9ubHkgYmUgcmVsaWVkIHVwb24g
YnkgQXV0aG9yaXplZCBSZWx5aW5nIFBhcnRpZXMgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBU
cnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwOi8vd3d3LmRpZ3NpZ3Ry
dXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzaW5kZXguaHRtbDB9BgNVHR8EdjB0MHKg
cKBuhmxsZGFwOi8vbGRhcC5kaWdzaWd0cnVzdC5jb20vY249RFNUIFJvb3QgQ0EgWDMsbz1E
aWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDti
aW5hcnkwfAYIKwYBBQUHAQEEcDBuMGwGCCsGAQUFBzAChmBsZGFwOi8vbGRhcC5kaWdzaWd0
cnVzdC5jb20vY249RFNUIFJvb3QgQ0EgWDMsbz1EaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBD
by4/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwHQYDVR0OBBYEFCql8H708O801Z2nKJgPI9Ofu3ME
MA0GCSqGSIb3DQEBBQUAA4IBAQCj+kOSoDVzPR/xEecuU53DL5i2rY0mjVe4oPfNzFyn4sW0
il++ylFKEi9/d+/EVaTUlXolr6ZTS1A3Lr7hjBkYAwV0pqJHSI2IYTJ2i13XL6mdid0ngs+j
Lrts/FXvSBpzRwKUXifNvoil2sXMaJJ5Nzm30bQY8CHsBC6S24w4j3QrFrgHJ25nG5vHtXR6
znyMIN5/e8y2W1/L0QNfsWAnRJWy75Dn9sCHQ82Mds0ZJkx6Px0M142Tf8Re156fHMBhDSrZ
bdE4K9HXS+zKISbc86Nw8HvrjriVf2FQ+e7+5GL1XmdDewSlgh0MxpWH+SeRlrErKaH7g2mY
v2Jq+TdNMIIDpjCCAo6gAwIBAgIRANAeRxoAAAJ8AAAAFgAAAAIwDQYJKoZIhvcNAQEFBQAw
gakxCzAJBgNVBAYTAnVzMQ0wCwYDVQQIEwRVdGFoMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0
eTEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMREwDwYDVQQLEwhEU1RD
QSBYMTEWMBQGA1UEAxMNRFNUIFJvb3RDQSBYMTEhMB8GCSqGSIb3DQEJARYSY2FAZGlnc2ln
dHJ1c3QuY29tMB4XDTAwMTAzMDIzMjk1NFoXDTA4MDgyOTIzMjk1NFowPzEkMCIGA1UEChMb
RGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRcwFQYDVQQDEw5EU1QgUm9vdCBDQSBYMzCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN+v6ZdQCINXtMxiZfaQguzH0yxrMMpb
7NnDfcdAwRgUi+DoM3ZJKuM/IUmTrE4Orz5Iy2Xu/NMhD2XSKtkyj4zl93ewEnu1lcCJo6m6
7XMuegwGMoOifooUMM0RoOEqOLl5CjH9UL2AZd+3UWODyOKIYepLYYHsUmu5ouJLGiifSKOe
DNoJjj4XLh7dIN9bxiqKqy69cK3FCxolkHRyxXtqqzTWMIn/5WgTe1QLyNau7Fqckh49ZLOM
xt+/yUFw7BZy1SbsOFU5Q9D8/RhcQPGX69Wam40dutolucbY38EVAjqr2m7xPi71XAicPNaD
aeQQmxkqtilX4+U9m5/wAl0CAwEAAaMyMDAwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU
xKexpHsscfrb4UuQdf/EFWCFiRAwDQYJKoZIhvcNAQEFBQADggEBACKYf00WJwpCQYO40o9Y
qgda845eu6ccwGUZje4aTsl/G14qQnTDeTTBjp1JUrp1xlI8Njj94nJI6xxn2CYMzdRthwmf
EkfbYAac4BlMsLuVwOyjj2vIggzQx9vI13gglAQuapCCEXBFTM2B/nKQRcZHMJ62xM9s3GEE
ZksVwMlQ4fFTshO6fC8Q+g4D/QD7UCToKTdVGEq8gKGZDs818EyQwSabJ4Nf40pHnA+FxxSl
kdX0BXcSH9rlZi5U47OvYfdXAKbSK2MkMs5x3ljw0aBnNG+SmtxgB0KZWKxN9pn8R5blvYqO
vkzVSurdDyZy2l8praRlhHT8Sqj0mnEQw/AxggHMMIIByAIBATByMF0xCzAJBgNVBAYTAlVT
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xEDAOBgNVBAsTB1RydXN0
SUQxFjAUBgNVBAMTDVRydXN0SUQgQ0EgQTECEQDPPDTjixdXueFJAvW6czvwMAkGBSsOAwIa
BQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIxMTIw
MjMzOTI2WjAjBgkqhkiG9w0BCQQxFgQU4a6+xS+DhnlbqLHw35K0w9vJ6KkwUgYJKoZIhvcN
AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB1Rjohou36PWXnf4yeNBOD
2a+EoRMpWnb9WpFFvvQOH99wuzWr0B3kEv1IFjsxcjMHBLbydoF3Va+W7uxh9VfwUowszdpH
/I637ORKU+51upUcp4gs4dYIhV5G259dnpD5hXrbe2BPrKTN6lvxyAc79hxrIYvxB9Adp3he
AytlMA==
--------------ms84DEC30A4AE64E0FFE04FCB2--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKLxFw13694 for ietf-pkix-bks; Wed, 20 Nov 2002 13:59:15 -0800 (PST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAKLxCg13690 for <[e-mail]>; Wed, 20 Nov 2002 13:59:12 -0800 (PST)
Received: from sydney.East.Sun.COM ([129.148.9.16]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02485; Wed, 20 Nov 2002 14:59:14 -0700 (MST)
Received: from sydney.East.Sun.COM (esun1as-be21-ge0.Central.Sun.COM [129.147.60.148]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id gAKLwxJ19918; Wed, 20 Nov 2002 16:59:01 -0500 (EST)
From: Steve Hanna <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 20 Nov 2002 16:59:04 -0500
To: "Housley, Russ" <[e-mail]>, <[e-mail]>
Cc: "Hallvard B Furuseth" <[e-mail]>, <[e-mail]>, "Ramsay, Ron" <[e-mail]>
Reply-To: <[e-mail]>
Subject: RE: No-op LDAP ;binary option
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley wrote:
>I do not really care as long as we agree on ONE way to do it.  We can come 
>up with a transition strategy once there is an agreed to standard.  I 
>cannot accept multiple ways to ask for the same stuff.

We need to support userCertificate;binary because that's what
the current spec and implementations support. The LDAPBIS
working group wants to transition to userCertificate.

I don't think it's possible to meet both of these requirements
without having two ways to access the attribute. Why is it so
important to only have one way? Wouldn't a smooth transition
from userCertificate;binary to userCertificate be preferable?
Do you have some better idea? If so, please present it.

Otherwise, I suggest we use Hallvard's simplest solution:
New servers MUST support userCertificate or userCertificate;binary
and treat them as identical. Clients SHOULD use userCertificate;binary.
Once the old servers are gone, we can say that clients SHOULD
use userCertificate.

-Steve



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKLPqi10838 for ietf-pkix-bks; Wed, 20 Nov 2002 13:25:52 -0800 (PST)
Received: from sfemail.bankofamerica.com (sfemail.bankofamerica.com [171.159.64.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAKLPog10829 for <[e-mail]>; Wed, 20 Nov 2002 13:25:50 -0800 (PST)
Received: from sfimail.bankofamerica.com (sfimail.bankofamerica.com [171.182.72.13]) by sfemail.bankofamerica.com (8.11.1/8.11.1) with ESMTP id gAKLPkx24958 for <[e-mail]>; Wed, 20 Nov 2002 21:25:46 GMT
Received: from smtpsw03 (smtpsw03.bankofamerica.com [165.48.14.143]) by sfimail.bankofamerica.com (8.11.1/8.11.1) with ESMTP id gAKLPXo15834 for <[e-mail]>; Wed, 20 Nov 2002 21:25:33 GMT
Content-return: allowed
Date: Wed, 20 Nov 2002 13:10:12 -0800
From: "Hicks, Mack" <[e-mail]>
Subject: Update of RFC 2527 - opposed
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have not posted on this list for some time, lurking has been fun though. I
will say something that some might consider radical.

I thought you might like to know how some of the business world is looking
at RFC 2527 and its impact on the PKI business.

RFC 2527 is being used as a template and checklist by auditors and
associations to perform reviews on certificate authorities. Each entry and
topic of RFC 2527 must be covered by the CA or one gets an "audit exception"
or operations questions. This is done as a rote exercise.  Back when CAs
were new, the checklist made sense - now some of the questions and sections
is RFC 2527 are not as relevant to all CAs.

I know of no use of the certificate policy in a business application; the
policy is only there to tell any relying party that they should have a
contract with someone before trusting this certificate. The meaning, impact,
legality, effectiveness, application, etc. of a certificate is addressed in
contract (and subject to contract law - as I understand it). There is no
detailed policy in the CP anymore.

The practice among most banks I talk to is that the certificate practice
statement (CPS) is an internal document about the operation of the CA and
related software (OCSP, CRL, LDAP); the CPS is not made public. Therefore
the original goal of automated or assisted examination of a CP and CPS by a
relying party is thwarted. (I supported the automation goal, but it is not
achievable.)

It is useful that a certificate has a reference to a policy - but the
construction and content of that policy is no longer relevant in the
businesses that I see.  There is no use to a CPS except as an internal
checklist on CA construction and operation and acts as a mill stone around
the neck of CA operators - a barrier to entry into PKI.  Therefore RFC 2527
is purely informational to constructing a CA; I would prefer that it move
toward elimination as standard.



Mack Hicks, SVP  
Bank of America  760-318-9345



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKKYs507436 for ietf-pkix-bks; Wed, 20 Nov 2002 12:34:54 -0800 (PST)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id gAKKYpg07429 for <[e-mail]>; Wed, 20 Nov 2002 12:34:51 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 20 Nov 2002 20:34:54 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA19158; Wed, 20 Nov 2002 15:34:50 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id gAKKW5T11034; Wed, 20 Nov 2002 15:32:05 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <W53VHJ7K>; Wed, 20 Nov 2002 15:34:49 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.39]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W53VHJ72; Wed, 20 Nov 2002 15:34:47 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: "Ramsay, Ron" <[e-mail]>, [e-mail], Hallvard B Furuseth <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 20 Nov 2002 15:33:46 -0500
Subject: RE: No-op LDAP ;binary option
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve:

I do not really care as long as we agree on ONE way to do it.  We can come 
up with a transition strategy once there is an agreed to standard.  I 
cannot accept multiple ways to ask for the same stuff.

Russ

At 11:22 AM 11/19/2002 -0500, Steve Hanna wrote:
>Russ Housley wrote:
> >I do not care how this gets encoded in the darn LDAP protocol; however,
> >certificate users need fetch the certificate as a binary blob.
>
>I *do* care how it gets encoded in LDAP. My LDAP client followed RFC 2256,
>which said to store and retrieve the userCertificate attribute using
>the ;binary option. It seems to me that future versions of LDAPv3
>should maintain the ability to do this, since it was once the recommended
>way (in a Proposed Standard that's part of LDAPv3, no less!). Any of
>Hallvard's solutions are fine with me.
>
>Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKJclf05457 for ietf-pkix-bks; Wed, 20 Nov 2002 11:38:47 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAKJcjg05453 for <[e-mail]>; Wed, 20 Nov 2002 11:38:45 -0800 (PST)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 20 Nov 2002 12:38:33 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.5.0 Beta 
Date: Wed, 20 Nov 2002 12:38:18 -0700
From: "Jim Sermersheim" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: ;binary migration solution
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gAKJcjg05454
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The way the specification was written, the ;binary option is never stored with the value. it was only to be used to denote the transfer encoding format. By making the "native encoding" of userCertificate equivalent to the "binary" encoding, this makes "userCertificate" and "userCertificate;binary" equivalent. This is why I agreed with your proposal.

Jim

>>> Hallvard B Furuseth <[e-mail]> 11/20/02 08:41AM >>>
[e-mail] writes:
> I am not sure that this solves the migration problem since you are
> giving rules that have to be obeyed by existing systems, which they
> cant do if they are not upgraded. My "control" solution did not effect
> existing systems, only new systems. This was the point in having a
> migration solution.

As Kurt mentioned, you should send your suggestion to [e-mail].
(And then maybe I should send this letter there too, unless you
tell me where I'm wrong or address this posting in your pkix message.)

Anyway, I don't see what you mean.

With my original suggesetion, the migration solution on the client side
is simply to make no changes and keep asking for userCertificate;binary.
That will handle both old and new servers.

The final step of the migration on the client side, to remove the
migration solution (not use ";binary" or a "don't use binary" control),
must in either case wait until one trusts that all serveres the client
will use have been upgraded.

The same step on the server side must in both cases wait until one
trusts that no clients that use the server, use the migration solution.

Have I missed something?


Well, I may have missed to handle update operations, though.  When
"userCertificate;binary" is added (with the add/modify operation) today,
does the server remove ";binary" and store the name "userCertificate"?
If so, my version of ";binary" should do the same.

-- 
Hallvard



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKIQbw00677 for ietf-pkix-bks; Wed, 20 Nov 2002 10:26:37 -0800 (PST)
Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAKIQZg00672 for <[e-mail]>; Wed, 20 Nov 2002 10:26:35 -0800 (PST)
Received: from dwc ([80.7.98.57]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20021120182635.HRNP28295.mta03-svc.ntlworld.com@dwc>; Wed, 20 Nov 2002 18:26:35 +0000
From: [e-mail]
To: <[e-mail]>, "Ramsay, Ron" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
Date: Wed, 20 Nov 2002 18:26:19 -0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: RE: No-op LDAP ;binary option
CC: "Hallvard B Furuseth" <[e-mail]>, <[e-mail]>
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.01a)
Message-Id: <20021120182635.HRNP28295.mta03-svc.ntlworld.com@dwc>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

From:           	Steve Hanna <[e-mail]>
Date sent:      	Wed, 20 Nov 2002 11:22:05 -0500
To:             	<[e-mail]>, <[e-mail]>,
  	"Ramsay, Ron" <[e-mail]>, "Russ Housley" <[e-mail]>
Copies to:      	"Hallvard B Furuseth" <[e-mail]>, <[e-mail]>
Send reply to:  	<[e-mail]>
Subject:        	RE: No-op LDAP ;binary option

> 
> >> I *do* care how it gets encoded in LDAP. 
> >
> >So do I. That's why the PKIX LDAP PKI Schema ID ensures that the bits on the 
> >line are exactly the same when userCertificates are requested in the new spec, 
> >compared with userCertificates;binary in the old spec
> 
> Great. But the new schema document and the new LDAP specs no longer
> include support for the ;binary option. Right? 

Correct

>So that means
> that old clients that ask for userCertificates;binary will get
> an error from new servers that don't recognize the ;binary option
> and new clients that ask for userCertificates will get an error
> from old servers that believe you must use the ;binary option
> to retrieve the userCertificates attribute. If I'm wrong, please
> explain why.

You are correct. I sent an email to the LDAPBis list last week that explained 
how this can be solved with a new LDAPv3 Control. I will circulate this to the 
PKIX list when I get my laptop back from the repairers (or if you have the 
message you could forward it for me)

regards

David

> 
> It's not enough to have the same bits in the attribute value.
> The new LDAP specs must also support the other features of the
> existing protocol, including the ;binary option. Otherwise,
> chaos will reign.
> 
> -Steve
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKI6L727993 for ietf-pkix-bks; Wed, 20 Nov 2002 10:06:21 -0800 (PST)
Received: from srv0.ops.ietf.org (srv0.ietf55.ops.ietf.org [205.238.48.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAKI6Jg27988 for <[e-mail]>; Wed, 20 Nov 2002 10:06:19 -0800 (PST)
Received: from [204.42.67.195] (helo=daasi.de) by srv0.ops.ietf.org with esmtp (Exim 4.10) id 18EZEw-000HVE-00; Wed, 20 Nov 2002 18:06:18 +0000
Message-ID: <[e-mail]>
Date: Wed, 20 Nov 2002 19:06:11 +0100
From: Peter Gietz <[e-mail]>
Organization: DAASI International GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: de-de, en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: new version of draft on additional x509certificateschema for LDAP
References: <p05200f15b9fee3f2beea@[204.42.71.167]> <20021120135537.BAMN16799.mta05-svc.ntlworld.com@dwc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gAKI6Jg27989
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:
> Date sent:      	Mon, 18 Nov 2002 21:47:54 +0100 (CET)
> Subject:        	Re: new version of draft on additional x509certificateschema for LDAP
> From:           	"Peter Gietz" <[e-mail]>
> To:             	<[e-mail]>
> 
>>I don't yet think that there is a need for similiar AUXILIARY object
>>classes. The whole idea behind our draft is to have an entry for each
>>certificate, thus the thing that this entry is all about is the
>>certificate, thus a typical use case for STRUCTURAL. Even if there will
>>be the need in future to add additional data to such an entry, it can
>>be done with auxiliary objectclasses sticked to these structural ones.
>>
>>Does the latter conflict with your idea of packaging, David?
> 
> 
> Yes. We already have a requirement for a common object class for all X.509 
> attributes. (You can read this in our detailed design submitted to Terena at the 
> end of last week). We need to search for all X.509 entries subordinate to a 
> user's entry. Whilst it is true that we could search for multiple object classes 
> (and update the code when new ones are defined), having a common object 
> class containing common attributes, makes it easier and hopefully future proof. 
> That's why I would like to hold off the final decision until we have published our 
> Attribute Cert and CRL schema IDs

Ok. My statement started with "until that discussion takes place" 
anyway. Looking forward to reading those IDs.

Cheers,

Peter


> 
> 
>>BTW: my first hesitance to define an ABSTRACT class, was that this is
>>not done very often (in fact it will be the first one after top).
> 
> 
> Actually I did this a few years ago when I defined Families of Entries
> 
> David
> 
> 
>>But
>>since it is a perfect means to prevent an instantiation without the
>>certificate, why not go for it.
>>
>>Cheers,
>>
>>Peter
>>
>>
>>
>>
>>
>>
> 
> 
> 


-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]
D-72074 Tübingen                        email: [e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKGMUs19232 for ietf-pkix-bks; Wed, 20 Nov 2002 08:22:30 -0800 (PST)
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAKGMRg19226 for <[e-mail]>; Wed, 20 Nov 2002 08:22:28 -0800 (PST)
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26877; Wed, 20 Nov 2002 08:22:18 -0800 (PST)
Received: from sydney.East.Sun.COM (esun1as-be21-ge0.Central.Sun.COM [129.147.60.148]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id gAKGM2J04949; Wed, 20 Nov 2002 11:22:03 -0500 (EST)
From: Steve Hanna <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 20 Nov 2002 11:22:05 -0500
To: <[e-mail]>, <[e-mail]>, "Ramsay, Ron" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: "Hallvard B Furuseth" <[e-mail]>, <[e-mail]>
Reply-To: <[e-mail]>
Subject: RE: No-op LDAP ;binary option
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>> I *do* care how it gets encoded in LDAP. 
>
>So do I. That's why the PKIX LDAP PKI Schema ID ensures that the bits on the 
>line are exactly the same when userCertificates are requested in the new spec, 
>compared with userCertificates;binary in the old spec

Great. But the new schema document and the new LDAP specs no longer
include support for the ;binary option. Right? So that means
that old clients that ask for userCertificates;binary will get
an error from new servers that don't recognize the ;binary option
and new clients that ask for userCertificates will get an error
from old servers that believe you must use the ;binary option
to retrieve the userCertificates attribute. If I'm wrong, please
explain why.

It's not enough to have the same bits in the attribute value.
The new LDAP specs must also support the other features of the
existing protocol, including the ;binary option. Otherwise,
chaos will reign.

-Steve



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKEP9W12999 for ietf-pkix-bks; Wed, 20 Nov 2002 06:25:09 -0800 (PST)
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAKEP7g12992 for <[e-mail]>; Wed, 20 Nov 2002 06:25:07 -0800 (PST)
Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18EVmo-0005t9-00; Wed, 20 Nov 2002 15:25:02 +0100
Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18EVmn-0000ok-00; Wed, 20 Nov 2002 15:25:01 +0100
From: Hallvard B Furuseth <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: Re: No-op LDAP ;binary option
In-Reply-To: <20021120135540.BAOK16799.mta05-svc.ntlworld.com@dwc>
References: <[e-mail]> <20021120135540.BAOK16799.mta05-svc.ntlworld.com@dwc>
X-Mailer: VM 6.37 under Emacs 19.34.1
Date: Wed, 20 Nov 2002 15:25:01 +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] writes:

> this is horrible. We dont really want to store two attribute do we?
> (...) existing systems that support ;binary encodings should still
> store the attributes as userCertificates and not
> userCertificate;binary.

Oh.  I misunderstood the spec.  I wish someone had told me before I
posted on both lists:-) But this certainly makes things nicer.  Here is
a revised suggestion:

- The "binary" option does nothing to encoding.
  Attribute syntaxes take care of encoding.
- The option is removed from attribute descriptions in an LDAP
  operations, except in the list of requested attributes in search
  operations, and except in places where options may not occur.
- If a search requested an attribute with the "binary" option,
  it is added to that attribute in the search result (if that
  attribute is returned).

Did I get it right this time?

-- 
Hallvard


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKDthI10116 for ietf-pkix-bks; Wed, 20 Nov 2002 05:55:43 -0800 (PST)
Received: from mta05-svc.ntlworld.com (mta05-svc.ntlworld.com [62.253.162.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAKDteg10109 for <[e-mail]>; Wed, 20 Nov 2002 05:55:41 -0800 (PST)
Received: from dwc ([80.7.98.57]) by mta05-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20021120135540.BAOK16799.mta05-svc.ntlworld.com@dwc>; Wed, 20 Nov 2002 13:55:40 +0000
From: [e-mail]
To: [e-mail], Hallvard B Furuseth <[e-mail]>
Date: Wed, 20 Nov 2002 13:55:20 -0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: No-op LDAP ;binary option
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.01a)
Message-Id: <20021120135540.BAOK16799.mta05-svc.ntlworld.com@dwc>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

From:           	Hallvard B Furuseth <[e-mail]>
To:             	[e-mail]
Subject:        	No-op LDAP ;binary option
Date sent:      	Mon, 18 Nov 2002 13:14:12 +0100

> 
> Three related suggestions for the ;binary LDAP option, moved here from
> LDAPBIS since it is the PKIX group who "owns" the ";binary" question:
> 
> 
> Define the ;binary option to have no effect on encoding, and trust the
> syntax of the attribute to take care of encoding.
> 
> Thus, you can put "userCertificate" in the Directory if that's what your
> clients need, "userCertificate;binary" - with the same encoding - if
> that's what they need, or both if you have both types of clients.
> 
> 
> Or, one could define ;binary to do nothing except that if the client
> requests ;binary on an attribute, it receives it with ;binary - whether
> or not the has ;binary in the directory.
> 
> Thus you could have "userCertificate" in the directory and clients would
> by default receive that, but clients that wanted ;binary would still be
> handled - provided that they explicitly asked for it.  Clients that want
> userCertificate;binary but ask for userCertificate or ask for all
> attributes would not be handled.  In this case you could not solve that
> by having both userCertificate and userCertificate;binary in the same
> entry in the directory.
> 

this is horrible. We dont really want to store two attribute do we? Remember 
that ;binary was a transfer encoding and not an attribute type. Therefore 
existing systems that support ;binary encodings should still store the attributes 
as userCertificates and not userCertificate;binary. There is no such thing as a 
userCertificate;binary attribute in the original LDAPv3 spec!.

> 
> Also, one could decide that if an attribute is stored with ;binary in
> the directory but the client requests the attribute without ;binary, it
> receives it without ;binary.
> 
> This handles a situation where the admin has put ;binary in the
> directory 

This is wrong thinking. The admin has stored a userCertificate in the directory 
and used ;binary as the transfer encoding to get it there. But it is a 
userCertificate that has been stored there. So LDAPv2 client should be able to 
pick it up as a userCertificate, without asking for userCertificate;binary.

David

>because most clients want that, but where some clients want
> the attribute without ;binary (and ask for it explicitly).  It breaks
> clients that ask for userCertificate but want userCertificate;binary,
> which is legal.  In this case it doesn't help if the admin added
> ;binary.
> 
> -- 
> Hallvard
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKDteU10103 for ietf-pkix-bks; Wed, 20 Nov 2002 05:55:40 -0800 (PST)
Received: from mta05-svc.ntlworld.com (mta05-svc.ntlworld.com [62.253.162.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAKDtcg10095 for <[e-mail]>; Wed, 20 Nov 2002 05:55:38 -0800 (PST)
Received: from dwc ([80.7.98.57]) by mta05-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20021120135537.BAMN16799.mta05-svc.ntlworld.com@dwc>; Wed, 20 Nov 2002 13:55:37 +0000
From: [e-mail]
To: <[e-mail]>, "Peter Gietz" <[e-mail]>
Date: Wed, 20 Nov 2002 13:55:20 -0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: new version of draft on additional x509certificateschema for LDAP
In-reply-to: <[e-mail]>
References: <p05200f15b9fee3f2beea@[204.42.71.167]>
X-mailer: Pegasus Mail for Win32 (v3.01a)
Message-Id: <20021120135537.BAMN16799.mta05-svc.ntlworld.com@dwc>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Date sent:      	Mon, 18 Nov 2002 21:47:54 +0100 (CET)
Subject:        	Re: new version of draft on additional x509certificateschema for LDAP
From:           	"Peter Gietz" <[e-mail]>
To:             	<[e-mail]>

> I don't yet think that there is a need for similiar AUXILIARY object
> classes. The whole idea behind our draft is to have an entry for each
> certificate, thus the thing that this entry is all about is the
> certificate, thus a typical use case for STRUCTURAL. Even if there will
> be the need in future to add additional data to such an entry, it can
> be done with auxiliary objectclasses sticked to these structural ones.
> 
> Does the latter conflict with your idea of packaging, David?

Yes. We already have a requirement for a common object class for all X.509 
attributes. (You can read this in our detailed design submitted to Terena at the 
end of last week). We need to search for all X.509 entries subordinate to a 
user's entry. Whilst it is true that we could search for multiple object classes 
(and update the code when new ones are defined), having a common object 
class containing common attributes, makes it easier and hopefully future proof. 
That's why I would like to hold off the final decision until we have published our 
Attribute Cert and CRL schema IDs

> 
> BTW: my first hesitance to define an ABSTRACT class, was that this is
> not done very often (in fact it will be the first one after top).

Actually I did this a few years ago when I defined Families of Entries

David

> But
> since it is a perfect means to prevent an instantiation without the
> certificate, why not go for it.
> 
> Cheers,
> 
> Peter
> 
> 
> 
> 
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKCnPM05281 for ietf-pkix-bks; Wed, 20 Nov 2002 04:49:25 -0800 (PST)
Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAKCnMg05274 for <[e-mail]>; Wed, 20 Nov 2002 04:49:22 -0800 (PST)
Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA02425 for <[e-mail]>; Wed, 20 Nov 2002 12:49:21 GMT
Received: from jap.ecs.soton.ac.uk (jap.ecs.soton.ac.uk [152.78.69.201]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gAKCnBWY032582 for <[e-mail]>; Wed, 20 Nov 2002 12:49:12 GMT
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 20 Nov 2002 12:55:00 +0000
To: [e-mail]
From: J Adrian Pickering <[e-mail]>
Subject: Re: Gauging Consensus on Logotypes:  (Was Re: New draft-ietf-pkix-logotypes-08.txt)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-ECS-MailScanner: Found to be clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 00:53 20/11/2002, [e-mail] wrote:

>I have been reviewing the list, and have been unable to determine whether the
>current draft represents rough consensus or not.

<snip>

>  If the current specification represents rough consensus, we
>will forward the specification to the ADs.  If not, we will ask the 
>editors to
>make the appropriate changes and then forward the resulting draft.

I continue to have the same misgivings as most do regarding the problem 
over masquerading. Logotypes just make this so much easier to do because 
they are so attractive to humans. However, this is honestly admitted in the 
security section. If there is anything more that can be done to strengthen 
the warnings or reduce the possibility of misleading logos let's do it. 
Otherwise, I think it is an inevitable and justifyable matter to pursue.

Adrian Pickering/
University of Southampton



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKChH304409 for ietf-pkix-bks; Wed, 20 Nov 2002 04:43:17 -0800 (PST)
Received: from mdx-bg-csex.cs.mdx.ac.uk (dyn059-041.mdx.ac.uk [158.94.59.41]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAKChFg04403 for <[e-mail]>; Wed, 20 Nov 2002 04:43:16 -0800 (PST)
Received: by cs.mdx.ac.uk with Internet Mail Service (5.5.2653.19) id <X2RC4HH1>; Wed, 20 Nov 2002 12:44:09 -0000
Message-ID: <[e-mail]>
From: Chandra Patni <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, [e-mail]
Subject: RE: Identification = Payment Transaction?
Date: Wed, 20 Nov 2002 12:44:08 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Could you tell me where I can get information about specific PKI-ventures?
Regards
Dr. Chandra Patni

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: 12 November 2002 15:20
To: [e-mail]
Subject: Identification = Payment Transaction?



Survey regarding the future of  PKI trust networks
------------------------------------------------------

Traditionally certificates have been purchased (or just issued) for
an entity by a party that is concerned that the entity can be properly
identified in authentication- and signature-operations.

For a relying party (RP) to check certificate-status has mostly been a
public and free service.

The financial industry however, have in several recent PKI-ventures
shown that they intend to change this by treating lookup-services as
equivalent to payment transactions, where the RP's bank is used as a
"trust clearing center" communicating with the subscriber's bank that
must be a member of the same "trust network".  To make it technically
impossible for RPs to fully verify signatures without going through
the trust network (and paying for the services), root-certificates are
usually not "published".

I would be very happy to hear what the PKI community in general
think about this scheme as the future for PKI.  Off-list responses
will be treated as CONFIDENTIAL information.

Anders Rundgren













Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKCfve04238 for ietf-pkix-bks; Wed, 20 Nov 2002 04:41:57 -0800 (PST)
Received: from mta02-svc.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAKCftg04231 for <[e-mail]>; Wed, 20 Nov 2002 04:41:55 -0800 (PST)
Received: from dwc ([80.7.98.57]) by mta02-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20021120124149.XZPH3850.mta02-svc.ntlworld.com@dwc>; Wed, 20 Nov 2002 12:41:49 +0000
From: [e-mail]
To: "Russ Housley" <[e-mail]>, "Ramsay, Ron" <[e-mail]>, <[e-mail]>
Date: Wed, 20 Nov 2002 12:41:31 -0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: RE: No-op LDAP ;binary option
CC: <[e-mail]>, "Hallvard B Furuseth" <[e-mail]>
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.01a)
Message-Id: <20021120124149.XZPH3850.mta02-svc.ntlworld.com@dwc>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

From:           	Steve Hanna <[e-mail]>
Date sent:      	Tue, 19 Nov 2002 11:22:25 -0500
To:             	"Russ Housley" <[e-mail]>, "Ramsay, Ron" <[e-mail]>
Copies to:      	<[e-mail]>, "Hallvard B Furuseth" <[e-mail]>
Send reply to:  	<[e-mail]>
Subject:        	RE: No-op LDAP ;binary option


> I *do* care how it gets encoded in LDAP. 

Steve

So do I. That's why the PKIX LDAP PKI Schema ID ensures that the bits on the 
line are exactly the same when userCertificates are requested in the new spec, 
compared with userCertificates;binary in the old spec

David

>My LDAP client followed RFC 2256,
> which said to store and retrieve the userCertificate attribute using
> the ;binary option. It seems to me that future versions of LDAPv3
> should maintain the ability to do this, since it was once the recommended
> way (in a Proposed Standard that's part of LDAPv3, no less!). Any of
> Hallvard's solutions are fine with me.
> 
> Steve
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKCNwe03520 for ietf-pkix-bks; Wed, 20 Nov 2002 04:23:58 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAKCNsg03513; Wed, 20 Nov 2002 04:23:54 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA20250; Wed, 20 Nov 2002 13:24:39 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id NAA25402; Wed, 20 Nov 2002 13:23:57 +0100
Message-ID: <[e-mail]>
Date: Wed, 20 Nov 2002 13:23:46 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: "Fillingham, David W." <[e-mail]>
CC: "'Paul Hoffman / IMC'" <[e-mail]>, "Jeffrey I. Schiller" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Request for IESG consideration: CP/CPS Framework
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

> Hi Paul:

> As someone who has worked PKI policy interoperability issues for several
> years, I will stand up in defense of RFC 2527 and its successor.  If you
> enter "certificate policy" into any Internet search engine, you will find
> hundreds of Certificate Policies and Practice Statements from all over the
> world, from both government and industry.  Nearly all of them conform to RFC
> 2527.  

RFC 2527 is not the single document in that category.
There exists other documents like:

ESTI TS 102 042 : Policy requirements for Certification Authorities
                   issuing Public Key Certificates

ESTI TS 101 456 : Policy requirements for Certification Authorities
                   issuing Qualified Certificates.

They have a different structure. There is also work being done by ISO at 
this time by TC 68.

So RFC 2527 is not the single reference anymore.

Having said this, it would be a pity not to update RFC 2527.

Denis

 > Having Certificate Policies presented with a common structure and
> format is extremely important to those of us who work in both the PKI
> technical and policy interoperability realms.
> 
> RFC 2527 has been very successful in meeting its objectives of providing a
> way to compare and contrast Certificate Policies and PKI implementations,
> and thereby promoting interoperable PKI implementations.  I believe PKIX
> should continue to support it.
> 
> Best Regards,
> Dave Fillingham
> US Department of Defense
> 
>  -----Original Message-----
> From: 	Paul Hoffman / IMC [mailto:[e-mail]] 
> Sent:	Tuesday, November 12, 2002 12:11 PM
> To:	Jeffrey I. Schiller; [e-mail]
> Cc:	[e-mail]
> Subject:	Re: Request for IESG consideration: CP/CPS Framework
> 
> 
> At 12:10 PM -0500 11/11/02, Jeffrey I. Schiller wrote:
> 
>>This document was discussed at the IESG and there were concerns that 
>>it was a legal document and not a technical document.
> 
> 
> Yup, just like its predecessor.
> 
> 
>> I don't know how to deal with the objection. It appears that the 
>>people objecting don't have any solid recommendation to make to 
>>change the document, they just don't like it... I will be taking 
>>this up with them in person.
> 
> 
> You can't change 2527 to not talk about legal/policy issues; that's 
> what it is about. The new document is simply a revision to an 
> existing RFC. It seems like some revision should be accepted, or the 
> old RFC should be removed (which is not possible). That is, you're 
> stuck with the previous decision to issue RFC 2527. If you have 
> changed your mind about that, is it better to revise it to reflect 
> current practice or to not revise it and hope no one uses the old one?
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAKBaZ402571 for ietf-pkix-bks; Wed, 20 Nov 2002 03:36:35 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAKBaWg02566 for <[e-mail]>; Wed, 20 Nov 2002 03:36:33 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA20250; Wed, 20 Nov 2002 12:37:10 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id MAA23814; Wed, 20 Nov 2002 12:36:29 +0100
Message-ID: <[e-mail]>
Date: Wed, 20 Nov 2002 12:36:17 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: [e-mail], "Housley, Russ" <[e-mail]>, Trevor Freeman <[e-mail]>, Tim Polk <[e-mail]>
Subject: Re: New draft-ietf-pkix-logotypes-08.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

> Denis,
> 
> Most of the issues are already handled in the document. See comments below.

Good. I read the document (too) fast.

> Regarding sizes, we may consider providing some guidance regarding the sizes
> to be expected. This should thus not be requirements for conformance, but
> rather just guidance for implementers.

Guidance is not sufficient. CAs may want to be sure that some logos included 
in their certificates can *always* be displayed. In this way, some clients 
can say that they are really "logo-enabled", which means conformant with the 
RFC.

So there is a need to mandate a minimum size for the image (as well as 
colors or greys). CAs using that minimun size can then be sure that if the 
client is logo-enabled then the logo can be displayed. Now, "if one size 
does not fit all", then several classes should be defined and clients would 
conform to class a, b or c.

See other responses below.

>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Tuesday, November 19, 2002 11:38 AM
>>To: [e-mail]
>>Cc: Stefan Santesson; Housley, Russ; Trevor Freeman
>>Subject: Re: New draft-ietf-pkix-logotypes-08.txt
>>
>>
>>
>>>There is a new logotypes draft 08 available from:
>>>
>>>http://www.addtrust.com/pub/logotypes-08_dr03.txt
>>>or from:
>>>
>>
>>ftp://ftp.rsasecurity.com/pub/rsalabs/tmp/draft-ietf-pkix-logotypes-08.txt
>>
>>>This draft support inclusion of multiple community logos.
>>>There is still support for audio.
>>>
>>>It is the authors view that this reflects the rough consensus
>>
>>of this list
>>
>>>and that it take care of the comments raised during WG last call.
>>
>>The following comments that have ben raised during the last call have not
>>been solved:
>>
>>3. Page 7. Section 4.1 Extension format
>>
>>There is no text which states what the client should do whenever it is
>>unable to support a given logotype. Insert the following text:
>>
>>  "Whenever a client is unable to support a given logotype, no
>>error SHALL be
>>  reported and the client MUST behave as if there was no logotype
>>included in
>>  the certificate".
>>
> 
> 
> This is covered in section 6 (use in clients)
> 
> Current texts says:
>    "If client is unable to support a provided logotype, the client
>    MUST NOT report an error, rather the client MUST behave as though no
>    logotype extension was included in the certificate."

This is fine.

>>This raises the point that section 3 is still incorrect:
>>
>>    "This specification defines two types of logotype data: image data and
>>    audio data. Implementations MUST support image data; however, support
>>    for audio data is OPTIONAL."
>>
>>There are no implementations that MUST support image data, since
>>display is
>>optional. However, we should define what is a client *capable of*
>>displaying
>>logotypes. We currently can't since comment 7 has not been addressed.
>>
> 
> 
> This is also covered in section 6.
> 
> Current text says:
>    "A client MAY, subject to local policy, choose to display none, one or
>    any number of the logotypes in the logotype extension."

This sentence is fine, but this issue is not only related to the local 
policy, but to the display capabilities. So this point remains.

> 
>>In the same way since it seems that this (?!?!) audio logotype is
>>likely to
>>stay, we should define what is a client capable of playing a logotype.
>>
>>Proposed text:
>>
>>    This specification defines two types of logotype data: image data and
>>    audio data. Implementations claiming conformance with this document
>>    MUST be able to support image data with some minimum caracteristics;
>>    however, they MAY also be able to support audio data, with some
>>    minimum caracteristics."
>>
> 
> 
> This says the same thing as the text in the beginning of section 3, except
> for your wording "minimum characteristics", where we simply disagree that
> this is appropriate wording, since the implementation has to accommodate the
> display characteristics of the device it is running on.
> 
> 
>>It is also proposed to add that key sentence to the abstract, which is
>>currently too short:
>>
>>    This document specifies a certificate extension for including
>>    logotypes in public key certificates and attribute certificates.
>>
> 
> 
> We think the abstract is fine, in any way we can't place requirements in the
> abstract.

The abstract is not fine. At least both image logotypes and sound logotypes 
should be mentionned in the abstract. Then, why not mention the difference 
in the approach between image logotypes and sound logotypes? This should not 
be hidden in the main body of the document.


>>7. Page 9. Section 4.1.
>>
>>        LogotypeImageInfo ::= SEQUENCE {
>>           fileSize        INTEGER,  -- In octets
>>           xSize           INTEGER,  -- In pixels
>>           ySize           INTEGER,  -- In pixels
>>           numColors       INTEGER } -- In bits
>>
>>  It is of particular importance to say what means conformance to this
>>  document for a client with respect to the number of pixels to
>>support and
>>  the colors to support.
>>
>>  It is proposed to add a sentence along these lines:
>>
>>  "Clients claiming to conform with this document SHALL support
>>an image with
>>  a minimum size of 48 pixels (xSize) by 32 pixels (ySize) in
>>black and white
>>  with X grey levels."
> 
> 
> This is addressed at the beginning of this mail.

This is indeed addressed, but we still do not agree.

Denis

> /Stefan & Trevor
> 
> 
>>Denis
>>
>>
>>>This draft, or an agreed update to this draft, will be posted
>>
>>to ID directly
>>
>>>after the Atlanta meeting.
>>>
>>>/Stefan
>>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [e-mail]
>>>>[mailto:[e-mail]]On Behalf Of Housley, Russ
>>>>Sent: Tuesday, October 29, 2002 3:17 PM
>>>>To: [e-mail]
>>>>Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
>>>>
>>>>
>>>>
>>>>This update captures the things that have agreed.  The biggest change is
>>>>the support in the syntax for color and gray scale images.  Many other
>>>>little changes are included.
>>>>
>>>>As I see it, there are two open issues:
>>>>   1) Removal of audio; and
>>>>   2) Support for more than one logotype in each of the categories
>>>>
>>>>These two topics are still being discussed on the list.
>>>>
>>>>Russ
>>>>
>>>>
>>>>
>>>>>       Title           : Internet X.509 Public Key Infrastructure:
>>>>>Logotypes in
>>>>>                         X.509 certificates
>>>>>       Author(s)       : S. Santesson, R. Housley, T. Freeman
>>>>>       Filename        : draft-ietf-pkix-logotypes-07.txt
>>>>>       Pages           : 21
>>>>>       Date            : 2002-10-28
>>>>
>>>
>>
>>
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAK1ltK02876 for ietf-pkix-bks; Tue, 19 Nov 2002 17:47:55 -0800 (PST)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAK1lqg02872 for <[e-mail]>; Tue, 19 Nov 2002 17:47:52 -0800 (PST)
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id gAK1lOdt010606; Tue, 19 Nov 2002 20:47:24 -0500 (EST)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.2/8.12.2) with ESMTP id gAK1lO8K013693; Tue, 19 Nov 2002 20:47:24 -0500 (EST)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.2/8.12.2/Submit) id gAK1lNBI013692; Tue, 19 Nov 2002 20:47:23 -0500 (EST)
X-Authentication-Warning: calendar.nist.gov: nobody set sender to [e-mail] using -f
Received: from 204.42.70.81 ( [204.42.70.81]) as user [e-mail] by imp.nist.gov with HTTP; Tue, 19 Nov 2002 20:47:23 -0500
Message-ID: <[e-mail]>
Date: Tue, 19 Nov 2002 20:47:23 -0500
From: [e-mail]
To: Stefan Santesson <[e-mail]>
Cc: Denis Pinkas <[e-mail]>, [e-mail], "Housley, Russ" <[e-mail]>, Trevor Freeman <[e-mail]>
Subject: RE: New draft-ietf-pkix-logotypes-08.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

Thanks for the detailed response.  This means we have only one outstanding 
issue...

Is it the sense of the group that conformance requirements can be mandated, or 
is implementor guidanjce sufficient??

As before, I will poll the room.  For those not in Atlanta, please post your 
poinion to the list.


Thanks,

Tim

Quoting Stefan Santesson <[e-mail]>:

> 
> Denis,
> 
> Most of the issues are already handled in the document. See comments below.
> 
> Regarding sizes, we may consider providing some guidance regarding the
> sizes
> to be expected. This should thus not be requirements for conformance, but
> rather just guidance for implementers.
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Tuesday, November 19, 2002 11:38 AM
> > To: [e-mail]
> > Cc: Stefan Santesson; Housley, Russ; Trevor Freeman
> > Subject: Re: New draft-ietf-pkix-logotypes-08.txt
> >
> >
> > > There is a new logotypes draft 08 available from:
> > >
> > > http://www.addtrust.com/pub/logotypes-08_dr03.txt
> > > or from:
> > >
> >
> ftp://ftp.rsasecurity.com/pub/rsalabs/tmp/draft-ietf-pkix-logotypes-08.txt
> > >
> > > This draft support inclusion of multiple community logos.
> > > There is still support for audio.
> > >
> > > It is the authors view that this reflects the rough consensus
> > of this list
> > > and that it take care of the comments raised during WG last call.
> >
> > The following comments that have ben raised during the last call have not
> > been solved:
> >
> > 3. Page 7. Section 4.1 Extension format
> >
> > There is no text which states what the client should do whenever it is
> > unable to support a given logotype. Insert the following text:
> >
> >   "Whenever a client is unable to support a given logotype, no
> > error SHALL be
> >   reported and the client MUST behave as if there was no logotype
> > included in
> >   the certificate".
> >
> 
> This is covered in section 6 (use in clients)
> 
> Current texts says:
>    "If client is unable to support a provided logotype, the client
>    MUST NOT report an error, rather the client MUST behave as though no
>    logotype extension was included in the certificate."
> 
> 
> > This raises the point that section 3 is still incorrect:
> >
> >     "This specification defines two types of logotype data: image data
> and
> >     audio data. Implementations MUST support image data; however, support
> >     for audio data is OPTIONAL."
> >
> > There are no implementations that MUST support image data, since
> > display is
> > optional. However, we should define what is a client *capable of*
> > displaying
> > logotypes. We currently can't since comment 7 has not been addressed.
> >
> 
> This is also covered in section 6.
> 
> Current text says:
>    "A client MAY, subject to local policy, choose to display none, one or
>    any number of the logotypes in the logotype extension."
> 
> > In the same way since it seems that this (?!?!) audio logotype is
> > likely to
> > stay, we should define what is a client capable of playing a logotype.
> >
> > Proposed text:
> >
> >     This specification defines two types of logotype data: image data and
> >     audio data. Implementations claiming conformance with this document
> >     MUST be able to support image data with some minimum caracteristics;
> >     however, they MAY also be able to support audio data, with some
> >     minimum caracteristics."
> >
> 
> This says the same thing as the text in the beginning of section 3, except
> for your wording "minimum characteristics", where we simply disagree that
> this is appropriate wording, since the implementation has to accommodate
> the
> display characteristics of the device it is running on.
> 
> > It is also proposed to add that key sentence to the abstract, which is
> > currently too short:
> >
> >     This document specifies a certificate extension for including
> >     logotypes in public key certificates and attribute certificates.
> >
> 
> We think the abstract is fine, in any way we can't place requirements in
> the
> abstract.
> 
> > 7. Page 9. Section 4.1.
> >
> >         LogotypeImageInfo ::= SEQUENCE {
> >            fileSize        INTEGER,  -- In octets
> >            xSize           INTEGER,  -- In pixels
> >            ySize           INTEGER,  -- In pixels
> >            numColors       INTEGER } -- In bits
> >
> >   It is of particular importance to say what means conformance to this
> >   document for a client with respect to the number of pixels to
> > support and
> >   the colors to support.
> >
> >   It is proposed to add a sentence along these lines:
> >
> >   "Clients claiming to conform with this document SHALL support
> > an image with
> >   a minimum size of 48 pixels (xSize) by 32 pixels (ySize) in
> > black and white
> >   with X grey levels."
> 
> This is addressed at the beginning of this mail.
> 
> /Stefan & Trevor
> 
> >
> > Denis
> >
> > > This draft, or an agreed update to this draft, will be posted
> > to ID directly
> > > after the Atlanta meeting.
> > >
> > > /Stefan
> > >
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: [e-mail]
> > >>[mailto:[e-mail]]On Behalf Of Housley, Russ
> > >>Sent: Tuesday, October 29, 2002 3:17 PM
> > >>To: [e-mail]
> > >>Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
> > >>
> > >>
> > >>
> > >>This update captures the things that have agreed.  The biggest change
> is
> > >>the support in the syntax for color and gray scale images.  Many other
> > >>little changes are included.
> > >>
> > >>As I see it, there are two open issues:
> > >>    1) Removal of audio; and
> > >>    2) Support for more than one logotype in each of the categories
> > >>
> > >>These two topics are still being discussed on the list.
> > >>
> > >>Russ
> > >>
> > >>
> > >>>        Title           : Internet X.509 Public Key Infrastructure:
> > >>>Logotypes in
> > >>>                          X.509 certificates
> > >>>        Author(s)       : S. Santesson, R. Housley, T. Freeman
> > >>>        Filename        : draft-ietf-pkix-logotypes-07.txt
> > >>>        Pages           : 21
> > >>>        Date            : 2002-10-28
> > >>
> > >
> > >
> >
> >
> >
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAK0rva29820 for ietf-pkix-bks; Tue, 19 Nov 2002 16:53:57 -0800 (PST)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAK0rig29810 for <[e-mail]>; Tue, 19 Nov 2002 16:53:54 -0800 (PST)
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id gAK0rKdt008874; Tue, 19 Nov 2002 19:53:20 -0500 (EST)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.2/8.12.2) with ESMTP id gAK0rJ8K027346; Tue, 19 Nov 2002 19:53:20 -0500 (EST)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.2/8.12.2/Submit) id gAK0rFRw027345; Tue, 19 Nov 2002 19:53:15 -0500 (EST)
X-Authentication-Warning: calendar.nist.gov: nobody set sender to [e-mail] using -f
Received: from 204.42.70.81 ( [204.42.70.81]) as user [e-mail] by imp.nist.gov with HTTP; Tue, 19 Nov 2002 19:53:15 -0500
Message-ID: <[e-mail]>
Date: Tue, 19 Nov 2002 19:53:15 -0500
From: [e-mail]
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: Gauging Consensus on Logotypes:  (Was Re: New draft-ietf-pkix-logotypes-08.txt)
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

I have been reviewing the list, and have been unable to determine whether the 
current draft represents rough consensus or not.  Denis has submitted comments 
that the editors have not addressed, believing that the current content 
represents the collective position of the WG.  The list has been silent 
regarding these topics.  As a result, I have only been able to determine the 
opinions of the editors and Denis.

I intend to conduct a strawpoll at the meeting tomorrow; I would appreciate it 
if those who are *not* in attendance this week and have an opinion would voice 
it on the list.  If the current specification represents rough consensus, we 
will forward the specification to the ADs.  If not, we will ask the editors to 
make the appropriate changes and then forward the resulting draft.

Thanks,

Tim Polk


Quoting Denis Pinkas <[e-mail]>:

> 
> > There is a new logotypes draft 08 available from:
> > 
> > http://www.addtrust.com/pub/logotypes-08_dr03.txt
> > or from:
> >
> ftp://ftp.rsasecurity.com/pub/rsalabs/tmp/draft-ietf-pkix-logotypes-08.txt
> > 
> > This draft support inclusion of multiple community logos.
> > There is still support for audio.
> > 
> > It is the authors view that this reflects the rough consensus of this
> list
> > and that it take care of the comments raised during WG last call.
> 
> The following comments that have ben raised during the last call have not 
> been solved:
> 
> 3. Page 7. Section 4.1 Extension format
> 
> There is no text which states what the client should do whenever it is
> unable to support a given logotype. Insert the following text:
> 
>   "Whenever a client is unable to support a given logotype, no error SHALL
> be
>   reported and the client MUST behave as if there was no logotype included
> in
>   the certificate".
> 
> This raises the point that section 3 is still incorrect:
> 
>     "This specification defines two types of logotype data: image data and
>     audio data. Implementations MUST support image data; however, support
>     for audio data is OPTIONAL."
> 
> There are no implementations that MUST support image data, since display is
> 
> optional. However, we should define what is a client *capable of* displaying
> 
> logotypes. We currently can't since comment 7 has not been addressed.
> 
> In the same way since it seems that this (?!?!) audio logotype is likely to
> 
> stay, we should define what is a client capable of playing a logotype.
> 
> Proposed text:
> 
>     This specification defines two types of logotype data: image data and
>     audio data. Implementations claiming conformance with this document
>     MUST be able to support image data with some minimum caracteristics;
>     however, they MAY also be able to support audio data, with some
>     minimum caracteristics."
> 
> It is also proposed to add that key sentence to the abstract, which is 
> currently too short:
> 
>     This document specifies a certificate extension for including
>     logotypes in public key certificates and attribute certificates.
> 
> 7. Page 9. Section 4.1.
> 
>         LogotypeImageInfo ::= SEQUENCE {
>            fileSize        INTEGER,  -- In octets
>            xSize           INTEGER,  -- In pixels
>            ySize           INTEGER,  -- In pixels
>            numColors       INTEGER } -- In bits
> 
>   It is of particular importance to say what means conformance to this
>   document for a client with respect to the number of pixels to support and
>   the colors to support.
> 
>   It is proposed to add a sentence along these lines:
> 
>   "Clients claiming to conform with this document SHALL support an image
> with
>   a minimum size of 48 pixels (xSize) by 32 pixels (ySize) in black and
> white
>   with X grey levels."
> 
> Denis
> 
> > This draft, or an agreed update to this draft, will be posted to ID
> directly
> > after the Atlanta meeting.
> > 
> > /Stefan
> > 
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: [e-mail]
> >>[mailto:[e-mail]]On Behalf Of Housley, Russ
> >>Sent: Tuesday, October 29, 2002 3:17 PM
> >>To: [e-mail]
> >>Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
> >>
> >>
> >>
> >>This update captures the things that have agreed.  The biggest change is
> >>the support in the syntax for color and gray scale images.  Many other
> >>little changes are included.
> >>
> >>As I see it, there are two open issues:
> >>    1) Removal of audio; and
> >>    2) Support for more than one logotype in each of the categories
> >>
> >>These two topics are still being discussed on the list.
> >>
> >>Russ
> >>
> >>
> >>>        Title           : Internet X.509 Public Key Infrastructure:
> >>>Logotypes in
> >>>                          X.509 certificates
> >>>        Author(s)       : S. Santesson, R. Housley, T. Freeman
> >>>        Filename        : draft-ietf-pkix-logotypes-07.txt
> >>>        Pages           : 21
> >>>        Date            : 2002-10-28
> >>
> > 
> > 
> 
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAK0rlT29815 for ietf-pkix-bks; Tue, 19 Nov 2002 16:53:47 -0800 (PST)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAK0rig29811 for <[e-mail]>; Tue, 19 Nov 2002 16:53:44 -0800 (PST)
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id gAK0rLdt008894; Tue, 19 Nov 2002 19:53:21 -0500 (EST)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.2/8.12.2) with ESMTP id gAK0rL8K027351; Tue, 19 Nov 2002 19:53:21 -0500 (EST)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.2/8.12.2/Submit) id gAK0rKJR027350; Tue, 19 Nov 2002 19:53:20 -0500 (EST)
X-Authentication-Warning: calendar.nist.gov: nobody set sender to [e-mail] using -f
Received: from 204.42.70.81 ( [204.42.70.81]) as user [e-mail] by imp.nist.gov with HTTP; Tue, 19 Nov 2002 19:53:20 -0500
Message-ID: <[e-mail]>
Date: Tue, 19 Nov 2002 19:53:20 -0500
From: [e-mail]
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: Gauging Consensus on Logotypes:  (Was Re: New draft-ietf-pkix-logotypes-08.txt)
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

I have been reviewing the list, and have been unable to determine whether the 
current draft represents rough consensus or not.  Denis has submitted comments 
that the editors have not addressed, believing that the current content 
represents the collective position of the WG.  The list has been silent 
regarding these topics.  As a result, I have only been able to determine the 
opinions of the editors and Denis.

I intend to conduct a strawpoll at the meeting tomorrow; I would appreciate it 
if those who are *not* in attendance this week and have an opinion would voice 
it on the list.  If the current specification represents rough consensus, we 
will forward the specification to the ADs.  If not, we will ask the editors to 
make the appropriate changes and then forward the resulting draft.

Thanks,

Tim Polk


Quoting Denis Pinkas <[e-mail]>:

> 
> > There is a new logotypes draft 08 available from:
> > 
> > http://www.addtrust.com/pub/logotypes-08_dr03.txt
> > or from:
> >
> ftp://ftp.rsasecurity.com/pub/rsalabs/tmp/draft-ietf-pkix-logotypes-08.txt
> > 
> > This draft support inclusion of multiple community logos.
> > There is still support for audio.
> > 
> > It is the authors view that this reflects the rough consensus of this
> list
> > and that it take care of the comments raised during WG last call.
> 
> The following comments that have ben raised during the last call have not 
> been solved:
> 
> 3. Page 7. Section 4.1 Extension format
> 
> There is no text which states what the client should do whenever it is
> unable to support a given logotype. Insert the following text:
> 
>   "Whenever a client is unable to support a given logotype, no error SHALL
> be
>   reported and the client MUST behave as if there was no logotype included
> in
>   the certificate".
> 
> This raises the point that section 3 is still incorrect:
> 
>     "This specification defines two types of logotype data: image data and
>     audio data. Implementations MUST support image data; however, support
>     for audio data is OPTIONAL."
> 
> There are no implementations that MUST support image data, since display is
> 
> optional. However, we should define what is a client *capable of* displaying
> 
> logotypes. We currently can't since comment 7 has not been addressed.
> 
> In the same way since it seems that this (?!?!) audio logotype is likely to
> 
> stay, we should define what is a client capable of playing a logotype.
> 
> Proposed text:
> 
>     This specification defines two types of logotype data: image data and
>     audio data. Implementations claiming conformance with this document
>     MUST be able to support image data with some minimum caracteristics;
>     however, they MAY also be able to support audio data, with some
>     minimum caracteristics."
> 
> It is also proposed to add that key sentence to the abstract, which is 
> currently too short:
> 
>     This document specifies a certificate extension for including
>     logotypes in public key certificates and attribute certificates.
> 
> 7. Page 9. Section 4.1.
> 
>         LogotypeImageInfo ::= SEQUENCE {
>            fileSize        INTEGER,  -- In octets
>            xSize           INTEGER,  -- In pixels
>            ySize           INTEGER,  -- In pixels
>            numColors       INTEGER } -- In bits
> 
>   It is of particular importance to say what means conformance to this
>   document for a client with respect to the number of pixels to support and
>   the colors to support.
> 
>   It is proposed to add a sentence along these lines:
> 
>   "Clients claiming to conform with this document SHALL support an image
> with
>   a minimum size of 48 pixels (xSize) by 32 pixels (ySize) in black and
> white
>   with X grey levels."
> 
> Denis
> 
> > This draft, or an agreed update to this draft, will be posted to ID
> directly
> > after the Atlanta meeting.
> > 
> > /Stefan
> > 
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: [e-mail]
> >>[mailto:[e-mail]]On Behalf Of Housley, Russ
> >>Sent: Tuesday, October 29, 2002 3:17 PM
> >>To: [e-mail]
> >>Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
> >>
> >>
> >>
> >>This update captures the things that have agreed.  The biggest change is
> >>the support in the syntax for color and gray scale images.  Many other
> >>little changes are included.
> >>
> >>As I see it, there are two open issues:
> >>    1) Removal of audio; and
> >>    2) Support for more than one logotype in each of the categories
> >>
> >>These two topics are still being discussed on the list.
> >>
> >>Russ
> >>
> >>
> >>>        Title           : Internet X.509 Public Key Infrastructure:
> >>>Logotypes in
> >>>                          X.509 certificates
> >>>        Author(s)       : S. Santesson, R. Housley, T. Freeman
> >>>        Filename        : draft-ietf-pkix-logotypes-07.txt
> >>>        Pages           : 21
> >>>        Date            : 2002-10-28
> >>
> > 
> > 
> 
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAJKrHS11967 for ietf-pkix-bks; Tue, 19 Nov 2002 12:53:17 -0800 (PST)
Received: from junker.stroeder.com (krl9-d9bb4d21.pool.mediaWays.net [217.187.77.33]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAJKrBg11963 for <[e-mail]>; Tue, 19 Nov 2002 12:53:13 -0800 (PST)
Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 611631573CC; Tue, 19 Nov 2002 21:53:06 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 19 Nov 2002 21:53:06 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Hallvard B Furuseth <[e-mail]>
Cc: [e-mail]
Subject: Re: No-op LDAP ;binary option
References: <[e-mail]> <[e-mail]>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hallvard B Furuseth wrote:
> Steve Hanna writes:
> 
>>Any of Hallvard's solutions are fine with me.
> 
> If they are all good enough, we should go for the first and simplest
> suggestion:  An option which does nothing, with no extra frills.

+1

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAJKnGv11893 for ietf-pkix-bks; Tue, 19 Nov 2002 12:49:16 -0800 (PST)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAJKnBg11888 for <[e-mail]>; Tue, 19 Nov 2002 12:49:12 -0800 (PST)
Received: from Santesson ([204.42.73.161]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Nov 2002 21:49:06 +0100
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, "Trevor Freeman" <[e-mail]>
Subject: RE: New draft-ietf-pkix-logotypes-08.txt
Date: Tue, 19 Nov 2002 21:49:04 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <[e-mail]>
X-OriginalArrivalTime: 19 Nov 2002 20:49:07.0318 (UTC) FILETIME=[1A7D2960:01C2900D]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

Most of the issues are already handled in the document. See comments below.

Regarding sizes, we may consider providing some guidance regarding the sizes
to be expected. This should thus not be requirements for conformance, but
rather just guidance for implementers.

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Tuesday, November 19, 2002 11:38 AM
> To: [e-mail]
> Cc: Stefan Santesson; Housley, Russ; Trevor Freeman
> Subject: Re: New draft-ietf-pkix-logotypes-08.txt
>
>
> > There is a new logotypes draft 08 available from:
> >
> > http://www.addtrust.com/pub/logotypes-08_dr03.txt
> > or from:
> >
> ftp://ftp.rsasecurity.com/pub/rsalabs/tmp/draft-ietf-pkix-logotypes-08.txt
> >
> > This draft support inclusion of multiple community logos.
> > There is still support for audio.
> >
> > It is the authors view that this reflects the rough consensus
> of this list
> > and that it take care of the comments raised during WG last call.
>
> The following comments that have ben raised during the last call have not
> been solved:
>
> 3. Page 7. Section 4.1 Extension format
>
> There is no text which states what the client should do whenever it is
> unable to support a given logotype. Insert the following text:
>
>   "Whenever a client is unable to support a given logotype, no
> error SHALL be
>   reported and the client MUST behave as if there was no logotype
> included in
>   the certificate".
>

This is covered in section 6 (use in clients)

Current texts says:
   "If client is unable to support a provided logotype, the client
   MUST NOT report an error, rather the client MUST behave as though no
   logotype extension was included in the certificate."


> This raises the point that section 3 is still incorrect:
>
>     "This specification defines two types of logotype data: image data and
>     audio data. Implementations MUST support image data; however, support
>     for audio data is OPTIONAL."
>
> There are no implementations that MUST support image data, since
> display is
> optional. However, we should define what is a client *capable of*
> displaying
> logotypes. We currently can't since comment 7 has not been addressed.
>

This is also covered in section 6.

Current text says:
   "A client MAY, subject to local policy, choose to display none, one or
   any number of the logotypes in the logotype extension."

> In the same way since it seems that this (?!?!) audio logotype is
> likely to
> stay, we should define what is a client capable of playing a logotype.
>
> Proposed text:
>
>     This specification defines two types of logotype data: image data and
>     audio data. Implementations claiming conformance with this document
>     MUST be able to support image data with some minimum caracteristics;
>     however, they MAY also be able to support audio data, with some
>     minimum caracteristics."
>

This says the same thing as the text in the beginning of section 3, except
for your wording "minimum characteristics", where we simply disagree that
this is appropriate wording, since the implementation has to accommodate the
display characteristics of the device it is running on.

> It is also proposed to add that key sentence to the abstract, which is
> currently too short:
>
>     This document specifies a certificate extension for including
>     logotypes in public key certificates and attribute certificates.
>

We think the abstract is fine, in any way we can't place requirements in the
abstract.

> 7. Page 9. Section 4.1.
>
>         LogotypeImageInfo ::= SEQUENCE {
>            fileSize        INTEGER,  -- In octets
>            xSize           INTEGER,  -- In pixels
>            ySize           INTEGER,  -- In pixels
>            numColors       INTEGER } -- In bits
>
>   It is of particular importance to say what means conformance to this
>   document for a client with respect to the number of pixels to
> support and
>   the colors to support.
>
>   It is proposed to add a sentence along these lines:
>
>   "Clients claiming to conform with this document SHALL support
> an image with
>   a minimum size of 48 pixels (xSize) by 32 pixels (ySize) in
> black and white
>   with X grey levels."

This is addressed at the beginning of this mail.

/Stefan & Trevor

>
> Denis
>
> > This draft, or an agreed update to this draft, will be posted
> to ID directly
> > after the Atlanta meeting.
> >
> > /Stefan
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: [e-mail]
> >>[mailto:[e-mail]]On Behalf Of Housley, Russ
> >>Sent: Tuesday, October 29, 2002 3:17 PM
> >>To: [e-mail]
> >>Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
> >>
> >>
> >>
> >>This update captures the things that have agreed.  The biggest change is
> >>the support in the syntax for color and gray scale images.  Many other
> >>little changes are included.
> >>
> >>As I see it, there are two open issues:
> >>    1) Removal of audio; and
> >>    2) Support for more than one logotype in each of the categories
> >>
> >>These two topics are still being discussed on the list.
> >>
> >>Russ
> >>
> >>
> >>>        Title           : Internet X.509 Public Key Infrastructure:
> >>>Logotypes in
> >>>                          X.509 certificates
> >>>        Author(s)       : S. Santesson, R. Housley, T. Freeman
> >>>        Filename        : draft-ietf-pkix-logotypes-07.txt
> >>>        Pages           : 21
> >>>        Date            : 2002-10-28
> >>
> >
> >
>
>
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAJJLPN06018 for ietf-pkix-bks; Tue, 19 Nov 2002 11:21:25 -0800 (PST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAJJLMg06008 for <[e-mail]>; Tue, 19 Nov 2002 11:21:22 -0800 (PST)
Received: from sydney.East.Sun.COM ([129.148.9.16]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08679; Tue, 19 Nov 2002 12:21:24 -0700 (MST)
Received: from sydney.East.Sun.COM (esun1as-be21-ge0.Central.Sun.COM [129.147.60.148]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id gAJJLHJ17240; Tue, 19 Nov 2002 14:21:18 -0500 (EST)
From: Steve Hanna <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 19 Nov 2002 14:21:14 -0500
To: "Kurt D. Zeilenga" <[e-mail]>, <[e-mail]>
Reply-To: <[e-mail]>
Subject: Re: PKI/LDAP schema, the ;binary question (Was: No-op LDAP ;binary  option)
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:
>This question is viewed by the LDAPBIS chairs as being "owned" by
>PKIX WG.   Accordingly, we've asked PKIX chairs to determine whether
>the PKI community prefers to continue using "userCertificate;binary"
>or, as proposed in draft-ietf-pkix-ldap-pki-schema-00.txt, use
>"userCertificate".

I don't know exactly what decision-making process the PKIX chairs
have in mind for determining the working group's preference.
But I suppose it all comes down to discussion on the list, so
I'll comment. I encourage others with an informed opinion on this
topic to also comment on the list.

My primary concern is that things continue to work for our users,
some whom have already deployed standards-compliant clients and
servers that only support userCertificate;binary (as required by
the current standards). To maintain compatibility with this installed
base, future clients and servers must continue to use
userCertificate;binary. If servers start accepting userCertificate
as a synonym, then once the old servers are gone we can move clients
toward using userCertificate. But that will take a long time and
until then we must use userCertificate;binary.

That's my opinion, anyway. Others are welcome.

-Steve

Kurt Zeilenga wrote:
>At 07:14 AM 2002-11-18, Hallvard B Furuseth wrote:
>>Three related suggestions for the ;binary LDAP option, moved here from
>>LDAPBIS since it is the PKIX group who "owns" the ";binary" question:
>
>For clarity here, there is an outstanding question regarding
>how X.509 certificate attributes are to be requested/transferred
>in LDAP.  Namely, will "userCertificate;binary" or "userCertificate"
>be the LDAP attribute description as the protocol token to refer
>to an userCertificate attribute.  Regardless of which, the value
>transferred is presumed to be a DER encoded X.509 certificate. 
>
>This question is viewed by the LDAPBIS chairs as being "owned" by
>PKIX WG.   Accordingly, we've asked PKIX chairs to determine whether
>the PKI community prefers to continue using "userCertificate;binary"
>or, as proposed in draft-ietf-pkix-ldap-pki-schema-00.txt, use
>"userCertificate".
>
>It should be noted that while LDAPBIS has decided to remove
>;binary from the LDAP "core" technical specification, this decision
>should not be viewed as precluding PKIX from either choice.
>In particular, ;binary can be specified as an extension to LDAP
>or, if necessary, the prior decision to remove ;binary from the
>LDAP "core" technical specification can be reconsidered.
>
>Kurt, LDAPBIS co-chair
>
>




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAJIkUu02699 for ietf-pkix-bks; Tue, 19 Nov 2002 10:46:30 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAJIkRg02692 for <[e-mail]>; Tue, 19 Nov 2002 10:46:27 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA18392; Tue, 19 Nov 2002 19:46:18 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Tue, 19 Nov 2002 19:46:18 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id TAA04990; Tue, 19 Nov 2002 19:46:16 +0100 (MET)
Date: Tue, 19 Nov 2002 19:46:16 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Another DPV/DPD challenger
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> No, DSS does not perform validation, it does the opposite, it creates
> signatures.
> 
> XKMS does delegated validation and location. It is approaching last call
> in W3C.
> 

oops, right. 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAJIS9002253 for ietf-pkix-bks; Tue, 19 Nov 2002 10:28:09 -0800 (PST)
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAJIS5g02249 for <[e-mail]>; Tue, 19 Nov 2002 10:28:05 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id gAJIS4P8018215; Tue, 19 Nov 2002 19:28:05 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <00b301c28ff8$50d62cb0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Hallam-Baker, Phillip" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Another DPV/DPD challenger
Date: Tue, 19 Nov 2002 19:20:18 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Phill,
>From the OASIS home-page:

The OASIS Digital Signature Services Technical Committee
will develop techniques to support the processing of digital
signatures. This includes defining an interface for requesting
that a web service produce and/or verify a digital signature
on a given piece of data and techniques for proving that a
signature was created within its private key validity period.

To me it sounds like DSS "does it all" w.r.t. signatures.

/anders

----- Original Message -----
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; "Peter Sylvester" <[e-mail]>; <[e-mail]>;
<[e-mail]>
Sent: Tuesday, November 19, 2002 19:14
Subject: RE: Another DPV/DPD challenger


No, DSS does not perform validation, it does the opposite, it creates
signatures.

XKMS does delegated validation and location. It is approaching last call
in W3C.

Phill

> -----Original Message-----
> From: Anders Rundgren [mailto:[e-mail]]
> Sent: Monday, November 18, 2002 12:29 PM
> To: Peter Sylvester; [e-mail]; [e-mail]
> Subject: DSS: Another DPV/DPD challenger
>
>
>
> Another contender from another "club".
>
> http://www.oasis-open.org/committees/dss/
>
> If I understand the minimal description correctly, DSS seems like
> a more logical next step than DPV/DPD as it addresses the
> current situation where information systems do not understand
> PKI at all.
>
> cheers,
> Anders
>
> ----- Original Message -----
> From: "Peter Sylvester" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>
> Sent: Monday, November 18, 2002 15:48
> Subject: Re: draft agenda for PKIX
>
>
>
>
> hello,
>
> tim polk reminded me that there is at least a fourth candidate
> for the DPV/DPD solution, i.e., using RFC 3029 for DPV and DPD.
> Since I am not able to present this at Atlanta, I'll do it
> here, and would be happy to hear/read comments.
>
> here it goes:
>
> DVCS, i.e., RFC 3029 has proposed from its very beginning a
> framework allowing validation of public key certificates
> in combination with its other services.
>
> Among others the goals are to provide thin client support
> and centralised management of certificate validity status.
> Furthermore, in a larger view, essentially by using relaying
> techniques, it is possible to implement a security infrastructure
> accompagning a application work flow that used certificates.
>
> The results of a DVCS service can be authenticated in two
> ways depending on the needs of an application. Either, any
> transport security mechanism allowing immediate authentication
> betwwen a client server, and/or some mechanism to allow
> long term validation of the result. The security mechnisms
> are orthogonal to the asserted payload. For long term
> authentication, a combination of offline methods and
> online services are defined, i.e., a service should
> provide an online validation service for its own (or
> some else's) data validation certificates.
>
> The current text describes how to transport requests and
> responses above HTTP(S), and email.
>
> The client has the possiblity to provide additional
> information about certificate paths to the server. This
> interpretation of this information, and the way how
> the service is provided can be influenced by a policy
> indication.
>
> DVCS responses can return combined information, i.e.,
> assertions of validity combined with external time stamps.
>
> As you might know, there is an ongoing open source
> implementation project for RFC 3029 and 3161 financed
> by the European Commission. As part of this, an
> update to correct some bugs in 3029 and to describe
> more usage scenarios, profiles is planned for
> begging next of year.
>
> For the rest you may read RFC 3029.
>
> Well, this is my 5 minutes presentation. :-)
> Regards and have fun.
> Peter Sylvester
>
>
>
>
>




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAJIEbp01937 for ietf-pkix-bks; Tue, 19 Nov 2002 10:14:37 -0800 (PST)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAJIEYg01933 for <[e-mail]>; Tue, 19 Nov 2002 10:14:34 -0800 (PST)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id gAJIEAkw009125; Tue, 19 Nov 2002 10:14:10 -0800 (PST)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <V874YQW1>; Tue, 19 Nov 2002 10:14:27 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: Anders Rundgren <[e-mail]>, Peter Sylvester <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Another DPV/DPD challenger
Date: Tue, 19 Nov 2002 10:14:27 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0005_01C28FCC.387FB8B0"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C28FCC.387FB8B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

No, DSS does not perform validation, it does the opposite, it creates
signatures.

XKMS does delegated validation and location. It is approaching last call
in W3C.

	Phill

> -----Original Message-----
> From: Anders Rundgren [mailto:[e-mail]]
> Sent: Monday, November 18, 2002 12:29 PM
> To: Peter Sylvester; [e-mail]; [e-mail]
> Subject: DSS: Another DPV/DPD challenger
> 
> 
> 
> Another contender from another "club".
> 
> http://www.oasis-open.org/committees/dss/
> 
> If I understand the minimal description correctly, DSS seems like
> a more logical next step than DPV/DPD as it addresses the
> current situation where information systems do not understand
> PKI at all.
> 
> cheers,
> Anders
> 
> ----- Original Message ----- 
> From: "Peter Sylvester" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>
> Sent: Monday, November 18, 2002 15:48
> Subject: Re: draft agenda for PKIX
> 
> 
> 
> 
> hello,
> 
> tim polk reminded me that there is at least a fourth candidate
> for the DPV/DPD solution, i.e., using RFC 3029 for DPV and DPD.
> Since I am not able to present this at Atlanta, I'll do it
> here, and would be happy to hear/read comments. 
> 
> here it goes:
> 
> DVCS, i.e., RFC 3029 has proposed from its very beginning a
> framework allowing validation of public key certificates
> in combination with its other services.
> 
> Among others the goals are to provide thin client support
> and centralised management of certificate validity status.
> Furthermore, in a larger view, essentially by using relaying
> techniques, it is possible to implement a security infrastructure
> accompagning a application work flow that used certificates.
> 
> The results of a DVCS service can be authenticated in two
> ways depending on the needs of an application. Either, any
> transport security mechanism allowing immediate authentication
> betwwen a client server, and/or some mechanism to allow
> long term validation of the result. The security mechnisms
> are orthogonal to the asserted payload. For long term
> authentication, a combination of offline methods and
> online services are defined, i.e., a service should
> provide an online validation service for its own (or
> some else's) data validation certificates. 
> 
> The current text describes how to transport requests and
> responses above HTTP(S), and email. 
> 
> The client has the possiblity to provide additional
> information about certificate paths to the server. This
> interpretation of this information, and the way how
> the service is provided can be influenced by a policy
> indication. 
> 
> DVCS responses can return combined information, i.e.,
> assertions of validity combined with external time stamps.
> 
> As you might know, there is an ongoing open source
> implementation project for RFC 3029 and 3161 financed
> by the European Commission. As part of this, an
> update to correct some bugs in 3029 and to describe
> more usage scenarios, profiles is planned for
> begging next of year.  
> 
> For the rest you may read RFC 3029. 
> 
> Well, this is my 5 minutes presentation. :-)
> Regards and have fun.
> Peter Sylvester
> 
> 
> 
> 
> 

------=_NextPart_000_0005_01C28FCC.387FB8B0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w
ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu
9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV
UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA
P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG
J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz
PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy
MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ
ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C
vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ
IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB
AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j
cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF
BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh
PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W
bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC
EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm
MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN
MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs
YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr
CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1
3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg
jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4
MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy
bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF
BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD
VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y
FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY
MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ
da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw
MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl
Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu
LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1
81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL
tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC
AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp
c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud
DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G
C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT
MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK
+gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK
D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/
H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa
BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExOTE4
MDQ0MFowIwYJKoZIhvcNAQkEMRYEFDwBbJG70bkr87iYVuMrmlrf+HxhMFgGCSqGSIb3DQEJDzFL
MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG
BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug
aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj
KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO
rwvJMA0GCSqGSIb3DQEBAQUABIGAKVU3vyL9CWzObZJlY5CmVAGj0U/nFd8Cz69ZguW1jICfy61L
MWYtzSx7UfAb6egT7eMJXQ49g8Ji5l3aUZHAgVxaYHLeSTB1lgJwdAHCDc1w1/gYJ7xgOEN34CMk
dzkFjAhqkkfae6KqAJ3TBuF7YTZSkvB5J4XTmwQ6RzCpZGoAAAAAAAA=

------=_NextPart_000_0005_01C28FCC.387FB8B0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAJHe7U27447 for ietf-pkix-bks; Tue, 19 Nov 2002 09:40:07 -0800 (PST)
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAJHe4g27442 for <[e-mail]>; Tue, 19 Nov 2002 09:40:04 -0800 (PST)
Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18ECLv-0005g7-00; Tue, 19 Nov 2002 18:39:59 +0100
Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18ECLu-0001b7-00; Tue, 19 Nov 2002 18:39:58 +0100
From: Hallvard B Furuseth <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: Russ Housley <[e-mail]>, "Ramsay, Ron" <[e-mail]>, [e-mail]
Subject: RE: No-op LDAP ;binary option
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 6.37 under Emacs 19.34.1
Date: Tue, 19 Nov 2002 18:39:58 +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve Hanna writes:
> Any of Hallvard's solutions are fine with me.

If they are all good enough, we should go for the first and simplest
suggestion:  An option which does nothing, with no extra frills.

-- 
Hallvard



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAJHQ1v26502 for ietf-pkix-bks; Tue, 19 Nov 2002 09:26:01 -0800 (PST)
Received: from mons.uio.no (mons.uio.no [129.240.130.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAJHPwg26498 for <[e-mail]>; Tue, 19 Nov 2002 09:25:59 -0800 (PST)
Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18EC8L-0001kd-00; Tue, 19 Nov 2002 18:25:57 +0100
Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18EC8H-0001YH-00; Tue, 19 Nov 2002 18:25:53 +0100
From: Hallvard B Furuseth <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Russ Housley <[e-mail]>
Cc: "Ramsay, Ron" <[e-mail]>, [e-mail]
Subject: RE: No-op LDAP ;binary option
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.37 under Emacs 19.34.1
Date: Tue, 19 Nov 2002 18:25:53 +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley writes:
> I do not care how this gets encoded in the darn LDAP protocol; however, 
> certificate users need fetch the certificate as a binary blob.

The userCertificate attribute's syntax takes care of that.
That's why LDAPBIS now feels the ;binary option was unnecessary and
could be removed as far as transfer formats are concerned.

So my suggestins puerly address how to support programs that call the
attribute 'userCertificate;binary' and/or expect it to be called that
when it is read from the directory.

-- 
Hallvard


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAJGYON25229 for ietf-pkix-bks; Tue, 19 Nov 2002 08:34:24 -0800 (PST)
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAJGYMg25223 for <[e-mail]>; Tue, 19 Nov 2002 08:34:22 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id gAJGYMdN002194 for <[e-mail]>; Tue, 19 Nov 2002 17:34:22 +0100 (CET)
X-Original-Recipient: <[e-mail]>
Message-ID: <002101c28fe8$6dcd4930$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: UIDs for organizations
Date: Tue, 19 Nov 2002 17:26:35 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,
I'm trying to figure out what kind of variations there is out there
with respect on how you identify organizations.

These are the schemes I know of

DUNS
   Duns and Bradstreet.  A 9-digit number that most commercial
   organizations over the world get without asking

Swedish AB
   12-digit number for Swedish corporations.  Similar schemes
   exist for self-employed people and governmental orgs.
   Different authorities manage these separate "name-spaces".

How about Germany, France, UK, Italy, Japan, India, Australia etc.?

Off-list posts are preferred.

Maybe there is a document somewhere on the web?

cheers,
Anders




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAJGMeP24174 for ietf-pkix-bks; Tue, 19 Nov 2002 08:22:40 -0800 (PST)
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAJGMbg24165 for <[e-mail]>; Tue, 19 Nov 2002 08:22:37 -0800 (PST)
Received: from sydney.East.Sun.COM ([129.148.9.16]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15976; Tue, 19 Nov 2002 09:22:36 -0700 (MST)
Received: from sydney.East.Sun.COM (esun1as-be21-ge0.Central.Sun.COM [129.147.60.148]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id gAJGMMJ22814; Tue, 19 Nov 2002 11:22:27 -0500 (EST)
From: Steve Hanna <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 19 Nov 2002 11:22:25 -0500
To: "Russ Housley" <[e-mail]>, "Ramsay, Ron" <[e-mail]>
Cc: <[e-mail]>, "Hallvard B Furuseth" <[e-mail]>
Reply-To: <[e-mail]>
Subject: RE: No-op LDAP ;binary option
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley wrote:
>I do not care how this gets encoded in the darn LDAP protocol; however, 
>certificate users need fetch the certificate as a binary blob.

I *do* care how it gets encoded in LDAP. My LDAP client followed RFC 2256,
which said to store and retrieve the userCertificate attribute using
the ;binary option. It seems to me that future versions of LDAPv3
should maintain the ability to do this, since it was once the recommended
way (in a Proposed Standard that's part of LDAPv3, no less!). Any of
Hallvard's solutions are fine with me.

Steve



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAJAdLO27997 for ietf-pkix-bks; Tue, 19 Nov 2002 02:39:21 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAJAdCg27984 for <[e-mail]>; Tue, 19 Nov 2002 02:39:14 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA29814; Tue, 19 Nov 2002 11:39:03 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id LAA16792; Tue, 19 Nov 2002 11:38:19 +0100
Message-ID: <[e-mail]>
Date: Tue, 19 Nov 2002 11:38:12 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
CC: Stefan Santesson <[e-mail]>, "Housley, Russ" <[e-mail]>, Trevor Freeman <[e-mail]>
Subject: Re: New draft-ietf-pkix-logotypes-08.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> There is a new logotypes draft 08 available from:
> 
> http://www.addtrust.com/pub/logotypes-08_dr03.txt
> or from:
> ftp://ftp.rsasecurity.com/pub/rsalabs/tmp/draft-ietf-pkix-logotypes-08.txt
> 
> This draft support inclusion of multiple community logos.
> There is still support for audio.
> 
> It is the authors view that this reflects the rough consensus of this list
> and that it take care of the comments raised during WG last call.

The following comments that have ben raised during the last call have not 
been solved:

3. Page 7. Section 4.1 Extension format

There is no text which states what the client should do whenever it is
unable to support a given logotype. Insert the following text:

  "Whenever a client is unable to support a given logotype, no error SHALL be
  reported and the client MUST behave as if there was no logotype included in
  the certificate".

This raises the point that section 3 is still incorrect:

    "This specification defines two types of logotype data: image data and
    audio data. Implementations MUST support image data; however, support
    for audio data is OPTIONAL."

There are no implementations that MUST support image data, since display is 
optional. However, we should define what is a client *capable of* displaying 
logotypes. We currently can't since comment 7 has not been addressed.

In the same way since it seems that this (?!?!) audio logotype is likely to 
stay, we should define what is a client capable of playing a logotype.

Proposed text:

    This specification defines two types of logotype data: image data and
    audio data. Implementations claiming conformance with this document
    MUST be able to support image data with some minimum caracteristics;
    however, they MAY also be able to support audio data, with some
    minimum caracteristics."

It is also proposed to add that key sentence to the abstract, which is 
currently too short:

    This document specifies a certificate extension for including
    logotypes in public key certificates and attribute certificates.

7. Page 9. Section 4.1.

        LogotypeImageInfo ::= SEQUENCE {
           fileSize        INTEGER,  -- In octets
           xSize           INTEGER,  -- In pixels
           ySize           INTEGER,  -- In pixels
           numColors       INTEGER } -- In bits

  It is of particular importance to say what means conformance to this
  document for a client with respect to the number of pixels to support and
  the colors to support.

  It is proposed to add a sentence along these lines:

  "Clients claiming to conform with this document SHALL support an image with
  a minimum size of 48 pixels (xSize) by 32 pixels (ySize) in black and white
  with X grey levels."

Denis

> This draft, or an agreed update to this draft, will be posted to ID directly
> after the Atlanta meeting.
> 
> /Stefan
> 
> 
> 
> 
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]]On Behalf Of Housley, Russ
>>Sent: Tuesday, October 29, 2002 3:17 PM
>>To: [e-mail]
>>Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
>>
>>
>>
>>This update captures the things that have agreed.  The biggest change is
>>the support in the syntax for color and gray scale images.  Many other
>>little changes are included.
>>
>>As I see it, there are two open issues:
>>    1) Removal of audio; and
>>    2) Support for more than one logotype in each of the categories
>>
>>These two topics are still being discussed on the list.
>>
>>Russ
>>
>>
>>>        Title           : Internet X.509 Public Key Infrastructure:
>>>Logotypes in
>>>                          X.509 certificates
>>>        Author(s)       : S. Santesson, R. Housley, T. Freeman
>>>        Filename        : draft-ietf-pkix-logotypes-07.txt
>>>        Pages           : 21
>>>        Date            : 2002-10-28
>>
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAJ24hV08911 for ietf-pkix-bks; Mon, 18 Nov 2002 18:04:43 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id gAJ24fg08907 for <[e-mail]>; Mon, 18 Nov 2002 18:04:42 -0800 (PST)
Received: (qmail 27989 invoked from network); 19 Nov 2002 02:04:41 -0000
Received: from unknown (HELO HOUSLEY-LAP.vigilsec.com) (204.42.71.71) by woodstock.binhost.com with SMTP; 19 Nov 2002 02:04:41 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 18 Nov 2002 21:04:28 -0500
To: "Ramsay, Ron" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: No-op LDAP ;binary option
Cc: Hallvard B Furuseth <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I do not care how this gets encoded in the darn LDAP protocol; however, 
certificate users need fetch the certificate as a binary blob.

At 12:49 PM 11/19/2002 +1100, Ramsay, Ron wrote:

>;binary was a transfer option, that is, it should never have been part of
>the storage of values.
>
>-----Original Message-----
>From: Hallvard B Furuseth [mailto:[e-mail]]
>Sent: Monday, 18 November 2002 23:14
>To: [e-mail]
>Subject: No-op LDAP ;binary option
>
>
>
>Three related suggestions for the ;binary LDAP option, moved here from
>LDAPBIS since it is the PKIX group who "owns" the ";binary" question:
>
>
>Define the ;binary option to have no effect on encoding, and trust the
>syntax of the attribute to take care of encoding.
>
>Thus, you can put "userCertificate" in the Directory if that's what your
>clients need, "userCertificate;binary" - with the same encoding - if
>that's what they need, or both if you have both types of clients.
>
>
>Or, one could define ;binary to do nothing except that if the client
>requests ;binary on an attribute, it receives it with ;binary - whether
>or not the has ;binary in the directory.
>
>Thus you could have "userCertificate" in the directory and clients would
>by default receive that, but clients that wanted ;binary would still be
>handled - provided that they explicitly asked for it.  Clients that want
>userCertificate;binary but ask for userCertificate or ask for all
>attributes would not be handled.  In this case you could not solve that
>by having both userCertificate and userCertificate;binary in the same
>entry in the directory.
>
>
>Also, one could decide that if an attribute is stored with ;binary in
>the directory but the client requests the attribute without ;binary, it
>receives it without ;binary.
>
>This handles a situation where the admin has put ;binary in the
>directory because most clients want that, but where some clients want
>the attribute without ;binary (and ask for it explicitly).  It breaks
>clients that ask for userCertificate but want userCertificate;binary,
>which is legal.  In this case it doesn't help if the admin added
>;binary.
>
>--
>Hallvard



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAJ1n3N08234 for ietf-pkix-bks; Mon, 18 Nov 2002 17:49:03 -0800 (PST)
Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAJ1n1g08228 for <[e-mail]>; Mon, 18 Nov 2002 17:49:01 -0800 (PST)
Received: by aspams52.ca.com with Internet Mail Service (5.5.2656.59) id <WPAFPFQY>; Tue, 19 Nov 2002 12:49:01 +1100
Message-ID: <[e-mail]>
From: "Ramsay, Ron" <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>, [e-mail]
Subject: RE: No-op LDAP ;binary option
Date: Tue, 19 Nov 2002 12:49:07 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

;binary was a transfer option, that is, it should never have been part of
the storage of values.

-----Original Message-----
From: Hallvard B Furuseth [mailto:[e-mail]]
Sent: Monday, 18 November 2002 23:14
To: [e-mail]
Subject: No-op LDAP ;binary option



Three related suggestions for the ;binary LDAP option, moved here from
LDAPBIS since it is the PKIX group who "owns" the ";binary" question:


Define the ;binary option to have no effect on encoding, and trust the
syntax of the attribute to take care of encoding.

Thus, you can put "userCertificate" in the Directory if that's what your
clients need, "userCertificate;binary" - with the same encoding - if
that's what they need, or both if you have both types of clients.


Or, one could define ;binary to do nothing except that if the client
requests ;binary on an attribute, it receives it with ;binary - whether
or not the has ;binary in the directory.

Thus you could have "userCertificate" in the directory and clients would
by default receive that, but clients that wanted ;binary would still be
handled - provided that they explicitly asked for it.  Clients that want
userCertificate;binary but ask for userCertificate or ask for all
attributes would not be handled.  In this case you could not solve that
by having both userCertificate and userCertificate;binary in the same
entry in the directory.


Also, one could decide that if an attribute is stored with ;binary in
the directory but the client requests the attribute without ;binary, it
receives it without ;binary.

This handles a situation where the admin has put ;binary in the
directory because most clients want that, but where some clients want
the attribute without ;binary (and ask for it explicitly).  It breaks
clients that ask for userCertificate but want userCertificate;binary,
which is legal.  In this case it doesn't help if the admin added
;binary.

-- 
Hallvard


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAILaek24630 for ietf-pkix-bks; Mon, 18 Nov 2002 13:36:40 -0800 (PST)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAILabg24626 for <[e-mail]>; Mon, 18 Nov 2002 13:36:38 -0800 (PST)
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id gAILaUdt023831 for <[e-mail]>; Mon, 18 Nov 2002 16:36:31 -0500 (EST)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.2/8.12.2) with ESMTP id gAILaU8K020503 for <[e-mail]>; Mon, 18 Nov 2002 16:36:30 -0500 (EST)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.2/8.12.2/Submit) id gAILaUGH020502 for [e-mail]; Mon, 18 Nov 2002 16:36:30 -0500 (EST)
X-Authentication-Warning: calendar.nist.gov: nobody set sender to [e-mail] using -f
Received: from 204.42.70.81 ( [204.42.70.81]) as user [e-mail] by imp.nist.gov with HTTP; Mon, 18 Nov 2002 16:36:30 -0500
Message-ID: <[e-mail]>
Date: Mon, 18 Nov 2002 16:36:30 -0500
From: [e-mail]
To: [e-mail]
Subject: Really final agenda
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Oops!

I forgot to correct Mike Myers' affiliation which is TraceRoute Security.  
Sorry, Mike.

Thanks,

Tim Polk

-------- Really final agenda for PKIX ---------------

PKIX WG (pkix-wg)

WEDNESDAY, November 20 1530-1730
=================================

CHAIR: Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>

AGENDA:

1. Document Status Review Tim Polk (NIST)
      The working group has twenty current Internet-Drafts.  A number of 
      documents are with the ADs or in various stages of WG Last Call.
      Several others are ready for Last Call. (5 min.)

2. Delegated Path Discovery & Validation (DPD/DPV)

      The working group has completed the DPD/DPV Requirements document; this
      specification has become RFC 3379.  The requirements document was
      developed as abseline for evaluation of competing proposals.  Four
      competing protocols have been proposed; only one will be permitted to
      progress.  (10 min. each protocol, 20 min. discussion)

      2.1 Certificate Validation Protocol    Tim Polk for Denis Pinkas (Bull)
        http://www.ietf.org/internet-drafts/draft-ietf-pkix-cvp-01.txt

           CVP defines a protocol that can be used to:
             (1) query the validation or discovery policies supported by 
                 a CVP server, 
             (2) validate one or more public key certificates according to a 
                 single validation policy, or
             (3) obtain one or more certification paths for one or more
                 certificates according to a single discovery policy.

      2.2 Simple Certificate Validation Protocol           Russ Housley (RSA)
                                    Ambarish Malpani (Independent Consultant)

         http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-10.txt

          SCVP allows a client to offload certificate handling to a server. The
          server can prove the client with a variety of valuable information
          about the certificate, such as whether the certificate is valid, a
          certification path to a trust anchor, and so on. 

      2.3 DPD/DPV using OCSP with extensions   Mike Myers (TraceRoute)

         To be submitted.
         
           OCSP is a protocol useful in determining the current status of a 
           digital certificate without requiring CRLs.  A supplemental draft
           for DPV using OCSP have been previously submitted; this content and
           OCSPv2 (see below) jointly form the basis for this DPD/DPV 
proposal.         

      2.4 Open Mike Discussion DPD/DPV Protocols  [15 min.]

      2.5 Selection Strategy & Timeline (Chairs)  [5 min.]

         As noted above, only one protocol may progress.  Selecting the "winner"
         should be achieved at the earliest possible date, to speed completion 
and 
         permit readers to concentrate engineering effort on the final protocol.

3. Proxy Certificate Profile - Von Welch (Univ. of Chicago)

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-03.txt

      Use of a proxy credential for impersonation is a common technique used in
      security systems, allowing an entity A to grant to another entity B the
      right for B to authenticate with others as if it were A.  This document
      defines a certificate profile for proxy credentials based on RFC 3280.
      (10 min.)

4. An LDAPv3 Schema for X.509 Certificates - Peter Gietz (DAASI) 

      http://www.directory.dfn.de/docs/draft-klasen-ldap-x509certificate-schema-
01.txt

      This personal draft describes an LDAPv3 schema which can be used to 
implement
      a certificate store for X.509 certificates. (10 min.)

5. Attribute Certificate Policy extension - Christopher Francis (WetStone)

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-01.txt

      This document defines an attribute certificate policy extension, which is 
an
      analog to the certificate policies extension for public key 
certificates.  This
      extension can be used to assert the policy governing issuance of the 
attribute
      certificate in which it appears. (10 min.)

6. Warranty Extension - Alice Sturgeon (Spyrus)

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-01.txt

      This document describes a certificate extension to explicitly state
      the warranty offered by a Certificate Authority (CA) for a the
      certificate containing the extension. (10 min.)

7. Online Certificate Status Protocol v2   Mike Myers (TraceRoute)

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocspv2-ext-00.txt
         
      OCSP is a protocol useful in determining the current status of a 
      digital certificate without requiring CRLs.   OCSP Version 1 is defined
      in RFC 2560.  This document specifies OCSPv2, which provides additional
      mechanisms for specifying the certificate for which the revocation status
      is requested. (10 min.)

7.  RFC 3280 Interoperability Testing Report - Tim Polk (NIST)

      NIST is currently performing the interoperability testing for RFC 3280.  
This
      presentation will update the WG on NIST's progress, projected completion 
date,
      and issues identified to date.  (5 min.)

8.  Subscriber Identification Method - Park Jong-Wook (KISA)

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-sim-00.txt

      This new draft attempts to resolve situations where one entity holds 
multiple
      certificates with different subject names. (5 min.)

9. JNSA Challenge PKI 2002 - Ryu Inada (JNSA)

      The Japan Network Security Association is conducting JNSA Challenge PKI 
2002.
      This is work in progress, and presents an approach towards implementing a
      Multi-Domain PKI Test Suite.  The JNSA reports will be available in 
English in
      the future; this presentation provides an interim update on JNSA's 
progress.
      (5 min.)




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAILBRD23837 for ietf-pkix-bks; Mon, 18 Nov 2002 13:11:27 -0800 (PST)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAILBPg23830 for <[e-mail]>; Mon, 18 Nov 2002 13:11:25 -0800 (PST)
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id gAILBIdt019688 for <[e-mail]>; Mon, 18 Nov 2002 16:11:18 -0500 (EST)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.2/8.12.2) with ESMTP id gAILBI8K004179 for <[e-mail]>; Mon, 18 Nov 2002 16:11:18 -0500 (EST)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.2/8.12.2/Submit) id gAILBHvI004175 for [e-mail]; Mon, 18 Nov 2002 16:11:17 -0500 (EST)
X-Authentication-Warning: calendar.nist.gov: nobody set sender to [e-mail] using -f
Received: from 204.42.70.81 ( [204.42.70.81]) as user [e-mail] by imp.nist.gov with HTTP; Mon, 18 Nov 2002 16:11:17 -0500
Message-ID: <[e-mail]>
Date: Mon, 18 Nov 2002 16:11:17 -0500
From: [e-mail]
To: [e-mail]
Subject: "final" PKIX agenda for Atlanta
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

I have appended the "final" agenda for the PKIX WG.  The following changes have 
been made:

(1) Peter Sylvester's DVCS presentation was deleted.  The presentation was made 
onlist, as he will not be in Atlanta.  (See email earlier today.)

(2) Christopher Francis has confirmed to present the Attribute Certificate 
Policies draft.

(3) Alice Sturgeon's presentation on Warranty Extension has been added as #6.

Thanks,

Tim Polk

-------------- PKIX Agenda, 55th IETF Meeting ---------------

PKIX WG (pkix-wg)

WEDNESDAY, November 20 1530-1730
=================================

CHAIR: Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>

AGENDA:

1. Document Status Review Tim Polk (NIST)
      The working group has twenty current Internet-Drafts.  A number of 
      documents are with the ADs or in various stages of WG Last Call.
      Several others are ready for Last Call. (5 min.)

2. Delegated Path Discovery & Validation (DPD/DPV)

      The working group has completed the DPD/DPV Requirements document; this
      specification has become RFC 3379.  The requirements document was
      developed as abseline for evaluation of competing proposals.  Four
      competing protocols have been proposed; only one will be permitted to
      progress.  (10 min. each protocol, 20 min. discussion)

      2.1 Certificate Validation Protocol    Tim Polk for Denis Pinkas (Bull)
        http://www.ietf.org/internet-drafts/draft-ietf-pkix-cvp-01.txt

           CVP defines a protocol that can be used to:
             (1) query the validation or discovery policies supported by 
                 a CVP server, 
             (2) validate one or more public key certificates according to a 
                 single validation policy, or
             (3) obtain one or more certification paths for one or more
                 certificates according to a single discovery policy.

      2.2 Simple Certificate Validation Protocol           Russ Housley (RSA)
                                    Ambarish Malpani (Independent Consultant)

         http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-10.txt

          SCVP allows a client to offload certificate handling to a server. The
          server can prove the client with a variety of valuable information
          about the certificate, such as whether the certificate is valid, a
          certification path to a trust anchor, and so on. 

      2.3 DPD/DPV using OCSP with extensions   Mike Myers (Lockheed Martin)

         To be submitted.
         
           OCSP is a protocol useful in determining the current status of a 
           digital certificate without requiring CRLs.  A supplemental draft
           for DPV using OCSP have been previously submitted; this content and
           OCSPv2 (see below) jointly form the basis for this DPD/DPV 
proposal.         

      2.4 Open Mike Discussion DPD/DPV Protocols  [15 min.]

      2.5 Selection Strategy & Timeline (Chairs)  [5 min.]

         As noted above, only one protocol may progress.  Selecting the "winner"
         should be achieved at the earliest possible date, to speed completion 
and 
         permit readers to concentrate engineering effort on the final protocol.

3. Proxy Certificate Profile - Von Welch (Univ. of Chicago)

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-03.txt

      Use of a proxy credential for impersonation is a common technique used in
      security systems, allowing an entity A to grant to another entity B the
      right for B to authenticate with others as if it were A.  This document
      defines a certificate profile for proxy credentials based on RFC 3280.
      (10 min.)

4. An LDAPv3 Schema for X.509 Certificates - Peter Gietz (DAASI) 

      http://www.directory.dfn.de/docs/draft-klasen-ldap-x509certificate-schema-
01.txt

      This personal draft describes an LDAPv3 schema which can be used to 
implement
      a certificate store for X.509 certificates. (10 min.)

5. Attribute Certificate Policy extension - Christopher Francis (WetStone)

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-01.txt

      This document defines an attribute certificate policy extension, which is 
an
      analog to the certificate policies extension for public key 
certificates.  This
      extension can be used to assert the policy governing issuance of the 
attribute
      certificate in which it appears. (10 min.)

6. Warranty Extension - Alice Sturgeon (Spyrus)

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-01.txt

      This document describes a certificate extension to explicitly state
      the warranty offered by a Certificate Authority (CA) for a the
      certificate containing the extension. (10 min.)

7. Online Certificate Status Protocol v2   Mike Myers (Lockheed Martin)

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocspv2-ext-00.txt
         
      OCSP is a protocol useful in determining the current status of a 
      digital certificate without requiring CRLs.   OCSP Version 1 is defined
      in RFC 2560.  This document specifies OCSPv2, which provides additional
      mechanisms for specifying the certificate for which the revocation status
      is requested. (10 min.)

7.  RFC 3280 Interoperability Testing Report - Tim Polk (NIST)

      NIST is currently performing the interoperability testing for RFC 3280.  
This
      presentation will update the WG on NIST's progress, projected completion 
date,
      and issues identified to date.  (5 min.)

8.  Subscriber Identification Method - Park Jong-Wook (KISA)

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-sim-00.txt

      This new draft attempts to resolve situations where one entity holds 
multiple
      certificates with different subject names. (5 min.)

9. JNSA Challenge PKI 2002 - Ryu Inada (JNSA)

      The Japan Network Security Association is conducting JNSA Challenge PKI 
2002.
      This is work in progress, and presents an approach towards implementing a
      Multi-Domain PKI Test Suite.  The JNSA reports will be available in 
English in
      the future; this presentation provides an interim update on JNSA's 
progress.
      (5 min.)




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIKm1923117 for ietf-pkix-bks; Mon, 18 Nov 2002 12:48:01 -0800 (PST)
Received: from isis.directory.dfn.de (isis.directory.dfn.de [134.2.217.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIKlwg23113 for <[e-mail]>; Mon, 18 Nov 2002 12:47:58 -0800 (PST)
Received: from clara.directory.dfn.de (clara.directory.dfn.de [134.2.217.66]) by isis.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id gAIKlsE13412 for <[e-mail]>; Mon, 18 Nov 2002 21:47:54 +0100
Received: from daasi.de (os.directory.dfn.de [134.2.217.70]) by clara.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with SMTP id gAIKls702563 for <[e-mail]>; Mon, 18 Nov 2002 21:47:54 +0100
Received: from mercury.directory.dfn.de ([204.42.67.195]) (SquirrelMail authenticated user zrngi01) by tutos.daasi.de with HTTP; Mon, 18 Nov 2002 21:47:54 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 18 Nov 2002 21:47:54 +0100 (CET)
Subject: Re: new version of draft on additional x509certificateschema for LDAP
From: "Peter Gietz" <[e-mail]>
To: <[e-mail]>
In-Reply-To: <p05200f15b9fee3f2beea@[204.42.71.167]>
References: <[e-mail]> <p05200f15b9fee3f2beea@[204.42.71.167]>
X-Priority: 3
Importance: Normal
X-MSMail-Priority: Normal
X-Mailer: SquirrelMail (version 1.2.7)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>  "Kurt D. Zeilenga" wrote:
>
>>  To paraphrase the subclassing restrictions:
>>    A structural class cannot subclass an auxiliary class.
>>    An auxiliary class cannot subclass a structural class.
>>    An abstract class cannot subsclass an auxiliary class.
>>    An abstract class cannot subsclass a structural class.
>>
>  This is definately paraphrasing, and most of us would agree that
> these restrictions are sensible, but I repeat, you cannot find
> sentences in X.501 that catagorically state the above, and you can
> find statements in X.501 that appear to allow some of the above.
>
>
>>  If consensus is to go the STRUCTURAL route, I suggest defining one
>> abstract class and two structural classes.
>>
>>  If consensus is to go the AUXILIARY route, I suggest defining one
>> abstract class and two auxiliary classes.
>>
>
>  I was suggesting an alternative: one AUXILIARY (for packaging) and
> two (unrelated) STRUCTURALs for certificate objects (CAs and Users).
> But I think we should hold the discussion until we have the schemas
> for CRLs and ACs. We will then see some common packaging needs (e.g.
> issuer and serial number) that is not in the existing proposed
> schemas, and so we might want to have different object classes.
>

Before this discussion has taken place I will propose the following
 (following Kurt's proposal):

an ABSTRACT x509Certificate objectclass
and the two STRUCTURAL object classes:
x509userCertificate and x509caCertificate as defined by Kurt.

I don't yet think that there is a need for similiar AUXILIARY object
classes. The whole idea behind our draft is to have an entry for each
certificate, thus the thing that this entry is all about is the
certificate, thus a typical use case for STRUCTURAL. Even if there will
be the need in future to add additional data to such an entry, it can
be done with auxiliary objectclasses sticked to these structural ones.

Does the latter conflict with your idea of packaging, David?

BTW: my first hesitance to define an ABSTRACT class, was that this is
not done very often (in fact it will be the first one after top). But
since it is a perfect means to prevent an instantiation without the
certificate, why not go for it.

Cheers,

Peter







Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIJ3fZ16304 for ietf-pkix-bks; Mon, 18 Nov 2002 11:03:41 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIJ3cg16300 for <[e-mail]>; Mon, 18 Nov 2002 11:03:39 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA13643; Mon, 18 Nov 2002 20:03:36 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Mon, 18 Nov 2002 20:03:37 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id UAA01613; Mon, 18 Nov 2002 20:03:35 +0100 (MET)
Date: Mon, 18 Nov 2002 20:03:35 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: DSS: Another DPV/DPD challenger
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> If I understand the minimal description correctly, DSS seems like
> a more logical next step than DPV/DPD as it addresses the
> current situation where information systems do not understand
> PKI at all.
True. 

There are several different possibilities of next steps. Note
that DVCS has a service for 'validate signed documents'.

Considering a 'certificate' as a signed document, you can
indeed also include verification of encryption certificats
or validation of signature certificate before usage. 

Then, replace 'services for signed document validation' by 
'services for validation of document authenticity' ...

Peter

  


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIHam710953 for ietf-pkix-bks; Mon, 18 Nov 2002 09:36:48 -0800 (PST)
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIHakg10949 for <[e-mail]>; Mon, 18 Nov 2002 09:36:46 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id gAIHaWhB009658; Mon, 18 Nov 2002 18:36:32 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <001401c28f27$f5506b60$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: DSS: Another DPV/DPD challenger
Date: Mon, 18 Nov 2002 18:28:44 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Another contender from another "club".

http://www.oasis-open.org/committees/dss/

If I understand the minimal description correctly, DSS seems like
a more logical next step than DPV/DPD as it addresses the
current situation where information systems do not understand
PKI at all.

cheers,
Anders

----- Original Message ----- 
From: "Peter Sylvester" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Monday, November 18, 2002 15:48
Subject: Re: draft agenda for PKIX




hello,

tim polk reminded me that there is at least a fourth candidate
for the DPV/DPD solution, i.e., using RFC 3029 for DPV and DPD.
Since I am not able to present this at Atlanta, I'll do it
here, and would be happy to hear/read comments. 

here it goes:

DVCS, i.e., RFC 3029 has proposed from its very beginning a
framework allowing validation of public key certificates
in combination with its other services.

Among others the goals are to provide thin client support
and centralised management of certificate validity status.
Furthermore, in a larger view, essentially by using relaying
techniques, it is possible to implement a security infrastructure
accompagning a application work flow that used certificates.

The results of a DVCS service can be authenticated in two
ways depending on the needs of an application. Either, any
transport security mechanism allowing immediate authentication
betwwen a client server, and/or some mechanism to allow
long term validation of the result. The security mechnisms
are orthogonal to the asserted payload. For long term
authentication, a combination of offline methods and
online services are defined, i.e., a service should
provide an online validation service for its own (or
some else's) data validation certificates. 

The current text describes how to transport requests and
responses above HTTP(S), and email. 

The client has the possiblity to provide additional
information about certificate paths to the server. This
interpretation of this information, and the way how
the service is provided can be influenced by a policy
indication. 

DVCS responses can return combined information, i.e.,
assertions of validity combined with external time stamps.

As you might know, there is an ongoing open source
implementation project for RFC 3029 and 3161 financed
by the European Commission. As part of this, an
update to correct some bugs in 3029 and to describe
more usage scenarios, profiles is planned for
begging next of year.  

For the rest you may read RFC 3029. 

Well, this is my 5 minutes presentation. :-)
Regards and have fun.
Peter Sylvester







Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIGQlJ06473 for ietf-pkix-bks; Mon, 18 Nov 2002 08:26:47 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIGQig06468 for <[e-mail]>; Mon, 18 Nov 2002 08:26:44 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gAIGQhF3085816 for <[e-mail]>; Mon, 18 Nov 2002 16:26:44 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021118101331.036c3e40@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 18 Nov 2002 11:24:49 -0500
To: [e-mail]
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: PKI/LDAP schema, the ;binary question (Was: No-op LDAP ;binary option)
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 07:14 AM 2002-11-18, Hallvard B Furuseth wrote:
>Three related suggestions for the ;binary LDAP option, moved here from
>LDAPBIS since it is the PKIX group who "owns" the ";binary" question:

For clarity here, there is an outstanding question regarding
how X.509 certificate attributes are to be requested/transferred
in LDAP.  Namely, will "userCertificate;binary" or "userCertificate"
be the LDAP attribute description as the protocol token to refer
to an userCertificate attribute.  Regardless of which, the value
transferred is presumed to be a DER encoded X.509 certificate. 

This question is viewed by the LDAPBIS chairs as being "owned" by
PKIX WG.   Accordingly, we've asked PKIX chairs to determine whether
the PKI community prefers to continue using "userCertificate;binary"
or, as proposed in draft-ietf-pkix-ldap-pki-schema-00.txt, use
"userCertificate".

It should be noted that while LDAPBIS has decided to remove
;binary from the LDAP "core" technical specification, this decision
should not be viewed as precluding PKIX from either choice.
In particular, ;binary can be specified as an extension to LDAP
or, if necessary, the prior decision to remove ;binary from the
LDAP "core" technical specification can be reconsidered.

Kurt, LDAPBIS co-chair




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAIEmh729390 for ietf-pkix-bks; Mon, 18 Nov 2002 06:48:43 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAIEmfg29382 for <[e-mail]>; Mon, 18 Nov 2002 06:48:41 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA12495; Mon, 18 Nov 2002 15:48:36 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Mon, 18 Nov 2002 15:48:36 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id PAA00333; Mon, 18 Nov 2002 15:48:34 +0100 (MET)
Date: Mon, 18 Nov 2002 15:48:34 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft agenda for PKIX
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

hello,

tim polk reminded me that there is at least a fourth candidate
for the DPV/DPD solution, i.e., using RFC 3029 for DPV and DPD.
Since I am not able to present this at Atlanta, I'll do it
here, and would be happy to hear/read comments. 

here it goes:

DVCS, i.e., RFC 3029 has proposed from its very beginning a
framework allowing validation of public key certificates
in combination with its other services.

Among others the goals are to provide thin client support
and centralised management of certificate validity status.
Furthermore, in a larger view, essentially by using relaying
techniques, it is possible to implement a security infrastructure
accompagning a application work flow that used certificates.

The results of a DVCS service can be authenticated in two
ways depending on the needs of an application. Either, any
transport security mechanism allowing immediate authentication
betwwen a client server, and/or some mechanism to allow
long term validation of the result. The security mechnisms
are orthogonal to the asserted payload. For long term
authentication, a combination of offline methods and
online services are defined, i.e., a service should
provide an online validation service for its own (or
some else's) data validation certificates. 

The current text describes how to transport requests and
responses above HTTP(S), and email. 

The client has the possiblity to provide additional
information about certificate paths to the server. This
interpretation of this information, and the way how
the service is provided can be influenced by a policy
indication. 

DVCS responses can return combined information, i.e.,
assertions of validity combined with external time stamps.

As you might know, there is an ongoing open source
implementation project for RFC 3029 and 3161 financed
by the European Commission. As part of this, an
update to correct some bugs in 3029 and to describe
more usage scenarios, profiles is planned for
begging next of year.  

For the rest you may read RFC 3029. 

Well, this is my 5 minutes presentation. :-)
Regards and have fun.
Peter Sylvester






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAICEFu16443 for ietf-pkix-bks; Mon, 18 Nov 2002 04:14:15 -0800 (PST)
Received: from mons.uio.no (mons.uio.no [129.240.130.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAICEDg16435 for <[e-mail]>; Mon, 18 Nov 2002 04:14:13 -0800 (PST)
Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18Dkn6-000793-00; Mon, 18 Nov 2002 13:14:12 +0100
Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18Dkn6-0005Q6-00; Mon, 18 Nov 2002 13:14:12 +0100
From: Hallvard B Furuseth <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: No-op LDAP ;binary option
Date: Mon, 18 Nov 2002 13:14:12 +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Three related suggestions for the ;binary LDAP option, moved here from
LDAPBIS since it is the PKIX group who "owns" the ";binary" question:


Define the ;binary option to have no effect on encoding, and trust the
syntax of the attribute to take care of encoding.

Thus, you can put "userCertificate" in the Directory if that's what your
clients need, "userCertificate;binary" - with the same encoding - if
that's what they need, or both if you have both types of clients.


Or, one could define ;binary to do nothing except that if the client
requests ;binary on an attribute, it receives it with ;binary - whether
or not the has ;binary in the directory.

Thus you could have "userCertificate" in the directory and clients would
by default receive that, but clients that wanted ;binary would still be
handled - provided that they explicitly asked for it.  Clients that want
userCertificate;binary but ask for userCertificate or ask for all
attributes would not be handled.  In this case you could not solve that
by having both userCertificate and userCertificate;binary in the same
entry in the directory.


Also, one could decide that if an attribute is stored with ;binary in
the directory but the client requests the attribute without ;binary, it
receives it without ;binary.

This handles a situation where the admin has put ;binary in the
directory because most clients want that, but where some clients want
the attribute without ;binary (and ask for it explicitly).  It breaks
clients that ask for userCertificate but want userCertificate;binary,
which is legal.  In this case it doesn't help if the admin added
;binary.

-- 
Hallvard


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAI368b26920 for ietf-pkix-bks; Sun, 17 Nov 2002 19:06:08 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAI365g26915 for <[e-mail]>; Sun, 17 Nov 2002 19:06:06 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gAI35xwA032226; Mon, 18 Nov 2002 16:06:03 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA187361; Mon, 18 Nov 2002 16:05:58 +1300 (NZDT) (sender [e-mail])
Date: Mon, 18 Nov 2002 16:05:58 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: PrintableString not usable tigether with OCSP?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve Hanna <[e-mail]> writes:

>There are other cases where memcmp would not be sufficient. For one thing, DN
>matching is supposed to be case-insensitive and ignore excess white space (as
>described in RFC 2459, RFC 3280, and X.520). memcmp won't handle that. Also,
>there are many ways to encode a particular name in Unicode. For instance, the
><E9> in Jos<E9> can be encoded as a composite character (U+00E9) or as a base
>character and a combining character (U+0065 U+0301). X.500 names with either
>of these two encodings should match.

I don't disagree with this, in fact AFAIK I was the first person to point out
the problems with encoding/canonicalisation/etc in the X.509 Style Guide some
years ago.  However, I have yet to see any evidence that there are certs which
do this.  The reason for this is that implementors realised some years ago
that it's practically suicidal to use anything other than memcpy() to encode a
reference to a cert (that is, you use memcpy() to move the DN from the cert to
where it's needed) and by extension memcmp() to compare the reference to the
original DN, in the same way that no-one even tries to apply the decode-and-
recode-in-DER requirement.  I can say this from having helped other vendors
debug implementations which erroneously tried to follow the X.500/RFC 2459
canonicalisation/encoding rules and then found that nothing worked with the
data being produced by their code.  You give an example of combining chars,
someone once sent me a cert with the 8-bit equivalent (floating diacritics) in
it.  I have yet to find anything anywhere which displays these correctly,
however everything handles the cert OK because they just do a memcpy()/
memcmp() without trying to do anything with the content.

In summary, it does't matter what's possible in theory, real-world experience
has told us that it's memcpy()/memcmp() or nothing.

[I got one private comment saying that it would be nice if the standards
 contained at least a vague approximation to reality.  I have a (long-delayed)
 update in the works for the Style Guide which points out some of the major
 points in PKI RFCs which are best ignored, although I've never really written
 it up since I didn't feel that publishing something like this would raise
 people's views of PKI standardisation much :-).  OTOH not having it available
 leads to much pain for implementors as everyone new to the field has to find
 out the hard way which bits of the standard do and don't work.  What are
 people's opinions on this?]

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAFMJwO15800 for ietf-pkix-bks; Fri, 15 Nov 2002 14:19:58 -0800 (PST)
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAFMJug15796 for <[e-mail]>; Fri, 15 Nov 2002 14:19:56 -0800 (PST)
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29162; Fri, 15 Nov 2002 15:19:55 -0700 (MST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAFMJtig026655; Fri, 15 Nov 2002 17:19:55 -0500 (EST)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.0) with ESMTP id RAA27560; Fri, 15 Nov 2002 17:19:54 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 15 Nov 2002 17:19:15 -0500
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail]
Subject: Re: PrintableString not usable tigether with OCSP?
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'll send you some UTF8String certs. It's always good
to check interoperability. I don't have a chain with
BMPString or UnicodeString. They are not widely used
and UTF8String is preferred by RFC 3280, so we didn't
implement them. I could write some code to generate
such a chain, if you like...

There are other cases where memcmp would not be sufficient.
For one thing, DN matching is supposed to be case-insensitive
and ignore excess white space (as described in RFC 2459,
RFC 3280, and X.520). memcmp won't handle that. Also, there
are many ways to encode a particular name in Unicode.
For instance, the é in José can be encoded as a composite
character (U+00E9) or as a base character and a combining
character (U+0065 U+0301). X.500 names with either of these
two encodings should match.

-Steve

Peter Gutmann wrote:
> 
> Steve Hanna <[e-mail]> writes:
> 
> >If you'd like to have some certs that contain subject or issuer names with
> >UTF8String, let me know. I'd be glad to send you some.
> 
> I have certs with these [0], what I'd be interested in seeing is a PKCS #7
> chain with issuer.subjectDN in Unicode and subject.issuerDN in UTF8, to see
> how much software actually handles this.  In other words, a cert chain where
> memcmp() won't work for checking chaining.
> 
> Peter.
> 
> [0] OTOH more can never heart, so if you have a few samples please beam them
>     over.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAFJpew05675 for ietf-pkix-bks; Fri, 15 Nov 2002 11:51:40 -0800 (PST)
Received: from mclean-vscan3.bah.com (mclean-vscan3.bah.com [156.80.3.63]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAFJpWg05654; Fri, 15 Nov 2002 11:51:33 -0800 (PST)
Received: from mclean-vscan3.bah.com (mclean-vscan3.bah.com [156.80.3.63]) by mclean-vscan3.bah.com (8.11.0/8.11.0) with SMTP id gAFJpQv17684; Fri, 15 Nov 2002 14:51:26 -0500 (EST)
Received: from mclean-mail.usae.bah.com ([156.80.5.109]) by mclean-vscan3.bah.com (NAVGW 2.5.2.11) with SMTP id M2002111514512525530 ; Fri, 15 Nov 2002 14:51:25 -0500
Received: from Chokhani ([156.80.128.85]) by mclean-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id H5MV5500.GQU; Fri, 15 Nov 2002 14:51:05 -0500 
From: "Santosh Chokhani" <[e-mail]>
To: "'Fillingham  David W.'" <[e-mail]>, "'Adrian McCullagh'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "'Jeffrey I. Schiller'" <[e-mail]>, <[e-mail]>, "'Paul Hoffman / IMC'" <[e-mail]>, <[e-mail]>
Subject: RE: Request for IESG consideration: CP/CPS Framework
Date: Fri, 15 Nov 2002 14:52:04 -0500
Message-ID: <004d01c28ce0$78a5a600$5580509c@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All:

As one of the original authors and who has been involved in developing
RFC 2527 and the new revised RFC, I would like to shed some light on the
CP Vs. CPS issue.

I agree with Dave Fillingham.

The separation of CP and CPS is not likely to change the size or the
topics for the RFC.

A CP is a statement of policy.  That is, a CP states what needs to be
achieved.

A CPS is a statement of practices.  This is, a CPS states how the policy
requirements are met.

Thus, I see very little (if any) difference between a framework for CP
and for CPS.

Also, there has been a lot of debate on this being a legal document.
Being a framework for policy, it needs to address various aspects,
including legal obligations, crypto, computer security, network
security, subscriber authentication, and life cycle security.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Fillingham, David W.
Sent: Friday, November 15, 2002 11:09 AM
To: 'Adrian McCullagh'; [e-mail]
Cc: [e-mail]; Jeffrey I. Schiller;
[e-mail]; 'Paul Hoffman / IMC'; [e-mail]
Subject: RE: Request for IESG consideration: CP/CPS Framework



Hi Dr. McCullagh:

I agree with nearly all of what you wrote.  The exception is where you
state:

"My personal view is that RFC 2527 is too complex and tries to deal with
2 distinct issues that should be separated; namely an RFC for a CPS and
a separate RFC for a CP."

I suppose one must ask "too complex for what?"  It seems to me that the
success of RFC 2527 indicates that it is not too complex to do what it
was intended to do, which is to standardize a CP and CPS format.  The
less "complex" you make the framework, the less complete it will be, and
the less comparable the resulting CP and CPS documents will be.

Many in the legal community have long felt that "policy" deals with
liability, jurisdiction, document management, and so on - and "technical
issues" ought to be separately dealt with in technical document like the
CPS.  I respectfully disagree.  Cryptographic module assurance
requirements, certificate validity periods, security measures included
in certificate profiles, physical security requirements all impact the
assurance of certificates, and need to be addressed by policy.  CPS
documents state how a PKI implementation will meet the policy
requirements, and so must cover the same ground, but from an
implementation perspective.

My experience stems from working with the US Department of Defense
Certificate Policy Management Working Group (I was Co-Chair for a
while). We never had any problems using a single  framework to support
both CP and CPS development and evaluation.  In fact, use of a single
framework enables CPS documents generated by anyone to be readily
evaluated with respect to CP documents developed by anyone else, so long
as both the CP and the CPS were developed in accordance with the IETF
RFC. I would disagree with separating the CP and CPS frameworks into two
separate RFCs, because the DoD, Federal, and many Federal Department and
Agency Certificate Policy management processes depend heavily on CP and
CPS documents being written to a single, common, standard framework.

Best Regards,
Dave Fillingham

 -----Original Message-----
From: 	Adrian McCullagh [mailto:[e-mail]] 
Sent:	Wednesday, November 13, 2002 5:34 PM
To:	[e-mail]
Cc:	Fillingham, David W.; [e-mail]; Jeffrey I. Schiller;
[e-mail]; 'Paul Hoffman / IMC'; [e-mail]
Subject:	RE: Request for IESG consideration: CP/CPS Framework


Dear All,

It is difficult to understand the reticence that has been raised by the
members IESG.

If one looks historically at the development of Public Key
Technology(PKT), it was clear in the Rivest et al paper of 1978 that one
the benefits of PKT was the development an electronic version of the
paper based signature as a mechanism for authentication.  Whether this
has been achieved is highy debatable.  But the Rivest et al  paper is
also the genesis of the legal input in the arena.

The topic of signature validity and authenitication has been mooted for
some 700 years within the common law jurisdictions (I have no experience
with civil law jurisdictions but I assume the same issues have also
arise). It is understandable that lawyers would provide some guidance in
this area for the electronic environment.  After all, if a dispute does
arise it is unlikely that the technologist will be called upon to
adjudicate the dispute.  Traditionally it is left to the legal
faternity, namely judges, to make a determination as to who has the
better claim to the dispute. Some times the courts decision is hard to
fathom due to policy reasons which are not always cleary articulated in
the judgements.

If a digital signature does come into dispute then RFC 2527 may give
some guidance to the courts.  The exercise of developing RFC 2527 is not
wasted and should be commended by all.  If there are faults with it then
they need to be resolved which is why, as I understand it, the revision
has taken place.  The original RFC 2527 was a good start but as with
everything it is an iterative process and will as time goes by become
more refined.  My personal view is that RFC 2527 is too complex and
tries to deal with 2 distinct issues that should be separated; namely an
RFC for a CPS and a separate RFC for a CP.

The issue of CPS/CP life cycle management and usage does involve legal
considerations and as such is not simply a technical issue.

These are my initial thoughts.

Dr. Adrian McCullagh Ph. D.
Solicitor/Lawyer
Freehills
Australia

Direct 61 7 3258 6603
Telephone [phone]
Facsimile 61 7 3258 6444
http://www.freehills.com

--------------------------------------------------------------------
FREEHILLS
This email is confidential.  If you are not the intended  recipient, you
must not disclose  or  use the  information  contained in it. If you
have received this email in error,  please notify us immediately by
return email and delete the document. Freehills is not responsible for
any changes made to a document other than those made by Freehills or for
the effect of the changes on the document's meaning.

Liability is limited by the Solicitors' Limitation of Liability Scheme,
approved under the Professional Standards Act 1994 (NSW)
--------------------------------------------------------------------




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAFJlYS05544 for ietf-pkix-bks; Fri, 15 Nov 2002 11:47:34 -0800 (PST)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAFJlVg05540 for <[e-mail]>; Fri, 15 Nov 2002 11:47:31 -0800 (PST)
Received: from corben (corben.ncsl.nist.gov [129.6.54.128]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id gAFJlFdu017457 for <[e-mail]>; Fri, 15 Nov 2002 14:47:15 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 15 Nov 2002 14:49:57 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: draft agenda for PKIX
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

I have appended the *draft* agenda for the PKIX meeting on Wednesday.  I 
believe that I have included everyone who asked for time.

**Please let me know if I missed anyone.**  While the schedule is full, two 
speakers are TBDs.  If we don't have those presentations, we will have some 
free time.  (Regardless, we can probably squeeze in a short [5 min.] 
presentation or two.)

As indicated previously, the agenda is heavily weighted towards the DPD/DPV 
work.  We will try to stay on schedule, but the DPD/DPV presentations are 
first to ensure that topic is thoroughly covered.  If we run short on time, 
I will ask the later speakers with 10 minute time slots to cut to 5 
minutes!  Hopefully, that will not occur, but please consider what topics 
are most important to cover if time is short...

Please note I have included URLs for all documents, along with a few words 
(liberally edited) from each document's abstract.

Thanks,

Tim Polk

--------------------- draft agenda ----------------------

PKIX WG (pkix-wg)

WEDNESDAY, November 20 1530-1730
=================================

CHAIR: Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>

AGENDA:

1. Document Status Review Tim Polk (NIST)
       The working group has twenty current Internet-Drafts.  A number of
       documents are with the ADs or in various stages of WG Last Call.
       Several others are ready for Last Call. (5 min.)

2. Delegated Path Discovery & Validation (DPD/DPV)

       The working group has completed the DPD/DPV Requirements document; this
       specification has become RFC 3379.  The requirements document was
       developed as abseline for evaluation of competing proposals.  Four
       competing protocols have been proposed; only one will be permitted to
       progress.  (10 min. each protocol, 20 min. discussion)

       2.1 Certificate Validation Protocol    Tim Polk for Denis Pinkas (Bull)
         http://www.ietf.org/internet-drafts/draft-ietf-pkix-cvp-01.txt

            CVP defines a protocol that can be used to:
              (1) query the validation or discovery policies supported by
                  a CVP server,
              (2) validate one or more public key certificates according to a
                  single validation policy, or
              (3) obtain one or more certification paths for one or more
                  certificates according to a single discovery policy.

       2.2 Simple Certificate Validation Protocol           Russ Housley (RSA)
                                     Ambarish Malpani (Independent Consultant)

          http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-10.txt

           SCVP allows a client to offload certificate handling to a 
server. The
           server can prove the client with a variety of valuable information
           about the certificate, such as whether the certificate is valid, a
           certification path to a trust anchor, and so on.

       2.3 Data Validation and Certification Server Protocols TBD

         http://www.ietf.org/rfc/rfc3029.txt

            Useful Data Validation and Certification Server 
responsibilities in a
            PKI are to assert the validity of signed documents, public key
            certificates, and the possession or existence of data.

       2.4 DPD/DPV using OCSP with extensions   Mike Myers (Lockheed Martin)

          To be submitted.

            OCSP is a protocol useful in determining the current status of a
            digital certificate without requiring CRLs.  A supplemental draft
            for DPV using OCSP have been previously submitted; this content and
            OCSPv2 (see below) jointly form the basis for this DPD/DPV 
proposal.

       2.5 Open Mike Discussion DPD/DPV Protocols  [15 min.]

       2.6 Selection Strategy & Timeline (Chairs)  [5 min.]

          As noted above, only one protocol may progress.  Selecting the 
"winner"
          should be achieved at the earliest possible date, to speed 
completion and
          permit readers to concentrate engineering effort on the final 
protocol.

3. Proxy Certificate Profile - Von Welch (Univ. of Chicago)

       http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-03.txt

       Use of a proxy credential for impersonation is a common technique 
used in
       security systems, allowing an entity A to grant to another entity B the
       right for B to authenticate with others as if it were A.  This document
       defines a certificate profile for proxy credentials based on RFC 3280.
       (10 min.)

4. An LDAPv3 Schema for X.509 Certificates - Peter Gietz (DAASI)

       http://www.directory.dfn.de/docs/draft-klasen-ldap-x509certificate-sc 
http://www.directory.dfn.de/docs/draft-klasen-ldap-x509certificate-schema-01 
.txt

       This personal draft describes an LDAPv3 schema which can be used to 
implement
       a certificate store for X.509 certificates. (10 min.)

5. Attribute Certificate Policy extension - TBD

       http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-0 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-01.txt

       This document defines an attribute certificate policy extension, 
which is an
       analog to the certificate policies extension for public key 
certificates.  This
       extension can be used to assert the policy governing issuance of the 
attribute
       certificate in which it appears. (10 min.)

6.  Online Certificate Status Protocol v2   Mike Myers (Lockheed Martin)

       http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocspv2-ext-00.txt

       OCSP is a protocol useful in determining the current status of a
       digital certificate without requiring CRLs.   OCSP Version 1 is defined
       in RFC 2560.  This document specifies OCSPv2, which provides additional
       mechanisms for specifying the certificate for which the revocation 
status
       is requested. (10 min.)

7.  RFC 3280 Interoperability Testing Report - Tim Polk (NIST)

       NIST is currently performing the interoperability testing for RFC 
3280.  This
       presentation will update the WG on NIST's progress, projected 
completion date,
       and issues identified to date.  (5 min.)

8.  Subscriber Identification Method - Park Jong-Wook (KISA)

       http://www.ietf.org/internet-drafts/draft-ietf-pkix-sim-00.txt

       This new draft attempts to resolve situations where one entity holds 
multiple
       certificates with different subject names. (5 min.)

9. JNSA Challenge PKI 2002 - Ryu Inada (JNSA)

       The Japan Network Security Association is conducting JNSA Challenge 
PKI 2002.
       This is work in progress, and presents an approach towards 
implementing a
       Multi-Domain PKI Test Suite.  The JNSA reports will be available in 
English in
       the future; this presentation provides an interim update on JNSA's 
progress.
       (5 min.)



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAFHMBs24296 for ietf-pkix-bks; Fri, 15 Nov 2002 09:22:11 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAFHM8g24290 for <[e-mail]>; Fri, 15 Nov 2002 09:22:08 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gAFHM3F3067059; Fri, 15 Nov 2002 17:22:03 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021115091357.029998e8@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 15 Nov 2002 09:21:28 -0800
To: David Chadwick <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: new version of draft on additional x509certificateschemafor LDAP
Cc: Peter Gietz <[e-mail]>, Ietf-Pkix <[e-mail]>
In-Reply-To: <[e-mail]>
References: <5.1.0.14.0.20021108070500.03498818@127.0.0.1> <5.1.0.14.0.20021114130625.02965568@127.0.0.1> <5.1.0.14.0.20021114150221.03604e70@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 05:44 AM 2002-11-15, David Chadwick wrote:
>"Kurt D. Zeilenga" wrote:
>> To paraphrase the subclassing restrictions:
>>   A structural class cannot subclass an auxiliary class.
>>   An auxiliary class cannot subclass a structural class.
>>   An abstract class cannot subsclass an auxiliary class.
>>   An abstract class cannot subsclass a structural class.
>
>This is definately paraphrasing, and most of us would agree that these
>restrictions are sensible, but I repeat, you cannot find sentences in
>X.501 that catagorically state the above,

Yes.  I was confused by more explicit statements in LDAPBIS I-Ds.
I'm glad we agree they are sensible.  Those who disagree should
raise a concern to LDAPBIS.

Kurt



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAFGA7F18496 for ietf-pkix-bks; Fri, 15 Nov 2002 08:10:07 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAFGA1g18475; Fri, 15 Nov 2002 08:10:01 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id gAFG9II11901; Fri, 15 Nov 2002 11:09:18 -0500 (EST)
Message-ID: <[e-mail]>
From: "Fillingham,  David W." <[e-mail]>
To: "'Adrian McCullagh'" <[e-mail]>, [e-mail]
Cc: [e-mail], "Jeffrey I. Schiller" <[e-mail]>, [e-mail], "'Paul Hoffman / IMC'" <[e-mail]>, [e-mail]
Subject: RE: Request for IESG consideration: CP/CPS Framework
Date: Fri, 15 Nov 2002 11:09:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
X-H-S-Loop-Check-Ejzfr: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Dr. McCullagh:

I agree with nearly all of what you wrote.  The exception is where you
state:

"My personal view is that RFC 2527 is too complex and tries to deal with 2
distinct issues that should be separated; namely an RFC for a CPS and a
separate RFC for a CP."

I suppose one must ask "too complex for what?"  It seems to me that the
success of RFC 2527 indicates that it is not too complex to do what it was
intended to do, which is to standardize a CP and CPS format.  The less
"complex" you make the framework, the less complete it will be, and the less
comparable the resulting CP and CPS documents will be.

Many in the legal community have long felt that "policy" deals with
liability, jurisdiction, document management, and so on - and "technical
issues" ought to be separately dealt with in technical document like the
CPS.  I respectfully disagree.  Cryptographic module assurance requirements,
certificate validity periods, security measures included in certificate
profiles, physical security requirements all impact the assurance of
certificates, and need to be addressed by policy.  CPS documents state how a
PKI implementation will meet the policy requirements, and so must cover the
same ground, but from an implementation perspective.

My experience stems from working with the US Department of Defense
Certificate Policy Management Working Group (I was Co-Chair for a while).
We never had any problems using a single  framework to support both CP and
CPS development and evaluation.  In fact, use of a single framework enables
CPS documents generated by anyone to be readily evaluated with respect to CP
documents developed by anyone else, so long as both the CP and the CPS were
developed in accordance with the IETF RFC. I would disagree with separating
the CP and CPS frameworks into two separate RFCs, because the DoD, Federal,
and many Federal Department and Agency Certificate Policy management
processes depend heavily on CP and CPS documents being written to a single,
common, standard framework.

Best Regards,
Dave Fillingham

 -----Original Message-----
From: 	Adrian McCullagh [mailto:[e-mail]] 
Sent:	Wednesday, November 13, 2002 5:34 PM
To:	[e-mail]
Cc:	Fillingham, David W.; [e-mail]; Jeffrey I. Schiller;
[e-mail]; 'Paul Hoffman / IMC'; [e-mail]
Subject:	RE: Request for IESG consideration: CP/CPS Framework


Dear All,

It is difficult to understand the reticence that has been raised by the
members IESG.

If one looks historically at the development of Public Key Technology(PKT),
it was clear in the Rivest et al paper of 1978 that one the benefits of PKT
was the development an electronic version of the paper based signature as a
mechanism for authentication.  Whether this has been achieved is highy
debatable.  But the Rivest et al  paper is also the genesis of the legal
input in the arena.

The topic of signature validity and authenitication has been mooted for
some 700 years within the common law jurisdictions (I have no experience
with civil law jurisdictions but I assume the same issues have also arise).
It is understandable that lawyers would provide some guidance in this area
for the electronic environment.  After all, if a dispute does arise it is
unlikely that the technologist will be called upon to adjudicate the
dispute.  Traditionally it is left to the legal faternity, namely judges,
to make a determination as to who has the better claim to the dispute.
Some times the courts decision is hard to fathom due to policy reasons
which are not always cleary articulated in the judgements.

If a digital signature does come into dispute then RFC 2527 may give some
guidance to the courts.  The exercise of developing RFC 2527 is not wasted
and should be commended by all.  If there are faults with it then they need
to be resolved which is why, as I understand it, the revision has taken
place.  The original RFC 2527 was a good start but as with everything it is
an iterative process and will as time goes by become more refined.  My
personal view is that RFC 2527 is too complex and tries to deal with 2
distinct issues that should be separated; namely an RFC for a CPS and a
separate RFC for a CP.

The issue of CPS/CP life cycle management and usage does involve legal
considerations and as such is not simply a technical issue.

These are my initial thoughts.

Dr. Adrian McCullagh Ph. D.
Solicitor/Lawyer
Freehills
Australia

Direct 61 7 3258 6603
Telephone [phone]
Facsimile 61 7 3258 6444
http://www.freehills.com

--------------------------------------------------------------------
FREEHILLS
This email is confidential.  If you are not the intended  recipient,
you must not disclose  or  use the  information  contained in it. If
you have received this email in error,  please notify us immediately
by return email and delete the document.
Freehills is not responsible for any changes made to a document other
than those made by Freehills or for the effect of the changes on the
document's meaning.

Liability is limited by the Solicitors' Limitation of Liability Scheme,
approved under the Professional Standards Act 1994 (NSW)
--------------------------------------------------------------------




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAFFBqr16492 for ietf-pkix-bks; Fri, 15 Nov 2002 07:11:52 -0800 (PST)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAFFBmg16484 for <[e-mail]>; Fri, 15 Nov 2002 07:11:48 -0800 (PST)
Received: from Santesson ([192.168.101.122]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 15 Nov 2002 16:11:44 +0100
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, "Trevor Freeman" <[e-mail]>
Subject: New draft-ietf-pkix-logotypes-08.txt
Date: Fri, 15 Nov 2002 16:11:43 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Importance: Normal
X-OriginalArrivalTime: 15 Nov 2002 15:11:44.0139 (UTC) FILETIME=[4EF62DB0:01C28CB9]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

There is a new logotypes draft 08 available from:

http://www.addtrust.com/pub/logotypes-08_dr03.txt
or from:
ftp://ftp.rsasecurity.com/pub/rsalabs/tmp/draft-ietf-pkix-logotypes-08.txt

This draft support inclusion of multiple community logos.
There is still support for audio.

It is the authors view that this reflects the rough consensus of this list
and that it take care of the comments raised during WG last call.

This draft, or an agreed update to this draft, will be posted to ID directly
after the Atlanta meeting.

/Stefan



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Housley, Russ
> Sent: Tuesday, October 29, 2002 3:17 PM
> To: [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
>
>
>
> This update captures the things that have agreed.  The biggest change is
> the support in the syntax for color and gray scale images.  Many other
> little changes are included.
>
> As I see it, there are two open issues:
>     1) Removal of audio; and
>     2) Support for more than one logotype in each of the categories
>
> These two topics are still being discussed on the list.
>
> Russ
>
> >         Title           : Internet X.509 Public Key Infrastructure:
> > Logotypes in
> >                           X.509 certificates
> >         Author(s)       : S. Santesson, R. Housley, T. Freeman
> >         Filename        : draft-ietf-pkix-logotypes-07.txt
> >         Pages           : 21
> >         Date            : 2002-10-28
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAFDdQr03703 for ietf-pkix-bks; Fri, 15 Nov 2002 05:39:26 -0800 (PST)
Received: from iapetus.salford.ac.uk (iapetus.salford.ac.uk [146.87.255.98]) by above.proper.com (8.11.6/8.11.3) with SMTP id gAFDdNg03690 for <[e-mail]>; Fri, 15 Nov 2002 05:39:23 -0800 (PST)
Received: (qmail 68845 invoked by alias); 15 Nov 2002 13:39:23 -0000
Received: (qmail 68819 invoked from network); 15 Nov 2002 13:39:23 -0000
Received: from unknown (HELO salford.ac.uk) (146.87.80.124) by iapetus.salford.ac.uk with SMTP; 15 Nov 2002 13:39:23 -0000
Message-ID: <[e-mail]>
Date: Fri, 15 Nov 2002 13:44:07 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
CC: Peter Gietz <[e-mail]>, Ietf-Pkix <[e-mail]>
Subject: Re: new version of draft on additional x509certificateschemafor LDAP
References: <5.1.0.14.0.20021108070500.03498818@127.0.0.1> <5.1.0.14.0.20021114130625.02965568@127.0.0.1> <5.1.0.14.0.20021114150221.03604e70@127.0.0.1>
Content-Type: multipart/mixed; boundary="------------49CD0AD8CE39DFBFA0F52510"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------49CD0AD8CE39DFBFA0F52510
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



"Kurt D. Zeilenga" wrote:

> To paraphrase the subclassing restrictions:
>   A structural class cannot subclass an auxiliary class.
>   An auxiliary class cannot subclass a structural class.
>   An abstract class cannot subsclass an auxiliary class.
>   An abstract class cannot subsclass a structural class.
> 

This is definately paraphrasing, and most of us would agree that these
restrictions are sensible, but I repeat, you cannot find sentences in
X.501 that catagorically state the above, and you can find statements in
X.501 that appear to allow some of the above.


> If consensus is to go the STRUCTURAL route, I suggest defining one
> abstract class and two structural classes.
> 
> If consensus is to go the AUXILIARY route, I suggest defining one
> abstract class and two auxiliary classes.
> 

I was suggesting an alternative: one AUXILIARY (for packaging) and two
(unrelated) STRUCTURALs for certificate objects (CAs and Users). But I
think we should hold the discussion until we have the schemas for CRLs
and ACs. We will then see some common packaging needs (e.g. issuer and
serial number) that is not in the existing proposed schemas, and so we
might want to have different object classes.

David

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------49CD0AD8CE39DFBFA0F52510
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------49CD0AD8CE39DFBFA0F52510--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAF5fj600502 for ietf-pkix-bks; Thu, 14 Nov 2002 21:41:45 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAF5fgg29996 for <[e-mail]>; Thu, 14 Nov 2002 21:41:42 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gAF5fhF3063923; Fri, 15 Nov 2002 05:41:43 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021114211424.036cac10@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 14 Nov 2002 21:41:08 -0800
To: Chris Davenport <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: subschemaSubentry in PKI/PMI LDAP schema I-Ds
Cc: David Chadwick <[e-mail]>, [e-mail]
In-Reply-To: <5.1.0.14.0.20021114165605.036b9e70@127.0.0.1>
References: <[e-mail]> <5.1.0.14.0.20021114124956.035fd5d8@127.0.0.1> <5.1.0.14.0.20021112192514.034e91d0@127.0.0.1> <5.1.0.14.0.20021114124956.035fd5d8@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 05:36 PM 2002-11-14, Kurt D. Zeilenga wrote:
>Sorry, no.  The client cannot determine, based upon the contents of
>the subschemaSubentry attribute held at the root DSE, which entries
>are controlled by the named subschema subentries.

I should clarify this a bit.

To perform operations on a set of entries, a client may need to
discover the schema controlling these entries.  That is, the
question the client is asking "what subschemas controls these
entries?".

While the client certainly read the root DSE subschemaSubentry
attribute and then by issuing a search for each listed value
determine which entries are controlled by which listed values.
But this is only answers the question if and only if the root
DSE lists all possible subschema subentries.  And, because the
client cannot assume that all possible subschema subentries are
listed,  this approach can fail.  Also, the list may be quite
large.  So, even where this approach might work, it also may
be quite expensive.

A simpler approach is just to request the return of the
subschemaSubentry attribute with each entry in the set.

Of course, most clients don't bother with schema discovery...

Kurt



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAF2KTo19873 for ietf-pkix-bks; Thu, 14 Nov 2002 18:20:29 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAF2KQg19869 for <[e-mail]>; Thu, 14 Nov 2002 18:20:27 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gAF2KOwA024621; Fri, 15 Nov 2002 15:20:24 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA163043; Fri, 15 Nov 2002 15:20:23 +1300 (NZDT) (sender [e-mail])
Date: Fri, 15 Nov 2002 15:20:23 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: PrintableString not usable tigether with OCSP?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve Hanna <[e-mail]> writes:

>If you'd like to have some certs that contain subject or issuer names with
>UTF8String, let me know. I'd be glad to send you some.

I have certs with these [0], what I'd be interested in seeing is a PKCS #7
chain with issuer.subjectDN in Unicode and subject.issuerDN in UTF8, to see
how much software actually handles this.  In other words, a cert chain where
memcmp() won't work for checking chaining.

Peter.

[0] OTOH more can never heart, so if you have a few samples please beam them
    over.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAF1bEo17848 for ietf-pkix-bks; Thu, 14 Nov 2002 17:37:14 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAF1bAg17843 for <[e-mail]>; Thu, 14 Nov 2002 17:37:11 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gAF1bAF3062492; Fri, 15 Nov 2002 01:37:10 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021114165605.036b9e70@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 14 Nov 2002 17:36:35 -0800
To: Chris Davenport <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: subschemaSubentry in PKI/PMI LDAP schema I-Ds
Cc: David Chadwick <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <5.1.0.14.0.20021114124956.035fd5d8@127.0.0.1> <5.1.0.14.0.20021112192514.034e91d0@127.0.0.1> <5.1.0.14.0.20021114124956.035fd5d8@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 01:55 PM 2002-11-14, Chris Davenport wrote:
>The client could easily restrict its search to only those objects whose 
>subschemaSubentry value matched one of the values listed in the root DSE that support the matching rules.

Sorry, no.  The client cannot determine, based upon the contents of
the subschemaSubentry attribute held at the root DSE, which entries
are controlled by the named subschema subentries.

The only reliable mechanism for the client to determine which
subschema controls a particular entry is reading that entry's
subschemaSubentry attribute.

Listing multiple values in the root DSE subschemaSubentry is
problematic.  Short summary of LDAPBIS discussions:  The client
would not be able to determine which subschema applied to the
root DSE itself.  The client cannot determine which values apply
elsewhere without out looking elsewhere.  Lastly, the
subschemaSubentry attribute is defined as being single valued.
(Those desiring details should check out the LDAPBIS archives).

Anyways, my primary comment here is that PKIX should be carefu
not to rely on subschema subentries for discover of server-specific
capabilities.  Subschema subentries are for discover of schema
policy.  Policy information doesn't necessarily reflect a
server's capabilities.  Values of attributes held in the
root DSE (e.g., supportedExtension, supportedControl,
supportedSASLmechanisms, supportedFeatures [coming soon])
should be used for server capability discover.

Kurt


>        Chris Davenport
>        Directory & Security Engineer
>        ISS Hewlett-Packard Corp.
>
>On Thursday 14 November 2002 03:04 pm, Kurt D. Zeilenga wrote:
>> At 12:50 PM 2002-11-14, David Chadwick wrote:
>> >Kurt
>> >
>> >your point is noted. However it does not work. Since the client is
>> >wanting to search the directory for particular PKI attributes, it does
>> >not necessarily know the entry that they are contained in.
>>
>> To issue this search, the client must have a baseObject.  It should
>> look at the subschemaSubentry attribute in this baseObject.
>>
>> >Therefore it
>> >cannot read the entry to find its subschema subentry before the entry
>> >has been found.
>>
>> While certainly entries subordinate to the baseObject may be
>> controlled by a different subschema, at least the client nows
>> the filter is valid at the baseObject.
>>
>> >For this reason I suggest that the subschemaSubentry
>> >attribute in the root DSE be made multivalued, so that the client can
>> >find out if the matching rules are supported prior to it issuing the
>> >extensible Search.
>>
>> Assume that a server listed two subschemaSubentry values in the
>> root DSE, one listing this matching rule use and one not.  How
>> does the client determine which subschema controls the entry
>> referenced by baseObject of its extensible search?
>>
>> Without reading the baseObject's subschemaSubentry, it cannot
>> reliably determine which subschema applies.
>>
>> Personally, I think the client should just issue the operation
>> without discovery...  worse case the assertion is Undefined.
>>
>> Kurt
>>
>> >David
>> >
>> >"Kurt D. Zeilenga" wrote:
>> >> Both the PKI and PMI LDAP Schema I-Ds contain a similar
>> >> worded section called "Subschema Publishing LDAPv3". Both
>> >> imply that a server has one and only one subschema subentry
>> >> and that this subentry is discoverable by reading the
>> >> subschemaSubentry attribute held in the Root DSE.
>> >>
>> >> The X.500 model, as used in LDAP, clearly allows multiple
>> >> subschema subentries to be present, each controlling a subtree
>> >> of entries.  In fact, each entry held by the server could
>> >> be controlled a different subschema subentry as indicated
>> >> by the entry's subschemaSubentry attribute.
>> >>
>> >> It is noted that RFC 2251 has a bug regarding the root DSE's
>> >> subschemaSubentry attribute.  To avoid this bug, PKI/PMI
>> >> specification should clearly state that the schema controlling
>> >> a particular entry is to be discovered by reading that entry's
>> >> subschemaSubentry's attribute. (Just as one would in X.500).
>> >>
>> >> Kurt
>> >
>> >--
>> >*****************************************************************
>> >
>> >David W. Chadwick, BSc PhD
>> >Professor of Information Systems Security
>> >IS Institute, University of Salford, Salford M5 4WT
>> >Tel: [phone]  Fax [phone]
>> >Mobile: [phone]
>> >Email: [e-mail]
>> >Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
>> >Research Projects: http://sec.isi.salford.ac.uk
>> >Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
>> >X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
>> >Entrust key validation string: MLJ9-DU5T-HV8J
>> >PGP Key ID is 0xBC238DE5
>> >
>> >*****************************************************************



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAENIwN10660 for ietf-pkix-bks; Thu, 14 Nov 2002 15:18:58 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAENItg10653 for <[e-mail]>; Thu, 14 Nov 2002 15:18:55 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gAENIrF3061760; Thu, 14 Nov 2002 23:18:53 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021114150221.03604e70@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 14 Nov 2002 15:18:18 -0800
To: David Chadwick <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: new version of draft on additional x509 certificateschemafor LDAP
Cc: Peter Gietz <[e-mail]>, Ietf-Pkix <[e-mail]>
In-Reply-To: <[e-mail]>
References: <5.1.0.14.0.20021108070500.03498818@127.0.0.1> <5.1.0.14.0.20021114130625.02965568@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 02:30 PM 2002-11-14, David Chadwick wrote:


>"Kurt D. Zeilenga" wrote:
>> 
>> At 12:57 PM 2002-11-14, David Chadwick wrote:
>> >"Kurt D. Zeilenga" wrote:
>> >>
>> >> At 02:47 AM 2002-11-08, Peter Gietz wrote:
>> >> >I am not yet sure, why Kurt proposes an ABSRACT object class for x509certificate instead of a STRUCTURAL derived from top.
>> >>
>> >> To prevent instantiation without a certificate.
>> >
>> >then it should be an AUXILIARY object class
>> 
>> Then it's subclasses could not be STRUCTURAL.
>
>Firstly I am not sure this is the case. I have read X501 again, and
>there does not seem to be anything to stop a chain of
>
>top>auxiliary>structural object class. Although I admit it is rather
>unusual.

That's invalid per X.501.  To paraphrase the subclassing restrictions:
  A structural class cannot subclass an auxiliary class.
  An auxiliary class cannot subclass a structural class.
  An abstract class cannot subsclass an auxiliary class.
  An abstract class cannot subsclass a structural class.


>However, you can just as easily define STRUCTURAL object classes for
>certificate entries, that are subordinate to Top, and have the
>x509certificate as an auxiliary object class. I believe this is a better
>approach, then the x509certificate object class, being auxiliary, can be
>attached to any type of entry that needs the package of attributes that
>it defines

Well, as I noted before, one **could** have

     structX509user, structX509ca
AND
     auxX509user, auxX509ca

all inheriting from abstractX509.  abstractX509 would require/allow
attributes common to all four classes.  But userCertificate would
only be MUSTed in structX509user and auxX509user and caCertificate
would be MUSTed in structX509ca and auxX509ca.

If consensus is to go the STRUCTURAL route, I suggest defining one
abstract class and two structural classes.

If consensus is to go the AUXILIARY route, I suggest defining one
abstract class and two auxiliary classes.

I am not prepared, at this time, to make a STRUCTURAL v AUXILIARY
recommendation.





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAEN4Vn10359 for ietf-pkix-bks; Thu, 14 Nov 2002 15:04:31 -0800 (PST)
Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id gAEN4Qg10355 for <[e-mail]>; Thu, 14 Nov 2002 15:04:27 -0800 (PST)
Received: (qmail 13755 invoked from network); 14 Nov 2002 22:56:43 -0000
Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 14 Nov 2002 22:56:43 -0000
Reply-To: <[e-mail]>
From: "Steven Legg" <[e-mail]>
To: "'Kurt D. Zeilenga'" <[e-mail]>, "'David Chadwick'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: subschemaSubentry in PKI/PMI LDAP schema I-Ds
Date: Fri, 15 Nov 2002 10:03:18 +1100
Message-ID: <001301c28c32$061ca830$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
In-Reply-To: <5.1.0.14.0.20021114124956.035fd5d8@127.0.0.1>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt & David,

Kurt D. Zeilenga wrote:
> At 12:50 PM 2002-11-14, David Chadwick wrote:
> >Kurt
> >
> >your point is noted. However it does not work. Since the client is
> >wanting to search the directory for particular PKI 
> attributes, it does
> >not necessarily know the entry that they are contained in.
> 
> To issue this search, the client must have a baseObject.  It should
> look at the subschemaSubentry attribute in this baseObject.
> 
> >Therefore it
> >cannot read the entry to find its subschema subentry before the entry
> >has been found.
> 
> While certainly entries subordinate to the baseObject may be
> controlled by a different subschema, at least the client nows
> the filter is valid at the baseObject.

The client can also discover if, and what, other subschema applies
within the scope of the subtree of the baseObject by issuing a subtree
search for subentries with objectClass=subschema.

> >For this reason I suggest that the subschemaSubentry
> >attribute in the root DSE be made multivalued, so that the client can
> >find out if the matching rules are supported prior to it issuing the
> >extensible Search.
> 
> Assume that a server listed two subschemaSubentry values in the
> root DSE, one listing this matching rule use and one not.  How
> does the client determine which subschema controls the entry
> referenced by baseObject of its extensible search?
> 
> Without reading the baseObject's subschemaSubentry, it cannot
> reliably determine which subschema applies.

Not that it really matters anyway. In the X.500 world view the absence
of a matching rule definition from a subschema subentry is not an
indication of a lack of capability on the part of the server mastering
the subschema subentry. Nor is the presence of a matching rule definition
a guarantee that a server supports the matching rule since the subschema
administrative area could span multiple DSAs, or be replicated to
other DSAs, each with their own particular set of supported features.

> Personally, I think the client should just issue the operation
> without discovery...  worse case the assertion is Undefined.

I agree. I expect most clients won't bother to do schema discovery, no
matter what we say. In practice it comes down to a server deployment
issue.  One should choose a directory server to hold PKI that supports
the matching rules one expects will be used, and entries should not be
replicated to directory servers that do not also support those matching
rules.

Regards,
Steven
 
> 
> Kurt
> 
> 
> >David
> >
> >
> >"Kurt D. Zeilenga" wrote:
> >> 
> >> Both the PKI and PMI LDAP Schema I-Ds contain a similar
> >> worded section called "Subschema Publishing LDAPv3". Both
> >> imply that a server has one and only one subschema subentry
> >> and that this subentry is discoverable by reading the
> >> subschemaSubentry attribute held in the Root DSE.
> >> 
> >> The X.500 model, as used in LDAP, clearly allows multiple
> >> subschema subentries to be present, each controlling a subtree
> >> of entries.  In fact, each entry held by the server could
> >> be controlled a different subschema subentry as indicated
> >> by the entry's subschemaSubentry attribute.
> >> 
> >> It is noted that RFC 2251 has a bug regarding the root DSE's
> >> subschemaSubentry attribute.  To avoid this bug, PKI/PMI
> >> specification should clearly state that the schema controlling
> >> a particular entry is to be discovered by reading that entry's
> >> subschemaSubentry's attribute. (Just as one would in X.500).
> >> 
> >> Kurt
> >
> >-- 
> >*****************************************************************
> >
> >David W. Chadwick, BSc PhD
> >Professor of Information Systems Security
> >IS Institute, University of Salford, Salford M5 4WT
> >Tel: [phone]  Fax [phone]
> >Mobile: [phone]
> >Email: [e-mail]
> >Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> >Research Projects: http://sec.isi.salford.ac.uk
> >Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> >X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> >Entrust key validation string: MLJ9-DU5T-HV8J
> >PGP Key ID is 0xBC238DE5
> >
> >*****************************************************************
> 
> 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAEMPqk07774 for ietf-pkix-bks; Thu, 14 Nov 2002 14:25:52 -0800 (PST)
Received: from iapetus.salford.ac.uk (iapetus.salford.ac.uk [146.87.255.98]) by above.proper.com (8.11.6/8.11.3) with SMTP id gAEMPog07764 for <[e-mail]>; Thu, 14 Nov 2002 14:25:50 -0800 (PST)
Received: (qmail 92188 invoked by alias); 14 Nov 2002 22:25:51 -0000
Received: (qmail 92170 invoked from network); 14 Nov 2002 22:25:51 -0000
Received: from unknown (HELO salford.ac.uk) (146.87.80.124) by iapetus.salford.ac.uk with SMTP; 14 Nov 2002 22:25:51 -0000
Message-ID: <[e-mail]>
Date: Thu, 14 Nov 2002 22:30:32 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
CC: Peter Gietz <[e-mail]>, Ietf-Pkix <[e-mail]>
Subject: Re: new version of draft on additional x509 certificateschemafor LDAP
References: <5.1.0.14.0.20021108070500.03498818@127.0.0.1> <5.1.0.14.0.20021114130625.02965568@127.0.0.1>
Content-Type: multipart/mixed; boundary="------------08474BDBE3CF7704E4508DDF"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------08474BDBE3CF7704E4508DDF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



"Kurt D. Zeilenga" wrote:
> 
> At 12:57 PM 2002-11-14, David Chadwick wrote:
> >"Kurt D. Zeilenga" wrote:
> >>
> >> At 02:47 AM 2002-11-08, Peter Gietz wrote:
> >> >I am not yet sure, why Kurt proposes an ABSRACT object class for x509certificate instead of a STRUCTURAL derived from top.
> >>
> >> To prevent instantiation without a certificate.
> >
> >then it should be an AUXILIARY object class
> 
> Then it's subclasses could not be STRUCTURAL.

Firstly I am not sure this is the case. I have read X501 again, and
there does not seem to be anything to stop a chain of

top>auxiliary>structural object class. Although I admit it is rather
unusual.

However, you can just as easily define STRUCTURAL object classes for
certificate entries, that are subordinate to Top, and have the
x509certificate as an auxiliary object class. I believe this is a better
approach, then the x509certificate object class, being auxiliary, can be
attached to any type of entry that needs the package of attributes that
it defines

David

> 
> I do believe ABSTRACT for the super class of the two STRUCTURAL
> classes, each requiring a different certificate attribute, is
> appropriate here to disallow the super class from being the
> structural object class of an entry.  Now, if someone wanted
> to allow attribute types of this ABSTRACT to be present in
> entries of arbitrary structural classes, then AUXILIARY classes
> could be defined (each hopefully requiring a certificate
> attribute) to support this.
> 
> But, being ABSTRACT, this class cannot be instatiated by
> itself.  That is, an ABSTRACT class can only be instatiated
> as a side-effect of instatiation of a (direct or in-direct)
> non-ABSTRACT subclass of this class.
> 
> Kurt

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------08474BDBE3CF7704E4508DDF
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------08474BDBE3CF7704E4508DDF--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAEMC4A07096 for ietf-pkix-bks; Thu, 14 Nov 2002 14:12:04 -0800 (PST)
Received: from junker.stroeder.com (krl9-d9bb4d9d.pool.mediaWays.net [217.187.77.157]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAEMC1g07092 for <[e-mail]>; Thu, 14 Nov 2002 14:12:02 -0800 (PST)
Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 401D71573CC; Thu, 14 Nov 2002 23:11:54 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 14 Nov 2002 23:11:54 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: David Chadwick <[e-mail]>
Cc: "Kurt D. Zeilenga" <[e-mail]>, [e-mail]
Subject: Re: subschemaSubentry in PKI/PMI LDAP schema I-Ds
References: <5.1.0.14.0.20021112192514.034e91d0@127.0.0.1> <[e-mail]>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David Chadwick wrote:
> For this reason I suggest that the subschemaSubentry
> attribute in the root DSE be made multivalued,

-1

It will cause nothing than grief!

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAELxnu06732 for ietf-pkix-bks; Thu, 14 Nov 2002 13:59:49 -0800 (PST)
Received: from iapetus.salford.ac.uk (iapetus.salford.ac.uk [146.87.255.98]) by above.proper.com (8.11.6/8.11.3) with SMTP id gAELxlg06728 for <[e-mail]>; Thu, 14 Nov 2002 13:59:47 -0800 (PST)
Received: (qmail 74530 invoked by alias); 14 Nov 2002 21:59:47 -0000
Received: (qmail 74484 invoked from network); 14 Nov 2002 21:59:47 -0000
Received: from unknown (HELO salford.ac.uk) (146.87.80.124) by iapetus.salford.ac.uk with SMTP; 14 Nov 2002 21:59:47 -0000
Message-ID: <[e-mail]>
Date: Thu, 14 Nov 2002 22:04:28 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Gietz <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, [e-mail], Norbert Klasen <[e-mail]>, Steven Legg <[e-mail]>
Subject: Re: new version of draft on additional x509 certificate schema  forLDAP
References: <[e-mail]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------6100C436AD616E60439D8F29"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------6100C436AD616E60439D8F29
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Peter Gietz wrote:

> As to sn vs x509SerialNumber:
> 
> serialNumber was defined in X.520 and RFC 2256 as:
> 
> "This attribute contains the serial number of a device."
> 
> It thus was rather meant for hardware than for software. But it seems that it is now quite regulary
> used in the pkix context. My question is
> 1.) should both attributes exist in parallel,
> 2.) or should I rather exchange x509SerialNumber with the RFC 2256 attribute serialNumber
>     (in analogy of the attribute mail taken from RFC 2798.
> 3.) or should we try to standardize the sole use of x509serialNumber

Peter

We need two serial number attributes and both should exist in parallel.

The X.520 serialNumber attribute is used to form a multi-valued RDN, in
case you have more than one person with the same CN ie, to ensure
uniqueness of DNs. This has a printable string format.

The certificate serial number issued by the CA and placed in the
certificate, needs to have a new attribute, and you have defined this as
x509SerialNumber. It is an integer.

To answer some of your other questions

- can and should this draft be work of the pkix group and should the
discussion about it be held on this list instead of in private email
communications?

Yes

- the draft introduces new naming attributes that should be included
into David's Draft "LDAPv3 DN strings for use with PKIs" 
<draft-ietf-pkix-dnstrings-00.txt>. Besides x509issuer and
x509serialNumber the allready widely used attribute emailaddress (email)
should be taken into account.

All 3 have been added to the revised ID, which I will issue in time for
the next IETF meeting (sorry I cant make Atlanta)

- the draft does not yet address the problem that there are "LDAPish"
implementations that are not able to support multi-valueelds RDNs (e.g. 
x509serialNumber=1234+x509issuer=<dn of a CA>). Shall this be addressed
by including a third name form with yet another naming attribute
x509issuerSerial?

This is my preferred solution, since serial number on its own is not
unique. I have added x509issuerSerial to the dnstrings ID in
anticipation.


- The draft does only describe fields described in RFC 3280. Should it
also deal with Qualified certificates (RFC 3039)?

Yes please


- Should it also take into account things like Permanent Identifier
(draft-ietf-pkix-pi-05.txt and draft-chadwick-pkix-pidn-00.txt)?

Yes please

- should revocation information be stored in a similiar fashion. 

Yes, we are already implementing this and writing a schema for it.

And if so how: 1.) Metadata attributes for CRLs or 2.) revocation
relevant attributes attached to the certificate entries.

We are implementing 1.)

- should attribute certificates be stored in a similiar fashion

Yes, and we are writing schema for this as well.

regards

David

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------6100C436AD616E60439D8F29
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------6100C436AD616E60439D8F29--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAELuDu06674 for ietf-pkix-bks; Thu, 14 Nov 2002 13:56:13 -0800 (PST)
Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAELuAg06668 for <[e-mail]>; Thu, 14 Nov 2002 13:56:11 -0800 (PST)
Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id F423D1AA8; Thu, 14 Nov 2002 15:56:07 -0600 (CST)
Received: from cceexc19.americas.cpqcorp.net ([16.110.250.85]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Nov 2002 15:56:07 -0600
Received: from gentoo ([16.100.241.118]) by cceexc19.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Nov 2002 15:56:02 -0600
Content-Type: text/plain; charset="iso-8859-1"
From: Chris Davenport <[e-mail]>
Organization: HP
To: "Kurt D. Zeilenga" <[e-mail]>, David Chadwick <[e-mail]>
Subject: Re: subschemaSubentry in PKI/PMI LDAP schema I-Ds
Date: Thu, 14 Nov 2002 15:55:28 -0600
User-Agent: KMail/1.4.3
Cc: [e-mail]
References: <5.1.0.14.0.20021112192514.034e91d0@127.0.0.1> <5.1.0.14.0.20021114124956.035fd5d8@127.0.0.1>
In-Reply-To: <5.1.0.14.0.20021114124956.035fd5d8@127.0.0.1>
MIME-Version: 1.0
Message-Id: <[e-mail]>
X-OriginalArrivalTime: 14 Nov 2002 21:56:02.0845 (UTC) FILETIME=[9FDD34D0:01C28C28]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gAELuBg06669
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The client could easily restrict its search to only those objects whose 
subschemaSubentry value matched one of the values listed in the root DSE that 
support the matching rules.

	Chris Davenport
	Directory & Security Engineer
	ISS Hewlett-Packard Corp.

On Thursday 14 November 2002 03:04 pm, Kurt D. Zeilenga wrote:
> At 12:50 PM 2002-11-14, David Chadwick wrote:
> >Kurt
> >
> >your point is noted. However it does not work. Since the client is
> >wanting to search the directory for particular PKI attributes, it does
> >not necessarily know the entry that they are contained in.
>
> To issue this search, the client must have a baseObject.  It should
> look at the subschemaSubentry attribute in this baseObject.
>
> >Therefore it
> >cannot read the entry to find its subschema subentry before the entry
> >has been found.
>
> While certainly entries subordinate to the baseObject may be
> controlled by a different subschema, at least the client nows
> the filter is valid at the baseObject.
>
> >For this reason I suggest that the subschemaSubentry
> >attribute in the root DSE be made multivalued, so that the client can
> >find out if the matching rules are supported prior to it issuing the
> >extensible Search.
>
> Assume that a server listed two subschemaSubentry values in the
> root DSE, one listing this matching rule use and one not.  How
> does the client determine which subschema controls the entry
> referenced by baseObject of its extensible search?
>
> Without reading the baseObject's subschemaSubentry, it cannot
> reliably determine which subschema applies.
>
> Personally, I think the client should just issue the operation
> without discovery...  worse case the assertion is Undefined.
>
> Kurt
>
> >David
> >
> >"Kurt D. Zeilenga" wrote:
> >> Both the PKI and PMI LDAP Schema I-Ds contain a similar
> >> worded section called "Subschema Publishing LDAPv3". Both
> >> imply that a server has one and only one subschema subentry
> >> and that this subentry is discoverable by reading the
> >> subschemaSubentry attribute held in the Root DSE.
> >>
> >> The X.500 model, as used in LDAP, clearly allows multiple
> >> subschema subentries to be present, each controlling a subtree
> >> of entries.  In fact, each entry held by the server could
> >> be controlled a different subschema subentry as indicated
> >> by the entry's subschemaSubentry attribute.
> >>
> >> It is noted that RFC 2251 has a bug regarding the root DSE's
> >> subschemaSubentry attribute.  To avoid this bug, PKI/PMI
> >> specification should clearly state that the schema controlling
> >> a particular entry is to be discovered by reading that entry's
> >> subschemaSubentry's attribute. (Just as one would in X.500).
> >>
> >> Kurt
> >
> >--
> >*****************************************************************
> >
> >David W. Chadwick, BSc PhD
> >Professor of Information Systems Security
> >IS Institute, University of Salford, Salford M5 4WT
> >Tel: [phone]  Fax [phone]
> >Mobile: [phone]
> >Email: [e-mail]
> >Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> >Research Projects: http://sec.isi.salford.ac.uk
> >Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> >X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> >Entrust key validation string: MLJ9-DU5T-HV8J
> >PGP Key ID is 0xBC238DE5
> >
> >*****************************************************************



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAELcIr05969 for ietf-pkix-bks; Thu, 14 Nov 2002 13:38:18 -0800 (PST)
Received: from pan.salford.ac.uk (pan.salford.ac.uk [146.87.255.104]) by above.proper.com (8.11.6/8.11.3) with SMTP id gAELcGg05960 for <[e-mail]>; Thu, 14 Nov 2002 13:38:16 -0800 (PST)
Received: (qmail 55791 invoked by alias); 14 Nov 2002 21:38:17 -0000
Received: (qmail 55777 invoked from network); 14 Nov 2002 21:38:17 -0000
Received: from unknown (HELO salford.ac.uk) (146.87.80.124) by pan.salford.ac.uk with SMTP; 14 Nov 2002 21:38:17 -0000
Message-ID: <[e-mail]>
Date: Thu, 14 Nov 2002 21:42:59 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
CC: [e-mail]
Subject: Re: subschemaSubentry in PKI/PMI LDAP schema I-Ds
References: <5.1.0.14.0.20021112192514.034e91d0@127.0.0.1> <5.1.0.14.0.20021114124956.035fd5d8@127.0.0.1>
Content-Type: multipart/mixed; boundary="------------65E9B54325BA9279C440790B"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------65E9B54325BA9279C440790B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



"Kurt D. Zeilenga" wrote:
> 
> At 12:50 PM 2002-11-14, David Chadwick wrote:
> >Kurt
> >
> >your point is noted. However it does not work. Since the client is
> >wanting to search the directory for particular PKI attributes, it does
> >not necessarily know the entry that they are contained in.
> 
> To issue this search, the client must have a baseObject.  It should
> look at the subschemaSubentry attribute in this baseObject.

Agreed. I will change the next version to say "look in the baseObject"

David


> 
> >Therefore it
> >cannot read the entry to find its subschema subentry before the entry
> >has been found.
> 
> While certainly entries subordinate to the baseObject may be
> controlled by a different subschema, at least the client nows
> the filter is valid at the baseObject.
> 
> >For this reason I suggest that the subschemaSubentry
> >attribute in the root DSE be made multivalued, so that the client can
> >find out if the matching rules are supported prior to it issuing the
> >extensible Search.
> 
> Assume that a server listed two subschemaSubentry values in the
> root DSE, one listing this matching rule use and one not.  How
> does the client determine which subschema controls the entry
> referenced by baseObject of its extensible search?
> 
> Without reading the baseObject's subschemaSubentry, it cannot
> reliably determine which subschema applies.
> 
> Personally, I think the client should just issue the operation
> without discovery...  worse case the assertion is Undefined.
> 
> Kurt
> 
> >David
> >
> >
> >"Kurt D. Zeilenga" wrote:
> >>
> >> Both the PKI and PMI LDAP Schema I-Ds contain a similar
> >> worded section called "Subschema Publishing LDAPv3". Both
> >> imply that a server has one and only one subschema subentry
> >> and that this subentry is discoverable by reading the
> >> subschemaSubentry attribute held in the Root DSE.
> >>
> >> The X.500 model, as used in LDAP, clearly allows multiple
> >> subschema subentries to be present, each controlling a subtree
> >> of entries.  In fact, each entry held by the server could
> >> be controlled a different subschema subentry as indicated
> >> by the entry's subschemaSubentry attribute.
> >>
> >> It is noted that RFC 2251 has a bug regarding the root DSE's
> >> subschemaSubentry attribute.  To avoid this bug, PKI/PMI
> >> specification should clearly state that the schema controlling
> >> a particular entry is to be discovered by reading that entry's
> >> subschemaSubentry's attribute. (Just as one would in X.500).
> >>
> >> Kurt
> >
> >--
> >*****************************************************************
> >
> >David W. Chadwick, BSc PhD
> >Professor of Information Systems Security
> >IS Institute, University of Salford, Salford M5 4WT
> >Tel: [phone]  Fax [phone]
> >Mobile: [phone]
> >Email: [e-mail]
> >Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> >Research Projects: http://sec.isi.salford.ac.uk
> >Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> >X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> >Entrust key validation string: MLJ9-DU5T-HV8J
> >PGP Key ID is 0xBC238DE5
> >
> >*****************************************************************

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------65E9B54325BA9279C440790B
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------65E9B54325BA9279C440790B--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAELWbJ04878 for ietf-pkix-bks; Thu, 14 Nov 2002 13:32:37 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAELWYg04872 for <[e-mail]>; Thu, 14 Nov 2002 13:32:34 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gAELWVF3061208; Thu, 14 Nov 2002 21:32:31 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021114130625.02965568@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 14 Nov 2002 13:31:57 -0800
To: David Chadwick <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: new version of draft on additional x509 certificate schemafor LDAP
Cc: Peter Gietz <[e-mail]>, Ietf-Pkix <[e-mail]>
In-Reply-To: <[e-mail]>
References: <5.1.0.14.0.20021108070500.03498818@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:57 PM 2002-11-14, David Chadwick wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>> At 02:47 AM 2002-11-08, Peter Gietz wrote:
>> >I am not yet sure, why Kurt proposes an ABSRACT object class for x509certificate instead of a STRUCTURAL derived from top.
>> 
>> To prevent instantiation without a certificate.
>
>then it should be an AUXILIARY object class

Then it's subclasses could not be STRUCTURAL.

I do believe ABSTRACT for the super class of the two STRUCTURAL
classes, each requiring a different certificate attribute, is
appropriate here to disallow the super class from being the
structural object class of an entry.  Now, if someone wanted
to allow attribute types of this ABSTRACT to be present in
entries of arbitrary structural classes, then AUXILIARY classes
could be defined (each hopefully requiring a certificate
attribute) to support this.

But, being ABSTRACT, this class cannot be instatiated by
itself.  That is, an ABSTRACT class can only be instatiated
as a side-effect of instatiation of a (direct or in-direct)
non-ABSTRACT subclass of this class.

Kurt



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAEL4iC02681 for ietf-pkix-bks; Thu, 14 Nov 2002 13:04:44 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAEL4fg02676 for <[e-mail]>; Thu, 14 Nov 2002 13:04:41 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gAEL4gF3061050; Thu, 14 Nov 2002 21:04:42 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021114124956.035fd5d8@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 14 Nov 2002 13:04:08 -0800
To: David Chadwick <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: subschemaSubentry in PKI/PMI LDAP schema I-Ds
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <5.1.0.14.0.20021112192514.034e91d0@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:50 PM 2002-11-14, David Chadwick wrote:
>Kurt
>
>your point is noted. However it does not work. Since the client is
>wanting to search the directory for particular PKI attributes, it does
>not necessarily know the entry that they are contained in.

To issue this search, the client must have a baseObject.  It should
look at the subschemaSubentry attribute in this baseObject.

>Therefore it
>cannot read the entry to find its subschema subentry before the entry
>has been found.

While certainly entries subordinate to the baseObject may be
controlled by a different subschema, at least the client nows
the filter is valid at the baseObject.

>For this reason I suggest that the subschemaSubentry
>attribute in the root DSE be made multivalued, so that the client can
>find out if the matching rules are supported prior to it issuing the
>extensible Search.

Assume that a server listed two subschemaSubentry values in the
root DSE, one listing this matching rule use and one not.  How
does the client determine which subschema controls the entry
referenced by baseObject of its extensible search?

Without reading the baseObject's subschemaSubentry, it cannot
reliably determine which subschema applies.

Personally, I think the client should just issue the operation
without discovery...  worse case the assertion is Undefined.

Kurt


>David
>
>
>"Kurt D. Zeilenga" wrote:
>> 
>> Both the PKI and PMI LDAP Schema I-Ds contain a similar
>> worded section called "Subschema Publishing LDAPv3". Both
>> imply that a server has one and only one subschema subentry
>> and that this subentry is discoverable by reading the
>> subschemaSubentry attribute held in the Root DSE.
>> 
>> The X.500 model, as used in LDAP, clearly allows multiple
>> subschema subentries to be present, each controlling a subtree
>> of entries.  In fact, each entry held by the server could
>> be controlled a different subschema subentry as indicated
>> by the entry's subschemaSubentry attribute.
>> 
>> It is noted that RFC 2251 has a bug regarding the root DSE's
>> subschemaSubentry attribute.  To avoid this bug, PKI/PMI
>> specification should clearly state that the schema controlling
>> a particular entry is to be discovered by reading that entry's
>> subschemaSubentry's attribute. (Just as one would in X.500).
>> 
>> Kurt
>
>-- 
>*****************************************************************
>
>David W. Chadwick, BSc PhD
>Professor of Information Systems Security
>IS Institute, University of Salford, Salford M5 4WT
>Tel: [phone]  Fax [phone]
>Mobile: [phone]
>Email: [e-mail]
>Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
>Research Projects: http://sec.isi.salford.ac.uk
>Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
>X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
>Entrust key validation string: MLJ9-DU5T-HV8J
>PGP Key ID is 0xBC238DE5
>
>*****************************************************************



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAEKqjN02333 for ietf-pkix-bks; Thu, 14 Nov 2002 12:52:45 -0800 (PST)
Received: from iapetus.salford.ac.uk (iapetus.salford.ac.uk [146.87.255.98]) by above.proper.com (8.11.6/8.11.3) with SMTP id gAEKqhg02328 for <[e-mail]>; Thu, 14 Nov 2002 12:52:43 -0800 (PST)
Received: (qmail 34614 invoked by alias); 14 Nov 2002 20:52:44 -0000
Received: (qmail 34580 invoked from network); 14 Nov 2002 20:52:43 -0000
Received: from unknown (HELO salford.ac.uk) (146.87.80.124) by iapetus.salford.ac.uk with SMTP; 14 Nov 2002 20:52:43 -0000
Message-ID: <[e-mail]>
Date: Thu, 14 Nov 2002 20:57:25 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
CC: Peter Gietz <[e-mail]>, Ietf-Pkix <[e-mail]>
Subject: Re: new version of draft on additional x509 certificate schemafor LDAP
References: <5.1.0.14.0.20021108070500.03498818@127.0.0.1>
Content-Type: multipart/mixed; boundary="------------DF22672FB05775BF905D0CDE"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------DF22672FB05775BF905D0CDE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



"Kurt D. Zeilenga" wrote:
> 
> At 02:47 AM 2002-11-08, Peter Gietz wrote:
> >I am not yet sure, why Kurt proposes an ABSRACT object class for x509certificate instead of a STRUCTURAL derived from top.
> 
> To prevent instantiation without a certificate.

then it should be an AUXILIARY object class

David

> 
> Kurt

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------DF22672FB05775BF905D0CDE
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------DF22672FB05775BF905D0CDE--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAEKkPr02212 for ietf-pkix-bks; Thu, 14 Nov 2002 12:46:25 -0800 (PST)
Received: from iapetus.salford.ac.uk (iapetus.salford.ac.uk [146.87.255.98]) by above.proper.com (8.11.6/8.11.3) with SMTP id gAEKkNg02208 for <[e-mail]>; Thu, 14 Nov 2002 12:46:23 -0800 (PST)
Received: (qmail 22672 invoked by alias); 14 Nov 2002 20:46:17 -0000
Received: (qmail 22647 invoked from network); 14 Nov 2002 20:46:17 -0000
Received: from unknown (HELO salford.ac.uk) (146.87.80.124) by iapetus.salford.ac.uk with SMTP; 14 Nov 2002 20:46:17 -0000
Message-ID: <[e-mail]>
Date: Thu, 14 Nov 2002 20:50:59 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
CC: [e-mail]
Subject: Re: subschemaSubentry in PKI/PMI LDAP schema I-Ds
References: <5.1.0.14.0.20021112192514.034e91d0@127.0.0.1>
Content-Type: multipart/mixed; boundary="------------4AA390F5459B1C4408A9D9C7"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------4AA390F5459B1C4408A9D9C7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Kurt

your point is noted. However it does not work. Since the client is
wanting to search the directory for particular PKI attributes, it does
not necessarily know the entry that they are contained in. Therefore it
cannot read the entry to find its subschema subentry before the entry
has been found. For this reason I suggest that the subschemaSubentry
attribute in the root DSE be made multivalued, so that the client can
find out if the matching rules are supported prior to it issuing the
extensible Search.

David


"Kurt D. Zeilenga" wrote:
> 
> Both the PKI and PMI LDAP Schema I-Ds contain a similar
> worded section called "Subschema Publishing LDAPv3". Both
> imply that a server has one and only one subschema subentry
> and that this subentry is discoverable by reading the
> subschemaSubentry attribute held in the Root DSE.
> 
> The X.500 model, as used in LDAP, clearly allows multiple
> subschema subentries to be present, each controlling a subtree
> of entries.  In fact, each entry held by the server could
> be controlled a different subschema subentry as indicated
> by the entry's subschemaSubentry attribute.
> 
> It is noted that RFC 2251 has a bug regarding the root DSE's
> subschemaSubentry attribute.  To avoid this bug, PKI/PMI
> specification should clearly state that the schema controlling
> a particular entry is to be discovered by reading that entry's
> subschemaSubentry's attribute. (Just as one would in X.500).
> 
> Kurt

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------4AA390F5459B1C4408A9D9C7
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------4AA390F5459B1C4408A9D9C7--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAEHWvn18816 for ietf-pkix-bks; Thu, 14 Nov 2002 09:32:57 -0800 (PST)
Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by above.proper.com (8.11.6/8.11.3) with SMTP id gAEHWsg18808 for <[e-mail]>; Thu, 14 Nov 2002 09:32:54 -0800 (PST)
Received: (qmail 26260 invoked from network); 14 Nov 2002 17:22:56 -0000
Received: from unknown (HELO multicert.com) (62.48.185.5) by mail0.sibs.pt with SMTP; 14 Nov 2002 17:22:56 -0000
Message-ID: <[e-mail]>
Date: Thu, 14 Nov 2002 17:33:22 +0000
From: Ricardo Barroso <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Christine Karman <[e-mail]>
CC: [e-mail]
Subject: Re: signed e-mail
References: <[e-mail]> <4.3.2.7.2.20021114120831.02abc5c0@localhost>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060709000204050103060405"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms060709000204050103060405
Content-Type: multipart/alternative;
 boundary="------------040909090602010405040303"


--------------040909090602010405040303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi people!

I also have made before several times to my self the Rob's question...
And I agree with Christine, I think that the people who is able to use 
signed e-mails (sorry, Stephen!) should do that
even that some people don't trust in the root CA you can at least try to 
prevent mail spoofing/impersonation.
Although we've not millions of EUR/$/£/... involved in this mailing-list 
"transactions" it can at least demonstrate, test
and even motivate other people to use digital certificates to sign their 
own e-mails.

Regards,
Ricardo Barroso

PS: 1) For the distracted people, if your e-mail client supports you can 
see that this e-mail is signed...
       2) Stephen, you can still read this mail though your browser 
doesn't support digital signatures, don't you?

MULTICERT S.A.
www.multicert.com <http://www.multicert.com>


Christine Karman wrote:

> At 04:12 PM 11/11/2002, you wrote:
>
>> Rob G Weemhoff wrote:
>> >
>> > To start with, why are we, as security advocates, not all using signed
>> > e-mail?
>>
>> Because signing the e-mail on this list does not make much sense...?
>
>
> It does. It would prevent people from spoofing, posing as someone who 
> has contributed before. In e-mail, trust is built up in the course of 
> time, not by the commercial company that issued your certificate.
>
> dagdag
> Christine
>
>> Or what does your certificate really mean? Or mine? Both are
>> validated against "trusted" root CA certs in our browsers but that's
>> all.
>>
>> But you're somewhat right. In most PKI projects I couldn't use
>> S/MIME e-mail while most project members had S/MIME capable MUAs...
>>
>> Ciao, Michael.
>>
>>
>> Subject Name: E=[e-mail], CN=Michael Stroeder, G=Michael, 
>> SN=Stroeder; Valid: False; ThumbPrint: 
>> 7FCFD6A4C4C52CC35434B2EC4C3F5B2E99C53123. Click Here 
>> <http://localhost/certificates/7FCFD6A4C4C52CC35434B2EC4C3F5B2E99C53123> 
>> for more certificate info 
>


--------------040909090602010405040303
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Hi people! <br>
<br>
I also have made before several times to my self the Rob's question...<br>
And I agree with Christine, I think that the people who is able to use signed
e-mails (sorry, Stephen!) should do that <br>
even that some people don't trust in the root CA you can at least try to
prevent mail spoofing/impersonation.<br>
Although we've not millions of &#8364;/$/&pound;/... involved in this mailing-list "transactions"
it can at least demonstrate, test <br>
and even motivate other people to use digital certificates to sign their
own e-mails.<br>
<br>
Regards,<br>
Ricardo Barroso<br>
<br>
PS: 1) For the distracted people, if your e-mail client supports you can
see that this e-mail is signed...<br>
&nbsp; &nbsp; &nbsp; &nbsp;2) Stephen, you can still read this mail though your browser doesn't
support digital signatures, don't you?<font size="2"><font
 color="#000000"><font face="Arial"><font size="20"><font
 color="#b91a1a"><font size="2"><font size="20"><font size="2"><font
 color="#000000"></font></font></font></font></font></font></font></font></font><br>
<br>
MULTICERT S.A.<br>
<a href="http://www.multicert.com">www.multicert.com</a><br>
<br>
<br>
Christine Karman wrote:<br>
<blockquote type="cite"
 cite="mid4.3.2.7.2.20021114120831.02abc5c0@localhost"> At 04:12 PM 11/11/2002,
you wrote:<br>
 
  <blockquote type="cite" cite="">Rob G Weemhoff wrote:<br>
 &gt;<br>
 &gt; To start with, why are we, as security advocates, not all using signed<br>
 &gt; e-mail?<br>
 <br>
 Because signing the e-mail on this list does not make much sense...?</blockquote>
  <br>
 It does. It would prevent people from spoofing, posing as someone who has 
contributed before. In e-mail, trust is built up in the course of time, not
by the commercial company that issued your certificate.<br>
 <br>
 dagdag<br>
 Christine<br>
 <br>
 
  <blockquote type="cite" cite="">Or what does your certificate really mean?
Or mine? Both are<br>
 validated against "trusted" root CA certs in our browsers but that's<br>
 all.<br>
 <br>
 But you're somewhat right. In most PKI projects I couldn't use<br>
 S/MIME e-mail while most project members had S/MIME capable MUAs...<br>
 <br>
 Ciao, Michael.<br>
 <br>
 <br>
 Subject Name: <a class="moz-txt-link-abbreviated" href="mailto:E=[e-mail]">E=[e-mail]</a>, CN=Michael Stroeder, G=Michael, SN=Stroeder;
Valid: False; ThumbPrint: 7FCFD6A4C4C52CC35434B2EC4C3F5B2E99C53123. Click 
    <a
 href="http://localhost/certificates/7FCFD6A4C4C52CC35434B2EC4C3F5B2E99C53123">Here</a> 
for more certificate info </blockquote>
</blockquote>
<br>
</body>
</html>

--------------040909090602010405040303--

--------------ms060709000204050103060405
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINIzCC
A+0wggNWoAMCAQICBAIAAn8wDQYJKoZIhvcNAQEFBQAwRTELMAkGA1UEBhMCVVMxGDAWBgNV
BAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1c3QgUm9vdDAeFw0w
MjA1MTcxNDI2MDBaFw0wNjAyMjMyMzU5MDBaMEQxCzAJBgNVBAYTAnB0MRgwFgYDVQQKEw9N
VUxUSUNFUlQtVGVzdGUxGzAZBgNVBAMTEk1VTFRJQ0VSVC1UZXN0ZSAwMTCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAM8mQgWxYF+MZy4P0GWhiVuY9kfqNNQRbAzu+vLblw4P
4GJJ02jRBcYNOTZGkUzGv4U+8fqyu2BzpLMGTren9362yZC/AypKxyghATaV/sIrVx4v6hJ0
aaXnqEQiqXnb8rGFDSvrL3uPuJGhABkBLbn3INGsErvEoUlrnRwWBqGD1NTgZJc5Qc+8gSOk
bUZhlGds6InxOI0chcfUCKsqjfOy41hV84vZOakrrNzkIxAyEliN+lmk1PnD1DDBXnvgKZ3x
v4GpxK2S1wWnb34kSRQ6squ4P6AOqp9br0UWetjgb7ALv/IN8ip6qezPSpQoXxzltR4va2zH
ax5gGWg49iUCAwEAAaOCAWUwggFhMEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly93d3cucHVi
bGljLXRydXN0LmNvbS9jZ2ktYmluL0NSTC8yMDA2L2NkcC5jcmwwHQYDVR0OBBYEFPao/xeF
UUGJiyl+/jV0nCb7A9llMFQGA1UdIARNMEswSQYKKoZIhvhjAQIBBTA7MDkGCCsGAQUFBwIB
Fi1odHRwOi8vd3d3LnB1YmxpYy10cnVzdC5jb20vQ1BTL09tbmlSb290Lmh0bWwwWAYDVR0j
BFEwT6FJpEcwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoG
A1UEAxMTR1RFIEN5YmVyVHJ1c3QgUm9vdIICAaMwKwYDVR0QBCQwIoAPMjAwMjA1MTcxNDI2
MjhagQ8yMDAzMDUxNzIzNTkwMFowDgYDVR0PAQH/BAQDAgEGMAwGA1UdEwQFMAMBAf8wDQYJ
KoZIhvcNAQEFBQADgYEAiTgHy2R6jY5bVzFjBZf2V0hR5H/2k+hDXBItkXhs71O8peHI5Yar
ngTvkexrpxk/fMM63UrrnEMPczsCbEHr0oncHNuof9VcxEqnlXnEcE0mH5lLQ1D1KjSI3Za9
K8hI9PNL2Dmys51ayqcXwTIMrMpF8t2PBVnyDrR5qpeEPMcwggSVMIIDfaADAgECAgQ8lgFD
MA0GCSqGSIb3DQEBBQUAMEQxCzAJBgNVBAYTAnB0MRgwFgYDVQQKEw9NVUxUSUNFUlQtVGVz
dGUxGzAZBgNVBAMTEk1VTFRJQ0VSVC1UZXN0ZSAwMTAeFw0wMjEwMTExNDUwMTFaFw0wMjEy
MTIwMDAwMDBaMIGmMQswCQYDVQQGEwJQVDEYMBYGA1UEChMPTVVMVElDRVJULVRlc3RlMRcw
FQYDVQQLEw5NVUxUSUNFUlQgLSBSQTESMBAGA1UECxMJQ29ycG9yYXRlMRIwEAYDVQQLEwlN
VUxUSUNFUlQxFDASBgNVBAsTC1BlcnNvbmFsIElEMSYwJAYDVQQDEx1SaWNhcmRvIEZpbGlw
ZSBQYXJkYWwgQmFycm9zbzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA5tio6v03k35B
3DFL/Z6oyD7Xlr/+rmEmMxWUEUZZxYKVZEEWxrhMQtK5GbPcUY4LJXfjlgiJeygIYtwuOwv+
ZNVMesM0C2zNLq/gDlzzxVCTeBYq1yiv5mIxkuEuOTsnL3IEaN/s9CxBDHoQkcLcs9Z2Jpea
XI15qP7HSCChUFkCAwEAAaOCAa4wggGqMAsGA1UdDwQEAwID+DA4BggrBgEFBQcBAQQsMCow
KAYIKwYBBQUHMAEWHGh0dHA6Ly9PQ1NQLk1VTFRJQ0VSVC5DT00vQ0EwgdgGA1UdIASB0DCB
zTBNBgkrBgEEAbA8CgIwQDA+BggrBgEFBQcCARYyaHR0cDovL1dXVy5NVUxUSUNFUlQuQ09N
L0NQUy9NVUxUSUNFUlQtQ0EtQ1BTLmh0bWwwfAYKKwYBBAGwPAoCBDBuMGwGCCsGAQUFBwIC
MGAeXgBoAHQAdABwADoALwAvAFcAVwBXAC4ATQBVAEwAVABJAEMARQBSAFQALgBDAE8ATQAv
AEMAUAAvAE0AVQBMAFQASQBDAEUAUgBUAC0AQwBBAC0ANAAuAGgAdABtAGwwEQYJYIZIAYb4
QgEBBAQDAgWgMCgGA1UdEQQhMB+BHXJpY2FyZG8uYmFycm9zb0BtdWx0aWNlcnQuY29tMB8G
A1UdIwQYMBaAFPao/xeFUUGJiyl+/jV0nCb7A9llMB0GA1UdDgQWBBQpfAB7VJckbVS9pBkG
wDTXR8u56TAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUAA4IBAQBLiMdQTq5/mIyw0/Qhw411
BEb0KHsE5XRwcGWwlPaeL2vVsEftVAXnSBLD2Kgd0Y89UJc5+7psm5JsOpi5vBGUtOd8ZFgp
QOEO5Z73cCp1PIKVWjKaMBxBSpzOZkq70Ag+kDdwY41kA3NSkYq3ebl6f9k3Gx7bex3jgKcS
bBN5MEC1XvN1415BgTQLeqF9tQOzRLSuSj2CMqLuZbHmPyuJbr9K7holHwoY5e6aHFpPKdF8
lu9n3U8QZu1u7XulkPPq0IyZXqMsO7uaLuWEg7Mwfrxh7LG0KoIx8ihcQ1Osz/3HztrD2XZ2
plEmIaVJMUpiB4fF72V6gf2K4SaUBxiOMIIElTCCA32gAwIBAgIEPJYBQzANBgkqhkiG9w0B
AQUFADBEMQswCQYDVQQGEwJwdDEYMBYGA1UEChMPTVVMVElDRVJULVRlc3RlMRswGQYDVQQD
ExJNVUxUSUNFUlQtVGVzdGUgMDEwHhcNMDIxMDExMTQ1MDExWhcNMDIxMjEyMDAwMDAwWjCB
pjELMAkGA1UEBhMCUFQxGDAWBgNVBAoTD01VTFRJQ0VSVC1UZXN0ZTEXMBUGA1UECxMOTVVM
VElDRVJUIC0gUkExEjAQBgNVBAsTCUNvcnBvcmF0ZTESMBAGA1UECxMJTVVMVElDRVJUMRQw
EgYDVQQLEwtQZXJzb25hbCBJRDEmMCQGA1UEAxMdUmljYXJkbyBGaWxpcGUgUGFyZGFsIEJh
cnJvc28wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAObYqOr9N5N+QdwxS/2eqMg+15a/
/q5hJjMVlBFGWcWClWRBFsa4TELSuRmz3FGOCyV345YIiXsoCGLcLjsL/mTVTHrDNAtszS6v
4A5c88VQk3gWKtcor+ZiMZLhLjk7Jy9yBGjf7PQsQQx6EJHC3LPWdiaXmlyNeaj+x0ggoVBZ
AgMBAAGjggGuMIIBqjALBgNVHQ8EBAMCA/gwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzAB
FhxodHRwOi8vT0NTUC5NVUxUSUNFUlQuQ09NL0NBMIHYBgNVHSAEgdAwgc0wTQYJKwYBBAGw
PAoCMEAwPgYIKwYBBQUHAgEWMmh0dHA6Ly9XV1cuTVVMVElDRVJULkNPTS9DUFMvTVVMVElD
RVJULUNBLUNQUy5odG1sMHwGCisGAQQBsDwKAgQwbjBsBggrBgEFBQcCAjBgHl4AaAB0AHQA
cAA6AC8ALwBXAFcAVwAuAE0AVQBMAFQASQBDAEUAUgBUAC4AQwBPAE0ALwBDAFAALwBNAFUA
TABUAEkAQwBFAFIAVAAtAEMAQQAtADQALgBoAHQAbQBsMBEGCWCGSAGG+EIBAQQEAwIFoDAo
BgNVHREEITAfgR1yaWNhcmRvLmJhcnJvc29AbXVsdGljZXJ0LmNvbTAfBgNVHSMEGDAWgBT2
qP8XhVFBiYspfv41dJwm+wPZZTAdBgNVHQ4EFgQUKXwAe1SXJG1UvaQZBsA010fLuekwCQYD
VR0TBAIwADANBgkqhkiG9w0BAQUFAAOCAQEAS4jHUE6uf5iMsNP0IcONdQRG9Ch7BOV0cHBl
sJT2ni9r1bBH7VQF50gSw9ioHdGPPVCXOfu6bJuSbDqYubwRlLTnfGRYKUDhDuWe93AqdTyC
lVoymjAcQUqczmZKu9AIPpA3cGONZANzUpGKt3m5en/ZNxse23sd44CnEmwTeTBAtV7zdeNe
QYE0C3qhfbUDs0S0rko9gjKi7mWx5j8riW6/Su4aJR8KGOXumhxaTynRfJbvZ91PEGbtbu17
pZDz6tCMmV6jLDu7mi7lhIOzMH68YeyxtCqCMfIoXENTrM/9x87aw9l2dqZRJiGlSTFKYgeH
xe9leoH9iuEmlAcYjjGCAgYwggICAgEBMEwwRDELMAkGA1UEBhMCcHQxGDAWBgNVBAoTD01V
TFRJQ0VSVC1UZXN0ZTEbMBkGA1UEAxMSTVVMVElDRVJULVRlc3RlIDAxAgQ8lgFDMAkGBSsO
AwIaBQCgggEQMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAy
MTExNDE3MzMyMlowIwYJKoZIhvcNAQkEMRYEFKoCG6EgKHpHdNCIZaUQNShctCbhMFIGCSqG
SIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA
MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMF0GCyqGSIb3DQEJEAILMU6gTDBEMQswCQYDVQQG
EwJwdDEYMBYGA1UEChMPTVVMVElDRVJULVRlc3RlMRswGQYDVQQDExJNVUxUSUNFUlQtVGVz
dGUgMDECBDyWAUMwDQYJKoZIhvcNAQEBBQAEgYCzFz5pBeWUtemXOQWNzI4PCvtpYELNn4Dx
R1QEbCkm5xc316xQzvz3dZFHzeEox7A7h1UpwqmByB+FM2apQkuOomB0r0GfpR9pxb3PKrQH
WJMg9GHqPuyyZK2+9UkHZGrr22qWb2nGd3Nyl29Pfw8PRyr63fZyysnxXpmnpInWqgAAAAAA
AA==
--------------ms060709000204050103060405--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAEFLK511203 for ietf-pkix-bks; Thu, 14 Nov 2002 07:21:20 -0800 (PST)
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAEFLHg11198 for <[e-mail]>; Thu, 14 Nov 2002 07:21:18 -0800 (PST)
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id gAEFLAMP028647; Thu, 14 Nov 2002 07:21:11 -0800
From: "Ambarish Malpani" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>
Subject: RE: PrintableString not usable tigether with OCSP?
Date: Thu, 14 Nov 2002 07:21:40 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

memcmp() would work fine for Kanji. I was addressing the part of
the mail which said that people were hardly using non-ascii
characters.

A

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



> -----Original Message-----
> From: Peter Gutmann [mailto:[e-mail]]
> Sent: Wednesday, November 13, 2002 10:04 PM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: PrintableString not usable tigether with OCSP?
> 
> 
> "Ambarish Malpani" <[e-mail]> writes:
> 
> >While I agree with the overall statement that using memcmp is 
> the best way of
> >checking for DN equality, there are folks that are using 
> non-ascii characters
> >in certs - in particular there are a lot of certs using Kanji in Japan.
> 
> Why would that not work with memcmp()?
> 
> Peter.
> 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAEBBDP20457 for ietf-pkix-bks; Thu, 14 Nov 2002 03:11:13 -0800 (PST)
Received: from izecom.com (cust.10.30.adsl.cistron.nl [62.216.10.30]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAEBBAg20448 for <[e-mail]>; Thu, 14 Nov 2002 03:11:11 -0800 (PST)
Received: from Pengo ([192.168.0.16]) by izecom.com (8.11.6/8.11.6) with SMTP id gAEBB9k25815 for <[e-mail]>; Thu, 14 Nov 2002 12:11:09 +0100
Message-Id: <4.3.2.7.2.20021114120831.02abc5c0@localhost>
X-Sender: chkxs4all@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 14 Nov 2002 12:11:15 +0100
To: [e-mail]
From: Christine Karman <[e-mail]>
Subject: Re: signed e-mail
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="{3D734EC8-DFB0-4B72-B2E3-CF0C2D428861}"; protocol="application/x-pkcs7-signature"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

--{3D734EC8-DFB0-4B72-B2E3-CF0C2D428861}
Content-Type: multipart/alternative; boundary="=====================_155193456==_.ALT"

--=====================_155193456==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 04:12 PM 11/11/2002, you wrote:
>Rob G Weemhoff wrote:
> >
> > To start with, why are we, as security advocates, not all using signed
> > e-mail?
>
>Because signing the e-mail on this list does not make much sense...?

It does. It would prevent people from spoofing, posing as someone who has 
contributed before. In e-mail, trust is built up in the course of time, not 
by the commercial company that issued your certificate.

dagdag
Christine

>Or what does your certificate really mean? Or mine? Both are
>validated against "trusted" root CA certs in our browsers but that's
>all.
>
>But you're somewhat right. In most PKI projects I couldn't use
>S/MIME e-mail while most project members had S/MIME capable MUAs...
>
>Ciao, Michael.
>
>
>Subject Name: E=[e-mail], CN=Michael Stroeder, G=Michael, 
>SN=Stroeder; Valid: False; ThumbPrint: 
>7FCFD6A4C4C52CC35434B2EC4C3F5B2E99C53123. Click 
><http://localhost/certificates/7FCFD6A4C4C52CC35434B2EC4C3F5B2E99C53123>Here 
>for more certificate info

--=====================_155193456==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 04:12 PM 11/11/2002, you wrote:<br>
<blockquote type=cite cite>Rob G Weemhoff wrote:<br>
&gt;<br>
&gt; To start with, why are we, as security advocates, not all using
signed<br>
&gt; e-mail?<br>
<br>
Because signing the e-mail on this list does not make much
sense...?</blockquote><br>
It does. It would prevent people from spoofing, posing as someone who has
contributed before. In e-mail, trust is built up in the course of time,
not by the commercial company that issued your certificate.<br>
<br>
dagdag<br>
Christine<br>
<br>
<blockquote type=cite cite>Or what does your certificate really mean? Or
mine? Both are<br>
validated against &quot;trusted&quot; root CA certs in our browsers but
that's<br>
all.<br>
<br>
But you're somewhat right. In most PKI projects I couldn't use<br>
S/MIME e-mail while most project members had S/MIME capable MUAs...<br>
<br>
Ciao, Michael.<br>
<br>
<br>
Subject Name: E=[e-mail], CN=Michael Stroeder, G=Michael,
SN=Stroeder; Valid: False; ThumbPrint:
7FCFD6A4C4C52CC35434B2EC4C3F5B2E99C53123. Click
<a href="http://localhost/certificates/7FCFD6A4C4C52CC35434B2EC4C3F5B2E99C53123">Here</a>
for more certificate info </blockquote></html>

--=====================_155193456==_.ALT--

--{3D734EC8-DFB0-4B72-B2E3-CF0C2D428861}
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIIWAYJKoZIhvcNAQcCoIIISTCCCEUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3
DQEHAaCCBwswggLvMIIB16ADAgECAgISNjANBgkqhkiG9w0BAQQFADBpMQswCQYD
VQQGEwJOTDESMBAGA1UEBxMJQW1zdGVyZGFtMQ8wDQYDVQQLEwZJWkVDT00xEjAQ
BgNVBAMTCUlaRUNPTSBDQTEhMB8GCSqGSIb3DQEJARYSbWFydGlqbkBpemVjb20u
Y29tMB4XDTAyMTExMTE2MjY0MFoXDTAzMTExMTE2MjY0MFowbDEUMBIGA1UEBhML
TmV0aGVybGFuZHMxEjAQBgNVBAoTCVphcGhvZCBCVjEZMBcGA1UEAxMQQ2hyaXN0
aW5lIEthcm1hbjElMCMGCSqGSIb3DQEJARYWY2hyaXN0aW5lQGNocmlzdGluZS5u
bDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA4inS3EhBcBRac94JMnF9pypN
NJs75QQuZJl6uHWRx6XAdHlsJv5SsMPYW6/ye3nX0V4qadpy6HhNasPNymWx3eFL
dTIQ3Xrac/7vclw054HlRTRub6GQ8OxYu1qEQFoKmehFrDLtUAq+NWL6QsNTJHEh
4FrrR9K1Jp5jAsXPeJUCAwEAAaMiMCAwCQYDVR0TBAIwADATBgNVHSUEDDAKBggr
BgEFBQcDBDANBgkqhkiG9w0BAQQFAAOCAQEAjVGsjgRnA1ufpj3ahMgbBd7Z4FOs
5MqZ+nQZZN16hby7KjnbKqlhD66JSt2cBvfXyu77BGtAt1L36lvLTZAgFi9qNqhI
zhPyEEmbSeZ15AylMukUAysBiS1mjziKt0stl8ZHzUM630IyWjJIce2cgZNhuWmr
NR0crcuh8Gjp4O3xR3bc/8+nfB1hCGlHDrCT/EpWqSm9WICmpjVByTWx08oHgKuM
qncv5eExLKjA6d+r9IgbY7CSPTmTt/0og40L0tU8ciej+DmZNPyLXSxcq8tc7dTd
lun2CeyZA4JKpXC8n9CEXeKtVm0spkBB6ZjXDhJ60hv+jgqnh1vciJ5WKDCCBBQw
ggL8oAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCTkwxEjAQBgNV
BAcTCUFtc3RlcmRhbTEPMA0GA1UECxMGSVpFQ09NMRIwEAYDVQQDEwlJWkVDT00g
Q0ExITAfBgkqhkiG9w0BCQEWEm1hcnRpam5AaXplY29tLmNvbTAeFw0wMjExMTEx
MzMyMjZaFw0wNTExMTAxMzMyMjZaMGkxCzAJBgNVBAYTAk5MMRIwEAYDVQQHEwlB
bXN0ZXJkYW0xDzANBgNVBAsTBklaRUNPTTESMBAGA1UEAxMJSVpFQ09NIENBMSEw
HwYJKoZIhvcNAQkBFhJtYXJ0aWpuQGl6ZWNvbS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDEPScbx2hmmGUcqN8fRb6cG968XLQmUwA3fHELla0p
gHxLs9OeBV7RxFW2mqB8JZ/E0rTIVpBpbil6i/5j9NA+pkZ0g1+k3aSH0w6xDjJy
hCxd4H52uySq1DlZJofXcCoZnBXIfKNPLre0fp8H4dx+14uZGJuYCURJ0FGSSWfm
n4PmLRcXrTRQiuA09bvXYxaty+joPME1r++KZmiw49ePmrZm9aQCMqZB5Lffi6qD
QBzzPu6BdUnqSZL/svWMCUk6qaeTyuMhq+SqRbVmN1RAaIA/Abg1VoMordjrjklh
C8fz5I+2IaC/44Jx6rTmEDxbKlWO81bpuyuaKXPVkkF9AgMBAAGjgcYwgcMwHQYD
VR0OBBYEFMFOVbFBWZAca/2cjE3ph7gSjFyvMIGTBgNVHSMEgYswgYiAFMFOVbFB
WZAca/2cjE3ph7gSjFyvoW2kazBpMQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQW1z
dGVyZGFtMQ8wDQYDVQQLEwZJWkVDT00xEjAQBgNVBAMTCUlaRUNPTSBDQTEhMB8G
CSqGSIb3DQEJARYSbWFydGlqbkBpemVjb20uY29tggEAMAwGA1UdEwQFMAMBAf8w
DQYJKoZIhvcNAQEEBQADggEBAEQiilFjuPQt3+Z8akNppUzxbBrhe2IujrR4Yh7K
+q5ltBMmaxSph+2oB/kuz79jeBQ92n2TaWZ0GbcrBDG9rHPSox08xQSJrHbxQZ+t
Bn4M86HhFsz2x2FKN4IleN4vBRo19UrDFpTmipZxYuAOClCNXtane8y+HisIadbT
jegy4XMq4E8AGy/RM5LrczYIGy0vOM1W96fgEvUzLaC44dMd0DqX66T4FYIPnjiK
CLQIqgsjiMxV5LV4GlW7KLm0sh8sMmf7cX4wojvRDE3mgYIsS2qgv33bKngvAj5m
Gq3cwDC04Qo5CDCNisWrDHdc7RXx/260tQX5S9NJS4ZgyyQxggEVMIIBEQIBATBv
MGkxCzAJBgNVBAYTAk5MMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAsTBkla
RUNPTTESMBAGA1UEAxMJSVpFQ09NIENBMSEwHwYJKoZIhvcNAQkBFhJtYXJ0aWpu
QGl6ZWNvbS5jb20CAhI2MAkGBSsOAwIaBQAwDQYJKoZIhvcNAQEBBQAEgYDOQ5EZ
qwYBTpLWgJK+gal7ygA5hQzfyeu4q6pD9IDUUSgvrAlY/bzrFL8lpa8c4rZvzSNn
RDTA4csqB/ZniftQheqJ0RRJQ3IhB4bzkbTCGzVLJCGo6vP/vebrv3QbHRbzN9jF
ynBUa/1OHyfPRfTr3nFmLDMHAU5sG5MNd/bz7A==

--{3D734EC8-DFB0-4B72-B2E3-CF0C2D428861}--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAE64Es05685 for ietf-pkix-bks; Wed, 13 Nov 2002 22:04:14 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAE64Ag05675 for <[e-mail]>; Wed, 13 Nov 2002 22:04:11 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gAE648wA003473; Thu, 14 Nov 2002 19:04:08 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id TAA156631; Thu, 14 Nov 2002 19:04:07 +1300 (NZDT) (sender [e-mail])
Date: Thu, 14 Nov 2002 19:04:07 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: PrintableString not usable tigether with OCSP?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Ambarish Malpani" <[e-mail]> writes:

>While I agree with the overall statement that using memcmp is the best way of
>checking for DN equality, there are folks that are using non-ascii characters
>in certs - in particular there are a lot of certs using Kanji in Japan.

Why would that not work with memcmp()?

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADHf3M24823 for ietf-pkix-bks; Wed, 13 Nov 2002 09:41:03 -0800 (PST)
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADHf1g24815 for <[e-mail]>; Wed, 13 Nov 2002 09:41:01 -0800 (PST)
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id gADHesMP027891; Wed, 13 Nov 2002 09:40:55 -0800
From: "Ambarish Malpani" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>
Subject: RE: PrintableString not usable tigether with OCSP?
Date: Wed, 13 Nov 2002 09:41:21 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

While I agree with the overall statement that using memcmp is
the best way of checking for DN equality, there are folks that
are using non-ascii characters in certs - in particular there
are a lot of certs using Kanji in Japan.

Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Peter Gutmann
> Sent: Tuesday, November 12, 2002 5:22 PM
> To: [e-mail]
> Subject: Re: PrintableString not usable tigether with OCSP?
>
>
>
> >From a discussion with an Anonymous Person:
>
> -- Snip --
>
> >While tehcnically there's this DN compare algorithm in RFC2459
> or the evil
> >X500 version anyone with any sense ignores it completely and
> normally treats
> >DNs as equal only if they have the same encoding or it will
> break OCSP et al.
> >
> >Have you ever come across "equal" DNs that don't have the same
> encoding? I
> >know I never have.
>
> I doubt I have - I actually implemented all the fancy conversion
> stuff back in
> about 1997, but I doubt it's ever really been tested.  I'm
> currently redoing
> that part of the code, I'm tempted to remove it all and do a
> memcmp() because
> it makes it harder to play tricks with encoding forms to get
> around security
> checks.  For one thing the coding required is so convoluted that its
> complexity alone is likely to be a source of security problems.
>
> >Presyumably you did the lesser evil version rather than the full version
> >which I doubt anyone would want to implement: i.e. the thing
> that can compare
> >Korean T61Strings and BMPStrings.
>
> I'd only bet on it working as far as latin1, however in theory I
> could compare
> widechars to Unicode.  In practice I found (in 1997, it's
> probably better now)
> that mbstowcs() usually only handled latin1, however I suspect
> MultiByteToWideChar() (at least under NT) handles more stuff because MS is
> pretty thorough with i18n.  OTOH I have no idea what sort of stuff would
> appear in a multibyte T61String encoding except it's unlikely to
> be anything
> that any ASN.1 spec defines but just whatever the local charset
> happens to be
> and whatever displays OK in Windows.  OTOH this stuff is barely
> used, at one
> point I wanted to play with some Asian charsets and had to ask someone to
> specially generate a cert for me because no-one normally uses them (if you
> look at something like the Hong Kong Post CPS, it says that if
> your company
> has a non-ASCII-representable name, you'll need to use an ASCII
> one to get a
> cert).  I asked someone else to create a Unicode cyrillic string
> for me for
> testing (that's outside the latin1 range, so I know it'll end up
> Unicode) to
> see if my code will handle it, but since there's no real
> multibyte equivalent
> I can't easily test the string-comparison capability, only the
> basic Unicode-
> handling.
>
> I suspect that if someone did manage to create a synthetic cert chain with
> (say) the issuer in multibyte and subject in Unicode, 100% of
> implementations
> which don't fall back to chaining by keyIDs would fail to
> recognise it as the
> issuer.  That's one guarantee that it's safe to ignore the
> comparison rules
> and use memcmp().
>
> -- Snip --
>
> Peter.
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADEvqp13610 for ietf-pkix-bks; Wed, 13 Nov 2002 06:57:52 -0800 (PST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADEvng13606 for <[e-mail]>; Wed, 13 Nov 2002 06:57:49 -0800 (PST)
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16353; Wed, 13 Nov 2002 07:57:47 -0700 (MST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADEvkig010896; Wed, 13 Nov 2002 09:57:46 -0500 (EST)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.0) with ESMTP id JAA20363; Wed, 13 Nov 2002 09:57:43 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 13 Nov 2002 09:57:06 -0500
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail]
Subject: Re: PrintableString not usable tigether with OCSP?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:
> I suspect that if someone did manage to create a synthetic
> cert chain with (say) the issuer in multibyte and subject
> in Unicode, 100% of implementations which don't fall back
> to chaining by keyIDs would fail to recognise it as the
> issuer. That's one guarantee that it's safe to ignore the
> comparison rules and use memcmp().

The path validation code in Sun's JDK 1.4 implements the
X.500 DN matching algorithm (stripping excess spaces and
doing case-insensitive comparison) for PrintableString and
UTF8String. And we support matching a PrintableString to a
UTF8String. We don't support Teletex (T.61), since this is
not widely used and not recommended for future use.

There are many people and companies whose names cannot be
represented with PrintableString. If we want PKI to be widely
deployed, we need to support UTF8String properly. I look forward
to the advancement of draft-zeilenga-ldapbis-strmatch-01.txt,
which is a stringprep profile for X.500 DN matching. Stringprep
implementations are starting to come out now, which will remove
the need for PKIX folks to be I18N experts.

If you'd like to have some certs that contain subject or
issuer names with UTF8String, let me know. I'd be glad to
send you some.

Thanks,

Steve Hanna
Sun Microsystems, Inc.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gADBVN228302 for ietf-pkix-bks; Wed, 13 Nov 2002 03:31:23 -0800 (PST)
Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gADBVKg28288; Wed, 13 Nov 2002 03:31:20 -0800 (PST)
Received: from mail6.magma.ca (mail6 [206.191.0.248]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id gADBVJe1020857; Wed, 13 Nov 2002 06:31:19 -0500 (EST)
Received: from asturgeonpc (ottawa-dial-64-26-139-73.d-ip.magma.ca [64.26.139.73]) by mail6.magma.ca (Magma's Mail Server) with SMTP id gADBVCRb028611; Wed, 13 Nov 2002 06:31:16 -0500 (EST)
Reply-To: <[e-mail]>
From: "Alice Sturgeon" <[e-mail]>
To: "Fillingham,  David W." <[e-mail]>, "'Paul Hoffman / IMC'" <[e-mail]>, "Jeffrey I. Schiller" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Request for IESG consideration: CP/CPS Framework
Date: Wed, 13 Nov 2002 06:39:27 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I certainly agree with Dave's comment about the widespread use of RFC 2527,
and the necessity of keeping it, and its successor.  The successor document
was developed to address some issues that have arisen over time and with the
use of 2527, to clarify, to amend slightly, to highlight the more important
provisions of 2527, and particularly to group like issues more conveniently
and more intuitively.
As one example of how the successor document updates 2527, the successor
introduces the PKI Disclosure Statement, which is becoming widely used, but
was not a part of 2527 (because it hadn't yet been conceived when 2527 was
developed).
One major concern about the revision was "backward compatibility", and
that's why one essential element of the revision is a mapping to the
previous (the current 2527).  With this in place, people can gradually move
to the new structure of the revision (successor) document, without being
concerned that their existing CP's/CPS's would suddenly become obsolete with
the approval of the successor.  That scenario would have been unacceptable,
and that's why it has been avoided, with the mapping.
The CP/CPS framework based on 2527 has become an integral and critical
element of implementing PKI and, even more importantly, of efforts towards
the interoperability of PKI implementations (and that reflects the
importance of standards in general). Adrian Pickering's comment really
reinforces this - especially the importance of the context of technical
specifications.  Note, too, that the CP/CPS framework is posited as an
informative RFC.  Whether IETF was the most appropriate body to develop 2527
is kind of an academic consideration at this point (but there wasn't another
standards body specifically in this space at that time).



Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     [phone]
Cell:         613-291-0331



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Fillingham, David W.
Sent: November 12, 2002 12:39 PM
To: 'Paul Hoffman / IMC'; Jeffrey I. Schiller; [e-mail]
Cc: [e-mail]
Subject: RE: Request for IESG consideration: CP/CPS Framework


Hi Paul:

As someone who has worked PKI policy interoperability issues for several
years, I will stand up in defense of RFC 2527 and its successor.  If you
enter "certificate policy" into any Internet search engine, you will find
hundreds of Certificate Policies and Practice Statements from all over the
world, from both government and industry.  Nearly all of them conform to RFC
2527.  Having Certificate Policies presented with a common structure and
format is extremely important to those of us who work in both the PKI
technical and policy interoperability realms.

RFC 2527 has been very successful in meeting its objectives of providing a
way to compare and contrast Certificate Policies and PKI implementations,
and thereby promoting interoperable PKI implementations.  I believe PKIX
should continue to support it.

Best Regards,
Dave Fillingham
US Department of Defense

 -----Original Message-----
From:   Paul Hoffman / IMC [mailto:[e-mail]]
Sent:   Tuesday, November 12, 2002 12:11 PM
To:     Jeffrey I. Schiller; [e-mail]
Cc:     [e-mail]
Subject:        Re: Request for IESG consideration: CP/CPS Framework


At 12:10 PM -0500 11/11/02, Jeffrey I. Schiller wrote:
>This document was discussed at the IESG and there were concerns that
>it was a legal document and not a technical document.

Yup, just like its predecessor.

>  I don't know how to deal with the objection. It appears that the
>people objecting don't have any solid recommendation to make to
>change the document, they just don't like it... I will be taking
>this up with them in person.

You can't change 2527 to not talk about legal/policy issues; that's
what it is about. The new document is simply a revision to an
existing RFC. It seems like some revision should be accepted, or the
old RFC should be removed (which is not possible). That is, you're
stuck with the previous decision to issue RFC 2527. If you have
changed your mind about that, is it better to revise it to reflect
current practice or to not revise it and hope no one uses the old one?

--Paul Hoffman, Director
--Internet Mail Consortium



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAD93Ap10659 for ietf-pkix-bks; Wed, 13 Nov 2002 01:03:10 -0800 (PST)
Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAD937g10653 for <[e-mail]>; Wed, 13 Nov 2002 01:03:08 -0800 (PST)
Received: from f67j40j ([80.5.45.65]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20021113090305.UQNL10927.mta06-svc.ntlworld.com@f67j40j> for <[e-mail]>; Wed, 13 Nov 2002 09:03:05 +0000
From: "Marc Poulaud" <[e-mail]>
To: <[e-mail]>
Subject: RE: Identification = Payment Transaction?
Date: Wed, 13 Nov 2002 09:02:47 -0000
MIME-Version: 1.0
Message-ID: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0009_01C28AF3.6D41A5A0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <010f01c28a5e$fbdf75c0$0500a8c0@arport>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C28AF3.6D41A5A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Anders,

I used to work one of these ventures (as you know), and consult in this
space.

For me, the point is - are the banks/scheme providing a useful service
that businesses are willing to pay for? I think the answer is, in some
cases 'yes'.

I think the issues are around outsourcing and buying a trust service - do
corporates want to create their own capability (or parts of it) and manage
or do they want to off-load this and focus on core business? If you want a
service, are you willing to pay for the wider rule-sets wrapped around
these schemes which put a contractual and legal framework around it? If
so, then what cost model is fair and equitable?

In one scheme I sorta 'know', the cost model does not directly translate
into a price model for businesses - this is up to the banks to decide and
so may charge on a per cert validation or package it up some other way.
(as an aside, this is where the banks struggle - deciding how to
productise trust and then market it, but that's a different story).

Equally, I can see different businesses/models, where so a scheme does not
make sense - so it's horses for courses and so will co-exist with
'free-validation' models IMO.

Marc.
-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Anders Rundgren
Sent: 12 November 2002 15:20
To: [e-mail]
Subject: Identification = Payment Transaction?



Survey regarding the future of  PKI trust networks
------------------------------------------------------

Traditionally certificates have been purchased (or just issued) for
an entity by a party that is concerned that the entity can be properly
identified in authentication- and signature-operations.

For a relying party (RP) to check certificate-status has mostly been a
public and free service.

The financial industry however, have in several recent PKI-ventures
shown that they intend to change this by treating lookup-services as
equivalent to payment transactions, where the RP's bank is used as a
"trust clearing center" communicating with the subscriber's bank that
must be a member of the same "trust network".  To make it technically
impossible for RPs to fully verify signatures without going through
the trust network (and paying for the services), root-certificates are
usually not "published".

I would be very happy to hear what the PKI community in general
think about this scheme as the future for PKI.  Off-list responses
will be treated as CONFIDENTIAL information.

Anders Rundgren












------=_NextPart_000_0009_01C28AF3.6D41A5A0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKITCCAj0w
ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH
mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF
4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d
6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix
3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR
cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy
MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL
uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj
zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw
RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD
gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h
U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1
E3LnQDGa07LEq+dWvovj+xUwggR2MIID36ADAgECAhB/l4yg+FrgmGLkay+Z3cRwMA0GCSqGSIb3
DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMTAwNzAwMDAw
MFoXDTAzMTAwNzIzNTk1OVowggEaMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW
VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0
b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs
bCBTZXJ2aWNlMRUwEwYDVQQDFAxNYXJjIFBvdWxhdWQxKTAnBgkqhkiG9w0BCQEWGm1hcmMucG91
bGF1ZEBpLXNvbHZlLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDfd3CCaom3tU0P
mdCz0ggSdD8UNJMSVDPou1CJjsLvYpwUySsSQgUdYdFjvQmheBDL2z0T3dX1mvce5WJrDg5fcWQG
aUmQbubJ0qxdK5uT4IkNJx9s1PPDfOEj4PdJExyyG0Cbsvwo8Wyq+xnRlCcMzwm4D/XNnXqkrEZw
MifX+wIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcC
AjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVm
ZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAh/j3ynKibKwqRZA4Y3KsDwboqp78AIi04ATWtK0MSq+qL2FIu7HORZrN9eJVwqkm
3lr4tNU/ld7bCqnd9zHO4FRyg17pDVwZ4/7Z3UR+wW6WLj2FXn+QPRPWuyeIpOz+LxPhn4HaBIS6
qaO6+glnQl0IX6axcAhLebO/J/hNIQAxggNWMIIDUgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp
Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52
ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx
SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv
bmEgTm90IFZhbGlkYXRlZAIQf5eMoPha4Jhi5Gsvmd3EcDAJBgUrDgMCGgUAoIIByjAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjExMTMwOTAyNDNaMCMGCSqGSIb3
DQEJBDEWBBSefF5H0spSz+SIpbhSvNGPK3IGsTB2BgkqhkiG9w0BCQ8xaTBnMAoGCCqGSIb3DQMH
MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC
GjAHBgUrDgMCGjAKBggqhkiG9w0CBTAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHM
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhB/l4yg+FrgmGLkay+Z3cRwMA0GCSqG
SIb3DQEBAQUABIGAgSoEmJjyqEf/3MWPStBhIB3aXRvoTIuWa2HXySsOtEVOh+T16o3N41240HB2
EbQqCFig1kI4LR1tMELDtUu0mifA+tCQevKC6lxMktsbk7wGiYenXcf53nOJ9SlnvTO1FOxQThvU
igEN0MxyvEpzV2dDDuWAXeDxutAYRqx8oA4AAAAAAAA=

------=_NextPart_000_0009_01C28AF3.6D41A5A0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAD4GGr14221 for ietf-pkix-bks; Tue, 12 Nov 2002 20:16:16 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAD4GDg14217 for <[e-mail]>; Tue, 12 Nov 2002 20:16:14 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gAD4GGF3048089 for <[e-mail]>; Wed, 13 Nov 2002 04:16:16 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021112192514.034e91d0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 12 Nov 2002 20:15:44 -0800
To: [e-mail]
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: subschemaSubentry in PKI/PMI LDAP schema I-Ds
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Both the PKI and PMI LDAP Schema I-Ds contain a similar
worded section called "Subschema Publishing LDAPv3". Both
imply that a server has one and only one subschema subentry
and that this subentry is discoverable by reading the
subschemaSubentry attribute held in the Root DSE.

The X.500 model, as used in LDAP, clearly allows multiple
subschema subentries to be present, each controlling a subtree
of entries.  In fact, each entry held by the server could
be controlled a different subschema subentry as indicated
by the entry's subschemaSubentry attribute.

It is noted that RFC 2251 has a bug regarding the root DSE's
subschemaSubentry attribute.  To avoid this bug, PKI/PMI
specification should clearly state that the schema controlling
a particular entry is to be discovered by reading that entry's
subschemaSubentry's attribute. (Just as one would in X.500).

Kurt



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAD1Lcg05599 for ietf-pkix-bks; Tue, 12 Nov 2002 17:21:38 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAD1LZg05594 for <[e-mail]>; Tue, 12 Nov 2002 17:21:36 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gAD1LXwA032055 for <[e-mail]>; Wed, 13 Nov 2002 14:21:33 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA145008 for [e-mail]; Wed, 13 Nov 2002 14:21:33 +1300 (NZDT) (sender [e-mail])
Date: Wed, 13 Nov 2002 14:21:33 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re:  PrintableString not usable tigether with OCSP?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>From a discussion with an Anonymous Person:

-- Snip --

>While tehcnically there's this DN compare algorithm in RFC2459 or the evil
>X500 version anyone with any sense ignores it completely and normally treats
>DNs as equal only if they have the same encoding or it will break OCSP et al.
>
>Have you ever come across "equal" DNs that don't have the same encoding? I
>know I never have.

I doubt I have - I actually implemented all the fancy conversion stuff back in
about 1997, but I doubt it's ever really been tested.  I'm currently redoing
that part of the code, I'm tempted to remove it all and do a memcmp() because
it makes it harder to play tricks with encoding forms to get around security
checks.  For one thing the coding required is so convoluted that its
complexity alone is likely to be a source of security problems.

>Presyumably you did the lesser evil version rather than the full version
>which I doubt anyone would want to implement: i.e. the thing that can compare
>Korean T61Strings and BMPStrings.

I'd only bet on it working as far as latin1, however in theory I could compare
widechars to Unicode.  In practice I found (in 1997, it's probably better now)
that mbstowcs() usually only handled latin1, however I suspect
MultiByteToWideChar() (at least under NT) handles more stuff because MS is
pretty thorough with i18n.  OTOH I have no idea what sort of stuff would
appear in a multibyte T61String encoding except it's unlikely to be anything
that any ASN.1 spec defines but just whatever the local charset happens to be
and whatever displays OK in Windows.  OTOH this stuff is barely used, at one
point I wanted to play with some Asian charsets and had to ask someone to
specially generate a cert for me because no-one normally uses them (if you
look at something like the Hong Kong Post CPS, it says that if your company
has a non-ASCII-representable name, you'll need to use an ASCII one to get a
cert).  I asked someone else to create a Unicode cyrillic string for me for
testing (that's outside the latin1 range, so I know it'll end up Unicode) to
see if my code will handle it, but since there's no real multibyte equivalent
I can't easily test the string-comparison capability, only the basic Unicode-
handling.

I suspect that if someone did manage to create a synthetic cert chain with
(say) the issuer in multibyte and subject in Unicode, 100% of implementations
which don't fall back to chaining by keyIDs would fail to recognise it as the
issuer.  That's one guarantee that it's safe to ignore the comparison rules
and use memcmp().

-- Snip --

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gACLLmo23946 for ietf-pkix-bks; Tue, 12 Nov 2002 13:21:48 -0800 (PST)
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gACLLlg23940 for <[e-mail]>; Tue, 12 Nov 2002 13:21:47 -0800 (PST)
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06675 for <[e-mail]>; Tue, 12 Nov 2002 13:21:44 -0800 (PST)
Received: from sr1-ubur-05 (sr1-ubur-05 [129.148.9.84]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id gACLLht10872 for <[e-mail]>; Tue, 12 Nov 2002 16:21:43 -0500 (EST)
Message-Id: <[e-mail]>
Date: Tue, 12 Nov 2002 16:21:43 -0500 (EST)
From: Radia Perlman - Boston Center for Networking <[e-mail]>
Reply-To: Radia Perlman - Boston Center for Networking <[e-mail]>
Subject: What are the LDAP/PKIX issues?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=ISO-8859-1
Content-MD5: GVCpR3G0wLK3VQ1lsy6Glg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id gACLLlg23942
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

People have said that there are some issues in LDAPv3 that will make
life hard for PKIX.
Patrik Fältström asked me if I could investigate.
I asked a few people, but so far I haven't found anyone
that claims to know for sure.
So, the easiest thing is to ask the PKIX mailing list.
Once I understand the issues, I'll write them down in a hopefully
very clear way, and then it should be easy to resolve them.

Thanks for your help!

Radia




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gACHdD806989 for ietf-pkix-bks; Tue, 12 Nov 2002 09:39:13 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gACHdBg06981; Tue, 12 Nov 2002 09:39:11 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id gACHcoK10302; Tue, 12 Nov 2002 12:38:50 -0500 (EST)
Message-ID: <[e-mail]>
From: "Fillingham,  David W." <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, "Jeffrey I. Schiller" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Request for IESG consideration: CP/CPS Framework
Date: Tue, 12 Nov 2002 12:39:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
X-H-S-Loop-Check-Ejzfr: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Paul:

As someone who has worked PKI policy interoperability issues for several
years, I will stand up in defense of RFC 2527 and its successor.  If you
enter "certificate policy" into any Internet search engine, you will find
hundreds of Certificate Policies and Practice Statements from all over the
world, from both government and industry.  Nearly all of them conform to RFC
2527.  Having Certificate Policies presented with a common structure and
format is extremely important to those of us who work in both the PKI
technical and policy interoperability realms.

RFC 2527 has been very successful in meeting its objectives of providing a
way to compare and contrast Certificate Policies and PKI implementations,
and thereby promoting interoperable PKI implementations.  I believe PKIX
should continue to support it.

Best Regards,
Dave Fillingham
US Department of Defense

 -----Original Message-----
From: 	Paul Hoffman / IMC [mailto:[e-mail]] 
Sent:	Tuesday, November 12, 2002 12:11 PM
To:	Jeffrey I. Schiller; [e-mail]
Cc:	[e-mail]
Subject:	Re: Request for IESG consideration: CP/CPS Framework


At 12:10 PM -0500 11/11/02, Jeffrey I. Schiller wrote:
>This document was discussed at the IESG and there were concerns that 
>it was a legal document and not a technical document.

Yup, just like its predecessor.

>  I don't know how to deal with the objection. It appears that the 
>people objecting don't have any solid recommendation to make to 
>change the document, they just don't like it... I will be taking 
>this up with them in person.

You can't change 2527 to not talk about legal/policy issues; that's 
what it is about. The new document is simply a revision to an 
existing RFC. It seems like some revision should be accepted, or the 
old RFC should be removed (which is not possible). That is, you're 
stuck with the previous decision to issue RFC 2527. If you have 
changed your mind about that, is it better to revise it to reflect 
current practice or to not revise it and hope no one uses the old one?

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gACHKQt06263 for ietf-pkix-bks; Tue, 12 Nov 2002 09:20:26 -0800 (PST)
Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gACHKMg06253; Tue, 12 Nov 2002 09:20:22 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05200f35b9f6e5026544@[165.227.249.18]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Tue, 12 Nov 2002 09:10:53 -0800
To: "Jeffrey I. Schiller" <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Request for IESG consideration: CP/CPS Framework
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:10 PM -0500 11/11/02, Jeffrey I. Schiller wrote:
>This document was discussed at the IESG and there were concerns that 
>it was a legal document and not a technical document.

Yup, just like its predecessor.

>  I don't know how to deal with the objection. It appears that the 
>people objecting don't have any solid recommendation to make to 
>change the document, they just don't like it... I will be taking 
>this up with them in person.

You can't change 2527 to not talk about legal/policy issues; that's 
what it is about. The new document is simply a revision to an 
existing RFC. It seems like some revision should be accepted, or the 
old RFC should be removed (which is not possible). That is, you're 
stuck with the previous decision to issue RFC 2527. If you have 
changed your mind about that, is it better to revise it to reflect 
current practice or to not revise it and hope no one uses the old one?

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gACGmFJ03723 for ietf-pkix-bks; Tue, 12 Nov 2002 08:48:15 -0800 (PST)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gACGmEg03716 for <[e-mail]>; Tue, 12 Nov 2002 08:48:14 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21928; Tue, 12 Nov 2002 11:47:56 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100309b9f6df955a36@[128.89.88.34]>
In-Reply-To: <010f01c28a5e$fbdf75c0$0500a8c0@arport>
References: <010f01c28a5e$fbdf75c0$0500a8c0@arport>
Date: Tue, 12 Nov 2002 11:44:45 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Identification = Payment Transaction?
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 4:20 PM +0100 11/12/02, Anders Rundgren wrote:
>Survey regarding the future of  PKI trust networks
>------------------------------------------------------
>
>Traditionally certificates have been purchased (or just issued) for
>an entity by a party that is concerned that the entity can be properly
>identified in authentication- and signature-operations.
>
>For a relying party (RP) to check certificate-status has mostly been a
>public and free service.
>
>The financial industry however, have in several recent PKI-ventures
>shown that they intend to change this by treating lookup-services as
>equivalent to payment transactions, where the RP's bank is used as a
>"trust clearing center" communicating with the subscriber's bank that
>must be a member of the same "trust network".  To make it technically
>impossible for RPs to fully verify signatures without going through
>the trust network (and paying for the services), root-certificates are
>usually not "published".
>
>I would be very happy to hear what the PKI community in general
>think about this scheme as the future for PKI.  Off-list responses
>will be treated as CONFIDENTIAL information.
>
>Anders Rundgren

This is nothing new. The ACES program developed by the U.S. General 
Services Administration adopted an analogous model, in which U.S. 
residents get "free" certs for identifying them in online 
transactions with U.S. Government agencies. The TTPs that issue the 
certs then get paid for cert revocation status checking every time an 
agency wants to be an RP with regard to the cert.

This just shows that TTP CAs have lots of ways to extract money from 
people for certs, both up front and on an ongoing basis. It might 
motivate more companies to realize that they can issue their own 
certs to their employees and customers and not have to pay TTP CAs 
for such services.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gACGS5H01366 for ietf-pkix-bks; Tue, 12 Nov 2002 08:28:05 -0800 (PST)
Received: from blooper.utfors.se (mail.utfors.se [195.58.103.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gACGS3g01360 for <[e-mail]>; Tue, 12 Nov 2002 08:28:04 -0800 (PST)
Received: from arport ([62.119.75.13]) by blooper.utfors.se (8.12.6/8.12.6) with SMTP id gACGRwgd014605 for <[e-mail]>; Tue, 12 Nov 2002 17:27:59 +0100 (MET)
Message-ID: <010f01c28a5e$fbdf75c0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Identification = Payment Transaction?
Date: Tue, 12 Nov 2002 16:20:07 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Survey regarding the future of  PKI trust networks
------------------------------------------------------

Traditionally certificates have been purchased (or just issued) for
an entity by a party that is concerned that the entity can be properly
identified in authentication- and signature-operations.

For a relying party (RP) to check certificate-status has mostly been a
public and free service.

The financial industry however, have in several recent PKI-ventures
shown that they intend to change this by treating lookup-services as
equivalent to payment transactions, where the RP's bank is used as a
"trust clearing center" communicating with the subscriber's bank that
must be a member of the same "trust network".  To make it technically
impossible for RPs to fully verify signatures without going through
the trust network (and paying for the services), root-certificates are
usually not "published".

I would be very happy to hear what the PKI community in general
think about this scheme as the future for PKI.  Off-list responses
will be treated as CONFIDENTIAL information.

Anders Rundgren














Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gACEt4125055 for ietf-pkix-bks; Tue, 12 Nov 2002 06:55:04 -0800 (PST)
Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gACEsvg25049 for <[e-mail]>; Tue, 12 Nov 2002 06:54:58 -0800 (PST)
Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA06421; Tue, 12 Nov 2002 14:54:42 GMT
Received: from jap.ecs.soton.ac.uk (jap.ecs.soton.ac.uk [152.78.69.201]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gACEsHWY013045; Tue, 12 Nov 2002 14:54:17 GMT
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 12 Nov 2002 14:59:52 +0000
To: [e-mail], "Jeffrey I. Schiller" <[e-mail]>, Tim Polk <[e-mail]>
From: J Adrian Pickering <[e-mail]>
Subject: Re: Request for IESG consideration: CP/CPS Framework
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-ECS-MailScanner: Found to be clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 17:10 11/11/2002, Jeffrey I. Schiller wrote:
>This document was discussed at the IESG and there were concerns that it 
>was a legal document and not a technical document. I don't know how to 
>deal with the objection. It appears that the people objecting don't have 
>any solid recommendation to make to change the document, they just don't 
>like it... I will be taking this up with them in person.
>
>                         -Jeff

Having had it explained to me quite forcefully that IETF concentrates on 
*engineering* rather than legal issues, I can see the problem!

I still think that engineering decisions need to be well informed about 
their context and such documents contribute to that. I would suggest that 
IETF still welcome such contributions but refrain from directing them 
towards standards. When reading such documents one should perhaps ask 
oneself regularly, 'Does this affect how the code would be written?' and 
use the answer as a metric.

However, TSA Policies is more legal than technical and this is moving in 
the same circles, I believe?

Adrian Pickering/
University of Southampton UK


>Tim Polk wrote:
>>
>>Jeff & Steve,
>>The PKIX working group has achieved rough consensus and completed WG Last 
>>Call for 
>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-new-rfc2527-01.txt, 
>>"Internet X.509 Public Key Infrastructure Certificate Policy and 
>>ertification Practices Framework".  Please consider this specification 
>>for submission to the IESG for advancement to RFC status.
>>This specification is an update to, and obsoletes, the current 
>>Informational Standard RFC 2527 (which has the same name). As with the 
>>specification it obsoletes, we believe that informational track would be 
>>appropriate for this specification.
>>Thanks,
>>Tim Polk
>>
>>
>
>
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gACCQJc13172 for ietf-pkix-bks; Tue, 12 Nov 2002 04:26:19 -0800 (PST)
Received: from www.mtgnet.de (www.mtgnet.de [62.144.85.193]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gACCQHg13168 for <[e-mail]>; Tue, 12 Nov 2002 04:26:17 -0800 (PST)
Received: from minka.mtgnet.de (minka [199.99.99.9]) by www.mtgnet.de (8.12.6/8.12.6) with ESMTP id gACCRdPN017065 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Tue, 12 Nov 2002 13:27:39 +0100
Received: from mtgnet.de (schroeder [199.99.99.38]) by minka.mtgnet.de (8.12.6/8.12.5) with ESMTP id gACCQBsK017701 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Tue, 12 Nov 2002 13:26:11 +0100
Message-ID: <[e-mail]>
Date: Tue, 12 Nov 2002 13:26:08 +0100
From: Peter Gervais <[e-mail]>
Reply-To: [e-mail]
Organization: media transfer GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021022
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: (no subject)
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080003000805080003050008"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms080003000805080003050008
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

unsubscribe

--------------ms080003000805080003050008
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOSjCC
A74wggMnoAMCAQICAXwwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoT
E0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIx
IzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAxMB4XDTAyMDYyNDA5NTcwMFoX
DTA4MDYyNDIzNTkwMFowYjELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVr
b20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxFDASBgNVBAMTC01haWxQ
YXNzIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHLuvqFdsGmG4EiOgaf6p9V/eU
fXG+FTXBNurA7JkkFGN7phu0/D7MK7iQ9SkD4qIQwzPlC+J7x7JrGHunv1V09OqGyooqlnWe
ZI3jfioYNkcm5/RGaGQqax9Ng4qOuj7hAe6d/NBqo2RAgjBkAecs8VYp/jsz4CyUoyzSLLXQ
UwIDAQABo4IBczCCAW8wggEHBgNVHR8Egf8wgfwwgZqggZeggZSGgZFsZGFwOi8vbGRhcC50
LW1haWxwYXNzLmRlL2NuPURldXRzY2hlJTIwVGVsZWtvbSUyMFJvb3QlMjBDQSUyMDEsb3U9
VC1UZWxlU2VjJTIwVHJ1c3RDZW50ZXIsbz1EZXV0c2NoZSUyMFRlbGVrb20lMjBBRyxjPURF
P0F1dGhvcml0eVJldm9jYXRpb25MaXN0MF2gW6BZhldodHRwOi8vd3d3Y2EudGVsZXNlYy5k
ZS9jZ2ktYmluL2Nhc2VydmljZS9NYWlsUGFzcy9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9m
b3JtYXQ9WF81MDkwHQYDVR0OBBYEFFdEktoHc0NRtEy64aeeL+Vbc0QUMB8GA1UdIwQYMBaA
FBQx4n+cyhKV+/FwINtNKBNxQmHGMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/
AgEBMA0GCSqGSIb3DQEBBQUAA4GBAEkF6QIEd1z3AnFtEcUIyGBc7V1JI8bf4inkfUbjKCrQ
IzXNSfu1kLdgRyT1IID2S9YFdXhK8Pw2FiX77rTTgDGBHXlL26I1UFKBLIqxLDedQ2uKR/XS
9dpsUVdO038MpX0rqPWt0ZkWTUxdRnq5w4Rj0JLynj3nIJ9mV29C38sAMIIFQDCCBKmgAwIB
AgIBWjANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUg
VGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEUMBIGA1UEAxML
TWFpbFBhc3MgQ0EwHhcNMDIwOTE3MTk1NjM2WhcNMDMwOTE3MjM1OTAwWjCBsjELMAkGA1UE
BhMCREUxHDAaBgNVBAoTE21lZGlhIHRyYW5zZmVyIEdtYkgxEjAQBgNVBAsTCW10Z25ldC5k
ZTEgMB4GA1UECxMXbXRHLURhcm1zdGFkdC5tdGduZXQuZGUxFDASBgNVBAsTC0VudHdpY2ts
dW5nMRYwFAYDVQQDEw1QZXRlciBHZXJ2YWlzMSEwHwYJKoZIhvcNAQkBFhJwZ2VydmFpc0Bt
dGduZXQuZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZrUeJXYf4RGNF/l79
i3Qnh7OkQsBPMuJ9Vy7JNVwIU4LKzW9EoovZhnzDHAhAbPFWwszA0l+hfb5cJtyY1uywXMbO
ytWEZOtymR299Io0PEmP4OtdOOFNMt9YyyFw1UMP7eds5iAtJUeU6gPjMQ7nGN2LydOxKTX6
w4da1HE1KmcVkJ8JqVisTjwqcasB0Ree35HqNV1ttYt83HEycTMuOBs++RTsjfS4bWrowKTY
KSL82HXcXzUAoyxqfUmFz/3DsrdTxYo4ynFdLZDQkIWTqooVfM4ECuMrQtpblI6oNbaSGdQJ
laNr3Y5bE4Em43Le874nIv20N1ovE5ClD9kpAgMBAAGjggIvMIICKzAfBgNVHSMEGDAWgBRX
RJLaB3NDUbRMuuGnni/lW3NEFDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0OBBYEFPln7ZqFcpF/
rXrmK+FN+LL/KNkhMGUGA1UdIAReMFwwWgYJKwYBBAG9Rw0LME0wSwYIKwYBBQUHAgEWP2h0
dHA6Ly93d3djYS50ZWxlc2VjLmRlL2Nhc2VydmljZS9NYWlsUGFzcy9Eb2t1bWVudGUvaW5k
ZXguaHRtbDAdBgNVHREEFjAUgRJwZ2VydmFpc0BtdGduZXQuZGUwgfEGA1UdHwSB6TCB5jCB
hKCBgaB/hn1sZGFwOi8vbGRhcC50LW1haWxwYXNzLmRlL2NuPU1haWxQYXNzJTIwQ0Esb3U9
VC1UZWxlU2VjJTIwVHJ1c3RDZW50ZXIsbz1EZXV0c2NoZSUyMFRlbGVrb20lMjBBRyxjPURF
P0NlcnRpZmNhdGVSZXZvY2F0aW9uTGlzdDBdoFugWYZXaHR0cDovL3d3d2NhLnRlbGVzZWMu
ZGUvY2dpLWJpbi9jYXNlcnZpY2UvTWFpbFBhc3MvYWZfRG93bmxvYWRDUkwuY3JsPy1jcmxf
Zm9ybWF0PXhfNTA5MF8GCCsGAQUFBwEBBFMwUTBPBggrBgEFBQcwAYZDaHR0cDovL3d3d2Nh
LnRlbGVzZWMuZGUvY2dpLWJpbi9jYXNlcnZpY2UvTWFpbFBhc3Mvb2NzcF9yZXF1ZXN0LmNn
aTANBgkqhkiG9w0BAQUFAAOBgQA1D8z/JV4WH85UsbPzSeGX42t3ojJsGbT+ttElLv0Q3AT2
86cl9TIaYPLHBt2YGZByho1PTV3NEJfgrIjbGLFcFCh9+G2LCWoN7VYJcmEAFdb+gjpjY7bb
CErRgHtMQvEZMEQD1CLzfJ39ooYoduXKt/u5lAU7DFV0dKZl1r/RxTCCBUAwggSpoAMCAQIC
AVowDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRl
bGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxFDASBgNVBAMTC01h
aWxQYXNzIENBMB4XDTAyMDkxNzE5NTYzNloXDTAzMDkxNzIzNTkwMFowgbIxCzAJBgNVBAYT
AkRFMRwwGgYDVQQKExNtZWRpYSB0cmFuc2ZlciBHbWJIMRIwEAYDVQQLEwltdGduZXQuZGUx
IDAeBgNVBAsTF210Ry1EYXJtc3RhZHQubXRnbmV0LmRlMRQwEgYDVQQLEwtFbnR3aWNrbHVu
ZzEWMBQGA1UEAxMNUGV0ZXIgR2VydmFpczEhMB8GCSqGSIb3DQEJARYScGdlcnZhaXNAbXRn
bmV0LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2a1HiV2H+ERjRf5e/Yt0
J4ezpELATzLifVcuyTVcCFOCys1vRKKL2YZ8wxwIQGzxVsLMwNJfoX2+XCbcmNbssFzGzsrV
hGTrcpkdvfSKNDxJj+DrXTjhTTLfWMshcNVDD+3nbOYgLSVHlOoD4zEO5xjdi8nTsSk1+sOH
WtRxNSpnFZCfCalYrE48KnGrAdEXnt+R6jVdbbWLfNxxMnEzLjgbPvkU7I30uG1q6MCk2Cki
/Nh13F81AKMsan1Jhc/9w7K3U8WKOMpxXS2Q0JCFk6qKFXzOBArjK0LaW5SOqDW2khnUCZWj
a92OWxOBJuNy3vO+JyL9tDdaLxOQpQ/ZKQIDAQABo4ICLzCCAiswHwYDVR0jBBgwFoAUV0SS
2gdzQ1G0TLrhp54v5VtzRBQwDgYDVR0PAQH/BAQDAgWgMB0GA1UdDgQWBBT5Z+2ahXKRf616
5ivhTfiy/yjZITBlBgNVHSAEXjBcMFoGCSsGAQQBvUcNCzBNMEsGCCsGAQUFBwIBFj9odHRw
Oi8vd3d3Y2EudGVsZXNlYy5kZS9jYXNlcnZpY2UvTWFpbFBhc3MvRG9rdW1lbnRlL2luZGV4
Lmh0bWwwHQYDVR0RBBYwFIEScGdlcnZhaXNAbXRnbmV0LmRlMIHxBgNVHR8EgekwgeYwgYSg
gYGgf4Z9bGRhcDovL2xkYXAudC1tYWlscGFzcy5kZS9jbj1NYWlsUGFzcyUyMENBLG91PVQt
VGVsZVNlYyUyMFRydXN0Q2VudGVyLG89RGV1dHNjaGUlMjBUZWxla29tJTIwQUcsYz1ERT9D
ZXJ0aWZjYXRlUmV2b2NhdGlvbkxpc3QwXaBboFmGV2h0dHA6Ly93d3djYS50ZWxlc2VjLmRl
L2NnaS1iaW4vY2FzZXJ2aWNlL01haWxQYXNzL2FmX0Rvd25sb2FkQ1JMLmNybD8tY3JsX2Zv
cm1hdD14XzUwOTBfBggrBgEFBQcBAQRTMFEwTwYIKwYBBQUHMAGGQ2h0dHA6Ly93d3djYS50
ZWxlc2VjLmRlL2NnaS1iaW4vY2FzZXJ2aWNlL01haWxQYXNzL29jc3BfcmVxdWVzdC5jZ2kw
DQYJKoZIhvcNAQEFBQADgYEANQ/M/yVeFh/OVLGz80nhl+Nrd6IybBm0/rbRJS79ENwE9vOn
JfUyGmDyxwbdmBmQcoaNT01dzRCX4KyI2xixXBQoffhtiwlqDe1WCXJhABXW/oI6Y2O22whK
0YB7TELxGTBEA9Qi83yd/aKGKHblyrf7uZQFOwxVdHSmZda/0cUxggM1MIIDMQIBATBnMGIx
CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZU
LVRlbGVTZWMgVHJ1c3QgQ2VudGVyMRQwEgYDVQQDEwtNYWlsUGFzcyBDQQIBWjAJBgUrDgMC
GgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjEx
MTIxMjI2MDhaMCMGCSqGSIb3DQEJBDEWBBS4iz2mc4/sOCU+2fd6GuCp+Qco6zBSBgkqhkiG
9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH
BgUrDgMCBzANBggqhkiG9w0DAgIBKDB2BgkrBgEEAYI3EAQxaTBnMGIxCzAJBgNVBAYTAkRF
MRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1
c3QgQ2VudGVyMRQwEgYDVQQDEwtNYWlsUGFzcyBDQQIBWjB4BgsqhkiG9w0BCRACCzFpoGcw
YjELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT
FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxFDASBgNVBAMTC01haWxQYXNzIENBAgFaMA0GCSqG
SIb3DQEBAQUABIIBABxWbFoBd4omyrWgyYILjqykX1T6Ce9nwH47nUUPgeMyVIs+yuom5o+K
bNQUEMH3kNiPixv9N9gattRIL7h2cqsbiUDDFywahIZ8C/5fkNZJSlzYwhcQrTsgohJjxZ7Y
S+wHLSkAIwFncsDeTyjGbHwZZGmAfnu1PtxDtChuHT/QRvnIPrcb+ejmyN5yLw1odcnYdyrB
ytCzSfyGI4VZkxjosgV1tBqWzjvvc4nxui1/af7C2w+ZO3azyh9+g0sRdaHwnJSCIxy76muf
yauIxg5qeHgb6ZexQQYEHi4DcCmz9dtj2ufuznB4lNptrmtBaQEunro8CbuFxwT5qGNtCqMA
AAAAAAA=
--------------ms080003000805080003050008--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gACBPtM07878 for ietf-pkix-bks; Tue, 12 Nov 2002 03:25:55 -0800 (PST)
Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by above.proper.com (8.11.6/8.11.3) with SMTP id gACBPqg07869 for <[e-mail]>; Tue, 12 Nov 2002 03:25:53 -0800 (PST)
Received: (qmail 31962 invoked from network); 12 Nov 2002 11:16:02 -0000
Received: from unknown (HELO multicert.com) (62.48.185.5) by mail0.sibs.pt with SMTP; 12 Nov 2002 11:16:02 -0000
Message-ID: <[e-mail]>
Date: Tue, 12 Nov 2002 11:22:22 +0000
From: Ricardo Barroso <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], Paul Hoffman / IMC <[e-mail]>
CC: Peter Sylvester <[e-mail]>
Subject: Re: TSA messages for http ?
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorry Paul Hoffman, I haven't readed your mail before I sent that...

Ricardo Barroso wrote:

> Yes Peter, I also think so, it seems that I have been receiving old 
> messages in the last days, too!
>
> Peter Sylvester wrote:
>
>> It seems to me that some news server is resending some messages
>> to this list.
>>
>>  
>>
>>> From [e-mail] Mon Nov 11 14:15:16 2002
>>> To: [e-mail]
>>> Path: comodo.net
>>> From: Peter Sylvester <[e-mail]>
>>> Newsgroups: comodo.lists.ietf.pkix
>>> Subject: RE: TSA messages for http ?
>>> Date: Wed, 14 Nov 2001 11:32:56 +0100 (MET)
>>> Organization: Comodo Research Labs   
>>> Lines: 40
>>> NNTP-Posting-Host: localhost
>>> X-Trace: kylie.comodogroup.com 1037018864 24025 127.0.0.1 (11 Nov 
>>> 2002 12:47:44 GMT)
>>> Delivered-To: [e-mail]
>>>   
>>
>>
>>  
>>
>
>




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gACBLn007750 for ietf-pkix-bks; Tue, 12 Nov 2002 03:21:49 -0800 (PST)
Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by above.proper.com (8.11.6/8.11.3) with SMTP id gACBLjg07744 for <[e-mail]>; Tue, 12 Nov 2002 03:21:46 -0800 (PST)
Received: (qmail 31792 invoked from network); 12 Nov 2002 11:11:43 -0000
Received: from unknown (HELO multicert.com) (62.48.185.5) by mail0.sibs.pt with SMTP; 12 Nov 2002 11:11:43 -0000
Message-ID: <[e-mail]>
Date: Tue, 12 Nov 2002 11:18:03 +0000
From: Ricardo Barroso <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: TSA messages for http ?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yes Peter, I also think so, it seems that I have been receiving old 
messages in the last days, too!

Peter Sylvester wrote:

>It seems to me that some news server is resending some messages
>to this list. 
>
>
>  
>
>>From [e-mail] Mon Nov 11 14:15:16 2002
>>To: [e-mail]
>>Path: comodo.net
>>From: Peter Sylvester <[e-mail]>
>>Newsgroups: comodo.lists.ietf.pkix
>>Subject: RE: TSA messages for http ?
>>Date: Wed, 14 Nov 2001 11:32:56 +0100 (MET)
>>Organization: Comodo Research Labs	
>>Lines: 40
>>NNTP-Posting-Host: localhost
>>X-Trace: kylie.comodogroup.com 1037018864 24025 127.0.0.1 (11 Nov 2002 12:47:44 GMT)
>>Delivered-To: [e-mail]
>>    
>>
>
>  
>




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAC8obP16118 for ietf-pkix-bks; Tue, 12 Nov 2002 00:50:37 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAC8oag16109 for <[e-mail]>; Tue, 12 Nov 2002 00:50:36 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id JAA14919 for <[e-mail]>; Tue, 12 Nov 2002 09:50:34 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Tue, 12 Nov 2002 09:50:34 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id JAA06924 for [e-mail]; Tue, 12 Nov 2002 09:50:32 +0100 (MET)
Date: Tue, 12 Nov 2002 09:50:32 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: TSA messages for http ?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It seems to me that some news server is resending some messages
to this list. 


> From [e-mail] Mon Nov 11 14:15:16 2002
> To: [e-mail]
> Path: comodo.net
> From: Peter Sylvester <[e-mail]>
> Newsgroups: comodo.lists.ietf.pkix
> Subject: RE: TSA messages for http ?
> Date: Wed, 14 Nov 2001 11:32:56 +0100 (MET)
> Organization: Comodo Research Labs	
> Lines: 40
> NNTP-Posting-Host: localhost
> X-Trace: kylie.comodogroup.com 1037018864 24025 127.0.0.1 (11 Nov 2002 12:47:44 GMT)
> Delivered-To: [e-mail]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAC6eL225766 for ietf-pkix-bks; Mon, 11 Nov 2002 22:40:21 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAC6eJg25758 for <[e-mail]>; Mon, 11 Nov 2002 22:40:19 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX F5.3 VnHj) with ESMTP; Tue, 12 Nov 2002 07:42:43 +0100
Date: Tue, 12 Nov 2002 07:39:20 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: PrintableString not usable tigether with OCSP?
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 2.2
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Mon, 11 Nov 2002 18:03:58 -0800, "Ambarish Malpani" <[e-mail]> said:

ambarish> 
ambarish> Hi Richard,
ambarish>     This hasn't ever come up as a problem before.

I'm glad to hear that, and that seems to reaffirm (is that the proper
term?) what Peter said...

ambarish> Anyway, when writing the server at Valicert, I used the hash of
ambarish> the CA's public key as the primary index to identify the CA.

You're talking about a different field in CertID.

ambarish> We originally had the CA's full DN to allow people to identify
ambarish> the CA, but one of the vendors had a strong objection to that
ambarish> and so it was reduced to the hash of the CA's DN.

Rereading section 4.1.2, I understand the reason (or at least one
reason).

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAC23dD10040 for ietf-pkix-bks; Mon, 11 Nov 2002 18:03:39 -0800 (PST)
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAC23cg10036 for <[e-mail]>; Mon, 11 Nov 2002 18:03:38 -0800 (PST)
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id gAC23ZMP026435; Mon, 11 Nov 2002 18:03:36 -0800
From: "Ambarish Malpani" <[e-mail]>
To: "Richard Levitte - VMS Whacker" <[e-mail]>, <[e-mail]>
Subject: RE: PrintableString not usable tigether with OCSP?
Date: Mon, 11 Nov 2002 18:03:58 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Richard,
    This hasn't ever come up as a problem before.

Anyway, when writing the server at Valicert, I used the hash of
the CA's public key as the primary index to identify the CA.

We originally had the CA's full DN to allow people to identify
the CA, but one of the vendors had a strong objection to that
and so it was reduced to the hash of the CA's DN.

Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Richard Levitte - VMS
> Whacker
> Sent: Sunday, November 10, 2002 11:37 AM
> To: [e-mail]
> Subject: PrintableString not usable tigether with OCSP?
> 
> 
> 
> Perhaps the subject is a little on the harsh side.  However, having
> just implemented the rules for PrintableString and emailAddress from
> RFC3280 [1] into OpenSSL, I was reminded that this in itself causes
> some problems when hashes over subject or issuer is used to find a
> certificate.
> 
> It could be dismissed if such hashes weren't seriously used anywhere.
> However, the CertID type in RFC2560 contains exactly this kind of
> hash, as the field issuerNameHash.  There may very well be cases where
> two issuer names which are considered equal according to the rules
> given above, but give different hashes.
> 
> Is there already a solution for this problem, or has it not been
> thought of yet?  In any case, it needs to be adressed, since such DNs
> do exist.  Also, there are tests in NISTs X.509 tes suite
> (http://csrc.nist.gov/pki/testing/x509paths.html) where comparison if
> PrintableStrings that differ in spacing and casing are present.
> 
> -----
> [1] saying the PrintableString in DNs should have spaces collapsed and
>     trimmed at the beginning and end of value, and considered case
>     insensitive, and the emailAddress with the string type ia5String
>     should be considered case insensitive...
> 
> -- 
> Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
> Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
> T: [phone] |                             | SWEDEN
>      "Price, performance, quality...  choose the two you like"
> 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABKibd23894 for ietf-pkix-bks; Mon, 11 Nov 2002 12:44:37 -0800 (PST)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id gABKiZg23890 for <[e-mail]>; Mon, 11 Nov 2002 12:44:35 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Nov 2002 20:44:38 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA13291; Mon, 11 Nov 2002 15:44:29 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id gABKflL25621; Mon, 11 Nov 2002 15:41:47 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWMG26>; Mon, 11 Nov 2002 15:44:27 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.13]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWMG2X; Mon, 11 Nov 2002 15:44:21 -0500
From: "Housley, Russ" <[e-mail]>
To: Takashi ITO <[e-mail]>
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 11 Nov 2002 13:53:41 -0500
Subject: Re: RFC 3280 : CRL Validation
In-Reply-To: <006e01c28954$62e92560$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Takashi:

Yes, you are correct.  Thanks for pointing out this error in RFC 3280.

Russ


   At 04:31 PM 11/11/2002 +0900, Takashi ITO wrote:

>Hi,
>
>I have a question about CRL Validation in RFC 3280.
>
>In clause 6.3.2, the state variable is defined as the following:
>
>     (a)  reasons_mask:  This variable contains the set of revocation
>     reasons supported by the CRLs and delta CRLs processed so far.
>     ...(snip)... This variable is initialized to the empty set.
>
>However, in CRL Processing described in clause 6.3.3,
>the reasons_mask state variable is not updated at all,
>while CRL Processing says "If reasons_mask is all-reasons ...".
>
>I think the updating phase is necessary in clause 6.3.3, CRL Processing.
>For example:
>
>     (l)  Set the reasons_mask state variable to the union of
>     its previous value and the value of the interim_reasons_mask
>     state variable.
>
>Is my understanding right?
>
>Thanks,
>
>
>Takashi ITO <[e-mail]>
>Mitsubishi Electric Corporation


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABHHjL09900 for ietf-pkix-bks; Mon, 11 Nov 2002 09:17:45 -0800 (PST)
Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABHHhg09895 for <[e-mail]>; Mon, 11 Nov 2002 09:17:44 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05200f08b9f595d0cac4@[165.227.249.18]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Mon, 11 Nov 2002 09:16:04 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: The list bombing has stopped
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Greetings again. I have spoken with the mail administrator at the 
Comodo Group, and he found the problem in his mail system. I mopped 
up here (there were over a thousand messages that you *didn't* get!), 
and I think things are back to normal. Obviously, I'll be watching 
closely today.

--Paul Hoffman, list admin


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABHBJD09706 for ietf-pkix-bks; Mon, 11 Nov 2002 09:11:19 -0800 (PST)
Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABHBDg09699 for <[e-mail]>; Mon, 11 Nov 2002 09:11:13 -0800 (PST)
Received: from jis.tzo.com (localhost [127.0.0.1]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id MAA27405; Mon, 11 Nov 2002 12:11:03 -0500 (EST)
Received: from mit.edu (jis.tzo.com [127.0.0.1]) by jis.tzo.com (8.12.3/8.12.3) with ESMTP id gABHAvxQ002218; Mon, 11 Nov 2002 12:10:58 -0500
Message-ID: <[e-mail]>
Date: Mon, 11 Nov 2002 12:10:57 -0500
From: "Jeffrey I. Schiller" <[e-mail]>
Organization: Massachusetts Institute of Technology
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Request for IESG consideration: CP/CPS Framework
References: <[e-mail]>
X-Enigmail-Version: 0.63.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD88CE211BA051270AE1811E2"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD88CE211BA051270AE1811E2
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

This document was discussed at the IESG and there were concerns that it 
was a legal document and not a technical document. I don't know how to 
deal with the objection. It appears that the people objecting don't have 
any solid recommendation to make to change the document, they just don't 
like it... I will be taking this up with them in person.

			-Jeff

Tim Polk wrote:
> 
> 
> Jeff & Steve,
> 
> The PKIX working group has achieved rough consensus and completed WG 
> Last Call for 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-new-rfc2527-01.txt, 
>  "Internet X.509 Public Key Infrastructure Certificate Policy and 
> ertification Practices Framework".  Please consider this specification 
> for submission to the IESG for advancement to RFC status.
> 
> This specification is an update to, and obsoletes, the current 
> Informational Standard RFC 2527 (which has the same name). As with the 
> specification it obsoletes, we believe that informational track would be 
> appropriate for this specification.
> 
> Thanks,
> 
> Tim Polk
> 
> 
> 
> 
> 


--------------enigD88CE211BA051270AE1811E2
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9z+Sh8CBzV/QUlSsRAk85AKC3kwh+qFW6Rmd4WFaoHuaP03ZbhgCfU0ek
aj6N1DqnRo1vXorHOAWEZDU=
=62lA
-----END PGP SIGNATURE-----

--------------enigD88CE211BA051270AE1811E2--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABGZbU06393 for ietf-pkix-bks; Mon, 11 Nov 2002 08:35:37 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCnfv29020 for <[e-mail]>; Mon, 11 Nov 2002 04:49:49 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDzd-0007E6-00 for <[e-mail]>; Mon, 11 Nov 2002 12:48:41 +0000
To: [e-mail]
Path: comodo.net
From: "Anders Rundgren" <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Updating RFC 3039 - and its impact on PI
Date: Tue, 19 Mar 2002 19:26:26 +0100
Organization: Comodo Research Labs	
Lines: 68
Message-ID: <000f01c1cf73$94db1920$0500a8c0@arport>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018921 24025 127.0.0.1 (11 Nov 2002 12:48:41 GMT)
Delivered-To: [e-mail]
To: <[e-mail]>, "Stefan Santesson" <[e-mail]>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<<< No Message Collected >>>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCvEt29821 for ietf-pkix-bks; Mon, 11 Nov 2002 04:57:14 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCnIv28924 for <[e-mail]>; Mon, 11 Nov 2002 04:49:23 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDzH-0006qE-00 for <[e-mail]>; Mon, 11 Nov 2002 12:48:19 +0000
To: [e-mail]
Path: comodo.net
From: Peter Sylvester <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: RFC 3161 (TSP): update for the criticality flag
Date: Fri, 8 Feb 2002 16:31:32 +0100 (MET)
Organization: Comodo Research Labs	
Lines: 8
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
X-Trace: kylie.comodogroup.com 1037018899 24025 127.0.0.1 (11 Nov 2002 12:48:19 GMT)
Delivered-To: [e-mail]
To: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> It will be replaced by:
> 
You probably mean: 

  "I propose to replace it by:"



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCq4J29632 for ietf-pkix-bks; Mon, 11 Nov 2002 04:52:04 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmgv28425 for <[e-mail]>; Mon, 11 Nov 2002 04:48:44 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyf-0006IR-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:41 +0000
To: [e-mail]
Path: comodo.net
From: "Anders Rundgren" <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Which RFC specifies: E=x@y.z?
Date: Mon, 12 Nov 2001 10:49:02 +0100
Organization: Comodo Research Labs	
Lines: 55
Message-ID: <009801c16b5f$4638fe90$0500a8c0@arport>
References: <000901c16a9f$d1e9f680$0500a8c0@arport> <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: kylie.comodogroup.com 1037018861 24025 127.0.0.1 (11 Nov 2002 12:47:41 GMT)
Delivered-To: [e-mail]
To: <[e-mail]>, <[e-mail]>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id fAC9mPc09202
X-Hops: 1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gABCmnv28571
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,
This is slightly more complicated in XML Dsig compared to CMS.
In CMS the signers' certificate is specified by ASN1 data that
normally is one-to-one of the associated certificate.  The chance
of misinterpretation is then zero.  In XML Dsig the Issuer, Subject
etc. are given as UTF-8 strings which must be matched against the ASN
representation.  Although this is also the case for LDAP, I
believe XML Dsig which is used for "machines talking to
machines" is likely to be more hurt by the historic lack of
stringens in DN strings.

BTW, neither Email= nor E= are to be found in the referred RFC.
I guess one should use the OID for that one as you suggest.
To only use OIDs is an option but looks awful.  The point with
XML was that you should be able to read it as well.

Anders

----- Original Message -----
From: "Michael Ströder" <[e-mail]>
To: <[e-mail]>
Sent: Sunday, November 11, 2001 16:05
Subject: Re: Which RFC specifies: E=x@y.z?



Anders Rundgren wrote:
>
> Although e-mail addresses are decprecated in Subject fields, this
> habit will probably not cease.  During our XML Dsig interperability testing
> we have found "dialects" in how rfc822 names are written symbolically.
>
> Some (MS) use E=x while others like SUN use EMAIL=x
>
> And I can't find the RFC!  Which one is it?
>
> No matter what the answer is, this will be an interoperability issue

Yes, it is an interoperability issue. But the PKIX lib/application
used is responsible for that. An application should never rely on
attribute type name strings being used. It should handle the OID of
the attribute type directly.

Further I'd suggest to use LDAP string representation of DNs like
described in RFC 2253 (e.g. OpenSSL does it since some time if
explicitly requested). Note: The string representation will not be
reversible since the knowledge about the used character set of a
string (encoded as different ASN.1 string types) is lost and the
attribute type name is undefined too (OIDs could be used instead).

Ciao, Michael.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCq4S29633 for ietf-pkix-bks; Mon, 11 Nov 2002 04:52:04 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmjv28498 for <[e-mail]>; Mon, 11 Nov 2002 04:48:48 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyh-0006KT-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:43 +0000
To: [e-mail]
Path: comodo.net
From: Stephen Kent <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Software for PKI
Date: Tue, 13 Nov 2001 13:58:37 -0500
Organization: Comodo Research Labs	
Lines: 47
Message-ID: <p05010403b816de84bc36@[128.89.88.34]>
References:  <[e-mail]> <006301c168a2$7f1f8f90$010aa8c0@tsg1>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Trace: kylie.comodogroup.com 1037018863 24025 127.0.0.1 (11 Nov 2002 12:47:43 GMT)
Delivered-To: [e-mail]
X-Sender: [e-mail]
In-Reply-To: <006301c168a2$7f1f8f90$010aa8c0@tsg1>
To: <[e-mail]>
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

IETF working groups produce standards that vendors and users may or 
may not choose to employ. Ultimately, irrespective of whether we 
produce use cases or business cases for the work we do, the 
marketplace will decide if the standards are beneficial and relevant. 
Thus the value of the added documentation burden that Todd suggested 
is not clear. (The inclusion of rationale in standards is often a 
good idea, if it does not make the document too long or too hard to 
read. The PKIX Roadmap document is intended to capture much of the 
rationale and arguments associated with the development of PKIX 
standards. This is more than most WGs do in this respect.)

The IETF imposes certain requirements for advancement of documents in 
the standards process and it is not obvious that the PKIX WG is 
unique in a fashion that requires or motivates deviation from the 
procedures by which the rest of the IETF operates, in this regard.

We make decisions about the potential utility of a proposed work item 
when we adopt the item for the WG, e.g., add it to the charter. This 
decision ultimately rests with the WG chairs, who decide based on WG 
list discussions and based on their experience. I am aware of no 
precedent in the IETF that requires the sort of documentation Todd 
has suggested as a normal part of developing IETF standards, and thus 
I do not envision adopting this proposal as part of the charter for 
PKIX. I submitted the revised PKIX charter to the Security Areas 
directors several weeks ago and when they approve it, it will be 
posted to the IETF web site.

The discussion that has taken place under the subject heading has 
been very wide ranging. Much of the discussion centered on "what's 
wrong with PKI." This discussion often failed to make the critical 
distinction between problems associated with implementations of PKI 
technology, problems with specific PKI models, and problems with PKI 
standards. This WG is not responsible for broken implementations. We 
are not responsible for marketing hype claiming that PKI is a 
panacea. We are not responsible for the ways in which people may 
choose to use PKI technology, which may be a bad fit for their 
businesses. We are responsible for creating standards that are 
technically accurate, comprehensible, and which we believe address 
some non-trivial range of problems associated with reasonable uses of 
PKI technology in the Internet. This is a sufficiently difficult task 
that we are probably well advised to focus on it.

Steve



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCq4029631 for ietf-pkix-bks; Mon, 11 Nov 2002 04:52:04 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmgv28413 for <[e-mail]>; Mon, 11 Nov 2002 04:48:44 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyf-0006I1-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:41 +0000
To: [e-mail]
Path: comodo.net
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Which RFC specifies: E=x@y.z?
Date: Sun, 11 Nov 2001 16:05:03 +0100
Organization: stroeder.com
Lines: 27
Message-ID: <[e-mail]>
References: <000901c16a9f$d1e9f680$0500a8c0@arport>
Reply-To: [e-mail]
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018861 24025 127.0.0.1 (11 Nov 2002 12:47:41 GMT)
Delivered-To: [e-mail]
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.20 i686)
X-Accept-Language: de-DE, de, en
To: "[e-mail]" <[e-mail]>
X-Sender: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:
> 
> Although e-mail addresses are decprecated in Subject fields, this
> habit will probably not cease.  During our XML Dsig interperability testing
> we have found "dialects" in how rfc822 names are written symbolically.
> 
> Some (MS) use E=x while others like SUN use EMAIL=x
> 
> And I can't find the RFC!  Which one is it?
> 
> No matter what the answer is, this will be an interoperability issue

Yes, it is an interoperability issue. But the PKIX lib/application
used is responsible for that. An application should never rely on
attribute type name strings being used. It should handle the OID of
the attribute type directly.

Further I'd suggest to use LDAP string representation of DNs like
described in RFC 2253 (e.g. OpenSSL does it since some time if
explicitly requested). Note: The string representation will not be
reversible since the knowledge about the used character set of a
string (encoded as different ASN.1 string types) is lost and the
attribute type name is undefined too (OIDs could be used instead).

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCq3v29628 for ietf-pkix-bks; Mon, 11 Nov 2002 04:52:03 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmgv28396 for <[e-mail]>; Mon, 11 Nov 2002 04:48:43 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDye-0006HX-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:40 +0000
To: [e-mail]
Path: comodo.net
From: [e-mail] (Peter Gutmann)
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Verisign extensions
Date: Sun, 11 Nov 2001 07:20:18 +1300 (NZDT)
Organization: Comodo Research Labs	
Lines: 18
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
X-Trace: kylie.comodogroup.com 1037018860 24025 127.0.0.1 (11 Nov 2002 12:47:40 GMT)
Delivered-To: [e-mail]
To: [e-mail], [e-mail]
Cc: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Henrik StM-ehl <[e-mail]> writes:

>VeriSignCZAG extension. 

Country, zip, date of birth (age), and gender of cert owner, hashed/obfuscated
in some way.

Description = verisignCPSv1nsi (2 16 840 1 113733 1 7 1 1 2)

nsi = non-verified subscriber information.

(#include stdgrumble about Verisign never publishing details of anything it
 puts in its certs).

Peter.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCq2W29630 for ietf-pkix-bks; Mon, 11 Nov 2002 04:52:02 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmev28351 for <[e-mail]>; Mon, 11 Nov 2002 04:48:40 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyd-0006GA-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:39 +0000
To: [e-mail]
Path: comodo.net
From: [e-mail]
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: DNSSEC (RE: Software for PKI)
Date: Fri, 9 Nov 2001 10:16:41 -0700
Organization: Comodo Research Labs	
Lines: 49
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: kylie.comodogroup.com 1037018859 24025 127.0.0.1 (11 Nov 2002 12:47:39 GMT)
Delivered-To: [e-mail]
To: [e-mail]
Cc: "Anders Rundgren" <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
X-MIMETrack: Serialize by Router on SRVSMTP02/FDC(Release 5.0.8 |June 18, 2001) at 11/09/2001 11:30:23 AM
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

but the cache protocol has life-time specified nominal is in the range of
minutes to hours  ... which is much better than years for certificates. you
don't actually have to revoke a key ...  there is just the maintenance of
what is the valid key (if any) ... and the issue of what size caching
window that you are willing to tolerate for the data. A hypothetical key
compromise could take on the order of hours from occurance, discovery,
administrative to validate report, etc  .... so a reasonable policy might
still be a cache life-time of  an hour.

and if you were really paranoid you can also do a DNS transaction that
looks up the data directly from the server, bypassing the caching i.e.
client could choose to bypass whatever the infrastructure chosen policy for
cache life-time .... supporting both institutional-centric policy and
client-centric policy.




[e-mail] on 11/9/2001 9:57 AM wrote:

Lynn,

yes and no. One of the problems is that you cannot actively "revoke"
a key or a signature other than physically delete that information
from the DNS zone file. However, the DNS data will still be
cached in dozens of servers out there.

Cheers,

           Stefan.

-------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. [phone], Fax [phone]
E-Mail [e-mail], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B







Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCq2229627 for ietf-pkix-bks; Mon, 11 Nov 2002 04:52:02 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmgv28415 for <[e-mail]>; Mon, 11 Nov 2002 04:48:44 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyf-0006I8-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:41 +0000
To: [e-mail]
Path: comodo.net
From: [e-mail]
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: DNSSEC (RE: Software for PKI)
Date: Sun, 11 Nov 2001 11:58:35 -0700
Organization: Comodo Research Labs	
Lines: 61
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: kylie.comodogroup.com 1037018861 24025 127.0.0.1 (11 Nov 2002 12:47:41 GMT)
Delivered-To: [e-mail]
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
X-MIMETrack: Serialize by Router on SRVSMTP02/FDC(Release 5.0.8 |June 18, 2001) at 11/11/2001 01:00:01 PM
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

and from the archives on a long ago, far away project  ... price has come
down some ....

Date: 1 July 1985, 08:17:15 MDT
To:   WHEELER

Lynn,
re: your questions about the public key encryption unit
  The Racal-Milgo Datacryptor III uses a AMD DES chip plus some proprietary
logic for exchanging master keys using a public key approach.  The master
keys
are then used to encrypt the working keys which are actually used for data
encryption.  I have run the off the shelf units at 128kb full duplex
through
the V.35 interfaces contained in the unit.  They cost about $3,200 each,
single unit price.
  I have to emphasize they are link level encryptors (e.g. level 1) rather
than level 2 (e.g. only the data encrypted with addressing in the clear).
They won't do you much good for "session" or "file" encryption.
  The public key synopsis goes something like this -
1. At install time, two 60 digit prime numbers are acquired and retained in
   storage.  The 'seeds' are developed by a combination of an operator
   pressing a button to sample a clock source along with internal logic.
2. When a operator wants to move a master key online, he asks the remote
end
   for a one-time E key (56 bits plus 8 parity bits).
3. The remote end uses the two 60 digit prime numbers (with their 120 digit
   product) to create a E key and a D key.  They are "mathematically
related
   to the prime numbers and to each other" to quote the Racal
documentation.
4. The E key can't be used for decryption and the D key can only decrypt
   what has been encrypted with the E key.
5. The remote end retains the D key and sends the E key to the 'requestor'.
6. The local end generates a new master key, encrypts it with the E key he
   just received, and sends it to the remote end.
7. The remote end decrypts the transfer with the D key he retained, they
   exchange a test message for verification, and exchange a new working
key.
8. The E/D pair of keys are not reused.  Each exchange of a master key
causes
   a new pair to be created.  The E/D pair never leave the boxes, and can't
   be read out or displayed.  It takes about 8 seconds for the hardware to
   do the decryption of the received master key using the D key previously
   retained.




[e-mail] on 11/9/2001 12:19 pm wrote

These DNSSEC servers will not be practical until HW-crypto
support is down in the $100 region.   This may take another
5 years or so.  It is driven by the B2B market that needs such
servers as well.






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCq2A29629 for ietf-pkix-bks; Mon, 11 Nov 2002 04:52:02 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmhv28434 for <[e-mail]>; Mon, 11 Nov 2002 04:48:44 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyf-0006Iq-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:41 +0000
To: [e-mail]
Path: comodo.net
From: "Tom Gindin" <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Which RFC specifies: E=x@y.z?
Date: Mon, 12 Nov 2001 09:48:42 -0500
Organization: Comodo Research Labs	
Lines: 57
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-Trace: kylie.comodogroup.com 1037018861 24025 127.0.0.1 (11 Nov 2002 12:47:41 GMT)
Delivered-To: [e-mail]
Importance: Normal
To: [e-mail]
Cc: Anders Rundgren <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.8 SPR #s MIAS4UTJ8H JPOS4U8UWQ CMCY4QLP6R |August 29, 2001) at 11/12/2001 09:48:25 AM
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id fACEmZ804799
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id fACEmaq04802
X-Hops: 1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gABCmnv28567
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

     Just to add to the confusion, there's a second contender with
identical meaning:
emailAddress {1 2 840 113549 1 9 1}, defined in PKCS #9 (section 5.2.1 of
version 2.0).

          Tom Gindin


Michael Ströder <[e-mail]>@mail.imc.org on 11/12/2001 08:56:16
AM

Please respond to [e-mail]

Sent by:  [e-mail]


To:   Anders Rundgren <[e-mail]>
cc:   [e-mail]
Subject:  Re: Which RFC specifies: E=x@y.z?



Anders Rundgren wrote:
>
> This is slightly more complicated in XML Dsig compared to CMS.
> In CMS the signers' certificate is specified by ASN1 data that
> normally is one-to-one of the associated certificate.  The chance
> of misinterpretation is then zero.  In XML Dsig the Issuer, Subject
> etc. are given as UTF-8 strings which must be matched against the ASN
> representation.  Although this is also the case for LDAP, I
> believe XML Dsig which is used for "machines talking to
> machines" is likely to be more hurt by the historic lack of
> stringens in DN strings.

I don't know of any authorative registry mapping the OIDs of
attribute types to unambigous strings. If XML-DSIG relies on
something which isn't exactly defined XML-DSIG is flawed.

Using "Email" or simply "E" is somewhat strange anyway. IMHO PKI
applications should take a look into the LDAP world where "mail"
(RFC 2798) and "rfc822Mailbox" (RCF 1274) is used for
0.9.2342.19200300.100.1.3.

But this does not only affect XML-DSIG. It affects all components
which handle a string representation of a subject DN. E.g. web
applications using CGI-BIN environment vars set by the SSL-capable
web server.

Ciao, Michael.







Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCq2X29624 for ietf-pkix-bks; Mon, 11 Nov 2002 04:52:02 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmev28363 for <[e-mail]>; Mon, 11 Nov 2002 04:48:41 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyd-0006Ge-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:39 +0000
To: [e-mail]
Path: comodo.net
From: [e-mail]
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: DNSSEC (RE: Software for PKI)
Date: Fri, 9 Nov 2001 14:44:17 -0700
Organization: Comodo Research Labs	
Lines: 137
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: kylie.comodogroup.com 1037018859 24025 127.0.0.1 (11 Nov 2002 12:47:39 GMT)
Delivered-To: [e-mail]
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
X-MIMETrack: Serialize by Router on SRVSMTP02/FDC(Release 5.0.8 |June 18, 2001) at 11/09/2001 03:47:22 PM
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

yes, well, humm.

my wife and I had been doing these networky things
http://www.garlic.com/~lynn/internet.htm#0
http://www.garlic.com/~lynn/subtopic.html#hsdt
http://www.garlic.com/~lynn/subtopic.html#osi

as part of some generalized high-assurance data processing
http://www.garlic.com/~lynn/subtopic.html#lcmp
http://www.garlic.com/~lynn/subtopic.html#smp

anyway several years ago, we were doing some consulting to this financial
services company and somebody from this new, small client/server startup
wanted to do financial transactions and my wife and I got assigned to work
with the small startup (in part because we had worked with the people in
charge of the project in previous life):
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/2001i.html#52

in any case they had this thing that they were going to call SSL for
protecting the transaction/information in flight .... that involved these
things called certificates. As part of the assurance review ... there had
to be a detailed end-to-end business process audit ... that was
significantly more than end-to-end protocol assusrance audit.

Out of the end-to-end business process reviews and deploying the stuff in
operational environment (now frequently referred to as electronic commerce)
we happened to gain some working knowledge about where the security and
trust issues were. It has actually seen fairly wide-spread and succesful
deployment.

Some of this experience went into the financial industry work on a
electronic payment standard for all account-based transactions
http://www.garlic.com/~lynn/index.html#x959

and some of it went into attempting to apply public key authentication
technology to existing business and technology infrastructures:
http://www.garlic.com/~lynn/subtopic.html#sslcerts
http://www.garlic.com/~lynn/subtopic.html#radius
http://www.garlic.com/~lynn/index.html#aads

note that it is possible to apply public-key distribution as part of the
existing DNS infrastructure as in this discussion thread. Another
application of public-key authentication technology is to integrating it
into existing RADIUS (and/or other) client authentication infrastructure
.... effectively substituting the registration of a public key in place of
registration of a password. In the DNS case, it is to leverage a widely
deployed information distribution protocol to also distribute public keys.
In the RADIUS (and similar cases) it is for the relying-party to directly
use their own public-key registration database w/o actually distributing
the keys. There is something of a gray area with regard to the sematics of
the process ..... in one case it can be viewed as information push from the
database (sort of as in the DNS cache scenerio) and in the other there is a
information pull from the database (as in the case of real-time access by
RADIUS to the enterprise authentication database).

In any case, the DNS use of caching is a pure implementation thing. Lots of
the above .... all the requests always execute against the actual real-time
data .... as opposed to having a temporary cache.
Now, in database terms, from work that we did on distributed lock manager
for super-scaling database
http://www.garrlic.com/~lynn/subtopic.html#hacmp
as well as some experience working on design of CPU caches
http://www.garlic.com/~lynn/subtopic.html#smp

things can be stated in terms of strong memory consistency, to week memory
consistency, to fuzzy memory consistency. The degree of distributed memory
consistency tends to be somewhat dependent on the application requirements.
Financial transactions tend to have relatively strong memory consistency.
And for some cases, you avoid doing distributed memory at all and all
requests execute directly on the repository. Most public-key distribution
consistency issues are somewhat simplified because there aren't actually
real distributed transactions (changing public key values). All the
existing caching schemes have tended to be R/O caching (certificates can be
viewed as one form R/O distributed caching of information). The upside of
certificates is that they are useful for offline environments. The downside
of the existing certificate distribution schemas have effectively little
bound on the number of places that R/O copies might occur. DNS is
significantly better than that ... with the bounding not so much better in
space ... but significantly better bounded in time. It is reasonable to to
do a risk assurance on the DNS time-bounding and possibly dynamically
adjust values. Also, there is a much more robust distribution
infrastructure (from the services stand-point). By comparison, certificates
have tended to go to the entity registering the public key and then they do
arbritrary re-distribution. By comparision a distributed transaction
database that confirms to strick ACID properties will always be able to
predictably do transaction operations.

Similar to the RADIUS case is the application of registering public-keys at
financial institutions using effectively the same business process used to
register PINs (frequently seen in debit &/or atm related activities):
http://www.garlic.com/~lynn/nacharfi.htm
http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm

All of these can be done with a combination of RA technology (from the CA
world for registering public keys) and existing business processes
currently used for managing other types of authentication information (aka
technology upgrades while maintaining existing business processes .... as
opposed to trying to introduce radical surgery on business operations).

there has also been a lot of effort put into the hardware token effort:
http://www.garlic.com/~[e-mail]#straw
http://www.garlic.com/~lynn/index.html#aads

a lot of it tho has come out of prior experience in deploying complex,
industrial strength, dataprocessing environments.




[e-mail] at 11/09/2001 12:19 pm wrote:

Lynn,
This is interesting.  What you are saying is that server-based PKI (sort
of)
that generates fresh (or short-time cached) responses from a database
is the way to go.

This is essentially the same thing I have been pushing several years for
extranet authentication.  That each company server generates freshly
signed "tickets" (http://www.x-obi.com/purple) based on their databases
instead of issuing and distributing employee certificates.

Server-cryptography rulez!

These DNSSEC servers will not be practical until HW-crypto
support is down in the $100 region.   This may take another
5 years or so.  It is driven by the B2B market that needs such
servers as well.

Anders






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCq1p29620 for ietf-pkix-bks; Mon, 11 Nov 2002 04:52:01 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmfv28383 for <[e-mail]>; Mon, 11 Nov 2002 04:48:42 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDye-0006H4-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:40 +0000
To: [e-mail]
Path: comodo.net
From: "Pei, Mingliang" <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: RE: Any Organization Certificates out there?
Date: Fri, 9 Nov 2001 18:28:34 -0800
Organization: Comodo Research Labs	
Lines: 112
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: kylie.comodogroup.com 1037018860 24025 127.0.0.1 (11 Nov 2002 12:47:40 GMT)
Delivered-To: [e-mail]
To: "'Anders Rundgren'" <[e-mail]>, "Pei, Mingliang" <[e-mail]>, [e-mail]
Cc: "Hsiao, Wentsung" <[e-mail]>
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It is relatively new to add a DUNS number into certificates
by CA vendors. So it is true that few are DUNS-enabled today. 
I believe the private OID choice is due to the lack of reserved 
standard OID for DUNS number so far and meanwhile try to avoid 
confusion associated if adding a string of numbers as a regular 
OU field (it is DUNS or SSN or even other number? there is no 
standard way for a client to interpret it). This is just my 
personal understanding about OID choices.

Code signing certificate is another kind of real "Organization 
Certificates". It does represents the company from a user's 
point of view when downloading the signed software. 

As either a passport or driver's license can equally serves 
to identify an individual, different kinds of certificates 
exist to represent a company according to different usages. 
No single certificate seems to be able to serve all. Application 
context would need to define how it recognize a digital ID as 
representation of a company in the context. 

- Ming

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Friday, November 09, 2001 1:02 PM
To: Pei, Mingliang; [e-mail]
Cc: Hsiao, Wentsung
Subject: Re: Any Organization Certificates out there?


Ming,
Interesting.  I put this queston a week ago to [e-mail]
and got no such information!

Then I "dumpasn1":ed https://www.versign.com and there is
no such extension there.

I'm sure this information of yours is correct but it seems to be a
pretty well hidden secret.  And why not put DUNS in OID.2.5.4.5
so it is shows up where the other ID-stuff is?
Or as an extra O=DUNS:887878787?

Under all circumstances a short test verified that few are DUNS-enabled
today.

Anders

----- Original Message ----- 
From: "Pei, Mingliang" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>; <[e-mail]>
Cc: "Hsiao, Wentsung" <[e-mail]>
Sent: Friday, November 09, 2001 21:15
Subject: RE: Any Organization Certificates out there?



Hi Anders,

The server certificate issued by VeriSign actually meet your need.
"a unique ID" DUNS number is included in server certificates.
When a customer provides their DUNS# during enrollment for retail 
Secure/Global server ID to VeriSign CA, the certificate issued 
always includes the DUNS# in the server id extension which OID is 
2.16.840.1.113733.1.6.15

- Ming

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Tuesday, November 06, 2001 2:07 PM
To: [e-mail]
Subject: Any Organization Certificates out there?



Hi,
My company is spearheading an effort to create an all
PKI-enabled version of the OBI (Open Buying on the Internet)
standard.  A stumbling block is that the core is based on what
we refer to as a "Digital Company Paper", which is an
organization certificate.  Some people consider Web-server
certificates as organization certificates, and that is true to
some extent, but has a major limitation: A domain name may
be owned by one legal entity and used by many associated
legal entities.  And the typical (non-standardized) other
information like O=x and OU=y is essentially useless
as it is not guaranteed to be unique or stable.  L (Locality) is even
worse as companies relocate quite often.  What you need
are certificates that contains a unique ID in a specified
fictitious (CA-specific) or externally administered
naming domain (National, DUNS etc).

Without such certificates, PKI-based B2B-business will be hard
to achieve as RP's sort of have to guess what IBM legal unit is
associated with a "secure.ibm.com" web-server certificate.
Particularly long-term, usage will break every now and
then due to the "imprecise" way, non-DNS information is applied.
And each renewed cerificate or changed web-server name (like
"secure0.ibm.com" to "secure9.ibm.com" replaces "secure.ibm.com")
is also a possible source of RP-troubles.  At least if plug-and-play
is called for, as in OBI Express.

Do anybody know if there are any *real* organization certificates
out there, available on a *global scale*?

Regards
Anders Rundgren
X-OBI
+46 70 - 627 74 37



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpvK29619 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:57 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmgv28391 for <[e-mail]>; Mon, 11 Nov 2002 04:48:43 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDye-0006HI-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:40 +0000
To: [e-mail]
Path: comodo.net
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Any Organization Certificates out there?
Date: Sat, 10 Nov 2001 15:31:32 +0100
Organization: stroeder.com
Lines: 20
Message-ID: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018860 24025 127.0.0.1 (11 Nov 2002 12:47:40 GMT)
Delivered-To: [e-mail]
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.20 i686)
X-Accept-Language: de-DE, de, en
To: "[e-mail]" <[e-mail]>
X-Sender: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Pei, Mingliang" wrote:
> 
> It is relatively new to add a DUNS number into certificates
> by CA vendors. So it is true that few are DUNS-enabled today.

Where is it documented at Verisign's site?

I already tried without success to get some more information about
how to decode other Verisign vendor-specific extensions like:

Description = verisignCZAG (2 16 840 1 113733 1 6 3)
Description = verisignInBox (2 16 840 1 113733 1 6 6)
Description = verisignCPSv1notice (2 16 840 1 113733 1 7 1 1 1)
Description = verisignCPSv1nsi (2 16 840 1 113733 1 7 1 1 2)

Well, if applications cannot decode it how to make use of it?

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpvJ29616 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:57 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmjv28488 for <[e-mail]>; Mon, 11 Nov 2002 04:48:48 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyh-0006Jy-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:43 +0000
To: [e-mail]
Path: comodo.net
From: Bernd Matthes <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: timestamp messageImprint
Date: Tue, 13 Nov 2001 12:31:43 +0100
Organization: Comodo Research Labs	
Lines: 92
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msFCA97144119F1C1EFB28FA8D"
X-Trace: kylie.comodogroup.com 1037018863 24025 127.0.0.1 (11 Nov 2002 12:47:43 GMT)
Delivered-To: [e-mail]
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: de,en
To: ietf pkix <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------msFCA97144119F1C1EFB28FA8D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi All!

I wish to timestamp a digital signature (not the document which is
signed),
that mean a digital signature (PKCS#7) should exist before a particular
time.
As RFC3161 puts it:
"The TSA's role is to time-stamp a datum to establish evidence
   indicating that a datum existed before a particular time.  This can
   then be used, for example, to verify that a digital signature was
   applied to a message before the corresponding certificate was
revoked..."

My question is: 
Which part of the signerInfo should be used to create the messageImprint
for the time-stamp query?

As first I could hash the DER encoded authenticatedAttributes.
That's would be the same hash value as in the encryptedDigest as
well, but readable without any decryption process. I think this is 
a security hole.

IMHO it's better to use the encryptedDigest itself to create the
messageImprint to ensure/proof that a signature was created 
with a particular signer private key before a particular time.

What's Your view of the matter?


with kind regards

-- 
Bernd Matthes               Celo Communications GmbH
Senior Software Engineer          - a Gemplus Company
Dipl.-Ing.(FH)              mailto:[e-mail]
------------------------------------------------------------
"Complexity breeds bugs. Bugs prevent adoption,
lack of adoption results in death. Death not good."
--------------msFCA97144119F1C1EFB28FA8D
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIH6gYJKoZIhvcNAQcCoIIH2zCCB9cCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
Bb0wggKMMIIB9aADAgECAgMEZkswDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTAzMTYxNDA0MzJaFw0wMjAzMTYxNDA0MzJa
MEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxKDAmBgkqhkiG9w0BCQEWGWJl
cm5kLm1hdHRoZXNAZ2VtcGx1cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAA
w8BVu1sFXcFZ0RiaI1E7cQGzD/ilmkCBs2shzSy/ORqzS5XCQvXat5tbDgWQg1qKKvh4gvly
pgwvJtnyOyqUBJ6/L+BiFHYsSgFZZ8dWCSnJFPWbYtvrAzvN3IhkRgkOiit/jo6mIOFDjQKm
ZbxC2sQzcuf3eUJVL5zXvjmnAgMBAAGjNjA0MCQGA1UdEQQdMBuBGWJlcm5kLm1hdHRoZXNA
Z2VtcGx1cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBy4Avl5Chdn6uQ
MnVuQd14NYuqtWZaAPL84JN0P6mEfrSxjvb/XsQNXBnfFeBe9dC28ENTWQqboh2EYlhM1LjD
+BmyyORFcEbJWqQce76vBXu7HAQXo+3GlesUKy3bW34z/bMdbiovChqBxTCbSxe1qCzxdFS3
WDxx+LaaIFJUGDCCAykwggKSoAMCAQICAQwwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYT
AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE
ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqG
SIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAwMDBa
Fw0wMjA4MjkyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBl
MRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlm
aWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjgu
MzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZgpcO
40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqdknWo
J67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFpAgMB
AAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzASBgNV
HRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQBzG28mZYv/
FTRLWWKK7US+ScfoDbuPuQ1qJipihB+4h2N0HG23zxpTkUvhzeY42e1Q9DpsNJKs5pKcbsEj
AcIJp+9LrnLdBmf1UG8uWLi2C8FQV7XsHNfvF7bViJu3ooga7TlbOX00/LaWGCVNavSdxcOR
L6mWuAU8Uvzd6WIDSDGCAfUwggHxAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM
V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsG
A1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWls
IFJTQSAyMDAwLjguMzACAwRmSzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTExMzExMzE1MFowIwYJKoZIhvcNAQkEMRYEFNZc
NMDkMo80WnI31tGNesY3WIOfMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGAtayv77xx7hUcNdBP+116adYdc7IvhB+5itM6AZhEDNtwfuJFtYAcu6e/
TI4LDvSHrpywa+CR2HFBw3F75rwywUl3VFmZnN00/dnafDibbXuWT7+IEAKsewp1qwXPiOIx
kCzGMPcTsCytDa1qOYyHYlKFhAkY3n29zs/44Dm4qIc=
--------------msFCA97144119F1C1EFB28FA8D--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpvk29615 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:57 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmjv28484 for <[e-mail]>; Mon, 11 Nov 2002 04:48:48 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyg-0006Ja-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:42 +0000
To: [e-mail]
Path: comodo.net
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Which RFC specifies: E=x@y.z?
Date: Mon, 12 Nov 2001 21:42:58 +0100
Organization: stroeder.com
Lines: 12
Message-ID: <[e-mail]>
References: <000901c16a9f$d1e9f680$0500a8c0@arport> <[e-mail]> <009801c16b5f$4638fe90$0500a8c0@arport> <[e-mail]> <[e-mail]> <00df01c16b9f$9db98dc0$0500a8c0@arport>
Reply-To: [e-mail]
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018862 24025 127.0.0.1 (11 Nov 2002 12:47:42 GMT)
Delivered-To: [e-mail]
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.20 i686)
X-Accept-Language: de-DE, de, en
To: [e-mail]
X-Sender: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:
> 
> It is true that XML DSIG allows a number of ways to identify the signing
> key.  Some are 100% safe but some are not.  What the majority will use
> is still to be seen.

Which translates to "XML-DSIG - yet another PKI standard too
complicated to be ever implemented completely and correctly."

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpqO29614 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:52 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmgv28398 for <[e-mail]>; Mon, 11 Nov 2002 04:48:43 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDye-0006Hd-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:40 +0000
To: [e-mail]
Path: comodo.net
From: [e-mail] (Peter Gutmann)
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Any Organization Certificates out there?
Date: Sun, 11 Nov 2001 07:09:39 +1300 (NZDT)
Organization: Comodo Research Labs	
Lines: 16
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
X-Trace: kylie.comodogroup.com 1037018860 24025 127.0.0.1 (11 Nov 2002 12:47:40 GMT)
Delivered-To: [e-mail]
To: [e-mail], [e-mail], [e-mail]
Cc: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Pei, Mingliang" <[e-mail]> writes:

>The server certificate issued by VeriSign actually meet your need. "a unique
>ID" DUNS number is included in server certificates. When a customer provides
>their DUNS# during enrollment for retail Secure/Global server ID to VeriSign
>CA, the certificate issued always includes the DUNS# in the server id
>extension which OID is 2.16.840.1.113733.1.6.15

So 2.16.840.1.113733.1.6.15 = "Verisign serverID"?  Are any of these OIDs ever
going to be documented anywhere?  I've managed to add a few to dumpasn1 based
on reverse-engineering and/or guesswork, but it'd be useful to have the full
list in there.

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpqP29613 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:52 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmgv28418 for <[e-mail]>; Mon, 11 Nov 2002 04:48:44 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyf-0006ID-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:41 +0000
To: [e-mail]
Path: comodo.net
From: [e-mail] (Peter Gutmann)
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: DNSSEC (RE: Software for PKI)
Date: Mon, 12 Nov 2001 09:19:27 +1300 (NZDT)
Organization: Comodo Research Labs	
Lines: 19
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
X-Trace: kylie.comodogroup.com 1037018861 24025 127.0.0.1 (11 Nov 2002 12:47:41 GMT)
Delivered-To: [e-mail]
To: [e-mail], [e-mail]
Cc: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] writes:
>These DNSSEC servers will not be practical until HW-crypto support is down in
>the $100 region.   This may take another 5 years or so.  It is driven by the
>B2B market that needs such servers as well.

It'll never get into the $100 region.  The same rule that says that a single
frame of CGI takes 20 minutes to render no matter what year it is (as hardware
and algorithms get better, more complexity is added to the scene which negates
the speedups) also says that crypto hardware will never sell for less than
about $500.

OTOH if you mean the crypto hardware which is labelled "AMD Athlon" then it's
already in this price range, and performs better than many $500 cards.

Peter (who has a Racal Datacryptor somewhere in his collection... if anyone's
       ever tossing out old crypto hardware, feel free to dispose of it in my
       direction so I can add it to my museum).



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpq429608 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:52 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmjv28491 for <[e-mail]>; Mon, 11 Nov 2002 04:48:48 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyh-0006KJ-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:43 +0000
To: [e-mail]
Path: comodo.net
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: OID repository (was Re: Any Organization Certificates out there?)
Date: Tue, 13 Nov 2001 16:40:14 +0100
Organization: stroeder.com
Lines: 15
Message-ID: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018863 24025 127.0.0.1 (11 Nov 2002 12:47:43 GMT)
Delivered-To: [e-mail]
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.20 i686)
X-Accept-Language: de-DE, de, en
To: Tom Gindin <[e-mail]>
Cc: [e-mail]
X-Sender: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom Gindin wrote:
> 
>      There is one (more or less) at http://www.alvestrand.no/objectid/.
> Should this group try to encourage vendors to put their OID's there and
> link to it from the PKIX web site?  Some vendors are already there.

Peter Gutmann's dumpasn1.cfg is another one and has the advantage of
being machine-readable but being limited to PKI-related OIDs.

I remember some discussion on the XML-DSIG list about an URL scheme
for OIDs. Any results there? Rich? Anders?

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpqT29612 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:52 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmkv28504 for <[e-mail]>; Mon, 11 Nov 2002 04:48:48 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyi-0006L0-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:44 +0000
To: [e-mail]
Path: comodo.net
From: Peter Sylvester <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: RE: TSA messages for http ?
Date: Wed, 14 Nov 2001 11:32:56 +0100 (MET)
Organization: Comodo Research Labs	
Lines: 40
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
X-Trace: kylie.comodogroup.com 1037018864 24025 127.0.0.1 (11 Nov 2002 12:47:44 GMT)
Delivered-To: [e-mail]
To: [e-mail], [e-mail], [e-mail], [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > 
> > > another TSA (what is actually quite possible), I would have
> > > to deal with all the socket-based things like polling, negative
> > > reply, etc.
> > > 
> > > At the moment, in such cases, I return an error, but well,
> > > it is not very correct, from my point of view...
> > IMHO the polling feature in the socket transport protocol is
> > not a feature of the TSP protocol, if there is a transport
> > mapper between HTTP and the socket protocol, then the
> > http server would just waitabit and loop if there are responses
> > for polling. 
> > 
> 
> Yes, I agree, but this means that a HTTP solution could be
> quite different from a socket-based solution.
Not really. In an HTTP transport protocol the client must
be prepared to handle http error events, location etc. This
is probably more work that an reaction to a poll request.

> On the other hand, to wait "a little" is no solution.
> You know exactly that the pollRep and the partialMsgRep include
> a so-called time to check back. So, at least theoretically,
> I should wait the specified time (10-20-60 seconds, why not?)
> and then try again.
> This doesn't sound like a good solution...

Aren't you describing a garbage in/garbage out situation? 

Why don't You want to wait 10-60 seconds? because there
may actually be a MIM attack? Or, if your HTTP front ends
policy requires to reply within 10 seconds, then you may 
want to create an error message saying that the time source is 
not available.

Anyway, if Your TSA that uses the socket protocol has a strange
behaviour, there is no need to correct this in a HTTP frontend. 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpkU29605 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:46 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmjv28486 for <[e-mail]>; Mon, 11 Nov 2002 04:48:48 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyh-0006Jo-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:43 +0000
To: [e-mail]
Path: comodo.net
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Which RFC specifies: E=x@y.z?
Date: Tue, 13 Nov 2001 00:40:20 +0100
Organization: stroeder.com
Lines: 17
Message-ID: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018862 24025 127.0.0.1 (11 Nov 2002 12:47:42 GMT)
Delivered-To: [e-mail]
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.20 i686)
X-Accept-Language: de-DE, de, en
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
X-Sender: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:
> 
> "Tom Gindin" <[e-mail]> writes:
> 
> >Just to add to the confusion, there's a second contender with identical
> >meaning: emailAddress {1 2 840 113549 1 9 1}, defined in PKCS #9 (section
> >5.2.1 of version 2.0).
> 
> What, only two?  There are (at least) rfc822Name, rfc822Mailbox, emailAddress,
> mail, and email.  There may be more which I haven't discovered yet.

Peter, are you also talking about OIDs or the names for attribute
types? Tom and me were talking about OIDs.

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpkx29607 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:46 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmgv28414 for <[e-mail]>; Mon, 11 Nov 2002 04:48:44 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyf-0006Hx-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:41 +0000
To: [e-mail]
Path: comodo.net
From: Aram Perez <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: signed e-mail
Date: Sun, 11 Nov 2001 07:12:04 -0800
Organization: Comodo Research Labs	
Lines: 17
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7BIT
X-Trace: kylie.comodogroup.com 1037018861 24025 127.0.0.1 (11 Nov 2002 12:47:41 GMT)
Delivered-To: [e-mail]
To: PKIX <[e-mail]>
X-Mailer: Apple Mail (2.472)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Friday, November 9, 2001, at 09:34  AM, Rob G Weemhoff wrote:

> To start with, why are we, as security advocates, not all using signed
> e-mail?

Because we are humans and we trust the Internet mail system. With all 
the respect they are due, you can tell the emails that come from Bob 
Juneman, Lynn Wheeler, Peter Gutman, Peter Williams, Steve Kent and 
others and hence we have an implicit way of verifying and trusting that 
the emails did actually come from those persons. And this implicit 
verification and trust has nothing to do with any type of PKI.

Just my opinion,
Aram Perez




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpjo29603 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:45 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmkv28507 for <[e-mail]>; Mon, 11 Nov 2002 04:48:48 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyi-0006LK-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:44 +0000
To: [e-mail]
Path: comodo.net
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: RFC2253 e-mail address
Date: Wed, 14 Nov 2001 13:18:35 +0100
Organization: stroeder.com
Lines: 17
Message-ID: <[e-mail]>
References: <000901c16a9f$d1e9f680$0500a8c0@arport> <[e-mail]> <009801c16b5f$4638fe90$0500a8c0@arport> <[e-mail]> <009c01c16d05$a28231b0$0500a8c0@arport>
Reply-To: [e-mail]
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018864 24025 127.0.0.1 (11 Nov 2002 12:47:44 GMT)
Delivered-To: [e-mail]
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.20 i686)
X-Accept-Language: de-DE, de, en
To: Anders Rundgren <[e-mail]>
Cc: [e-mail]
X-Sender: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:
> 
> In 2253 there is a paragraph 2.4 saying that if there are no
> Attribute value defined for it (like e-email) it should be
> outputted as 1.2.840.113549.1.9.1=#AD45FE
> I.e. given as HEX!
> 
> Is this a correct interpretation?  Yeck!

You're mixing attribute *type* with attribute *value* here. Reread
the paragraph. It only talks about string representation of
attribute values. E-Mail addresses are you usually IA5String and
therefore indeed have a string representation.

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpja29606 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:45 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmiv28457 for <[e-mail]>; Mon, 11 Nov 2002 04:48:45 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyg-0006JQ-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:42 +0000
To: [e-mail]
Path: comodo.net
From: <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: PKI and trust.....(changing topic a bit from secure email)
Date: Mon, 12 Nov 2001 10:50:52 -0800
Organization: Comodo Research Labs	
Lines: 154
Message-ID: <001201c16baa$f47efd60$8119fea9@Nerdvana2>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018862 24025 127.0.0.1 (11 Nov 2002 12:47:42 GMT)
Delivered-To: [e-mail]
To: <[e-mail]>
Cc: <[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <[e-mail]>
Importance: Normal
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ah, so we are back to one of the original questions of everyday
transactions - Who do I trust and just how much do I really trust them?

On an everyday basis, people everywhere apply some decision making process
(with or without full awareness of the process) to every transaction that
occurs between them. To take this a step further, business policy applied to
computing systems often tries to make this sort of decision process and
apply it to applications.  PKI is one way that this trust binding is
attempted and it often fails quite miserably. Humans seem to do this
relatively effortlessly based on thier experiences.

What's really wrong with PKI is that is it is difficult for most people to
implement and costly to use and it just doesn't happen as quickly as some
human judgment call on who they trust in any transaction.  Where is the
granularity of trust levels, the recognition that trust is temporal and
transitive presented in a fairly simple way for the everyday programmer use?

We can now plaster the world with X509 certificates in various forms that
work the way it was intended (and this has taken several years) but we as a
group have done little to make it easy and relatively idiot proof to use PKI
in applications (and there are many
perfect idiots in our wide world).

I have looked into and tested many a CA vendor's toolkit and let me say it
just isn't easy to use any of them. Where is the application enabling
middleware that is easy to use? (Yes, there are several other standards
groups addressing this is some piecemeal fashion and there are some vendors
who are beginning to address this space.)

 I look at a lot of the work being done with PKI and XML in wonderment of
really allowing the "average"  (read, less experienced) programmer who will
follow some standard and then really botch things up, expose keys, etc due
to lack of knowledge on how to do it securely.

Let's get real and do something about all this, that makes PKI an easy and
reliable method of enabling trust on an everyday basis with all the goodness
that PKI offers instead of making it so difficult that the average user
would rather get a root canal than use PKI.

Just my opinion,

	Jean Pawluk


PS As an architect and senior manager I am often astounded how many firms do
not know thier own business well enough to decide what needs to be secured.

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Henrik Bergman
Sent: Monday, November 12, 2001 7:03 AM
To: todd glassey
Cc: [e-mail]; [e-mail]
Subject: Re: Signed e-mail



Todd, I mean

1. humans, e-mail read and processed by you and me.
2. computers, business transactions between business systems over Internet.
Data transferred between
systems without any manual interception. Computers that are used in business
or processing industry.

And ofcause "2. computers" are always some kind of digital agents in service
for humans in the end.
But they are without human control in the daily life transactions. The human
part comes later in the
process.

Can anyone else understand this??

/Henrik

todd glassey wrote:

> ----- Original Message -----
> From: "Henrik Bergman" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>
> Sent: Sunday, November 11, 2001 9:55 PM
> Subject: Signed e-mail
>
> >
> > >Khaja, you are pointing to a very important thing.
> > >
> > >The need of signed messages for two categories:
> > >1. Humans
> > >2. Computers
>
> You of course mean "Too their Digital Agents"
>
> > >
> > >For humans, the need isn't very big if we are talking about
> > >authentic messages. I think many of us
> > >already know what contents a message could contain. If it doesn't
> > >contain things from that area, we
> > >will suspect that something is wrong. There for the value for signed
> > >e-mails  is limited. Especially
> > >is you consider how much work it usually is to maintain your
> > >certificates and program installations.
> > >
> > >If we continue to the next category, computers, the need is quite
> > >different. We still don't have any
> > >Java-objects for AI around telling the business application when we
> > >should suspect the transaction
> > >to be faulty. Therefor computer to computer in B2B is an ideal
> > >situation for PKI. But as you pointed
> > >out, the interoperability between different CA's is very low. And I
> > >remember a long lived discussion
> > >on this list about "Basic Cert-2-Directory mapping". The discussion
> > >showed (at least myself) that
> > >standards do not tell anything about what (minimum) a certificate
> > >should contain, only what it COULD
> > >contain. This opens a wide variety of certificates, all following
> > >the standard of cause, that
> > >confuses the market. This will lead us to a discussion about the
> > >need for permanent identifiers.
> > >
> > >Bob once said, the only this a CA could guarantee is a unique (with
> > >this CA) number. Everything else
> > >is just a snapshot (Bob didn't said that, I added it!) and will vary
> > >over the time.
> > >
> > >So what's the conclusion?
> > >
> > >For me it's that certificates and signed messages should be used in
> > >B2B between computers
> > >(especially for $1M transactions).
> > >Certificates should be simple (subject contents), as most vital and
> > >dynamic information is available
> > >from other sources ONLINE!
> > >
> > >Regards
> > >
> > >Henrik Bergman
> > >X-OBI AB
> >
> > --
> > __________________________________________
> > Henrik Bergman, X-OBI, mob [phone]
> > e-mail: [e-mail]
> >
> >
> >

--
__________________________________________
Henrik Bergman, X-OBI, mob [phone]
e-mail: [e-mail]





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpi929602 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:44 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmiv28458 for <[e-mail]>; Mon, 11 Nov 2002 04:48:46 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyg-0006JU-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:42 +0000
To: [e-mail]
Path: comodo.net
From: Andreas Sterbenz <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Which RFC specifies: E=x@y.z?
Date: Mon, 12 Nov 2001 19:15:14 +0000
Organization: Comodo Research Labs	
Lines: 30
Message-ID: <[e-mail]>
References: <000901c16a9f$d1e9f680$0500a8c0@arport>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018862 24025 127.0.0.1 (11 Nov 2002 12:47:42 GMT)
Delivered-To: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5) Gecko/20011011
X-Accept-Language: en-us
To: Anders Rundgren <[e-mail]>
CC: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:

> Although e-mail addresses are decprecated in Subject fields, this
> habit will probably not cease.  During our XML Dsig interperability testing
> we have found "dialects" in how rfc822 names are written symbolically.
> 
> Some (MS) use E=x while others like SUN use EMAIL=x
> 
> And I can't find the RFC!  Which one is it?
> 
> No matter what the answer is, this will be an interoperability issue

If by SUN you mean the code that is in J2SE, the situation is this:

  . cert.getSubjectDN().getName() returns a String in an implementation 
dependent format. In case of the Sun X509Certificate implementation, an 
RFC1779 style syntax extended with common non-standard keywords such as 
EMAIL is used.

  . cert.getSubjectX500Principal().getName() return a String in RFC2253 
format. The PKCS#9 email address attribute is encoded using the OID 
format. This API is new in 1.4, currently in beta. See also 
http://java.sun.com/j2se/1.4/docs/api/javax/security/auth/x500/X500Principal.html

If you have any other questions, please contact me off-list.

Andreas.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpid29600 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:44 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmkv28524 for <[e-mail]>; Mon, 11 Nov 2002 04:48:49 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyi-0006MP-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:44 +0000
To: [e-mail]
Path: comodo.net
From: "Anders Rundgren" <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: RFC2253 e-mail address
Date: Thu, 15 Nov 2001 13:35:52 +0100
Organization: Comodo Research Labs	
Lines: 44
Message-ID: <002101c16dd2$134eb6d0$0500a8c0@arport>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: kylie.comodogroup.com 1037018864 24025 127.0.0.1 (11 Nov 2002 12:47:44 GMT)
Delivered-To: [e-mail]
To: <[e-mail]>, "Ramsay, Ron" <[e-mail]>
Cc: <[e-mail]>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id fAFCZMY24609
X-Hops: 1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gABCmxv28691
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

OOOoops!
This "simple" question was apparently not that trvial..

It seems that the XMLDsig designers failed to realize that an element

        <X509SignatureCertificate
            Subject="Optional string in arbitrary interpretation"
            Issuer="Optional string in arbitrary interpretation"
            Serial="Optional integer">base64certblob</X509SignatureCerificate>

would have reduced the problem to NIL instead of going into string matching which
seems to be a real PITA and also looks like s---t.

Anders

----- Original Message -----
From: "Michael Ströder" <[e-mail]>
To: "Ramsay, Ron" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, November 15, 2001 11:22
Subject: Re: RFC2253 e-mail address



"Ramsay, Ron" wrote:
>
> So, why isn't it a real solution. You code the object identifier and wrap
> the value:
>
> 1.3.6.1.4.1.1466.115.121.1.41=#0411726f6e2e726a6d7361794063612e636f6d

Because it's unclear which BER-encoding to use for the string type?
E.g. if CN contains NON-ASCII chars and the attribute value is
encoded as T61String. Which string type to use for the BER encoding?
The answer is clear for LDAP (UTF-8-encoded Unicode wrapped in OCTET
STRING). But for PKIX?

Ciao, Michael.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpgR29599 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:42 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmjv28485 for <[e-mail]>; Mon, 11 Nov 2002 04:48:49 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyg-0006Je-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:42 +0000
To: [e-mail]
Path: comodo.net
From: [e-mail] (Peter Gutmann)
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Which RFC specifies: E=x@y.z?
Date: Tue, 13 Nov 2001 09:49:30 +1300 (NZDT)
Organization: Comodo Research Labs	
Lines: 16
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
X-Trace: kylie.comodogroup.com 1037018862 24025 127.0.0.1 (11 Nov 2002 12:47:42 GMT)
Delivered-To: [e-mail]
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Tom Gindin" <[e-mail]> writes:

>Just to add to the confusion, there's a second contender with identical
>meaning: emailAddress {1 2 840 113549 1 9 1}, defined in PKCS #9 (section
>5.2.1 of version 2.0).

What, only two?  There are (at least) rfc822Name, rfc822Mailbox, emailAddress,
mail, and email.  There may be more which I haven't discovered yet.

(My code resolves the mess by mapping any of them to the CRYPT_CERTINFO_EMAIL
attribute (alised to CRYPT_CERTINFO_RFC822NAME), this has worked fine for the
several years it's been in use).

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpge29598 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:42 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmgv28429 for <[e-mail]>; Mon, 11 Nov 2002 04:48:44 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyf-0006Ig-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:41 +0000
To: [e-mail]
Path: comodo.net
From: Jean-Marc Desperrier <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Which RFC specifies: E=x@y.z?
Date: Mon, 12 Nov 2001 15:52:20 +0100
Organization: Certplus
Lines: 18
Message-ID: <[e-mail]>
References: <000901c16a9f$d1e9f680$0500a8c0@arport> <[e-mail]> <009801c16b5f$4638fe90$0500a8c0@arport>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018861 24025 127.0.0.1 (11 Nov 2002 12:47:41 GMT)
Delivered-To: [e-mail]
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
To: [e-mail]
X-OriginalArrivalTime: 12 Nov 2001 14:52:17.0309 (UTC) FILETIME=[9F760CD0:01C16B89]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:

> BTW, neither Email= nor E= are to be found in the referred RFC.
> I guess one should use the OID for that one as you suggest.

Anders, it sound like you still haven't realised this OID has been created by RSA
(it's in the RSA OID arc) and was first described in the PKCS#9 document.

The name RSA gave it in pkcs#9 is emailAddress.

> To only use OIDs is an option but looks awful.  The point with
> XML was that you should be able to read it as well.

The name never have really been normative in the ASN1/DER world, OIDs always were
the real reference.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpdk29595 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:39 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmhv28447 for <[e-mail]>; Mon, 11 Nov 2002 04:48:50 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyg-0006JF-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:42 +0000
To: [e-mail]
Path: comodo.net
From: "Anders Rundgren" <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Which RFC specifies: E=x@y.z?
Date: Mon, 12 Nov 2001 18:29:42 +0100
Organization: Comodo Research Labs	
Lines: 37
Message-ID: <00df01c16b9f$9db98dc0$0500a8c0@arport>
References: <000901c16a9f$d1e9f680$0500a8c0@arport> <[e-mail]> <009801c16b5f$4638fe90$0500a8c0@arport> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018862 24025 127.0.0.1 (11 Nov 2002 12:47:42 GMT)
Delivered-To: [e-mail]
To: "Rich Salz" <[e-mail]>
Cc: <[e-mail]>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Rich,
It is true that XML DSIG allows a number of ways to identify the signing
key.  Some are 100% safe but some are not.  What the majority will use
is still to be seen.  

Anders


----- Original Message ----- 
From: "Rich Salz" <[e-mail]>
To: <[e-mail]>
Cc: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Monday, November 12, 2001 17:49
Subject: Re: Which RFC specifies: E=x@y.z?


> If XML-DSIG relies on
> something which isn't exactly defined XML-DSIG is flawed.

It doesn't, and it isn't. :)

XML DSIG allows a number of ways to identify a sigining key, including:
issuer and serial# (number and string, respectively)
subject name (string)
x509 certificate (base64 encoded DER)
subject key identifier (base64 encoded value [i.e., not DER])
The spec says that the DN strings SHOULD be compliant with RFC2253,
using the official IETF meaning of SHOULD.
/r$

-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpWO29585 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:32 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmgv28427 for <[e-mail]>; Mon, 11 Nov 2002 04:48:44 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyf-0006IX-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:41 +0000
To: [e-mail]
Path: comodo.net
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: signed e-mail
Date: Mon, 12 Nov 2001 11:00:46 +0100
Organization: stroeder.com
Lines: 26
Message-ID: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018861 24025 127.0.0.1 (11 Nov 2002 12:47:41 GMT)
Delivered-To: [e-mail]
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.20 i686)
X-Accept-Language: de-DE, de, en
To: [e-mail]
X-Sender: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Khaja E. Ahmed" wrote:
> 
> 1.) Benefit.  It adds too little value in the instance being discussed. The
> infrastructures is not quite there yet so proper and complete path
> validation not always possible.  The certificates are not interoperable
> enough in practice. There is frequently no way of checking revocation
> status.
> 2.) Cost.  It has not crossed the threshold of being easy enough to use all
> the time, even by the judgment of security experts.
> 
> I happen to agree with this view for signed email on this list.
> 
> What worries me however is that in discussions with senior management and
> CIOs of 4 B2B exchanges (2 of them big name) this argument was applied to
> signed transactions that are valued at $1M average. Surprisingly, even the
> point that Adam Perez makes about being able to recognize "implicitly" who
> wrote the email was applied to purchase orders and reverse auctions.

It's just a matter of risk managment. It's up to the application
owner to decide if he wants to live with that risk or not. In most
cases there is in fact a human being processing the transaction and
validating the request. Especially when it comes to the $1M range.

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpWk29587 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:32 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmkv28527 for <[e-mail]>; Mon, 11 Nov 2002 04:48:49 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyj-0006MW-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:45 +0000
To: [e-mail]
Path: comodo.net
From: Stephen Kent <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Software for PKI
Date: Thu, 15 Nov 2001 15:14:03 -0500
Organization: Comodo Research Labs	
Lines: 23
Message-ID: <p05010409b819d219422a@[128.89.88.34]>
References:  <[e-mail]>	 <006301c168a2$7f1f8f90$010aa8c0@tsg1> <p05010403b816de84bc36@[128.89.88.34]> <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
X-Trace: kylie.comodogroup.com 1037018865 24025 127.0.0.1 (11 Nov 2002 12:47:45 GMT)
Delivered-To: [e-mail]
X-Sender: [e-mail]
In-Reply-To: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id fAFKJm822152
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id fAFKJnW22155
X-Hops: 1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gABCmxv28706
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 1:09 AM +0100 11/14/01, Michael Ströder wrote:
>Stephen Kent wrote:
>>
>>  This WG is not responsible for broken implementations.
>
>I disagree. If a standard is very complicated and features are most
>times optional it's difficult too implement it correctly and
>complete. Therefore the designers of a security standard are IMHO
>indeed somewhat responsible for broken implementations.
>
>Ciao, Michael.

Michale,

You are right that the more complex a standard becomes, the harder it 
is to implement, and thus the more likely to be broken. But, what 
constitutes a necessary level of complexity, to accommodate a range 
of legitimate "requirements" vs. what is "excessive complexity" is a 
matter of judgement.

Steve



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpUG29586 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:30 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmgv28401 for <[e-mail]>; Mon, 11 Nov 2002 04:48:43 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyf-0006Hm-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:41 +0000
To: [e-mail]
Path: comodo.net
From: "Anders Rundgren" <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Which RFC specifies: E=x@y.z?
Date: Sun, 11 Nov 2001 11:58:38 +0100
Organization: Comodo Research Labs	
Lines: 14
Message-ID: <000901c16a9f$d1e9f680$0500a8c0@arport>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018861 24025 127.0.0.1 (11 Nov 2002 12:47:41 GMT)
Delivered-To: [e-mail]
To: <[e-mail]>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Although e-mail addresses are decprecated in Subject fields, this
habit will probably not cease.  During our XML Dsig interperability testing
we have found "dialects" in how rfc822 names are written symbolically.

Some (MS) use E=x while others like SUN use EMAIL=x

And I can't find the RFC!  Which one is it?

No matter what the answer is, this will be an interoperability issue

Anders




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpKY29575 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:21 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmkv28506 for <[e-mail]>; Mon, 11 Nov 2002 04:48:48 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyi-0006LG-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:44 +0000
To: [e-mail]
Path: comodo.net
From: Peter Sylvester <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: RE: TSA messages for http ?
Date: Wed, 14 Nov 2001 13:18:23 +0100 (MET)
Organization: Comodo Research Labs	
Lines: 74
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
X-Trace: kylie.comodogroup.com 1037018864 24025 127.0.0.1 (11 Nov 2002 12:47:44 GMT)
Delivered-To: [e-mail]
To: [e-mail], [e-mail], [e-mail], [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> In fact, I can return an error, but I simply DON'T LIKE
> this kind o stuff. You first specify some kind of communication
> protocol for socket-based TSP, and than forget about the whole
> stuff when it comes to HTTP. Well, I assume that the ideea of the
> committee was that a server using HTTP has to return an answer
> from the first try, and that's it. Well, in this case, why bother
> and do it for the socket-based solution? The developers have to
> take such things into account...

Its not me, but someone else :-)

The direct socket protocol has its origin in CMP. It is not
100% clear why it is in TSP. The texts of chapter 5.2 of RFC2510
and 3.3 of RFC3161 are stil quite similar. 

In the general model if TSP you don't have an 'initial TSP message', 
there is just a request/response. I am not convinced
at all that the socket protocol had been added because it
is useful (I can be wrong), but rather to have at least TWO
reasonable transport protocols (HTTP and another one).
There was alomost no discussion about the socket protocol
in the context of TSP. in fact, the protocol itself is 
incompletely defined. You don't know whether and who may
close a connection. 

I don't care about the socket "protocol" on a WAN level, you
may need proxy logics etc. (a CONNECT method for example in clients,
which would turn you almost into an HTTP client.) 

Note also that there is no way to correctly add a 
subjectInformationAccess for that protocol if You don't want to use 
the default port. 

I have the feeling that people are implementing it just because
it is simpler than HTTP to make a "prototype". 
I have seen single threaded implementations of servers, 
I have seen servers that do not time out on connections
and I don't know what else. decoding and coding the two PDUs
is just the small part of a service.


> > Anyway, if Your TSA that uses the socket protocol has a strange
> > behaviour, there is no need to correct this in a HTTP frontend. 
> > 
> 
> Yeah, right. There is NO strange behaviour, from this point of
> view. Well, if you are making such assumptions, let me ask you
I am not making assumptions.

> something else: why not define a simple, but effective standard,
> if we can have a complicated one?   :)
I see You know the shadoks :-)
I tend to agree with You. BUT: You first have to define the
problem, use cases, a problem space, definitions, etc. 
Note for example that there is actually another draft
about 'timestamps'.   


> But I think that the discussion won't bring us too much, now
> after the standard has been released. So just forget about it.
RFC3161 is NOT A STANDARD. It is an RFC with status 'PROPOSED STANDARD'. 
It may well be that one gets rid of inappropriate stuff as a quite
normal activity in the process.

 
> We have to admit that there are some problems, if we want an HTTP
> solution to rely on a socket-based TSA. And there are several
> solutions.

> The problem is just to choose between them. That's it.
So just choose something.  



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCpLg29531 for ietf-pkix-bks; Mon, 11 Nov 2002 04:51:21 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmgv28390 for <[e-mail]>; Mon, 11 Nov 2002 04:48:43 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDye-0006HE-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:40 +0000
To: [e-mail]
Path: comodo.net
From: "Anders Rundgren" <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Any Organization Certificates out there?
Date: Sat, 10 Nov 2001 08:27:37 +0100
Organization: Comodo Research Labs	
Lines: 153
Message-ID: <003801c169b9$2d0da620$0500a8c0@arport>
References: <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018860 24025 127.0.0.1 (11 Nov 2002 12:47:40 GMT)
Delivered-To: [e-mail]
To: "Pei, Mingliang" <[e-mail]>, <[e-mail]>
Cc: "Hsiao, Wentsung" <[e-mail]>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanx Ming,
Actually I think this is a case for Permanent Identifiers.   If it is
DUNS or not, is IMHO of less importance.  A VeriSign 
"Customer-ID" is equally good assuming that these stay constant etc.

The problem with the [expired] PI-draft as it stands today with respect to
organization certificates is:
- It is intended for individuals.  In spite of being equally interesting for organizations
- It is based on a flawed data model where EE-certs can contain arbitrary (well
I guess the CPS says how arbitrary) such definitions which makes it impossible
to use.  A sound data model would be that the CA-cert (that "owns" and "vouches"
for the EE-certs), indicates that its "children" indeed contains a permanent identifier
and its naming domain etc.  Then an RP can build *very sleek* systems to identify
messages signed by such an EE.  As this is what we do for a living, I can just say
this is a real mess that unfortunately none in this list seems to grip.

Regarding the use of OU etc. in web-server certificates, they are already all over
the map so adding a OU=DUNS/7878887 would have no (negative) impact.

But again, I think this should be addressed through a revised *CA-based*
PI-scheme. 

A "funny" comment on the side: I've been told (off-list) that the use of
web-server certificates for signing business transactions is way out
of what VeriSign allows.  Is this really true?  It is a reality in quite a
few places anyway.

Regards
Anders Rundgren
X-OBI

----- Original Message ----- 
From: "Pei, Mingliang" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>; "Pei, Mingliang" <[e-mail]>; <[e-mail]>
Cc: "Hsiao, Wentsung" <[e-mail]>
Sent: Saturday, November 10, 2001 03:28
Subject: RE: Any Organization Certificates out there?




It is relatively new to add a DUNS number into certificates
by CA vendors. So it is true that few are DUNS-enabled today. 
I believe the private OID choice is due to the lack of reserved 
standard OID for DUNS number so far and meanwhile try to avoid 
confusion associated if adding a string of numbers as a regular 
OU field (it is DUNS or SSN or even other number? there is no 
standard way for a client to interpret it). This is just my 
personal understanding about OID choices.

Code signing certificate is another kind of real "Organization 
Certificates". It does represents the company from a user's 
point of view when downloading the signed software. 

As either a passport or driver's license can equally serves 
to identify an individual, different kinds of certificates 
exist to represent a company according to different usages. 
No single certificate seems to be able to serve all. Application 
context would need to define how it recognize a digital ID as 
representation of a company in the context. 

- Ming

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Friday, November 09, 2001 1:02 PM
To: Pei, Mingliang; [e-mail]
Cc: Hsiao, Wentsung
Subject: Re: Any Organization Certificates out there?


Ming,
Interesting.  I put this queston a week ago to [e-mail]
and got no such information!

Then I "dumpasn1":ed https://www.versign.com and there is
no such extension there.

I'm sure this information of yours is correct but it seems to be a
pretty well hidden secret.  And why not put DUNS in OID.2.5.4.5
so it is shows up where the other ID-stuff is?
Or as an extra O=DUNS:887878787?

Under all circumstances a short test verified that few are DUNS-enabled
today.

Anders

----- Original Message ----- 
From: "Pei, Mingliang" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>; <[e-mail]>
Cc: "Hsiao, Wentsung" <[e-mail]>
Sent: Friday, November 09, 2001 21:15
Subject: RE: Any Organization Certificates out there?



Hi Anders,

The server certificate issued by VeriSign actually meet your need.
"a unique ID" DUNS number is included in server certificates.
When a customer provides their DUNS# during enrollment for retail 
Secure/Global server ID to VeriSign CA, the certificate issued 
always includes the DUNS# in the server id extension which OID is 
2.16.840.1.113733.1.6.15

- Ming

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Tuesday, November 06, 2001 2:07 PM
To: [e-mail]
Subject: Any Organization Certificates out there?



Hi,
My company is spearheading an effort to create an all
PKI-enabled version of the OBI (Open Buying on the Internet)
standard.  A stumbling block is that the core is based on what
we refer to as a "Digital Company Paper", which is an
organization certificate.  Some people consider Web-server
certificates as organization certificates, and that is true to
some extent, but has a major limitation: A domain name may
be owned by one legal entity and used by many associated
legal entities.  And the typical (non-standardized) other
information like O=x and OU=y is essentially useless
as it is not guaranteed to be unique or stable.  L (Locality) is even
worse as companies relocate quite often.  What you need
are certificates that contains a unique ID in a specified
fictitious (CA-specific) or externally administered
naming domain (National, DUNS etc).

Without such certificates, PKI-based B2B-business will be hard
to achieve as RP's sort of have to guess what IBM legal unit is
associated with a "secure.ibm.com" web-server certificate.
Particularly long-term, usage will break every now and
then due to the "imprecise" way, non-DNS information is applied.
And each renewed cerificate or changed web-server name (like
"secure0.ibm.com" to "secure9.ibm.com" replaces "secure.ibm.com")
is also a possible source of RP-troubles.  At least if plug-and-play
is called for, as in OBI Express.

Do anybody know if there are any *real* organization certificates
out there, available on a *global scale*?

Regards
Anders Rundgren
X-OBI
+46 70 - 627 74 37




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCovd29381 for ietf-pkix-bks; Mon, 11 Nov 2002 04:50:57 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmgv28420 for <[e-mail]>; Mon, 11 Nov 2002 04:48:44 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyf-0006II-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:41 +0000
To: [e-mail]
Path: comodo.net
From: "yew meng" <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Key usage of X509 certificate
Date: Mon, 12 Nov 2001 10:55:55 +0800
Organization: Comodo Research Labs	
Lines: 17
Message-ID: <000b01c16b25$8ec01700$[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018861 24025 127.0.0.1 (11 Nov 2002 12:47:41 GMT)
Delivered-To: [e-mail]
To: <[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,
I had a question on the key usage of X509 certificate. I noticed that most
certificates issue by Certificate Authorities include a constraint extension
of key usage in their user certificate. But some CAs mark the extension as
critical, but some don't. I wondered which is a more correct way? It is
stated in RFC2459, when the extension is used, it should be marked critical.
Thanks.
Regards,

Regards,

Ng Yew Meng





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCok329229 for ietf-pkix-bks; Mon, 11 Nov 2002 04:50:46 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmgv28400 for <[e-mail]>; Mon, 11 Nov 2002 04:48:43 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyf-0006Hh-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:41 +0000
To: [e-mail]
Path: comodo.net
From: "todd glassey" <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Any Organization Certificates out there?
Date: Sat, 10 Nov 2001 14:22:00 -0800
Organization: Comodo Research Labs	
Lines: 41
Message-ID: <042d01c16a36$4b2c0980$010aa8c0@tsg1>
References: <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018861 24025 127.0.0.1 (11 Nov 2002 12:47:41 GMT)
Delivered-To: [e-mail]
To: "Peter Gutmann" <[e-mail]>
Cc: <[e-mail]>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter, I suggested once or twice that this WG might 
want to sponsor a Universal OID tree or perhaps the 
IETF or IANA might  be put up to it. They (the IANA) 
handle the PEN OIDs at least.

Of course I got slammed for the idea but what the hey - 
it was a good one after all.

Todd

----- Original Message -----
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Saturday, November 10, 2001 10:09 AM
Subject: Re: Any Organization Certificates out there?


>
> "Pei, Mingliang" <[e-mail]> writes:
>
> >The server certificate issued by VeriSign actually meet your need. "a
unique
> >ID" DUNS number is included in server certificates. When a customer
provides
> >their DUNS# during enrollment for retail Secure/Global server ID to
VeriSign
> >CA, the certificate issued always includes the DUNS# in the server id
> >extension which OID is 2.16.840.1.113733.1.6.15
>
> So 2.16.840.1.113733.1.6.15 = "Verisign serverID"?  Are 
> any of these OIDs ever going to be documented anywhere?  
> I've managed to add a few based to dumpasn1 on reverse-
> engineering and/or guesswork, but it'd be useful to have the full
> list in there.
>
> Peter.





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCokY29403 for ietf-pkix-bks; Mon, 11 Nov 2002 04:50:46 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmjv28493 for <[e-mail]>; Mon, 11 Nov 2002 04:48:48 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyh-0006KE-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:43 +0000
To: [e-mail]
Path: comodo.net
From: Stephen Kent <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: signed e-mail
Date: Tue, 13 Nov 2001 10:48:14 -0500
Organization: Comodo Research Labs	
Lines: 13
Message-ID: <p05010404b816f084f6d3@[128.89.88.34]>
References: <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Trace: kylie.comodogroup.com 1037018863 24025 127.0.0.1 (11 Nov 2002 12:47:43 GMT)
Delivered-To: [e-mail]
X-Sender: [e-mail]
In-Reply-To: <[e-mail]>
To: "Rob G Weemhoff" <[e-mail]>
Cc: <[e-mail]>
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>To start with, why are we, as security advocates, not all using signed
>e-mail?
>
Rob,

As a Mac and Eudora user, I don not appear to have a viable option 
for S/MIME support, so I don't send signed e-mail.  Otherwise I would 
do so, just to try to set a good example, even though I agree that on 
this list it would serve relatively little practical purpose.

Steve



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCok629279 for ietf-pkix-bks; Mon, 11 Nov 2002 04:50:46 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmev28356 for <[e-mail]>; Mon, 11 Nov 2002 04:48:40 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyd-0006GK-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:39 +0000
To: [e-mail]
Path: comodo.net
From: Eric Rescorla <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: DNSSEC (RE: Software for PKI)
Date: 09 Nov 2001 11:50:00 -0800
Organization: Comodo Research Labs	
Lines: 35
Message-ID: <[e-mail]>
References: <[e-mail]>
Reply-To: EKR <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
X-Trace: kylie.comodogroup.com 1037018859 24025 127.0.0.1 (11 Nov 2002 12:47:39 GMT)
Delivered-To: [e-mail]
To: [e-mail]
Cc: "Anders Rundgren" <[e-mail]>, [e-mail], [e-mail], [e-mail]
In-Reply-To: [e-mail]'s message of "Fri, 9 Nov 2001 09:30:27 -0700"
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] writes:
> since the client already has the public key for the server before it even
> does anything (i.e. as part of obtaining the ip-address), the client
> encrypts cypersuites, session id, key all in one message. Server responds
> accepted/finsihed or changespec. Single round-trip if the server accepts
> the client's specification. To increase the probability, the server can
> register the preferred ciphersuite with their key in DNS and DNS can
> distribute that as a single bundle with the key ... in the single DNS call.
Yes, this scheme was considered back in about 1995/1996 and rejected
as infeasible for pretty much the same reason then as now: it relies
on DNSSEC, which doesn't exist to any significant degree. One of the
primary virtues of SSL/TLS is that it doesn't require much in the way
of supporting infrastructure.

In fact, what was proposed at the time was an optimization whereby if
the client knew the server's public key and preferences (never mind
how) it could short-circuit the handshake. This would also have
allowed the client to cache the server's identity data.

In any case, this doesn't really simplify things very much. The client
needs to process much the same data but from two sources rather than
one. And since SSL has to work in situations where DNS is not
available, you need to retain the full handshake anyway so you've
added complexity to the protocol, not subtracted it. At the time the
sense of the group was that DNSSEC was insufficiently deployed to make
this a worthwhile optimization. Things haven't changed much in 5
years.

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]
                http://www.rtfm.com/



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCoOS29132 for ietf-pkix-bks; Mon, 11 Nov 2002 04:50:24 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmjv28490 for <[e-mail]>; Mon, 11 Nov 2002 04:48:48 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyh-0006K8-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:43 +0000
To: [e-mail]
Path: comodo.net
From: Jean-Marc Desperrier <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: timestamp messageImprint
Date: Tue, 13 Nov 2001 14:48:25 +0100
Organization: Certplus
Lines: 18
Message-ID: <[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018863 24025 127.0.0.1 (11 Nov 2002 12:47:43 GMT)
Delivered-To: [e-mail]
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
To: ietf pkix <[e-mail]>
X-OriginalArrivalTime: 13 Nov 2001 13:48:22.0059 (UTC) FILETIME=[DBE317B0:01C16C49]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bernd Matthes wrote:

> My question is:
> Which part of the signerInfo should be used to create the messageImprint
> for the time-stamp query?

Read APPENDIX A :
"The value of messageImprint field within TimeStampToken shall be a hash
of the value of signature field within SignerInfo for the signedData
being timestamped."

In this case, you time-stamp the fact that _someone_ had signed a data at a
given time, not just the fact that the data existed at that time, so you
need to base yourself on the signature content.





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCoIt29169 for ietf-pkix-bks; Mon, 11 Nov 2002 04:50:18 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmgv28392 for <[e-mail]>; Mon, 11 Nov 2002 04:48:43 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDye-0006HN-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:40 +0000
To: [e-mail]
Path: comodo.net
From: "todd glassey" <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: TSA messages for http ?
Date: Sat, 10 Nov 2001 06:21:11 -0800
Organization: Comodo Research Labs	
Lines: 51
Message-ID: <038701c169f4$bf2d2c70$010aa8c0@tsg1>
References: <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018860 24025 127.0.0.1 (11 Nov 2002 12:47:40 GMT)
Delivered-To: [e-mail]
To: "S.T. Wong" <[e-mail]>, <[e-mail]>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Has anyone looked at integrating timestamping into XDAS. The XDAS
specification is much more stable that the TSP and would allow any UNIX
System or XDAS Compliant logging infrastructure to use the time stamp call
structures to reinforce the XDAS Logging Content.

This is a real world use model for the TSP (yuk - I am proposing it,
ewwwwww.) Oh well - anyway. For the TSP to really get some use it still
needs a couple of things like a reason for being used in the first place.

One use I would like to propose is as an addition to the OpenGroup's XDAS
Protocol. I have secured formal permission from the OpenGroup to submit that
as a proposed extension to both the xDAS protocol and the TSP.

My gut level feeling is that by bundling the missing pieces of the TSP
proposal together with the TSP itself  (that being some time management
process and an embedded application to use the TSP)  this protocol might get
some traction.

If you would like to see the xDAS draft send me some email and I will blast
off a copy to you. Its a 360kb PDF File at this time.

Todd

----- Original Message -----
From: "S.T. Wong" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, November 08, 2001 11:44 PM
Subject: TSA messages for http ?


>
> Hi, there,
>
> As mentioned in RFC3161, in socket based protocol TCP-based TSA messages,
> which consist of triplet of (length, flag, value), are used to communicate
> between the request initiator and listener.  If functions (like polling
> requests) are implemented on other protocols (e.g. SMTP, FTP, HTTP, etc),
can
> we simply make use of such TSA message triplets ?
>
> Would anyone please advise ?
> Thanks a lot.
>
> ST Wong
>
> --
> S.T. Wong                               | Email: [e-mail]
>




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCo9S29112 for ietf-pkix-bks; Mon, 11 Nov 2002 04:50:09 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmgv28428 for <[e-mail]>; Mon, 11 Nov 2002 04:48:44 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyf-0006Ic-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:41 +0000
To: [e-mail]
Path: comodo.net
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Which RFC specifies: E=x@y.z?
Date: Mon, 12 Nov 2001 14:56:16 +0100
Organization: stroeder.com
Lines: 29
Message-ID: <[e-mail]>
References: <000901c16a9f$d1e9f680$0500a8c0@arport> <[e-mail]> <009801c16b5f$4638fe90$0500a8c0@arport>
Reply-To: [e-mail]
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018861 24025 127.0.0.1 (11 Nov 2002 12:47:41 GMT)
Delivered-To: [e-mail]
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.20 i686)
X-Accept-Language: de-DE, de, en
To: Anders Rundgren <[e-mail]>
Cc: [e-mail]
X-Sender: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:
> 
> This is slightly more complicated in XML Dsig compared to CMS.
> In CMS the signers' certificate is specified by ASN1 data that
> normally is one-to-one of the associated certificate.  The chance
> of misinterpretation is then zero.  In XML Dsig the Issuer, Subject
> etc. are given as UTF-8 strings which must be matched against the ASN
> representation.  Although this is also the case for LDAP, I
> believe XML Dsig which is used for "machines talking to
> machines" is likely to be more hurt by the historic lack of
> stringens in DN strings.

I don't know of any authorative registry mapping the OIDs of
attribute types to unambigous strings. If XML-DSIG relies on
something which isn't exactly defined XML-DSIG is flawed.

Using "Email" or simply "E" is somewhat strange anyway. IMHO PKI
applications should take a look into the LDAP world where "mail"
(RFC 2798) and "rfc822Mailbox" (RCF 1274) is used for
0.9.2342.19200300.100.1.3.

But this does not only affect XML-DSIG. It affects all components
which handle a string representation of a subject DN. E.g. web
applications using CGI-BIN environment vars set by the SSL-capable
web server.

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCo1028995 for ietf-pkix-bks; Mon, 11 Nov 2002 04:50:01 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmgv28423 for <[e-mail]>; Mon, 11 Nov 2002 04:48:44 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyf-0006IN-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:41 +0000
To: [e-mail]
Path: comodo.net
From: Cristian Marinescu <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: RE: TSA messages for http ?
Date: Mon, 12 Nov 2001 09:50:42 +0100
Organization: Comodo Research Labs	
Lines: 78
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset="windows-1252"
X-Trace: kylie.comodogroup.com 1037018861 24025 127.0.0.1 (11 Nov 2002 12:47:41 GMT)
Delivered-To: [e-mail]
To: "S.T. Wong" <[e-mail]>, [e-mail]
X-Mailer: Internet Mail Service (5.0.1460.8)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Hello!

I am having the same problem. We have implemented
a socket-based server and client, and now we are
trying to offer some HTTP support, too. The main problem
is that, behind the WWW server (because I would like to
use IIS and Apache), I would definitively forward the
request to the socket-based TSA. The problem is that
in such cases, if I would configure the servlet to use
another TSA (what is actually quite possible), I would have
to deal with all the socket-based things like polling, negative
reply, etc.

At the moment, in such cases, I return an error, but well,
it is not very correct, from my point of view...
The standard is not suggesting any answer to this question.
What would you do? (And BTW, Todd, please send me your pdf,
I would be interested...)

Any comments are highly appreciated,
Cristian


=====================
Dipl-Ing. Cristian Marinescu
Software Developer
OMICRON electronics GmbH
Oberes Ried 1
A-6833 Klaus
AUSTRIA
Tel. [phone]
Fax. [phone]
E-Mail: [e-mail]
WWW: www.omicron.at


> -----Original Message-----
> From: S.T. Wong [mailto:[e-mail]]
> Sent: Freitag, 9. November 2001 08:44
> To: [e-mail]
> Subject: TSA messages for http ?
> 
> 
> 
> Hi, there,
> 
> As mentioned in RFC3161, in socket based protocol TCP-based 
> TSA messages,
> which consist of triplet of (length, flag, value), are used 
> to communicate
> between the request initiator and listener.  If functions 
> (like polling 
> requests) are implemented on other protocols (e.g. SMTP, FTP, 
> HTTP, etc), can 
> we simply make use of such TSA message triplets ?    
> 
> Would anyone please advise ?
> Thanks a lot.
> 
> ST Wong
> 
> -- 
> S.T. Wong                               | Email: [e-mail]
> 
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0.2i

iQA/AwUBO+9/UsV5iyNCxCiSEQJcJwCfdtMVE94zetthhcfjNxNGXzP/7YcAnjve
PQ0oq+hdiGkQiJ9f/71Qky5m
=4tbc
-----END PGP SIGNATURE-----



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCnUU28972 for ietf-pkix-bks; Mon, 11 Nov 2002 04:49:30 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmhv28435 for <[e-mail]>; Mon, 11 Nov 2002 04:48:44 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyf-0006Iu-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:41 +0000
To: [e-mail]
Path: comodo.net
From: Peter Sylvester <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: RE: TSA messages for http ?
Date: Mon, 12 Nov 2001 16:42:02 +0100 (MET)
Organization: Comodo Research Labs	
Lines: 13
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
X-Trace: kylie.comodogroup.com 1037018861 24025 127.0.0.1 (11 Nov 2002 12:47:41 GMT)
Delivered-To: [e-mail]
To: [e-mail], [e-mail], [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> another TSA (what is actually quite possible), I would have
> to deal with all the socket-based things like polling, negative
> reply, etc.
> 
> At the moment, in such cases, I return an error, but well,
> it is not very correct, from my point of view...
IMHO the polling feature in the socket transport protocol is
not a feature of the TSP protocol, if there is a transport
mapper between HTTP and the socket protocol, then the
http server would just waitabit and loop if there are responses
for polling. 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCnT728963 for ietf-pkix-bks; Mon, 11 Nov 2002 04:49:29 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmgv28430 for <[e-mail]>; Mon, 11 Nov 2002 04:48:44 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyf-0006Im-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:41 +0000
To: [e-mail]
Path: comodo.net
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Which RFC specifies: E=x@y.z?
Date: Mon, 12 Nov 2001 16:08:05 +0100
Organization: stroeder.com
Lines: 18
Message-ID: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018861 24025 127.0.0.1 (11 Nov 2002 12:47:41 GMT)
Delivered-To: [e-mail]
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.20 i686)
X-Accept-Language: de-DE, de, en
To: Tom Gindin <[e-mail]>
Cc: Anders Rundgren <[e-mail]>, [e-mail]
X-Sender: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom Gindin wrote:
> 
> > Using "Email" or simply "E" is somewhat strange anyway. IMHO PKI
> > applications should take a look into the LDAP world where "mail"
> > (RFC 2798) and "rfc822Mailbox" (RCF 1274) is used for
> > 0.9.2342.19200300.100.1.3.
>
>      Just to add to the confusion, there's a second contender with
> identical meaning:
> emailAddress {1 2 840 113549 1 9 1}, defined in PKCS #9 (section 5.2.1 of
> version 2.0).

Uuh, yes. My fault. 1.2.840.113549.1.9.1 is the OID usually used in
certs.

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCnPj28875 for ietf-pkix-bks; Mon, 11 Nov 2002 04:49:25 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmfv28368 for <[e-mail]>; Mon, 11 Nov 2002 04:48:42 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDye-0006Gt-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:40 +0000
To: [e-mail]
Path: comodo.net
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Any Organization Certificates out there?
Date: Sat, 10 Nov 2001 00:47:55 +0100
Organization: stroeder.com
Lines: 24
Message-ID: <[e-mail]>
References: <[e-mail]> <001501c16961$cc6e2800$0500a8c0@arport>
Reply-To: [e-mail]
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018860 24025 127.0.0.1 (11 Nov 2002 12:47:40 GMT)
Delivered-To: [e-mail]
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.20 i686)
X-Accept-Language: de-DE, de, en
To: [e-mail]
X-Sender: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:
> 
> > When a customer provides their DUNS# during enrollment for retail
> > Secure/Global server ID to VeriSign CA, the certificate issued
> > always includes the DUNS# in the server id extension which OID is
> > 2.16.840.1.113733.1.6.15
>
> Interesting.  I put this queston a week ago to [e-mail]
> and got no such information!
> 
> Then I "dumpasn1":ed https://www.versign.com and there is
> no such extension there.

Searching for 2.16.840.1.113733.1.6.15 on Google only returns this
link:

http://jcewww.iaik.at/servlet/demo.sslserverinfo.SSLServerInfoServlet/info?hostname=zvinet.creditanstalt.co.at&port=443

Extension 2.16.840.1.113733.1.6.15 does not seem to be well
documented though...

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCnPA28874 for ietf-pkix-bks; Mon, 11 Nov 2002 04:49:25 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmfv28371 for <[e-mail]>; Mon, 11 Nov 2002 04:48:42 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDye-0006Gz-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:40 +0000
To: [e-mail]
Path: comodo.net
From: [e-mail]
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: DNSSEC (RE: Software for PKI)
Date: Fri, 9 Nov 2001 16:55:31 -0700
Organization: Comodo Research Labs	
Lines: 9
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: kylie.comodogroup.com 1037018860 24025 127.0.0.1 (11 Nov 2002 12:47:40 GMT)
Delivered-To: [e-mail]
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
X-MIMETrack: Serialize by Router on SRVSMTP02/FDC(Release 5.0.8 |June 18, 2001) at 11/09/2001 05:56:43 PM
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

i managed to fat finger some number of the URLs in the previous note ...
they've been corrected in the version at:
http://www.garlic.com/~lynn/aadsm8.htm#softpki19






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCnO828871 for ietf-pkix-bks; Mon, 11 Nov 2002 04:49:24 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmfv28365 for <[e-mail]>; Mon, 11 Nov 2002 04:48:42 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyd-0006Gj-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:39 +0000
To: [e-mail]
Path: comodo.net
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: signed e-mail
Date: Fri, 09 Nov 2001 22:48:30 +0100
Organization: stroeder.com
Lines: 68
Message-ID: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msE2CDECE283E7CEFA0C8A593E"
X-Trace: kylie.comodogroup.com 1037018859 24025 127.0.0.1 (11 Nov 2002 12:47:39 GMT)
Delivered-To: [e-mail]
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.20 i686)
X-Accept-Language: de-DE, de, en
To: "[e-mail]" <[e-mail]>
X-Sender: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------msE2CDECE283E7CEFA0C8A593E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Rob G Weemhoff wrote:
> 
> To start with, why are we, as security advocates, not all using signed
> e-mail?

Because signing the e-mail on this list does not make much sense...?
Or what does your certificate really mean? Or mine? Both are
validated against "trusted" root CA certs in our browsers but that's
all.

But you're somewhat right. In most PKI projects I couldn't use
S/MIME e-mail while most project members had S/MIME capable MUAs...

Ciao, Michael.
--------------msE2CDECE283E7CEFA0C8A593E
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIH2AYJKoZIhvcNAQcCoIIHyTCCB8UCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BdIwggKhMIICCqADAgECAgMFDbAwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA2MTgyMTMyMDJaFw0wMjA2MTgyMTMyMDJa
MGUxETAPBgNVBAQTCFN0cm9lZGVyMRAwDgYDVQQqEwdNaWNoYWVsMRkwFwYDVQQDExBNaWNo
YWVsIFN0cm9lZGVyMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0cm9lZGVyLmNvbTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3XB78lpoh5TalCI/NC+W2tirbRvPS24SfuNj6zEb
ZtQaoqDv0czj9kgtwC9X9RRrHP46E0po08Fe53pAocV2OUPkf27WgXkrMgIUUAhZWP0RxVQD
1ntG7HwhpPTzVmwbaeSE5bimHN7DNUFj2Z21haZkBapDib/xIXYJ4KJgWw0CAwEAAaMxMC8w
HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG
9w0BAQQFAAOBgQBoq8JC32ueo3SpZzIutOBK6eiAuxFEtcTgJH5LqCWRMQfMgcQwwA8iXQ/T
AAJzSPXddvbyG6mBTwPAOo9rVO+IUeLAXY7iCygxGT72oYqTJNDhg37UVE4buywKhmwWYqyd
uNfh5Te7XhQ0Se6dWoLnHZCkbPVD0bvaMhXWUJSNhjCCAykwggKSoAMCAQICAQwwDQYJKoZI
hvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV
BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl
cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3Rl
LmNvbTAeFw0wMDA4MzAwMDAwMDBaFw0wMjA4MjkyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEV
MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRo
YXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFs
IEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4z
MqZjxwklRT7SbngnZ4HF2ogZgpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+i
ZdsN+kvx1t1hpfmFzVWaNRqdknWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SK
E4f/s5udSWYALQmJ7JRr6aFpAgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQ
cml2YXRlTGFiZWwxLTI5NzASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkq
hkiG9w0BAQQFAAOBgQBzG28mZYv/FTRLWWKK7US+ScfoDbuPuQ1qJipihB+4h2N0HG23zxpT
kUvhzeY42e1Q9DpsNJKs5pKcbsEjAcIJp+9LrnLdBmf1UG8uWLi2C8FQV7XsHNfvF7bViJu3
ooga7TlbOX00/LaWGCVNavSdxcORL6mWuAU8Uvzd6WIDSDGCAc4wggHKAgEBMIGaMIGSMQsw
CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24x
DzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNV
BAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwUNsDAJBgUrDgMCGgUAoIGK
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTEwOTIxNDgz
MFowIwYJKoZIhvcNAQkEMRYEFJuyMfAIjQXSX5B+kOonruWjc5QkMCsGCSqGSIb3DQEJDzEe
MBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCSqGSIb3DQEBAQUABIGAB//q6Kec
9o/Sykmggw0Z/orI24pj/O7u4WDXyJ1Obc+wELO0f1Q2BwVf0vPL+cYCfLDputxPj0s6QKFQ
zleZvNdYeuGClDbr+/UHWO+z5K8sofHjdqDfSEtr+aGKWos3UFMZrFeEpKjO8Hmb2MgrCpgb
VOSM+xVYyvkPgs791sc=
--------------msE2CDECE283E7CEFA0C8A593E--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCnOi28763 for ietf-pkix-bks; Mon, 11 Nov 2002 04:49:24 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmfv28366 for <[e-mail]>; Mon, 11 Nov 2002 04:48:41 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDye-0006Go-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:40 +0000
To: [e-mail]
Path: comodo.net
From: [e-mail]
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: DNSSEC (RE: Software for PKI)
Date: Fri, 9 Nov 2001 15:13:43 -0700
Organization: Comodo Research Labs	
Lines: 67
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: kylie.comodogroup.com 1037018860 24025 127.0.0.1 (11 Nov 2002 12:47:40 GMT)
Delivered-To: [e-mail]
To: EKR <[e-mail]>
Cc: "Anders Rundgren" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
X-MIMETrack: Serialize by Router on SRVSMTP02/FDC(Release 5.0.8 |June 18, 2001) at 11/09/2001 04:43:27 PM
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

oops, the client for current SSL is getting several transmissions from a
single source .... and only because PKI has not been implemented (just
certificate manufactoring .... if PKI implementation was ever attempted,
the client could have a huge number of responses with large number of
different entities).

Yes, SSL needs the option of working in the non-DNS environment.

However, the discussion started with my clain with regard specifically to
SSL domain name certificates possibly accounts for 99.99999 percent of all
certificate relateed operations that occur in the world today and the
supposed purpose for the existance of those SSL domain name certificates
was because of perceived integrity problems with the DNS domain name
infrastructure operation. Also that within the context of that purpose for
the existance of the SSL domain name certificates and representing a
significant percentage of all such operations .... that something else
might make sense.

It might be useful for having a specific optimization for 99.99999 percent
of the events .... and let the remaining .0000001 percent of the events be
done the less efficient way.

Aka, in a DNS environment ... the client has to make the DNS call
regardless and get the DNS results regardless. Piggy-backing the public key
on that call does not increase any additional client transactions with any
addition entities.

Then SSL setup is done in a single round-trip .... for possibly 99.999999
percent of the cases.

And SSL could be done some other, less efficient  way for the remaining
.0000001 percent of the cases.

The difficulty of having such an option isn't any worse than the existing
option for mutual certificate authentication which gets used even a lower
percentage of the time than the non-DNS operations.



[e-mail] on 11/9/2001 12:50 pm wrote:

In fact, what was proposed at the time was an optimization whereby if
the client knew the server's public key and preferences (never mind
how) it could short-circuit the handshake. This would also have
allowed the client to cache the server's identity data.

In any case, this doesn't really simplify things very much. The client
needs to process much the same data but from two sources rather than
one. And since SSL has to work in situations where DNS is not
available, you need to retain the full handshake anyway so you've
added complexity to the protocol, not subtracted it. At the time the
sense of the group was that DNSSEC was insufficiently deployed to make
this a worthwhile optimization. Things haven't changed much in 5
years.

-Ekr

--
[Eric Rescorla                                   [e-mail]]
                http://www.rtfm.com/







Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCnMk28545 for ietf-pkix-bks; Mon, 11 Nov 2002 04:49:22 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmdv28344 for <[e-mail]>; Mon, 11 Nov 2002 04:48:40 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyd-0006Fp-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:39 +0000
To: [e-mail]
Path: comodo.net
From: [e-mail]
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: DNSSEC (RE: Software for PKI)
Date: Fri, 9 Nov 2001 09:30:27 -0700
Organization: Comodo Research Labs	
Lines: 76
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: kylie.comodogroup.com 1037018859 24025 127.0.0.1 (11 Nov 2002 12:47:39 GMT)
Delivered-To: [e-mail]
To: EKR <[e-mail]>
Cc: "Anders Rundgren" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
X-MIMETrack: Serialize by Router on SRVSMTP02/FDC(Release 5.0.8 |June 18, 2001) at 11/09/2001 10:34:44 AM
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

since the client already has the public key for the server before it even
does anything (i.e. as part of obtaining the ip-address), the client
encrypts cypersuites, session id, key all in one message. Server responds
accepted/finsihed or changespec. Single round-trip if the server accepts
the client's specification. To increase the probability, the server can
register the preferred ciphersuite with their key in DNS and DNS can
distribute that as a single bundle with the key ... in the single DNS call.

There is no middle man attacks ... assuming trusted distribution of the
public key ... since only the server can decode what the client has sent in
the initial message.

There is the ancillary issue of flowing HTTP/HTTPS/stateless over short TCP
... with the associated TCP set-up/shutdown (all the performance issues
with various TCP linear list scanning from the early & mid-90s)

The issue then is to look at having real tunneling with long-term (TCP)
sessions and a real stateless transactiion where the client transaction is
piggybacked with the setup ... more like reliable UDP and do the
transaction version in single packet round-trip ... aka XTP (actually three
packet exchange for reliable setup/transaction/tear-down/etc ... but that
is better than the TCP minimum of seven packet)

random ref:
http://www.garlic.com/~lynn/99.html#0 Early tcp development?
http://www.garlic.com/~lynn/99.html#164 Uptime (was Re: Q: S/390 on
PowerPC?)
http://www.garlic.com/~lynn/99.html#207 Life-Advancing Work of Timothy
Berners-Lee
http://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still
have a meaning?
http://www.garlic.com/~lynn/2001b.html#57 I am fed up!
http://www.garlic.com/~lynn/2001e.html#24 Pre ARPAnet email?




[e-mail] on 11/9/2001 8:58 AM wrote:


Actually, very little of the SSL protocol overhead is concerned with
certificate issues. Most of it is concerned with ciphersuite negotiation,
key exchange and handshake verification, none of which would be
affected significantly by DNSSEC.

The typical SSL handshake is:

C: ClientHello (ciphersuites, random, session id)
S: ServerHello (ciphersuite selection, random, session id)
S: Certificate
S: ServerHelloDone
C: ClientKeyExchange
C: ChangeCipherSpec
C: Finished
S: ChangeCipherSpec
S: Finished

In a hypothetical world in which we had DNSSEC we'd be able to eliminate
exactly one of these messages, the server Certificate.

I agree that a world with DNSSEC would be potentially more secure than
the current world of SSL certificates, but it wouldn't make SSL
much simpler.

-Ekr

--
[Eric Rescorla                                   [e-mail]]
                http://www.rtfm.com/







Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCn8w28615 for ietf-pkix-bks; Mon, 11 Nov 2002 04:49:08 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmdv28341 for <[e-mail]>; Mon, 11 Nov 2002 04:48:40 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyd-0006Fg-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:39 +0000
To: [e-mail]
Path: comodo.net
From: Eric Rescorla <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: DNSSEC (RE: Software for PKI)
Date: 09 Nov 2001 07:58:07 -0800
Organization: Comodo Research Labs	
Lines: 41
Message-ID: <[e-mail]>
References: <[e-mail]>
Reply-To: EKR <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
X-Trace: kylie.comodogroup.com 1037018859 24025 127.0.0.1 (11 Nov 2002 12:47:39 GMT)
Delivered-To: [e-mail]
To: [e-mail]
Cc: "Anders Rundgren" <[e-mail]>, [e-mail], [e-mail], [e-mail]
In-Reply-To: [e-mail]'s message of "Fri, 9 Nov 2001 07:19:12 -0700"
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] writes:
> 5) In a DNSSEC world, browser could obtain a valid ip-address and public
> key in the same DNS transaction. By definition, the ip-address is trusted
> (so the issue of domain name to ip-address translation is eliminated).
> Also, by definition the public key for that "domain name/ip-address/public
> key" tuble is trusted. Majority of the protocol setup chatter in the
> existingf SSL is eliminated ... since there is real-time trusted key
> distribution (as part of real-time trusted ip-address distribution). So the
> only real SSL setup step that is left is the validaty of some signed
> something from the server.
Actually, very little of the SSL protocol overhead is concerned with
certificate issues. Most of it is concerned with ciphersuite negotiation,
key exchange and handshake verification, none of which would be 
affected significantly by DNSSEC.

The typical SSL handshake is:

C: ClientHello (ciphersuites, random, session id)
S: ServerHello (ciphersuite selection, random, session id)
S: Certificate
S: ServerHelloDone
C: ClientKeyExchange
C: ChangeCipherSpec
C: Finished
S: ChangeCipherSpec
S: Finished

In a hypothetical world in which we had DNSSEC we'd be able to eliminate
exactly one of these messages, the server Certificate.

I agree that a world with DNSSEC would be potentially more secure than
the current world of SSL certificates, but it wouldn't make SSL 
much simpler.

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]
                http://www.rtfm.com/



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCn7028619 for ietf-pkix-bks; Mon, 11 Nov 2002 04:49:07 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmev28358 for <[e-mail]>; Mon, 11 Nov 2002 04:48:41 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyd-0006GV-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:39 +0000
To: [e-mail]
Path: comodo.net
From: "Anders Rundgren" <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: Any Organization Certificates out there?
Date: Fri, 9 Nov 2001 22:02:09 +0100
Organization: Comodo Research Labs	
Lines: 82
Message-ID: <001501c16961$cc6e2800$0500a8c0@arport>
References: <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018859 24025 127.0.0.1 (11 Nov 2002 12:47:39 GMT)
Delivered-To: [e-mail]
To: "Pei, Mingliang" <[e-mail]>, <[e-mail]>
Cc: "Hsiao, Wentsung" <[e-mail]>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ming,
Interesting.  I put this queston a week ago to [e-mail]
and got no such information!

Then I "dumpasn1":ed https://www.versign.com and there is
no such extension there.

I'm sure this information of yours is correct but it seems to be a
pretty well hidden secret.  And why not put DUNS in OID.2.5.4.5
so it is shows up where the other ID-stuff is?
Or as an extra O=DUNS:887878787?

Under all circumstances a short test verified that few are DUNS-enabled
today.

Anders

----- Original Message ----- 
From: "Pei, Mingliang" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>; <[e-mail]>
Cc: "Hsiao, Wentsung" <[e-mail]>
Sent: Friday, November 09, 2001 21:15
Subject: RE: Any Organization Certificates out there?



Hi Anders,

The server certificate issued by VeriSign actually meet your need.
"a unique ID" DUNS number is included in server certificates.
When a customer provides their DUNS# during enrollment for retail 
Secure/Global server ID to VeriSign CA, the certificate issued 
always includes the DUNS# in the server id extension which OID is 
2.16.840.1.113733.1.6.15

- Ming

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Tuesday, November 06, 2001 2:07 PM
To: [e-mail]
Subject: Any Organization Certificates out there?



Hi,
My company is spearheading an effort to create an all
PKI-enabled version of the OBI (Open Buying on the Internet)
standard.  A stumbling block is that the core is based on what
we refer to as a "Digital Company Paper", which is an
organization certificate.  Some people consider Web-server
certificates as organization certificates, and that is true to
some extent, but has a major limitation: A domain name may
be owned by one legal entity and used by many associated
legal entities.  And the typical (non-standardized) other
information like O=x and OU=y is essentially useless
as it is not guaranteed to be unique or stable.  L (Locality) is even
worse as companies relocate quite often.  What you need
are certificates that contains a unique ID in a specified
fictitious (CA-specific) or externally administered
naming domain (National, DUNS etc).

Without such certificates, PKI-based B2B-business will be hard
to achieve as RP's sort of have to guess what IBM legal unit is
associated with a "secure.ibm.com" web-server certificate.
Particularly long-term, usage will break every now and
then due to the "imprecise" way, non-DNS information is applied.
And each renewed cerificate or changed web-server name (like
"secure0.ibm.com" to "secure9.ibm.com" replaces "secure.ibm.com")
is also a possible source of RP-troubles.  At least if plug-and-play
is called for, as in OBI Express.

Do anybody know if there are any *real* organization certificates
out there, available on a *global scale*?

Regards
Anders Rundgren
X-OBI
+46 70 - 627 74 37




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gABCn0128483 for ietf-pkix-bks; Mon, 11 Nov 2002 04:49:00 -0800 (PST)
Received: from kylie.comodogroup.com ([212.56.93.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gABCmev28353 for <[e-mail]>; Mon, 11 Nov 2002 04:48:40 -0800 (PST)
Received: from news by kylie.comodogroup.com with local (Exim 3.35 #1 (Debian)) id 18BDyd-0006GF-00 for <[e-mail]>; Mon, 11 Nov 2002 12:47:39 +0000
To: [e-mail]
Path: comodo.net
From: "Anders Rundgren" <[e-mail]>
Newsgroups: comodo.lists.ietf.pkix
Subject: Re: DNSSEC (RE: Software for PKI)
Date: Fri, 9 Nov 2001 20:19:35 +0100
Organization: Comodo Research Labs	
Lines: 99
Message-ID: <00dc01c16953$78950a40$0500a8c0@arport>
References: <[e-mail]>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Trace: kylie.comodogroup.com 1037018859 24025 127.0.0.1 (11 Nov 2002 12:47:39 GMT)
Delivered-To: [e-mail]
To: <[e-mail]>
Cc: <[e-mail]>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
X-Hops: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Lynn,
This is interesting.  What you are saying is that server-based PKI (sort of)
that generates fresh (or short-time cached) responses from a database
is the way to go.

This is essentially the same thing I have been pushing several years for
extranet authentication.  That each company server generates freshly
signed "tickets" (http://www.x-obi.com/purple) based on their databases
instead of issuing and distributing employee certificates.

Server-cryptography rulez!

These DNSSEC servers will not be practical until HW-crypto
support is down in the $100 region.   This may take another
5 years or so.  It is driven by the B2B market that needs such
servers as well.

Anders

----- Original Message ----- 
From: <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Friday, November 09, 2001 15:19
Subject: Re: DNSSEC (RE: Software for PKI)



Well, comparing a chain-of-trust:

1) both TTP CAs and DNS are dependent on the same domain name
infrastructure registration & operation as the authoritative reference as
to the validity of domain name owndership.

2) Registering public keys as part of domain name registeration to improve
the integrity of #1 would also be the same for both TTP CAs and DNS

3) DNS would obtain the public key from that data base in real time ...
effectively inverting the current TTP CA PKI valid key issue. The TTP CA
for SSL domain name certificates doesn't have a real PKI i.e. from the
point of view of administrating stale certificates that they have
manufactored at some time way in the past .... based on #1 & possibly #2.
DNS effectively jumps way ahead of the existing SSL domain name certificate
to the equivalent of a real PKI ... having real-time administration of
validity of public keys.

4) SSL currently obtains a server public key from a lot of protocol chatter
involving certificate distribution, certificates which have been signed by
some CA public key. Then the current SSL validates a certificate with CA
public keys that have been distributed as part of the browser. Once, the
certificate signature has been validating (note that this isn't a real PKI
so none of the other certificate validation stuff is in effect), then the
cretificate can be checked that the domain name requested and the domain
name in the certificate is the same. After that, the validity of some
signed something from the server can be validated with the public key in
the certificate.

5) In a DNSSEC world, browser could obtain a valid ip-address and public
key in the same DNS transaction. By definition, the ip-address is trusted
(so the issue of domain name to ip-address translation is eliminated).
Also, by definition the public key for that "domain name/ip-address/public
key" tuble is trusted. Majority of the protocol setup chatter in the
existing SSL is eliminated ... since there is real-time trusted key
distribution (as part of real-time trusted ip-address distribution). So the
only real SSL setup step that is left is the validaty of some signed
something from the server.

The issue ... as always ... with DNS is does it provide real-time trusted
information distribution. If DNSSEC can improve the trust & integrity of
that process ... then I would claim that there is, in effect, a real PKI
(real-time distribution and administration of trusted public keys) as
compared to the restricted subset of certificate manufactoring that occurs
today for SSL domain name certificates.



[e-mail] on 11/9/2001 3:10 am:


Stefan,
Does not DNSSEC suffer from basically the same problems as
web-server certficates with resp to RPs?  I.e. you must install
trusted root certificates in clients.   Or is the hope that there will
be just a single root?  Signed by UN I guess...

The primary advantage seem to be that people don't have to buy
and install web-server certificates.  Quite a TTP-market there that
goes into pieces!

But does HTTPS really work without these?
If it does not, I don't think DNSSEC will be such a success.

Anders







Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAB7Vw821053 for ietf-pkix-bks; Sun, 10 Nov 2002 23:31:58 -0800 (PST)
Received: from mx04.melco.co.jp (mx04.melco.co.jp [192.218.140.144]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAB7Vvv21043 for <[e-mail]>; Sun, 10 Nov 2002 23:31:57 -0800 (PST)
Received: by mx04.melco.co.jp (mx04) id gAB7Vtg07677; Mon, 11 Nov 2002 16:31:55 +0900 (JST)
Received: by mr04.melco.co.jp (mr04) id gAB7Vok18064; Mon, 11 Nov 2002 16:31:51 +0900 (JST)
Received: from elmail by elgw.isl.melco.co.jp (8.8.8/3.6W) id QAA00574; Mon, 11 Nov 2002 16:31:46 +0900 (JST)
Received: from iss.isl.melco.co.jp (iss.isl.melco.co.jp [10.74.5.60]) by elmail.isl.melco.co.jp (iPlanet Messaging Server 5.0 Patch 3 (built Mar 23 2001)) with ESMTP id <[e-mail]>; Mon, 11 Nov 2002 16:31:45 +0900 (JST)
Received: from jos818 by iss.isl.melco.co.jp (8.8.8/3.6W) id QAA26375; Mon, 11 Nov 2002 16:31:44 +0900 (JST)
Date: Mon, 11 Nov 2002 16:31:43 +0900
From: Takashi ITO <[e-mail]>
Subject: RFC 3280 : CRL Validation
To: [e-mail]
Message-id: <006e01c28954$62e92560$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4920.2300
X-Mailer: Microsoft Outlook Express 5.50.4920.2300
Content-type: text/plain; charset=iso-2022-jp
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

I have a question about CRL Validation in RFC 3280.

In clause 6.3.2, the state variable is defined as the following:

    (a)  reasons_mask:  This variable contains the set of revocation
    reasons supported by the CRLs and delta CRLs processed so far.
    ...(snip)... This variable is initialized to the empty set.

However, in CRL Processing described in clause 6.3.3,
the reasons_mask state variable is not updated at all,
while CRL Processing says "If reasons_mask is all-reasons ...".

I think the updating phase is necessary in clause 6.3.3, CRL Processing.
For example:

    (l)  Set the reasons_mask state variable to the union of
    its previous value and the value of the interim_reasons_mask
    state variable.

Is my understanding right?

Thanks,


Takashi ITO <[e-mail]>
Mitsubishi Electric Corporation



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAB4HLM10678 for ietf-pkix-bks; Sun, 10 Nov 2002 20:17:21 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAB4HJv10673 for <[e-mail]>; Sun, 10 Nov 2002 20:17:19 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gAB4H3wA009836; Mon, 11 Nov 2002 17:17:03 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id RAA126842; Mon, 11 Nov 2002 17:17:02 +1300 (NZDT) (sender [e-mail])
Date: Mon, 11 Nov 2002 17:17:02 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  PrintableString not usable tigether with OCSP?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Richard Levitte - VMS Whacker <[e-mail]> writes:

>Perhaps the subject is a little on the harsh side.  However, having just
>implemented the rules for PrintableString and emailAddress from RFC3280 [1]
>into OpenSSL, I was reminded that this in itself causes some problems when
>hashes over subject or issuer is used to find a certificate.
>
>[1] saying the PrintableString in DNs should have spaces collapsed and
>    trimmed at the beginning and end of value, and considered case
>    insensitive, and the emailAddress with the string type ia5String should
>    be considered case insensitive...

This is about as realistic as the requirement that certs be re-coded using
DER, and has the same solution: Everyone just uses the string as encoded in
the cert.  This works just fine, it's a non-problem.

Peter.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAAJbnb10317 for ietf-pkix-bks; Sun, 10 Nov 2002 11:37:49 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAAJblv10313 for <[e-mail]>; Sun, 10 Nov 2002 11:37:47 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX F5.3 VnHj) with ESMTP for <[e-mail]>; Sun, 10 Nov 2002 20:40:26 +0100
Date: Sun, 10 Nov 2002 20:37:08 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: PrintableString not usable tigether with OCSP?
From: Richard Levitte - VMS Whacker <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 2.2
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Perhaps the subject is a little on the harsh side.  However, having
just implemented the rules for PrintableString and emailAddress from
RFC3280 [1] into OpenSSL, I was reminded that this in itself causes
some problems when hashes over subject or issuer is used to find a
certificate.

It could be dismissed if such hashes weren't seriously used anywhere.
However, the CertID type in RFC2560 contains exactly this kind of
hash, as the field issuerNameHash.  There may very well be cases where
two issuer names which are considered equal according to the rules
given above, but give different hashes.

Is there already a solution for this problem, or has it not been
thought of yet?  In any case, it needs to be adressed, since such DNs
do exist.  Also, there are tests in NISTs X.509 tes suite
(http://csrc.nist.gov/pki/testing/x509paths.html) where comparison if
PrintableStrings that differ in spacing and casing are present.

-----
[1] saying the PrintableString in DNs should have spaces collapsed and
    trimmed at the beginning and end of value, and considered case
    insensitive, and the emailAddress with the string type ia5String
    should be considered case insensitive...

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gAA8xfU18831 for ietf-pkix-bks; Sun, 10 Nov 2002 00:59:41 -0800 (PST)
Received: from web40612.mail.yahoo.com (web40612.mail.yahoo.com [66.218.78.149]) by above.proper.com (8.11.6/8.11.3) with SMTP id gAA8xdv18825 for <[e-mail]>; Sun, 10 Nov 2002 00:59:39 -0800 (PST)
Message-ID: <[e-mail]>
Received: from [12.254.35.162] by web40612.mail.yahoo.com via HTTP; Sun, 10 Nov 2002 00:59:34 PST
Date: Sun, 10 Nov 2002 00:59:34 -0800 (PST)
From: Camile Howe <[e-mail]>
Subject: Re: new version of draft on additional x509 certificate schema for LDAP
To: Norbert Klasen <[e-mail]>, Peter Gietz <[e-mail]>, Ietf-Pkix <[e-mail]>
In-Reply-To: <13824208.1036766521@[10.110.20.169]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt... Believe though that the opposite is true if
you permit ABSTRACT from the top down.
Don't you mean "derived", but we'd still retain the
"binary blob of the certifate as only the STRUCTURAL
object classes x509cACertificate".

Camile

--- Norbert Klasen <[e-mail]> wrote:
> 
> 
> 
> --On Freitag, 8. November 2002 11:47 +0100 Peter
> Gietz 
> <[e-mail]> wrote:
> 
> > I am not yet sure, why Kurt proposes an ABSRACT
> object class for
> > x509certificate instead of a STRUCTURAL derived
> from top.
> 
> If x509certificate would be STRUCTURAL, one could
> create entries with 
> x509certificate as the "structural object class of
> the entry". When is is 
> made ABSTRACT, such entries are not allowed. This
> will enforce the 
> requirement that an entry must contain the binary
> blob of the certifate as 
> only the STRUCTURAL object classes x509cACertificate
> and 
> x509userCertificate may be instantiated.
> 
> Norbert


__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA93rlA14038 for ietf-pkix-bks; Fri, 8 Nov 2002 19:53:47 -0800 (PST)
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA93rhv14033 for <[e-mail]>; Fri, 8 Nov 2002 19:53:43 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id gA93rhOB013479; Sat, 9 Nov 2002 04:53:44 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <002601c2879a$4003f630$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Hal Lockhart" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: [OASIS members] XACML public review
Date: Sat, 9 Nov 2002 03:46:48 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C287A2.A1683CD0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0023_01C287A2.A1683CD0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

FW: [OASIS members] XACML public reviewHal,
You are not supposed to post XML-related stuff in the PKIX-list as it is =
dedicated to worship of an ancient language called ASN.1 :-)

I guess XACML is yet another stab at the already dead x.509 AC?

cheers,
Anders
  ----- Original Message -----=20
  From: Hal Lockhart=20
  To: [e-mail]=20
  Sent: Saturday, November 09, 2002 00:15
  Subject: FW: [OASIS members] XACML public review





  -----Original Message-----=20
  From: Karl Best [mailto:[e-mail]]=20
  Sent: Friday, November 08, 2002 11:58 AM=20
  To: [e-mail]; [e-mail]=20
  Subject: [OASIS members] XACML public review=20



  On behalf of the co-chairs of the TC, I am pleased to announce that =
the=20
  OASIS eXtensible Access Control Markup Language (XACML) Technical=20
  Committee has voted unanimously to approve its XACML 1.0 document as a =

  Committee Specification.=20

  The XACML TC also voted to begin the process of moving the =
specification=20
  to an OASIS Standard by initiating a 30-day public review period with=20
  respect to the XACML 1.0 Committee Specification, in accordance with=20
  Section 2 of the OASIS Technical Committee Process document=20
  (http://www.oasis-open.org/committees/process.shtml).=20

  The public review period extends from=20
        Friday, November 8, 2002, until=20
        Sunday, December 8, 2002 (inclusive).=20

  The specification and accompanying schema documents may be found at=20
   =20
  =
http://www.oasis-open.org/committees/xacml/repository/cs-xacml-core-01.do=
c=20
  =
http://www.oasis-open.org/committees/xacml/repository/cs-xacml-schema-pol=
icy-01.xsd=20
  =
http://www.oasis-open.org/committees/xacml/repository/cs-xacml-schema-con=
text-01.xsd=20

  or from the XACML Web site at =
http://www.oasis-open.org/committees/xacml=20

  Comments are welcome and encouraged from all interested parties.=20
  Comments should be submitted to the XACML comment list at=20
  [e-mail].=20

  (OASIS comment lists no longer require subscription, but you will be=20
  required by the mail server to return a token to confirm your =
message.)=20



  -Karl=20

  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
  Karl F. Best=20
  Vice President, OASIS=20
  +1 978.667.5115 x206=20
  [e-mail]  http://www.oasis-open.org=20



  ----------------------------------------------------------------=20
  To subscribe or unsubscribe from this elist use the subscription=20
  manager: <http://lists.oasis-open.org/ob/adm.pl>=20


------=_NextPart_000_0023_01C287A2.A1683CD0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>FW: [OASIS members] XACML public review</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hal,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>You are not supposed to post =
XML-related stuff in=20
the PKIX-list as it is dedicated to worship of an ancient language =
called ASN.1=20
:-)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I guess XACML is yet another stab at =
the already=20
dead x.509 AC?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>cheers,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:[e-mail]"=20
  title=[e-mail]>Hal Lockhart</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:[e-mail]"=20
  title=[e-mail]>[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Saturday, November 09, =
2002=20
  00:15</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> FW: [OASIS members] =
XACML public=20
  review</DIV>
  <DIV><BR></DIV><BR><BR>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Karl=20
  Best [<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]<=
/A>]</FONT>=20
  <BR><FONT size=3D2>Sent: Friday, November 08, 2002 11:58 AM</FONT> =
<BR><FONT=20
  size=3D2>To: <A=20
  =
href=3D"mailto:[e-mail]">[e-mail]=
</A>;=20
  <A =
href=3D"mailto:[e-mail]">[e-mail]</A></FONT>=20
  <BR><FONT size=3D2>Subject: [OASIS members] XACML public review</FONT> =
</P><BR>
  <P><FONT size=3D2>On behalf of the co-chairs of the TC, I am pleased =
to announce=20
  that the </FONT><BR><FONT size=3D2>OASIS eXtensible Access Control =
Markup=20
  Language (XACML) Technical </FONT><BR><FONT size=3D2>Committee has =
voted=20
  unanimously to approve its XACML 1.0 document as a </FONT><BR><FONT=20
  size=3D2>Committee Specification.</FONT> </P>
  <P><FONT size=3D2>The XACML TC also voted to begin the process of =
moving the=20
  specification </FONT><BR><FONT size=3D2>to an OASIS Standard by =
initiating a=20
  30-day public review period with </FONT><BR><FONT size=3D2>respect to =
the XACML=20
  1.0 Committee Specification, in accordance with </FONT><BR><FONT=20
  size=3D2>Section 2 of the OASIS Technical Committee Process document=20
  </FONT><BR><FONT size=3D2>(<A=20
  href=3D"http://www.oasis-open.org/committees/process.shtml"=20
  =
target=3D_blank>http://www.oasis-open.org/committees/process.shtml</A>).<=
/FONT>=20
  </P>
  <P><FONT size=3D2>The public review period extends from</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Friday, November 8, 2002, =
until</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sunday, December 8, =
2002=20
  (inclusive).</FONT> </P>
  <P><FONT size=3D2>The specification and accompanying schema documents =
may be=20
  found at</FONT> <BR><FONT size=3D2>&nbsp;</FONT> <BR><FONT size=3D2><A =

  =
href=3D"http://www.oasis-open.org/committees/xacml/repository/cs-xacml-co=
re-01.doc"=20
  =
target=3D_blank>http://www.oasis-open.org/committees/xacml/repository/cs-=
xacml-core-01.doc</A></FONT>=20
  <BR><FONT size=3D2><A=20
  =
href=3D"http://www.oasis-open.org/committees/xacml/repository/cs-xacml-sc=
hema-policy-01.xsd"=20
  =
target=3D_blank>http://www.oasis-open.org/committees/xacml/repository/cs-=
xacml-schema-policy-01.xsd</A></FONT>=20
  <BR><FONT size=3D2><A=20
  =
href=3D"http://www.oasis-open.org/committees/xacml/repository/cs-xacml-sc=
hema-context-01.xsd"=20
  =
target=3D_blank>http://www.oasis-open.org/committees/xacml/repository/cs-=
xacml-schema-context-01.xsd</A></FONT>=20
  </P>
  <P><FONT size=3D2>or from the XACML Web site at <A=20
  href=3D"http://www.oasis-open.org/committees/xacml"=20
  target=3D_blank>http://www.oasis-open.org/committees/xacml</A></FONT> =
</P>
  <P><FONT size=3D2>Comments are welcome and encouraged from all =
interested=20
  parties. </FONT><BR><FONT size=3D2>Comments should be submitted to the =
XACML=20
  comment list at </FONT><BR><FONT=20
  size=3D2>[e-mail].</FONT> </P>
  <P><FONT size=3D2>(OASIS comment lists no longer require subscription, =
but you=20
  will be </FONT><BR><FONT size=3D2>required by the mail server to =
return a token=20
  to confirm your message.)</FONT> </P><BR>
  <P><FONT size=3D2>-Karl</FONT> </P>
  <P><FONT=20
  =
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>=20
  <BR><FONT size=3D2>Karl F. Best</FONT> <BR><FONT size=3D2>Vice =
President,=20
  OASIS</FONT> <BR><FONT size=3D2>+1 978.667.5115 x206</FONT> <BR><FONT=20
  size=3D2>[e-mail]&nbsp; <A =
href=3D"http://www.oasis-open.org"=20
  target=3D_blank>http://www.oasis-open.org</A></FONT> </P><BR>
  <P><FONT=20
  =
size=3D2>----------------------------------------------------------------=
</FONT>=20
  <BR><FONT size=3D2>To subscribe or unsubscribe from this elist use the =

  subscription</FONT> <BR><FONT size=3D2>manager: &lt;<A=20
  href=3D"http://lists.oasis-open.org/ob/adm.pl"=20
  target=3D_blank>http://lists.oasis-open.org/ob/adm.pl</A>&gt;</FONT>=20
</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0023_01C287A2.A1683CD0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA93oAB13918 for ietf-pkix-bks; Fri, 8 Nov 2002 19:50:10 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA93o8v13914 for <[e-mail]>; Fri, 8 Nov 2002 19:50:09 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gA93nTwA021986; Sat, 9 Nov 2002 16:49:30 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA109591; Sat, 9 Nov 2002 16:49:29 +1300 (NZDT) (sender [e-mail])
Date: Sat, 9 Nov 2002 16:49:29 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Sylvester <[e-mail]> writes:

>What about also:

Argh, that makes it even worse!  I don't want to implement a string-parsing
and text-formatting package just to display a simple error message.  I think
"Free-format IA5String" is enough, it tells people what to expect and doesn't
encourage them to try and play tricks with formatting.  For example, I'd never
use a MULTI_SZ value because it's pretty much guaranteed that non-Windows
implementations (most of which will be C) will drop everything after the first
string; I know the display limits so I want to control line breaks, not have
the sender do it for me; etc etc.

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA93lNE13835 for ietf-pkix-bks; Fri, 8 Nov 2002 19:47:23 -0800 (PST)
Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA93lIv13830; Fri, 8 Nov 2002 19:47:18 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05200f1fb9f2353443db@[165.227.249.18]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Fri, 8 Nov 2002 19:47:19 -0800
To: Peter Sylvester <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2:18 PM +0100 11/8/02, Peter Sylvester wrote:
>   PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
>       -- text encoded as UTF-8 String (note:  each UTF8String SHOULD
>       -- include an RFC 1766 language tag to indicate the language
>       -- of the contained text)
>
>How can the language tag be distinguished from the text?

Language tags in Unicode have their own code points that don't 
conflict with any other characters. They are E0001 and E0020-E007F 
(yes, that's in plane 14).

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA93WvP13241 for ietf-pkix-bks; Fri, 8 Nov 2002 19:32:57 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA93Wtv13233 for <[e-mail]>; Fri, 8 Nov 2002 19:32:55 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gA93W5wA021697; Sat, 9 Nov 2002 16:32:06 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA109438; Sat, 9 Nov 2002 16:32:01 +1300 (NZDT) (sender [e-mail])
Date: Sat, 9 Nov 2002 16:32:01 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Sylvester <[e-mail]> writes:

>  PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
>      -- text encoded as UTF-8 String (note:  each UTF8String SHOULD
>      -- include an RFC 1766 language tag to indicate the language
>      -- of the contained text)
>
>How can the language tag be distinguished from the text?

By a de facto agreement where everyone ignores the requirement for the
language tag, since all messages are in English anyway.  I've never seen one
used, and I don't use them either.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA8NJfF29563 for ietf-pkix-bks; Fri, 8 Nov 2002 15:19:41 -0800 (PST)
Received: from dymwsm18.mailwatch.com (dymwsm18.mailwatch.com [204.253.83.220]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA8NJev29559 for <[e-mail]>; Fri, 8 Nov 2002 15:19:40 -0800 (PST)
Received: from mwsc0221.mw.mailwatch.com (mwsc0221.mw4.mailwatch.com [204.253.83.143]) by dymwsm18.mailwatch.com (8.11.0/8.11.0) with ESMTP id gA8NJRE21754 for <[e-mail]>; Fri, 8 Nov 2002 18:19:27 -0500
Received: from mail pickup service by mwsc0221.mw.mailwatch.com with Microsoft SMTPSVC; Fri, 8 Nov 2002 18:19:27 -0500
Received: from 204.253.83.34 ([204.253.83.34]) by MWSC0221 with SMTP id 00020015d82e1544-d5a3-49aa-a3b3-5f8cdc53fc7c; Fri, 08 Nov 2002 18:19:27 -0500
Received: from bigbird.entegrity.com (bigbird.entegrity.com [192.92.110.50]) by dymwsm12.mailwatch.com (8.12.6/8.12.6) with ESMTP id gA8NJR9o010684 for <[e-mail]>; Fri, 8 Nov 2002 18:19:27 -0500
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10) id <V8YZWFV7>; Fri, 8 Nov 2002 18:15:39 -0500
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: [e-mail]
Subject: FW: [OASIS members] XACML public review
Date: Fri, 8 Nov 2002 18:15:38 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2877C.BFD523CA"
HOP-COUNT: 1
X-MAILWATCH-INSTANCEID: 01020015d82e1544-d5a3-49aa-a3b3-5f8cdc53fc7c
X-OriginalArrivalTime: 08 Nov 2002 23:19:27.0402 (UTC) FILETIME=[485580A0:01C2877D]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2877C.BFD523CA
Content-Type: text/plain;
	charset="iso-8859-1"



-----Original Message-----
From: Karl Best [mailto:[e-mail]]
Sent: Friday, November 08, 2002 11:58 AM
To: [e-mail]; [e-mail]
Subject: [OASIS members] XACML public review


On behalf of the co-chairs of the TC, I am pleased to announce that the 
OASIS eXtensible Access Control Markup Language (XACML) Technical 
Committee has voted unanimously to approve its XACML 1.0 document as a 
Committee Specification.

The XACML TC also voted to begin the process of moving the specification 
to an OASIS Standard by initiating a 30-day public review period with 
respect to the XACML 1.0 Committee Specification, in accordance with 
Section 2 of the OASIS Technical Committee Process document 
(http://www.oasis-open.org/committees/process.shtml).

The public review period extends from
      Friday, November 8, 2002, until
      Sunday, December 8, 2002 (inclusive).

The specification and accompanying schema documents may be found at
 
http://www.oasis-open.org/committees/xacml/repository/cs-xacml-core-01.doc
http://www.oasis-open.org/committees/xacml/repository/cs-xacml-schema-policy
-01.xsd
http://www.oasis-open.org/committees/xacml/repository/cs-xacml-schema-contex
t-01.xsd

or from the XACML Web site at http://www.oasis-open.org/committees/xacml

Comments are welcome and encouraged from all interested parties. 
Comments should be submitted to the XACML comment list at 
[e-mail].

(OASIS comment lists no longer require subscription, but you will be 
required by the mail server to return a token to confirm your message.)


-Karl

=================================================================
Karl F. Best
Vice President, OASIS
+1 978.667.5115 x206
[e-mail]  http://www.oasis-open.org


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

------_=_NextPart_001_01C2877C.BFD523CA
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>FW: [OASIS members] XACML public review</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Karl Best [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, November 08, 2002 11:58 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: [OASIS members] XACML public review</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>On behalf of the co-chairs of the TC, I am pleased to =
announce that the </FONT>
<BR><FONT SIZE=3D2>OASIS eXtensible Access Control Markup Language =
(XACML) Technical </FONT>
<BR><FONT SIZE=3D2>Committee has voted unanimously to approve its XACML =
1.0 document as a </FONT>
<BR><FONT SIZE=3D2>Committee Specification.</FONT>
</P>

<P><FONT SIZE=3D2>The XACML TC also voted to begin the process of =
moving the specification </FONT>
<BR><FONT SIZE=3D2>to an OASIS Standard by initiating a 30-day public =
review period with </FONT>
<BR><FONT SIZE=3D2>respect to the XACML 1.0 Committee Specification, in =
accordance with </FONT>
<BR><FONT SIZE=3D2>Section 2 of the OASIS Technical Committee Process =
document </FONT>
<BR><FONT SIZE=3D2>(<A =
HREF=3D"http://www.oasis-open.org/committees/process.shtml" =
TARGET=3D"_blank">http://www.oasis-open.org/committees/process.shtml</A>=
).</FONT>
</P>

<P><FONT SIZE=3D2>The public review period extends from</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Friday, November 8, =
2002, until</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sunday, December 8, =
2002 (inclusive).</FONT>
</P>

<P><FONT SIZE=3D2>The specification and accompanying schema documents =
may be found at</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.oasis-open.org/committees/xacml/repository/cs-xacml-c=
ore-01.doc" =
TARGET=3D"_blank">http://www.oasis-open.org/committees/xacml/repository/=
cs-xacml-core-01.doc</A></FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.oasis-open.org/committees/xacml/repository/cs-xacml-s=
chema-policy-01.xsd" =
TARGET=3D"_blank">http://www.oasis-open.org/committees/xacml/repository/=
cs-xacml-schema-policy-01.xsd</A></FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.oasis-open.org/committees/xacml/repository/cs-xacml-s=
chema-context-01.xsd" =
TARGET=3D"_blank">http://www.oasis-open.org/committees/xacml/repository/=
cs-xacml-schema-context-01.xsd</A></FONT>
</P>

<P><FONT SIZE=3D2>or from the XACML Web site at <A =
HREF=3D"http://www.oasis-open.org/committees/xacml" =
TARGET=3D"_blank">http://www.oasis-open.org/committees/xacml</A></FONT>
</P>

<P><FONT SIZE=3D2>Comments are welcome and encouraged from all =
interested parties. </FONT>
<BR><FONT SIZE=3D2>Comments should be submitted to the XACML comment =
list at </FONT>
<BR><FONT SIZE=3D2>[e-mail].</FONT>
</P>

<P><FONT SIZE=3D2>(OASIS comment lists no longer require subscription, =
but you will be </FONT>
<BR><FONT SIZE=3D2>required by the mail server to return a token to =
confirm your message.)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-Karl</FONT>
</P>

<P><FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>Karl F. Best</FONT>
<BR><FONT SIZE=3D2>Vice President, OASIS</FONT>
<BR><FONT SIZE=3D2>+1 978.667.5115 x206</FONT>
<BR><FONT SIZE=3D2>[e-mail]&nbsp; <A =
HREF=3D"http://www.oasis-open.org" =
TARGET=3D"_blank">http://www.oasis-open.org</A></FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-</FONT>
<BR><FONT SIZE=3D2>To subscribe or unsubscribe from this elist use the =
subscription</FONT>
<BR><FONT SIZE=3D2>manager: &lt;<A =
HREF=3D"http://lists.oasis-open.org/ob/adm.pl" =
TARGET=3D"_blank">http://lists.oasis-open.org/ob/adm.pl</A>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2877C.BFD523CA--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA8LaMY23699 for ietf-pkix-bks; Fri, 8 Nov 2002 13:36:22 -0800 (PST)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA8LaKv23695 for <[e-mail]>; Fri, 8 Nov 2002 13:36:21 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02673; Fri, 8 Nov 2002 16:36:25 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100312b9f1d56e2d28@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <p0510031eb9ecb0a938ee@[128.89.88.34]> <[e-mail]>
Date: Fri, 8 Nov 2002 16:36:36 -0500
To: "Phillip H. Griffin" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate profile for Biometrics information.
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-1175331040==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1175331040==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Phil,

>><SNIP>
>>i think there is some confusion here. My fingerprints and other 
>>biometrics are not secrets, but many folks consider them to be 
>>"private." The concern I coted is that anyone with access to a 
>>plaintext template, and knowledge of the scoring algorithm used by 
>>a vendor, could engage in analysis to try to construct a digital 
>>input which would be accepted by the algorithm as a match for the 
>>template in question. This, as Tony noted, represents a distinct 
>>form of attack from the covert acquisition of physical biometric 
>>samples, and it is a form of attack that is easy to effect from a 
>>distance, perhaps for thousands of individuals whose templates 
>>might be disclosed. So, I do think there is good cause to take 
>>precautions to prevent disclosure of this data wherever it is 
>>stored, transmitted, etc.
>>
>A possibility of course, but I think that there are much easier 
>attacks to launch.
>And this one depends on being able to guess algorithm details and to 
>be able to
>spoof input samples into a matching system where the biometric data in the
>templates may have been obscurred or encrypted. And it is an overall security
>system, which may integrate biometrics along with other factors, that must be
>attacked, and not simply the biometric.

In the security business, we always assume that the attackers know 
the system config, algorithms, etc. So the impediments you cite here 
would be discounted.

I don't fully understand the second part of your comment. If 
biometrics are used as the primary (sole?) authentication mechanism 
(which is the usual proposal because the ease of use feature of 
biometrics is lost if one imposes other mechanisms such as passwords 
or crypto tokens), then defeating the biometrics defeats 
authentication, and that usually undermines access control (which is 
typically based on authentication), etc. Yes, in some circumstances 
there might be other safeguards that might limit the damage done by 
subversion of a user authentication mechanism, but user 
authentication is typically our first line of defense, and one would 
expect that someone who subverted this mechanism would, at a minimum, 
be able to pose as the user who is being impersonated and thus 
inherit the authorizations of that person.  That's a pretty serious 
security problem.

>In all US standards, a template contains two basic parts, header information
>and biometric data. At the message level, the  later is treated as 
>opaque, having
>no specified structural details. In fact there are details, but 
>these are generally held
>private by vendors as are the details of their processing algorithms 
>and matching
>methods, which frequently incorporate safeguards against spoofing the inputs.

Again, the proprietary nature of the algorithms is discounted; it 
falls under the rubric of "security by obscurity." I also have little 
confidence in the measures used by low cost biometric capture devices 
to deter spoofing. So, unless you have a more concrete example of the 
sort of safeguards you allude to above, I don't think we agree on 
there being any substantial countermeasures for a typical, remote 
user authentication application under these compromise scenarios.

>Depending on the vendor, and where and how the template is used, the biometric
>data portion of a template may be encrypted or otherwise obscured. 
>Over the past
>several years, I've heard of the data being protected by everything 
>from Triple
>DES, to strong cryptography but I can't tell you what it is, to it's 
>a proprietary
>format that you'll never be able to guess.

3DES is reasonably strong crypto, but it's not very useful in many 
attacks scenarios.  If all biometric capture devices from a vendor 
have the same key (a real example) then this is not much of a 
deterrent. None of the devices I've seen meet FIPS 140-1 criteria for 
protecting keys, so it would usually be easy to extract keys from any 
of these devices anyway.

>Now this may sound bad at first blush. But there is a great range of products
>to consider that can provide varying levels of security for protecting assets
>with different values at different costs. At the low end, PKI and encryption
>may be out of the question. At the high end, biometrics will likely be used
>as part of a security solution along with other measures and factors. And
>beyond the template format itself are the issues of just how inputs are
>processed to create a template in the first place and how sample inputs
>are processed or validated validated before a system attempts a match.

Biometrics are not intrinsically more secure than use of certs, say 
with good hardware tokens, so I object to the implied spectrum you 
cite above. Again, the major, credible push for biometric use stems 
from user convenience and possible cost savings. Arguments about 
superior security have usually been invalid, if examined in detail 
against mechanisms other than simple, static passwords.

>
>But how enrollment data is collected and processed to form a template, and
>how samples are used to perform matches are points at which there are often
>safeguards that must be used against spoofing the system, perhaps even the
>encryption of some or all parts of the data. An example being the Afgan girl's
>iris data being detected as coming from a photograph and not a valid iris scan
>camera. This on top of the proprietary methods being used, environmental
>controls and hardware.

Encryption of the data during transmission from capture/sample point 
to the checking point is necessary, but far from sufficient to make 
these systems secure.


><SNIP>
>In X9.84 and XCBF, when signature mechanisms are used for sample or
>template protection, they must be used as part of an overall solution.These
>standards support four basic mechanisms, SignedData, AuthenticatedData
>and an ordinary digital signature like the one used to sign a 
>certificate, and a
>MAC (HMAC). A digital certificate then is really just another package for
>biometric information, one that extends an ordinary signature to identify the
>key of the signer and provide support for a hierarchy.

Putting the template into the cert is just plain bad in many, many 
instances. I don't claim that there are no contexts in which it might 
be appropriate, but we seem to have a dearth of them so far, and lost 
of examples where it is a bad idea.

><SNIP>
>
>In most systems, I don't believe that privacy will be an issue for templates
>at the message level. But here privacy will be needed for some communities
>even for the header data. For example, knowing which version of vendor
>product is being used or the age of a record of some biometric type may
>assist an attacker.

yes, and there will be lots of ways to acquire that data. let's not 
forget the fake ATM attacks as a means of acquiring PINs and account 
info.

>I think that biometric samples, how they are treated when they are collected
>and processed to form a template, what becomes of them after this process,
>and how they are treated when they are collected to perform a match, will
>become the dominant points of public concern. I wouldn't much mind your
>having my photograph if I knew that no system would grant you access to
>something I valued based on your having a copy. I wouldn't mind your
>collecting my fingerprint to match against the template on my smart card
>if I knew the sample were handled properly - not retained or shared with
>others.

That might be a rational level of concern, but only if the systems 
were a lot better than they are now. low cost sensors are readily 
fooled in many contexts, starting with that photo or fingerprint, or 
with a template. And, given that cost if always a major factor in 
system design processes, I expect that lower cost sensors that are 
more easily fooled will be deployed, with predictable results.

>
>>>Biometric information seems destined to become the financial 
>>>identifier that one
>>>day replaces the social security number. There's much interest in 
>>>using it to try
>>>to combat identity fraud, said to be the fastest rising crime. On 
>>>another front,
>>>a DOD pilot is to use a biometric extension in a smart card certificate.
>>>
>>
>>I think this is a very questionable assertion. The SSN is an ID and 
>>a convenient one. it is dangerous one in that people rely on it in 
>>the absence of any secure means of verifying that the individual 
>>asserting the SSN is the :owner" of that ID.  Biometric data is
>>
>SSNs can be reassigned, so they are not necessarily unique.

it is true that they are no necessarily unique, though not for the 
reason you stated. (I had the privilege of being briefed on this by 
the SSA folks in the course of a NRC study that I chair.) But, the 
combination of SSN and name is unique, for all practical purposes, 
and lots of systems rely on that and work well.

>And I agree, and the point I tried to make above is that if
>systems do not care who, what or where an input comes from,
>then all bets are off.

But systems that try to verify user identity remotely, which is what 
we often do in the information systems arena, do not have much 
reliable info about exactly where the inputs originate.

>
>>not an ID. It varies from sample to sample and thus is a poor 
>>substitute for any form of static, globally unique ID. Also, as you 
>>noted, templates are vendor-specific, which makes this for of ID 
>>not useful for identifying the same individual in two contexts 
>>where different biometric systems from different vendors have been 
>>employed.
>>
>Not unlike having the same keys being certified by different authorities.

I disagree. the bits in the template will likely differ, the samples 
differ every time I capture them, but the public key is constant in 
this example.

>>>The BiometricObject in X9.84 and XCBF contains a 'hole' that can carry an
>>>arbitrary payload relevant to an application. There are many 
>>>things this might
>>>be, the blinded hash of a customer PAN as used in SET for cardholder common
>>>names, an encrypted smart identifier, etc. This type can also 
>>>carry the biometric
>>>processing algorithm and matching method needed by a relying party. And most
>>>importantly, a set of these can carry multiple occurances of a 
>>>biometric, say three
>>>fingerprints, or sets of mutiple biometric types, say ten 
>>>fingerprints and two iris
>>>
>>>images.
>>>
>>
>>I don't think the representational flexibility you describe here 
>>addresses the fundamental security and privacy issues being raised.
>>
>I believe that the capability of binding access to an account, to a 
>specific token,
>and to a means of identifying the particular individual authorized 
>to use the token
>and thereby to access the account, can be used to address security 
>issues. If the
>template is stored only on the token and not on a centralized data 
>base, then there
>are also privacy issues that might be addressed.

Yes, if the token is stored only on the token and NOT sent to a 
central sever for comparison, many privacy issues are alleviated and 
some security concerns are diminished as well.  But, I don't need to 
put the template in a cert to support this usage model, since it is 
consumed locally by the card.

Steve
--============_-1175331040==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: Certificate profile for Biometrics
information.</title></head><body>
<div>Phil,</div>
<div><br></div>
<blockquote type="cite" cite>
<blockquote type="cite" cite>&lt;SNIP&gt;</blockquote>
<blockquote type="cite" cite>i think there is some confusion here. My
fingerprints and other biometrics are not secrets, but many folks
consider them to be &quot;private.&quot; The concern I coted is that
anyone with access to a plaintext template, and knowledge of the
scoring algorithm used by a vendor, could engage in analysis to try to
construct a digital input which would be accepted by the algorithm as
a match for the template in question. This, as Tony noted, represents
a distinct form of attack from the covert acquisition of physical
biometric samples, and it is a form of attack that is easy to effect
from a distance, perhaps for thousands of individuals whose templates
might be disclosed. So, I do think there is good cause to take
precautions to prevent disclosure of this data wherever it is stored,
transmitted, etc.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite>A possibility of course, but I think that
there are much easier attacks to launch.<br>
And this one depends on being able to guess algorithm details and to
be able to<br>
spoof input samples into a matching system where the biometric data in
the<br>
templates may have been obscurred or encrypted. And it is an overall
security<br>
system, which may integrate biometrics along with other factors, that
must be<br>
attacked, and not simply the biometric.</blockquote>
<div><br></div>
<div>In the security business, we always assume that the attackers
know the system config, algorithms, etc. So the impediments you cite
here would be discounted.</div>
<div><br></div>
<div>I don't fully understand the second part of your comment. If
biometrics are used as the primary (sole?) authentication mechanism
(which is the usual proposal because the ease of use feature of
biometrics is lost if one imposes other mechanisms such as passwords
or crypto tokens), then defeating the biometrics defeats
authentication, and that usually undermines access control (which is
typically based on authentication), etc. Yes, in some circumstances
there might be other safeguards that might limit the damage done by
subversion of a user authentication mechanism, but user authentication
is typically our first line of defense, and one would expect that
someone who subverted this mechanism would, at a minimum, be able to
pose as the user who is being impersonated and thus inherit the
authorizations of that person.&nbsp; That's a pretty serious security
problem.</div>
<div><br></div>
<blockquote type="cite" cite>In all US standards, a template contains
two basic parts, header information<br>
and biometric data. At the message level, the&nbsp; later is treated
as opaque, having<br>
no specified structural details. In fact there are details, but these
are generally held<br>
private by vendors as are the details of their processing algorithms
and matching<br>
methods, which frequently incorporate safeguards against spoofing the
inputs.</blockquote>
<div><br></div>
<div>Again, the proprietary nature of the algorithms is discounted; it
falls under the rubric of &quot;security by obscurity.&quot; I also
have little confidence in the measures used by low cost biometric
capture devices to deter spoofing. So, unless you have a more concrete
example of the sort of safeguards you allude to above, I don't think
we agree on there being any substantial countermeasures for a typical,
remote user authentication application under these compromise
scenarios.</div>
<div><br></div>
<blockquote type="cite" cite>Depending on the vendor, and where and
how the template is used, the biometric<br>
data portion of a template may be encrypted or otherwise obscured.
Over the past<br>
several years, I've heard of the data being protected by everything
from Triple<br>
DES, to strong cryptography but I can't tell you what it is, to it's a
proprietary</blockquote>
<blockquote type="cite" cite>format that you'll never be able to
guess.</blockquote>
<div><br></div>
<div>3DES is reasonably strong crypto, but it's not very useful in
many attacks scenarios.&nbsp; If all biometric capture devices from a
vendor have the same key (a real example) then this is not much of a
deterrent. None of the devices I've seen meet FIPS 140-1 criteria for
protecting keys, so it would usually be easy to extract keys from any
of these devices anyway.</div>
<div><br></div>
<blockquote type="cite" cite>Now this may sound bad at first blush.
But there is a great range of products</blockquote>
<blockquote type="cite" cite>to consider that can provide varying
levels of security for protecting assets<br>
with different values at different costs. At the low end, PKI and
encryption<br>
may be out of the question. At the high end, biometrics will likely be
used<br>
as part of a security solution along with other measures and factors.
And<br>
beyond the template format itself are the issues of just how inputs
are<br>
processed to create a template in the first place and how sample
inputs<br>
are processed or validated validated before a system attempts a
match.</blockquote>
<div><br></div>
<div>Biometrics are not intrinsically more secure than use of certs,
say with good hardware tokens, so I object to the implied spectrum you
cite above. Again, the major, credible push for biometric use stems
from user convenience and possible cost savings. Arguments about
superior security have usually been invalid, if examined in detail
against mechanisms other than simple, static passwords.</div>
<div><br></div>
<blockquote type="cite" cite><br>
But how enrollment data is collected and processed to form a template,
and<br>
how samples are used to perform matches are points at which there are
often<br>
safeguards that must be used against spoofing the system, perhaps even
the<br>
encryption of some or all parts of the data. An example being the
Afgan girl's<br>
iris data being detected as coming from a photograph and not a valid
iris scan<br>
camera. This on top of the proprietary methods being used,
environmental<br>
controls and hardware.</blockquote>
<div><br></div>
<div>Encryption of the data during transmission from capture/sample
point to the checking point is necessary, but far from sufficient to
make these systems secure.</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite>&lt;SNIP&gt;</blockquote>
<blockquote type="cite" cite>In X9.84 and XCBF, when signature
mechanisms are used for sample or<br>
template protection, they must be used as part of an overall
solution.These<br>
standards support four basic mechanisms, SignedData,
AuthenticatedData<br>
and an ordinary digital signature like the one used to sign a
certificate, and a<br>
MAC (HMAC). A digital certificate then is really just another package
for<br>
biometric information, one that extends an ordinary signature to
identify the</blockquote>
<blockquote type="cite" cite>key of the signer and provide support for
a hierarchy.</blockquote>
<div><br></div>
<div>Putting the template into the cert is just plain bad in many,
many instances. I don't claim that there are no contexts in which it
might be appropriate, but we seem to have a dearth of them so far, and
lost of examples where it is a bad idea.</div>
<div><br></div>
<blockquote type="cite" cite>&lt;SNIP&gt;</blockquote>
<blockquote type="cite" cite><br>
In most systems, I don't believe that privacy will be an issue for
templates<br>
at the message level. But here privacy will be needed for some
communities<br>
even for the header data. For example, knowing which version of
vendor<br>
product is being used or the age of a record of some biometric type
may<br>
assist an attacker.</blockquote>
<div><br></div>
<div>yes, and there will be lots of ways to acquire that data. let's
not forget the fake ATM attacks as a means of acquiring PINs and
account info.</div>
<div><br></div>
<blockquote type="cite" cite>I think that biometric samples, how they
are treated when they are collected<br>
and processed to form a template, what becomes of them after this
process,<br>
and how they are treated when they are collected to perform a match,
will<br>
become the dominant points of public concern. I wouldn't much mind
your<br>
having my photograph if I knew that no system would grant you access
to<br>
something I valued based on your having a copy. I wouldn't mind
your<br>
collecting my fingerprint to match against the template on my smart
card<br>
if I knew the sample were handled properly - not retained or shared
with<br>
others.</blockquote>
<div><br></div>
<div>That might be a rational level of concern, but only if the
systems were a lot better than they are now. low cost sensors are
readily fooled in many contexts, starting with that photo or
fingerprint, or with a template. And, given that cost if always a
major factor in system design processes, I expect that lower cost
sensors that are more easily fooled will be deployed, with predictable
results.</div>
<div><br></div>
<blockquote type="cite" cite><br>
<blockquote type="cite" cite>
<blockquote type="cite" cite>Biometric information seems destined to
become the financial identifier that one<br>
day replaces the social security number. There's much interest in
using it to try<br>
to combat identity fraud, said to be the fastest rising crime. On
another front,<br>
a DOD pilot is to use a biometric extension in a smart card
certificate.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>I think this is a very questionable
assertion. The SSN is an ID and a convenient one. it is dangerous one
in that people rely on it in the absence of any secure means of
verifying that the individual asserting the SSN is the :owner&quot; of
that ID.&nbsp; Biometric data is</blockquote>
<blockquote type="cite" cite><br></blockquote>
</blockquote>
<blockquote type="cite" cite>SSNs can be reassigned, so they are not
necessarily unique.</blockquote>
<div><br></div>
<div>it is true that they are no necessarily unique, though not for
the reason you stated. (I had the privilege of being briefed on this
by the SSA folks in the course of a NRC study that I chair.) But, the
combination of SSN and name is unique, for all practical purposes, and
lots of systems rely on that and work well.</div>
<div><br></div>
<blockquote type="cite" cite>And I agree, and the point I tried to
make above is that if<br>
systems do not care who, what or where an input comes from,<br>
then all bets are off.</blockquote>
<div><br></div>
<div>But systems that try to verify user identity remotely, which is
what we often do in the information systems arena, do not have much
reliable info about exactly where the inputs originate.</div>
<div><br></div>
<blockquote type="cite" cite><br>
<blockquote type="cite" cite>not an ID. It varies from sample to
sample and thus is a poor substitute for any form of static, globally
unique ID. Also, as you noted, templates are vendor-specific, which
makes this for of ID not useful for identifying the same individual in
two contexts where different biometric systems from different vendors
have been employed.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite>Not unlike having the same keys being
certified by different authorities.</blockquote>
<div><br></div>
<div>I disagree. the bits in the template will likely differ, the
samples differ every time I capture them, but the public key is
constant in this example.</div>
<div><br></div>
<blockquote type="cite" cite>
<blockquote type="cite" cite>
<blockquote type="cite" cite>The<font face="Courier New" size="-1"><b>
BiometricObject</b></font> in X9.84 and XCBF contains a 'hole' that
can carry an<br>
arbitrary payload relevant to an application. There are many things
this might<br>
be, the blinded hash of a customer PAN as used in SET for cardholder
common<br>
names, an encrypted smart identifier, etc. This type can also carry
the biometric<br>
processing algorithm and matching method needed by a relying party.
And most<br>
importantly, a set of these can carry multiple occurances of a
biometric, say three<br>
fingerprints, or sets of mutiple biometric types, say ten fingerprints
and two iris<br>
</blockquote>
<blockquote type="cite" cite>images.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>I don't think the representational
flexibility you describe here addresses the fundamental security and
privacy issues being raised.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite>I believe that the capability of binding
access to an account, to a specific token,<br>
and to a means of identifying the particular individual authorized to
use the token<br>
and thereby to access the account, can be used to address security
issues. If the<br>
template is stored only on the token and not on a centralized data
base, then there</blockquote>
<blockquote type="cite" cite>are also privacy issues that might be
addressed.</blockquote>
<div><br></div>
<div>Yes, if the token is stored only on the token and NOT sent to a
central sever for comparison, many privacy issues are alleviated and
some security concerns are diminished as well.&nbsp; But, I don't need
to put the template in a cert to support this usage model, since it is
consumed locally by the card.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1175331040==_ma============--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA8FAg827989 for ietf-pkix-bks; Fri, 8 Nov 2002 07:10:42 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA8FAev27984 for <[e-mail]>; Fri, 8 Nov 2002 07:10:40 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id gA8FAWDH025758; Fri, 8 Nov 2002 15:10:32 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021108070500.03498818@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 08 Nov 2002 07:09:46 -0800
To: Peter Gietz <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: new version of draft on additional x509 certificate schema for LDAP
Cc: Ietf-Pkix <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 02:47 AM 2002-11-08, Peter Gietz wrote:
>I am not yet sure, why Kurt proposes an ABSRACT object class for x509certificate instead of a STRUCTURAL derived from top.

To prevent instantiation without a certificate.

Kurt



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA8DdiI18072 for ietf-pkix-bks; Fri, 8 Nov 2002 05:39:44 -0800 (PST)
Received: from ms01020.ffm.avinci.de (h-213.61.184.2.host.de.colt.net [213.61.184.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA8Ddgv18068 for <[e-mail]>; Fri, 8 Nov 2002 05:39:42 -0800 (PST)
Received: from [10.110.20.169] ([10.110.20.169]) by ms01020.ffm.avinci.de with Microsoft SMTPSVC(5.0.2195.2966); Fri, 8 Nov 2002 14:42:02 +0100
Date: Fri, 08 Nov 2002 14:42:01 +0100
From: Norbert Klasen <[e-mail]>
To: Peter Gietz <[e-mail]>, Ietf-Pkix <[e-mail]>
Subject: Re: new version of draft on additional x509 certificate schema for LDAP
Message-ID: <13824208.1036766521@[10.110.20.169]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/2.2.1 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-OriginalArrivalTime: 08 Nov 2002 13:42:02.0399 (UTC) FILETIME=[9E4D92F0:01C2872C]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Freitag, 8. November 2002 11:47 +0100 Peter Gietz 
<[e-mail]> wrote:

> I am not yet sure, why Kurt proposes an ABSRACT object class for
> x509certificate instead of a STRUCTURAL derived from top.

If x509certificate would be STRUCTURAL, one could create entries with 
x509certificate as the "structural object class of the entry". When is is 
made ABSTRACT, such entries are not allowed. This will enforce the 
requirement that an entry must contain the binary blob of the certifate as 
only the STRUCTURAL object classes x509cACertificate and 
x509userCertificate may be instantiated.

Norbert


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA8DIDj14974 for ietf-pkix-bks; Fri, 8 Nov 2002 05:18:13 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA8DICv14970 for <[e-mail]>; Fri, 8 Nov 2002 05:18:12 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA02205; Fri, 8 Nov 2002 14:18:11 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Fri, 8 Nov 2002 14:18:12 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id OAA25318; Fri, 8 Nov 2002 14:18:10 +0100 (MET)
Date: Fri, 8 Nov 2002 14:18:10 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Phil, thanks for trying to help, I think that's for sure useful in some 
ditto 
> cases but here we can't / don't wan't
> to describe all the possible combinations of PKIFailure BIT STRING 
> values since in my opinion that
> will probably create a great mess around a "simple" issue!

There are indeed some protocols that use BITSTRING in a way that
each bit is not indicating independantly something specific, or, 
well, at least there is only a formal orthogonal 2**N space.
Sometime it would have been better to assign three possible values
0 1 2 to an integer instead of havin a 2 bit combination (which is
in fact larger to encode).

> 
> Maybe Peter, Denis, Andrew, Peter S. or someone else have another opinion...
> 

  PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
      -- text encoded as UTF-8 String (note:  each UTF8String SHOULD
      -- include an RFC 1766 language tag to indicate the language
      -- of the contained text)

How can the language tag be distinguished from the text? 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA8CYML13254 for ietf-pkix-bks; Fri, 8 Nov 2002 04:34:22 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA8CYLv13249 for <[e-mail]>; Fri, 8 Nov 2002 04:34:21 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA02046; Fri, 8 Nov 2002 13:34:20 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Fri, 8 Nov 2002 13:34:20 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id NAA25259; Fri, 8 Nov 2002 13:34:19 +0100 (MET)
Date: Fri, 8 Nov 2002 13:34:19 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-cvp-01.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> The answer is quite simple.
That was a rhetoric question anyway.

> 
> Everything which is in the core protocol (i.e. what MUST be supported either 
> for DPD or DPV) is not designed using extensions.

But since you answered: This does not mean IMO that other things
should  be designed using extensions.

  "A server may support either DPV or DPD, or both DPV and DPD."

A DPV implmentation can consider all DPD functionality as
optional feature. 


--

> I let you make a proposal.

Since you have already 
requesterName        [1]  EXPLICIT GeneralName       OPTIONAL,

to indicate identities, I suggest that you change this to 

requesterNames        [1]  GeneralNames       OPTIONAL,


A server MUST add its own identity to the list of clients when 
forwarding the request.


A server that supports relaying performs tests: 

- It checks whether the requests already contains it own identity,
  and SHOULD reject the request if so.

- In case it knowns the identity of a relay to which it forwards
  the request, it MAY checks whether the request already contains
  the identity of the next server and MAY reject the request.

change 

     cVPServerCert              ESSCertID                 OPTIONAL,

into GeneralNames indicating the identities of the servers
that paricipated in creating the response.  

add a corresponding optional field to the request allowing a
client to indicate to a server to indicate for example the
identity of other servers that are known (to the client) to
be able to perform the service. 

change "requesterData" to be a SEQUENCE, allow a relay to add elements
to the list. 

Provide a similar list of text for the responses. 
---

Can you clarify the relation between signtures of the individualRepsones
and the global one. Does this mean for example that you can have 
individualresponses signed by other entities? 

--

It is intended that the policy discovery is a MUST for
both protocols, I guess, as sepcified in the requirements
doc. I object to this. policy discovery should be an optional
feature.
---
Additional hint (in order to further comment some points
that you havn't addressed).

  Provide a complete ASN1 module and run it through some 
  compiler before publishing.


--


Peter
 


 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA8BfB209975 for ietf-pkix-bks; Fri, 8 Nov 2002 03:41:11 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA8Bf9v09971 for <[e-mail]>; Fri, 8 Nov 2002 03:41:10 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA01860; Fri, 8 Nov 2002 12:41:09 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Fri, 8 Nov 2002 12:41:09 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id MAA25111; Fri, 8 Nov 2002 12:41:07 +0100 (MET)
Date: Fri, 8 Nov 2002 12:41:07 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >kabbalistic interpretations to the text ("The placing of the comma in 
> >the second sentence implies that the author meant X, and therefore your
> >implementation is wrong and mine is right").  Saying something like
> >"This is a free-format text field containing information about the
> >error or errors" would convey the intended meaning without implying
> >that there's some particular required way to do it.
> >
> I understand and totally agree with you, Peter. And that's a good 
> sentence, I think.

What about also: 

\0 characters that occurs MUST NOT be treated as end of string indicators.

Multiple values in the SEQUENCE SHOULD be used to line formatting.
CR, LF, TAB   MUST not be used.

A conforming client SHOULD NOT reject response containing these characters.
it MAY replace them by space.

Well, shouldn't this text go into an update of CMP and NOT into RFC 3161? 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA8B2Mi07458 for ietf-pkix-bks; Fri, 8 Nov 2002 03:02:22 -0800 (PST)
Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA8B2Jv07438 for <[e-mail]>; Fri, 8 Nov 2002 03:02:19 -0800 (PST)
Received: (qmail 3145 invoked from network); 8 Nov 2002 10:52:38 -0000
Received: from unknown (HELO multicert.com) (62.48.185.5) by mail0.sibs.pt with SMTP; 8 Nov 2002 10:52:38 -0000
Message-ID: <[e-mail]>
Date: Fri, 08 Nov 2002 10:59:32 +0000
From: Ricardo Barroso <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Phillip H. Griffin" <[e-mail]>
CC: Denis Pinkas <[e-mail]>, [e-mail]
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/alternative; boundary="------------050001010301000001080204"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------050001010301000001080204
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Phil, thanks for trying to help, I think that's for sure useful in some 
cases but here we can't / don't wan't
to describe all the possible combinations of PKIFailure BIT STRING 
values since in my opinion that
will probably create a great mess around a "simple" issue!

Maybe Peter, Denis, Andrew, Peter S. or someone else have another opinion...

Best regards,
Ricardo Barroso

MULTICERT S.A.
www.multicert.com <http://www.multicert.com>


Phillip H. Griffin wrote:

> It seems to me that you have a notation readily at hand that allows
> you to assign names to any bit pattern you choose. For example,
>
>    ErrorCodes ::= BIT STRING
>
>    iMeanAllOfTheBits ErrorCodes ::= '1111111111111'B
>
> Once you've assigned useful names to acceptable bit patterns, you gain
> the advantage of being able to refer to them in English prose, such as
> stating "when the value of type ErrorCodes is iManAllOfTheBits, the
> receiving application should blah blah blah".
>
> Phil
>
>
> Ricardo Barroso wrote:
>
>> In my opion in RFC 3161/draft-ietf-pkix-rfc3161bis-00, section 2.4.2.:
>>
>>    «When the TimeStampToken is not present, the failInfo indicates the
>>    reason why the time-stamp request was rejected and may be one of the
>>    following values.»
>>
>> should be replace by something like this:
>>
>>    «When the TimeStampToken is not present, the failInfo indicates one
>>    or more reasons why the time-stamp request was rejected and may be
>>    one or more of the following values.»
>>
>> and:
>>
>>    «The statusString field of PKIStatusInfo MAY be used to include reason
>>    text such as "messageImprint field is not correctly formatted".»
>>
>> should also be replaced by something like this:
>>
>>    «The statusString field of PKIStatusInfo MAY be used to include 
>> reason(s)
>>    text such as "messageImprint field is not correctly formatted".»
>>
>> I have no experience in writing RFCs and I don't know if my English 
>> is the best suited for this
>> cases but it's my proposal.
>>
>> Denis, I don't know if I got it right, when you say "is not crystal 
>> clear when bits are described"
>> do you mean that should be written something more about the bits 
>> inside the PKIFailureInfo
>> BIT STRING?
>>
>> Best regards,
>> Ricardo Barroso
>>
>> MULTICERT S.A.
>> www.multicert.com <http://www.multicert.com>
>>
>>
>> Denis Pinkas wrote:
>>
>>>
>>> Since, you seem to all agree in principle, can some of you propose a 
>>> full text remplacement, providing the old and new sentence ?
>>>
>>> "Only the following values MAY occur" is not crystal clear when bits 
>>> are described.
>>>
>>> Denis
>>>
>>> PS. Remember that I am still awaiting an interoperability test so 
>>> that we can progress the document on the Standards Track.
>>>
>>>
>>>> Peter Sylvester wrote:
>>>>
>>>>>> Because with RFC 3161 it's possible that exist two compliant systems
>>>>>> which can't interoperate properly in some situations because one 
>>>>>> accepts that
>>>>>> PKIFailueInfo contains more than one bit with value one (1) and 
>>>>>> the other not!
>>>>>>   
>>>>>
>>>>>
>>>>>
>>>>> It seems that the text could say 'MAY only be any of the following 
>>>>> values'.
>>>>> as the list is a restriction (and extension) of the values define 
>>>>> in CMP.
>>>>>
>>>>> Or: 'Only the following values MAY occur'.
>>>>>
>>>>> I could detect an invalid hash algorithm and an unsupported 
>>>>> extension,
>>>>> an unacceptable policy, and even time source not available all 
>>>>> together.
>>>>
>>>>
>>>> Peter, I agree with you.
>>>>
>>>> Ricardo Barroso
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>


--------------050001010301000001080204
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Phil, thanks for trying to help, I think that's for sure useful in some cases
but here we can't / don't wan't <br>
to describe all the possible combinations of PKIFailure BIT STRING values
since in my opinion that <br>
will probably create a great mess around a "simple" issue!<br>
<br>
Maybe Peter, Denis, Andrew, Peter S. or someone else have another opinion...<br>
<br>
Best regards,<br>
Ricardo Barroso<br>
<br>
MULTICERT S.A.<br>
<a href="http://www.multicert.com">www.multicert.com</a><br>
<br>
<br>
Phillip H. Griffin wrote:<br>
<blockquote type="cite" cite="[e-mail]">     
  <meta http-equiv="Content-Type" content="text/html;">
  <title></title>
     It seems to me that you have a notation readily at hand that allows
  <br>
 you to assign names to any bit pattern you choose. For example,<br>
 <br>
 &nbsp; &nbsp;ErrorCodes ::= BIT STRING<br>
 <br>
 &nbsp; &nbsp;iMeanAllOfTheBits&nbsp;ErrorCodes ::= '1111111111111'B<br>
 <br>
 Once you've assigned useful names to acceptable bit patterns, you gain<br>
 the advantage of being able to refer to them in English prose, such as <br>
 stating "when the value of type ErrorCodes is iManAllOfTheBits, the <br>
 receiving application should blah blah blah".<br>
 <br>
 Phil<br>
 <br>
 <br>
 Ricardo Barroso wrote:<br>
 
  <blockquote type="cite" cite="[e-mail]">
    <title></title>
           In my opion in RFC 3161/draft-ietf-pkix-rfc3161bis-00, section
2.4.2.:<br>
  <br>
  &nbsp;&nbsp; &laquo;<tt>When the TimeStampToken is not present, the failInfo indicates
the<br>
  &nbsp;&nbsp; reason why the time-stamp request was rejected and may be one of the<br>
  &nbsp;&nbsp; following values.</tt>&raquo;<br>
  <br>
  should be replace by something like this:<br>
  <br>
  &nbsp;&nbsp; &laquo;<tt>When the TimeStampToken is not present, the failInfo indicates
one    <br>
  &nbsp;&nbsp; or more reasons why the time-stamp request was rejected and may be <br>
  &nbsp;&nbsp; one or more of the following values.</tt>&raquo;<br>
  <br>
  and:<br>
  <br>
  &nbsp;&nbsp; &laquo;<tt>The statusString field of PKIStatusInfo MAY be used to include
reason<br>
  &nbsp;&nbsp; text such as "messageImprint field is not correctly formatted".</tt>&raquo;<br>
  <br>
  should also be replaced by something like this:<br>
  <br>
  &nbsp;&nbsp; &laquo;<tt>The statusString field of PKIStatusInfo MAY be used to include
reason(s)<br>
  &nbsp;&nbsp; text such as "messageImprint field is not correctly formatted".</tt>&raquo;<br>
  <br>
  I have no experience in writing RFCs and I don't know if my English is
the  best suited for this <br>
  cases but it's my proposal.<br>
  <br>
  Denis, I don't know if I got it right, when you say "is not crystal clear
 when bits are  described" <br>
  do you mean that should be written something more about the bits inside 
the PKIFailureInfo <br>
  BIT STRING?<br>
  <br>
  Best regards,<br>
  Ricardo Barroso<br>
  <br>
  MULTICERT S.A.<br>
  <a href="http://www.multicert.com">www.multicert.com</a><br>
  <br>
  <br>
  Denis Pinkas wrote:<br>
     
    <blockquote type="cite" cite="[e-mail]"> <br>
  Since, you seem to all agree in principle, can some of you propose a full
  text remplacement, providing the old and new sentence ? <br>
   <br>
  "Only the following values MAY occur" is not crystal clear when bits are
  described. <br>
   <br>
  Denis <br>
   <br>
  PS. Remember that I am still awaiting an interoperability test so that
we   can progress the document on the Standards Track. <br>
   <br>
   <br>
         
      <blockquote type="cite">Peter Sylvester wrote: <br>
   <br>
             
        <blockquote type="cite">                
          <blockquote type="cite">Because with RFC 3161 it's possible that 
exist two compliant systems <br>
  which can't interoperate properly in some situations because one  accepts
 that <br>
  PKIFailueInfo contains more than one bit with value one (1) and the  other
 not! <br>
  &nbsp;  </blockquote>
   <br>
   <br>
  It seems that the text could say 'MAY only be any of the following  values'. 
       <br>
  as the list is a restriction (and extension) of the values define in CMP. 
       <br>
   <br>
  Or: 'Only the following values MAY occur'. <br>
   <br>
  I could detect an invalid hash algorithm and an unsupported extension,
          <br>
  an unacceptable policy, and even time source not available all together. 
        <br>
      </blockquote>
   <br>
  Peter, I agree with you. <br>
   <br>
  Ricardo Barroso <br>
   <br>
   <br>
   <br>
    </blockquote>
   <br>
   <br>
   <br>
   <br>
  </blockquote>
  <br>
  </blockquote>
 <br>
 </blockquote>
<br>
</body>
</html>

--------------050001010301000001080204--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA8ApDc05537 for ietf-pkix-bks; Fri, 8 Nov 2002 02:51:13 -0800 (PST)
Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA8ApAv05528 for <[e-mail]>; Fri, 8 Nov 2002 02:51:11 -0800 (PST)
Received: (qmail 2804 invoked from network); 8 Nov 2002 10:41:29 -0000
Received: from unknown (HELO multicert.com) (62.48.185.5) by mail0.sibs.pt with SMTP; 8 Nov 2002 10:41:29 -0000
Message-ID: <[e-mail]>
Date: Fri, 08 Nov 2002 10:48:25 +0000
From: Ricardo Barroso <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
References: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------080907000603050800040907"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------080907000603050800040907
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Peter Gutmann wrote:

>Ricardo Barroso <[e-mail]> writes:
>
>  
>
>>In my opinion even maintaining here the original RFC sentence, it doesn't 
>>restrict that you can't have for example a comma between more than one 
>>reason - that's still a valid string/"reason text" I suppose.
>>Do you agree with that? Do you think that a system that does that will
>>not be compliant?
>>    
>>
>
>My concern was that people are going to try and apply all sorts of 
>kabbalistic interpretations to the text ("The placing of the comma in 
>the second sentence implies that the author meant X, and therefore your
>implementation is wrong and mine is right").  Saying something like
>"This is a free-format text field containing information about the
>error or errors" would convey the intended meaning without implying
>that there's some particular required way to do it.
>
I understand and totally agree with you, Peter. And that's a good 
sentence, I think.

>Peter (who has just finished trying to mediate a debate among two 
>       software companies about how any angels you can fit in a DN:
>       "Your software is broken, fix it!" <-> "Our DNs are more 
>        standards-conformant than yours").
>
Lol, sometimes is hard to do our work! :)

Cheers,
Ricardo Barroso

MULTICERT S.A.
www.multicert.com <http://www.multicert.com>

--------------080907000603050800040907
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Peter Gutmann wrote:<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">Ricardo Barroso <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a> writes:

  </pre>
  <blockquote type="cite">
    <pre wrap="">In my opinion even maintaining here the original RFC sentence, it doesn't 
restrict that you can't have for example a comma between more than one 
reason - that's still a valid string/"reason text" I suppose.
Do you agree with that? Do you think that a system that does that will
not be compliant?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
My concern was that people are going to try and apply all sorts of 
kabbalistic interpretations to the text ("The placing of the comma in 
the second sentence implies that the author meant X, and therefore your
implementation is wrong and mine is right").  Saying something like
"This is a free-format text field containing information about the
error or errors" would convey the intended meaning without implying
that there's some particular required way to do it.</pre>
</blockquote>
I understand and totally agree with you, Peter. And that's a good sentence,
I think.<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">Peter (who has just finished trying to mediate a debate among two 
       software companies about how any angels you can fit in a DN:
       "Your software is broken, fix it!" &lt;-&gt; "Our DNs are more 
        standards-conformant than yours").</pre>
</blockquote>
Lol, sometimes is hard to do our work! :)<br>
<br>
Cheers,<br>
Ricardo Barroso<br>
<br>
MULTICERT S.A.<br>
<a href="http://www.multicert.com">www.multicert.com</a><br>
</body>
</html>

--------------080907000603050800040907--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA8AlXN05114 for ietf-pkix-bks; Fri, 8 Nov 2002 02:47:33 -0800 (PST)
Received: from isis.directory.dfn.de (isis.directory.dfn.de [134.2.217.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA8AlVv05110 for <[e-mail]>; Fri, 8 Nov 2002 02:47:31 -0800 (PST)
Received: from clara.directory.dfn.de (clara.directory.dfn.de [134.2.217.66]) by isis.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id gA8AlQE29192 for <[e-mail]>; Fri, 8 Nov 2002 11:47:26 +0100
Received: from daasi.de (mercury.directory.dfn.de [134.2.217.50]) by clara.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id gA8AlP704194 for <[e-mail]>; Fri, 8 Nov 2002 11:47:25 +0100
Message-ID: <[e-mail]>
Date: Fri, 08 Nov 2002 11:47:26 +0100
From: Peter Gietz <[e-mail]>
Organization: DAASI International GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: de-de, en-us, en
MIME-Version: 1.0
To: Ietf-Pkix <[e-mail]>
Subject: Re: new version of draft on additional x509 certificate schema for LDAP
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gA8AlWv05111
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with Kurt's and Russ's proposals. It is better to define the 
MUSTs inside the object class and attribute definitions. Everything else 
is not easily enforcable.

Thus I intend to do something like the following in the next version of 
the draft:

( x.x.x.x NAME 'x509userCert'
   EQUALITY certificateExactMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 SINGLE-VALUE )

( x.x.x.x NAME 'x509cACert'
   EQUALITY certificateExactMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 SINGLE-VALUE )

( x.x.x.x NAME 'x509certificate' ABSTRACT
  MUST ( x509serialNumber $ x509signatureAlgorithm
    $ x509issuer $ x509validityNotBefore $ x509validityNotAfter
    $ PublicKeyInfoAlgorithm )
  MAY ( mail $ x509authorityKeyIdentifier $ x509authorityCertIssuer
    $ x509authorityCertSerialNumber $ x509subjectKeyIdentifier
    $ x509keyUsage $ x509policyInformationIdentifier
    $ x509subjectAltNameRfc822Name $ x509subjectAltNameDnsName
    $ x509subjectAltNameDirectoryName $ x509subjectAltNameURI
    $ x509subjectAltNameIpAddress $ x509subjectAltNameRegisteredID
    $ x509isssuerAltNameRfc822Name $ x509isssuerAltNameDnsName
    $ x509isssuerAltNameDirectoryName $ x509isssuerAltNameURI
    $ x509isssuerAltNameIpAddress $ x509isssuerAltNameRegisteredID
    $ x509extKeyUsage $ x509cRLDistributionPoint
    $ x509certHolder) )

( x.x.x.x NAME 'x509userCertificate' SUP x509certificate
    MUST x509userCert
    MAY x509subject )

( x.x.x.x NAME 'x509cACertificate' SUP x509certificate
    MUST x509cACert $ x509subject )


BTW: I changed the name of the attribute x509certificateHolder to 
x509certHolder to prevent the same name for an attribute and an 
objectclass, following a suggestion by Michael Stroeder.

I am not yet sure, why Kurt proposes an ABSRACT object class for 
x509certificate instead of a STRUCTURAL derived from top.

Cheers,

Peter

> Kurt D. Zeilenga wrote:
> At 01:23 PM 2002-11-07, Housley, Russ wrote:
> 
> If we take your approach, with two different classes, we can impose the requirement that CAs have x509subject.
> 
> 
> Yes, we could.
> 
> Another section 4.4 requirement which concerns me is:
>   For the purpose of this specification, each entry with a   structural objectclass of x509certificate MUST have one
>   and only one value of the userCertificate attribute or
>   caCertificate attribute, respectively.
> This single-valued requirement should be enforced by schema
> by defining one or two (depending on whether a user/ca
> distinction is desired) new singled-valued x509 attribute
> types of certificate syntax and having the objectclass(es)
> require their presence.
> 
> That is, use schema rules to express requirements upon the
> representation of the information.
> 
> Kurt

[...]
-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]
D-72074 Tübingen                        email: [e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________
____



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA8Ahua04664 for ietf-pkix-bks; Fri, 8 Nov 2002 02:43:56 -0800 (PST)
Received: from isis.directory.dfn.de (isis.directory.dfn.de [134.2.217.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA8Ahsv04660 for <[e-mail]>; Fri, 8 Nov 2002 02:43:54 -0800 (PST)
Received: from clara.directory.dfn.de (clara.directory.dfn.de [134.2.217.66]) by isis.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id gA8AhmE28973; Fri, 8 Nov 2002 11:43:48 +0100
Received: from daasi.de (mercury.directory.dfn.de [134.2.217.50]) by clara.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id gA8Ahm704099; Fri, 8 Nov 2002 11:43:48 +0100
Message-ID: <[e-mail]>
Date: Fri, 08 Nov 2002 11:43:48 +0100
From: Peter Gietz <[e-mail]>
Organization: DAASI International GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: de-de, en-us, en
MIME-Version: 1.0
To: "Ramsay, Ron" <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: new version of draft on additional x509 certificate schema  f orLDAP
References: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gA8Ahtv04661
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ramsay, Ron wrote:
> I appreciate this. It requires engineering, though. You can get a lot of
> mileage simply with schema and a tool to convert a certificate into an
> entry.

which will be made available as Open Source fairly soon after draft 
version -02 (or pkixdraft -00).

Cheers,

Peter



> -----Original Message-----
> From: Steven Legg [mailto:[e-mail]]
> Sent: Friday, 8 November 2002 16:24
> To: Ramsay, Ron
> Cc: [e-mail]
> Subject: RE: new version of draft on additional x509 certificate schema
> forLDAP
> 
> 
> 
> Ron,
> 
> Ramsay, Ron wrote:
> 
>>I should think a key advantage of subordinate certificate 
>>entries is that
>>you may return a single certificate. If all certificates are 
>>stored in the
>>user's entry, you would generally receive them all on a search.
> 
> 
> David Chadwick's valuesReturnFilter control, in conjunction with
> a component matching rule, enables searches that return only the
> desired certificate, despite there being multiple certificate values
> in entries.
> 
> Regards,
> Steven
> 
> 
>>-----Original Message-----
>>From: Steven Legg [mailto:[e-mail]]
>>Sent: Thursday, 7 November 2002 4:52 PM
>>To: 'Peter Gietz'; 'Housley, Russ'
>>Cc: [e-mail]; 'Norbert Klasen'; 'David Chadwick'
>>Subject: RE: new version of draft on additional x509 
>>certificate schema
>>forLDAP
>>
>><snip>
>>
>>Since an implementation of component matching could always 
>>use internal
>>data structures that mimic the metadata approach, component 
>>matching is
>>theoretically no worse than the metadata approach. Component matching
>>obviously permits greater space efficiency since it does not 
>>require the
>>duplication of certificates as subordinate entries, and their 
>>component
>>parts as additional attributes (e.g. in our server implementation the
>>component parts of certificates, CRLs, etc, are indexed directly).
>>This has a positive effect on the overall efficiency of a directory
>>server, but the bigger win is in the clients which are free 
>>of the burden
>>of managing all the explicit redundancy entailed in metadata approach.
>>
>><snip>
>>
>>Regards,
>>Steven
>>
>>
> 
> 


-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]
D-72074 Tübingen                        email: [e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA85WaI21836 for ietf-pkix-bks; Thu, 7 Nov 2002 21:32:36 -0800 (PST)
Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA85WZv21828 for <[e-mail]>; Thu, 7 Nov 2002 21:32:35 -0800 (PST)
Received: by aspams52.ca.com with Internet Mail Service (5.5.2656.59) id <WPAFNR0J>; Fri, 8 Nov 2002 16:32:34 +1100
Message-ID: <[e-mail]>
From: "Ramsay, Ron" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: new version of draft on additional x509 certificate schema  f orLDAP
Date: Fri, 8 Nov 2002 16:33:03 +1100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I appreciate this. It requires engineering, though. You can get a lot of
mileage simply with schema and a tool to convert a certificate into an
entry.

-----Original Message-----
From: Steven Legg [mailto:[e-mail]]
Sent: Friday, 8 November 2002 16:24
To: Ramsay, Ron
Cc: [e-mail]
Subject: RE: new version of draft on additional x509 certificate schema
forLDAP



Ron,

Ramsay, Ron wrote:
> I should think a key advantage of subordinate certificate 
> entries is that
> you may return a single certificate. If all certificates are 
> stored in the
> user's entry, you would generally receive them all on a search.

David Chadwick's valuesReturnFilter control, in conjunction with
a component matching rule, enables searches that return only the
desired certificate, despite there being multiple certificate values
in entries.

Regards,
Steven

> -----Original Message-----
> From: Steven Legg [mailto:[e-mail]]
> Sent: Thursday, 7 November 2002 4:52 PM
> To: 'Peter Gietz'; 'Housley, Russ'
> Cc: [e-mail]; 'Norbert Klasen'; 'David Chadwick'
> Subject: RE: new version of draft on additional x509 
> certificate schema
> forLDAP
> 
> <snip>
> 
> Since an implementation of component matching could always 
> use internal
> data structures that mimic the metadata approach, component 
> matching is
> theoretically no worse than the metadata approach. Component matching
> obviously permits greater space efficiency since it does not 
> require the
> duplication of certificates as subordinate entries, and their 
> component
> parts as additional attributes (e.g. in our server implementation the
> component parts of certificates, CRLs, etc, are indexed directly).
> This has a positive effect on the overall efficiency of a directory
> server, but the bigger win is in the clients which are free 
> of the burden
> of managing all the explicit redundancy entailed in metadata approach.
> 
> <snip>
> 
> Regards,
> Steven
> 
> 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA85PEt21629 for ietf-pkix-bks; Thu, 7 Nov 2002 21:25:14 -0800 (PST)
Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id gA85P7v21624 for <[e-mail]>; Thu, 7 Nov 2002 21:25:08 -0800 (PST)
Received: (qmail 29806 invoked from network); 8 Nov 2002 05:18:11 -0000
Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 8 Nov 2002 05:18:10 -0000
Reply-To: <[e-mail]>
From: "Steven Legg" <[e-mail]>
To: "'Ramsay, Ron'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: new version of draft on additional x509 certificate schema  forLDAP
Date: Fri, 8 Nov 2002 16:24:01 +1100
Message-ID: <000201c286e7$0ce1fee0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ron,

Ramsay, Ron wrote:
> I should think a key advantage of subordinate certificate 
> entries is that
> you may return a single certificate. If all certificates are 
> stored in the
> user's entry, you would generally receive them all on a search.

David Chadwick's valuesReturnFilter control, in conjunction with
a component matching rule, enables searches that return only the
desired certificate, despite there being multiple certificate values
in entries.

Regards,
Steven

> -----Original Message-----
> From: Steven Legg [mailto:[e-mail]]
> Sent: Thursday, 7 November 2002 4:52 PM
> To: 'Peter Gietz'; 'Housley, Russ'
> Cc: [e-mail]; 'Norbert Klasen'; 'David Chadwick'
> Subject: RE: new version of draft on additional x509 
> certificate schema
> forLDAP
> 
> <snip>
> 
> Since an implementation of component matching could always 
> use internal
> data structures that mimic the metadata approach, component 
> matching is
> theoretically no worse than the metadata approach. Component matching
> obviously permits greater space efficiency since it does not 
> require the
> duplication of certificates as subordinate entries, and their 
> component
> parts as additional attributes (e.g. in our server implementation the
> component parts of certificates, CRLs, etc, are indexed directly).
> This has a positive effect on the overall efficiency of a directory
> server, but the bigger win is in the clients which are free 
> of the burden
> of managing all the explicit redundancy entailed in metadata approach.
> 
> <snip>
> 
> Regards,
> Steven
> 
> 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA84Vht19918 for ietf-pkix-bks; Thu, 7 Nov 2002 20:31:43 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA84Vfv19914 for <[e-mail]>; Thu, 7 Nov 2002 20:31:41 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gA84V5wA032277; Fri, 8 Nov 2002 17:31:05 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id RAA101389; Fri, 8 Nov 2002 17:31:05 +1300 (NZDT) (sender [e-mail])
Date: Fri, 8 Nov 2002 17:31:05 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ricardo Barroso <[e-mail]> writes:

>In my opinion even maintaining here the original RFC sentence, it doesn't 
>restrict that you can't have for example a comma between more than one 
>reason - that's still a valid string/"reason text" I suppose.
>Do you agree with that? Do you think that a system that does that will
>not be compliant?

My concern was that people are going to try and apply all sorts of 
kabbalistic interpretations to the text ("The placing of the comma in 
the second sentence implies that the author meant X, and therefore your
implementation is wrong and mine is right").  Saying something like
"This is a free-format text field containing information about the
error or errors" would convey the intended meaning without implying
that there's some particular required way to do it.

Peter (who has just finished trying to mediate a debate among two 
       software companies about how any angels you can fit in a DN:
       "Your software is broken, fix it!" <-> "Our DNs are more 
        standards-conformant than yours").


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7LcmQ29614 for ietf-pkix-bks; Thu, 7 Nov 2002 13:38:48 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA7Lckv29603 for <[e-mail]>; Thu, 7 Nov 2002 13:38:46 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id gA7LclDH021345; Thu, 7 Nov 2002 21:38:48 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021107132504.0299d280@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 07 Nov 2002 13:38:03 -0800
To: "Housley, Russ" <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: new version of draft on additional x509 certificate schema for LDAP
Cc: [e-mail]
In-Reply-To: <[e-mail] .com>
References: <5.1.0.14.0.20021107114155.02925c30@127.0.0.1> <96688570.1036629652@[192.168.0.4]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 01:23 PM 2002-11-07, Housley, Russ wrote:
>If we take your approach, with two different classes, we can impose the requirement that CAs have x509subject.

Yes, we could.

Another section 4.4 requirement which concerns me is:
  For the purpose of this specification, each entry with a 
  structural objectclass of x509certificate MUST have one
  and only one value of the userCertificate attribute or
  caCertificate attribute, respectively. 

This single-valued requirement should be enforced by schema
by defining one or two (depending on whether a user/ca
distinction is desired) new singled-valued x509 attribute
types of certificate syntax and having the objectclass(es)
require their presence.

That is, use schema rules to express requirements upon the
representation of the information.

Kurt

>( 1.1.1 NAME 'x509certificate' ABSTRACT
>  MUST ( x509serialNumber $ x509signatureAlgorithm
>    $ x509issuer $ x509validityNotBefore $ x509validityNotAfter
>    $ PublicKeyInfoAlgorithm )
>  MAY ( mail $ x509authorityKeyIdentifier $ x509authorityCertIssuer
>    $ x509authorityCertSerialNumber $ x509subjectKeyIdentifier
>    $ x509keyUsage $ x509policyInformationIdentifier
>    $ x509subjectAltNameRfc822Name $ x509subjectAltNameDnsName
>    $ x509subjectAltNameDirectoryName $ x509subjectAltNameURI
>    $ x509subjectAltNameIpAddress $ x509subjectAltNameRegisteredID
>    $ x509isssuerAltNameRfc822Name $ x509isssuerAltNameDnsName
>    $ x509isssuerAltNameDirectoryName $ x509isssuerAltNameURI
>    $ x509isssuerAltNameIpAddress $ x509isssuerAltNameRegisteredID
>    $ x509extKeyUsage $ x509cRLDistributionPoint
>    $ x509certificateHolder) )
>
>( 1.1.2 NAME 'x509userCertificate' SUP x509certificate
>    MUST userCertificate
>    MAY x509subject )
>
>( 1.1.3 NAME 'x509cACertificate' SUP x509certificate
>    MUST cACertificate $ x509subject )
>
>-- Russ
>
>At 11:55 AM 11/7/2002 -0800, Kurt D. Zeilenga wrote:
>
>>At 03:40 PM 2002-11-06, Norbert Klasen wrote:
>>>>I think that another MUST attribute is needed.  The certificate itself
>>>>MUST be stored as a binary blob.  We want to be able to get the
>>>>certificate from the repository in a manner that preserves the DER
>>>>encoding applied by the signer.
>>>
>>>Our intention was that the binary blob should be stored in a well known attribute ("userCertificate" or "caCertificate"). These are allowed in an x509certificate entry by including one of the auxiliary object classes "pkiUser" or "pkiCA":
>>>
>>>  Entries of this structural object class MUST also have one of the
>>>  following auxiliary object classes: "pkiUser" or "pkiCA".  This way,
>>>  the entry can contain the certificate in the "userCertificate" or
>>>  "cacertificate" attribute.
>>
>>But who is this MUST requirement placed upon?  Seems to be
>>more on the user than on either (or both) the client or server
>>implementation.
>>
>>I suggest you modify the schema so it requires a certificate
>>attribute to allows be present in the structural object class
>>of certificate objects.  Since we have two certificate attributes,
>>one possible approach is to have two structural classes, one
>>for user certificates and one for CA certificates, each
>>inheriting from a common abstract class.  That is,
>>
>>( 1.1.1 NAME 'x509certificate' ABSTRACT
>>  MUST ( x509serialNumber $ x509signatureAlgorithm
>>    $ x509issuer $ x509validityNotBefore $ x509validityNotAfter
>>    $ x509subject $ x509subjectPublicKeyInfoAlgorithm )
>>  MAY ( mail $ x509authorityKeyIdentifier $ x509authorityCertIssuer
>>    $ x509authorityCertSerialNumber $ x509subjectKeyIdentifier
>>    $ x509keyUsage $ x509policyInformationIdentifier
>>    $ x509subjectAltNameRfc822Name $ x509subjectAltNameDnsName
>>    $ x509subjectAltNameDirectoryName $ x509subjectAltNameURI
>>    $ x509subjectAltNameIpAddress $ x509subjectAltNameRegisteredID
>>    $ x509isssuerAltNameRfc822Name $ x509isssuerAltNameDnsName
>>    $ x509isssuerAltNameDirectoryName $ x509isssuerAltNameURI
>>    $ x509isssuerAltNameIpAddress $ x509isssuerAltNameRegisteredID
>>    $ x509extKeyUsage $ x509cRLDistributionPoint
>>    $ x509certificateHolder) )
>>
>>( 1.1.2 NAME 'x509userCertificate' SUP x509certificate
>>    MUST userCertificate )
>>
>>( 1.1.3 NAME 'x509cACertificate' SUP x509certificate
>>    MUST cACertificate )



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7LO6g27371 for ietf-pkix-bks; Thu, 7 Nov 2002 13:24:06 -0800 (PST)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA7LO4v27367 for <[e-mail]>; Thu, 7 Nov 2002 13:24:04 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 Nov 2002 21:24:07 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA11432 for <[e-mail]>; Thu, 7 Nov 2002 16:24:06 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id gA7LLOL21187 for <[e-mail]>; Thu, 7 Nov 2002 16:21:24 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWK6BT>; Thu, 7 Nov 2002 16:24:02 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.25]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWK6BR; Thu, 7 Nov 2002 16:24:00 -0500
From: "Housley, Russ" <[e-mail]>
To: "Kurt D. Zeilenga" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 07 Nov 2002 16:23:52 -0500
Subject: Re: new version of draft on additional x509 certificate schema for LDAP
In-Reply-To: <5.1.0.14.0.20021107114155.02925c30@127.0.0.1>
References: <96688570.1036629652@[192.168.0.4]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt:

If we take your approach, with two different classes, we can impose the 
requirement that CAs have x509subject.

( 1.1.1 NAME 'x509certificate' ABSTRACT
   MUST ( x509serialNumber $ x509signatureAlgorithm
     $ x509issuer $ x509validityNotBefore $ x509validityNotAfter
     $ PublicKeyInfoAlgorithm )
   MAY ( mail $ x509authorityKeyIdentifier $ x509authorityCertIssuer
     $ x509authorityCertSerialNumber $ x509subjectKeyIdentifier
     $ x509keyUsage $ x509policyInformationIdentifier
     $ x509subjectAltNameRfc822Name $ x509subjectAltNameDnsName
     $ x509subjectAltNameDirectoryName $ x509subjectAltNameURI
     $ x509subjectAltNameIpAddress $ x509subjectAltNameRegisteredID
     $ x509isssuerAltNameRfc822Name $ x509isssuerAltNameDnsName
     $ x509isssuerAltNameDirectoryName $ x509isssuerAltNameURI
     $ x509isssuerAltNameIpAddress $ x509isssuerAltNameRegisteredID
     $ x509extKeyUsage $ x509cRLDistributionPoint
     $ x509certificateHolder) )

( 1.1.2 NAME 'x509userCertificate' SUP x509certificate
     MUST userCertificate
     MAY x509subject )

( 1.1.3 NAME 'x509cACertificate' SUP x509certificate
     MUST cACertificate $ x509subject )

-- Russ

At 11:55 AM 11/7/2002 -0800, Kurt D. Zeilenga wrote:

>At 03:40 PM 2002-11-06, Norbert Klasen wrote:
> >>I think that another MUST attribute is needed.  The certificate itself
> >>MUST be stored as a binary blob.  We want to be able to get the
> >>certificate from the repository in a manner that preserves the DER
> >>encoding applied by the signer.
> >
> >Our intention was that the binary blob should be stored in a well known 
> attribute ("userCertificate" or "caCertificate"). These are allowed in an 
> x509certificate entry by including one of the auxiliary object classes 
> "pkiUser" or "pkiCA":
> >
> >  Entries of this structural object class MUST also have one of the
> >  following auxiliary object classes: "pkiUser" or "pkiCA".  This way,
> >  the entry can contain the certificate in the "userCertificate" or
> >  "cacertificate" attribute.
>
>But who is this MUST requirement placed upon?  Seems to be
>more on the user than on either (or both) the client or server
>implementation.
>
>I suggest you modify the schema so it requires a certificate
>attribute to allows be present in the structural object class
>of certificate objects.  Since we have two certificate attributes,
>one possible approach is to have two structural classes, one
>for user certificates and one for CA certificates, each
>inheriting from a common abstract class.  That is,
>
>( 1.1.1 NAME 'x509certificate' ABSTRACT
>   MUST ( x509serialNumber $ x509signatureAlgorithm
>     $ x509issuer $ x509validityNotBefore $ x509validityNotAfter
>     $ x509subject $ x509subjectPublicKeyInfoAlgorithm )
>   MAY ( mail $ x509authorityKeyIdentifier $ x509authorityCertIssuer
>     $ x509authorityCertSerialNumber $ x509subjectKeyIdentifier
>     $ x509keyUsage $ x509policyInformationIdentifier
>     $ x509subjectAltNameRfc822Name $ x509subjectAltNameDnsName
>     $ x509subjectAltNameDirectoryName $ x509subjectAltNameURI
>     $ x509subjectAltNameIpAddress $ x509subjectAltNameRegisteredID
>     $ x509isssuerAltNameRfc822Name $ x509isssuerAltNameDnsName
>     $ x509isssuerAltNameDirectoryName $ x509isssuerAltNameURI
>     $ x509isssuerAltNameIpAddress $ x509isssuerAltNameRegisteredID
>     $ x509extKeyUsage $ x509cRLDistributionPoint
>     $ x509certificateHolder) )
>
>( 1.1.2 NAME 'x509userCertificate' SUP x509certificate
>     MUST userCertificate )
>
>( 1.1.3 NAME 'x509cACertificate' SUP x509certificate
>     MUST cACertificate )


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7KKgw22453 for ietf-pkix-bks; Thu, 7 Nov 2002 12:20:42 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA7KEcv22109; Thu, 7 Nov 2002 12:14:38 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST)
Message-Id: <[e-mail]>
From: The IESG <[e-mail]>
To: All IETF Working Groups: ;
Subject: Note Well Statement
x-msg: NoteWell
Date: Thu, 07 Nov 2002 15:11:40 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>From time to time, especially just before a meeting, this statement is to
be sent to each and every IETF working group mailing list.
===========================================================================

				NOTE WELL

All statements related to the activities of the IETF and addressed to the
IETF are subject to all provisions of Section 10 of RFC 2026, which grants
to the IETF and its participants certain licenses and rights in such
statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which are
addressed to

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other function,
that are clearly not intended to be input to an IETF activity, group or
function, are not subject to these provisions.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7JuC321337 for ietf-pkix-bks; Thu, 7 Nov 2002 11:56:12 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA7JuAv21333 for <[e-mail]>; Thu, 7 Nov 2002 11:56:10 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id gA7Ju6DH020799; Thu, 7 Nov 2002 19:56:06 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021107114155.02925c30@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 07 Nov 2002 11:55:22 -0800
To: Norbert Klasen <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: new version of draft on additional x509 certificate schema for LDAP
Cc: [e-mail]
In-Reply-To: <96688570.1036629652@[192.168.0.4]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 03:40 PM 2002-11-06, Norbert Klasen wrote:
>>I think that another MUST attribute is needed.  The certificate itself
>>MUST be stored as a binary blob.  We want to be able to get the
>>certificate from the repository in a manner that preserves the DER
>>encoding applied by the signer.
>
>Our intention was that the binary blob should be stored in a well known attribute ("userCertificate" or "caCertificate"). These are allowed in an x509certificate entry by including one of the auxiliary object classes "pkiUser" or "pkiCA":
>
>  Entries of this structural object class MUST also have one of the
>  following auxiliary object classes: "pkiUser" or "pkiCA".  This way,
>  the entry can contain the certificate in the "userCertificate" or
>  "cacertificate" attribute.

But who is this MUST requirement placed upon?  Seems to be
more on the user than on either (or both) the client or server
implementation.

I suggest you modify the schema so it requires a certificate
attribute to allows be present in the structural object class
of certificate objects.  Since we have two certificate attributes,
one possible approach is to have two structural classes, one
for user certificates and one for CA certificates, each
inheriting from a common abstract class.  That is,

( 1.1.1 NAME 'x509certificate' ABSTRACT
  MUST ( x509serialNumber $ x509signatureAlgorithm
    $ x509issuer $ x509validityNotBefore $ x509validityNotAfter
    $ x509subject $ x509subjectPublicKeyInfoAlgorithm )
  MAY ( mail $ x509authorityKeyIdentifier $ x509authorityCertIssuer
    $ x509authorityCertSerialNumber $ x509subjectKeyIdentifier
    $ x509keyUsage $ x509policyInformationIdentifier
    $ x509subjectAltNameRfc822Name $ x509subjectAltNameDnsName
    $ x509subjectAltNameDirectoryName $ x509subjectAltNameURI
    $ x509subjectAltNameIpAddress $ x509subjectAltNameRegisteredID
    $ x509isssuerAltNameRfc822Name $ x509isssuerAltNameDnsName
    $ x509isssuerAltNameDirectoryName $ x509isssuerAltNameURI
    $ x509isssuerAltNameIpAddress $ x509isssuerAltNameRegisteredID
    $ x509extKeyUsage $ x509cRLDistributionPoint
    $ x509certificateHolder) )

( 1.1.2 NAME 'x509userCertificate' SUP x509certificate
    MUST userCertificate )

( 1.1.3 NAME 'x509cACertificate' SUP x509certificate
    MUST cACertificate )



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7JiWW20990 for ietf-pkix-bks; Thu, 7 Nov 2002 11:44:32 -0800 (PST)
Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA7JiUv20983 for <[e-mail]>; Thu, 7 Nov 2002 11:44:30 -0800 (PST)
Received: (qmail 19044 invoked from network); 7 Nov 2002 19:34:43 -0000
Received: from unknown (HELO multicert.com) (62.48.185.5) by mail0.sibs.pt with SMTP; 7 Nov 2002 19:34:42 -0000
Message-ID: <[e-mail]>
Date: Thu, 07 Nov 2002 19:41:45 +0000
From: Ricardo Barroso <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
References: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------080900030903090502000108"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------080900030903090502000108
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Peter Gutmann wrote:

>Denis Pinkas <[e-mail]> writes:
>
>  
>
>>Is it fine with Peter (S), Andrew, Peter (G) and Phil  ?
>>    
>>
>
>Well, one comment:
>
>  
>
>>   <AB>The statusString field of PKIStatusInfo MAY be used to include reason(s)
>>   text such as "messageImprint field is not correctly formatted".<BB>
>>    
>>
>
>Maybe this should be left as "reason text" - what do you do if there is > 1
>failure reason?  Pick the most important one?  Put a comma between them?  A
>linefeed?  Use the Windows-style \0 + \0\0?  It's better to imply there's a
>single string, and not do any more with it than that.
>
>Peter.
>
>  
>
Peter, maybe you're right that can turn a little confuse!
In my opinion even maintaining here the original RFC sentence, it 
doesn't restrict that you can't have
for example a comma between more than one reason - that's still a valid 
string/"reason text" I suppose.
Do you agree with that? Do you think that a system that does that will 
not be compliant?
I think the format of that string is not important (if it's still a 
valid ASN.1 PKIFreeText) since it's just
a "friendly message", it's the BIT STRING values that give to the 
time-stamping "system" the knowledge
of how to proceed or what error(s) need to be handled...

Best regards,
Ricardo Barroso

MULTICERT S.A.
www.multicert.com <http://www.multicert.com>

--------------080900030903090502000108
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
<br>
<br>
Peter Gutmann wrote:<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">Denis Pinkas <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a> writes:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Is it fine with Peter (S), Andrew, Peter (G) and Phil  ?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Well, one comment:

  </pre>
  <blockquote type="cite">
    <pre wrap="">   &lt;AB&gt;The statusString field of PKIStatusInfo MAY be used to include reason(s)
   text such as "messageImprint field is not correctly formatted".&lt;BB&gt;
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Maybe this should be left as "reason text" - what do you do if there is &gt; 1
failure reason?  Pick the most important one?  Put a comma between them?  A
linefeed?  Use the Windows-style \0 + \0\0?  It's better to imply there's a
single string, and not do any more with it than that.

Peter.

  </pre>
</blockquote>
Peter, maybe you're right that can turn a little confuse!<br>
In my opinion even maintaining here the original RFC sentence, it doesn't
restrict that you can't have <br>
for example a comma between more than one reason - that's still a valid string/"reason
text" I suppose. <br>
Do you agree with that? Do you think that a system that does that will not
be compliant? <br>
I think the format of that string is not important (if it's still a valid
ASN.1 PKIFreeText) since it's just <br>
a "friendly message", it's the BIT STRING values that give to the time-stamping
"system" the knowledge <br>
of how to proceed or what error(s) need to be handled...<br>
<br>
Best regards,<br>
Ricardo Barroso<br>
<br>
MULTICERT S.A.<br>
<a href="http://www.multicert.com">www.multicert.com</a><br>
</body>
</html>

--------------080900030903090502000108--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7JeKg20908 for ietf-pkix-bks; Thu, 7 Nov 2002 11:40:20 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA7JeIv20904 for <[e-mail]>; Thu, 7 Nov 2002 11:40:18 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id gA7JeKDH020704 for <[e-mail]>; Thu, 7 Nov 2002 19:40:20 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20021107113551.02934930@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 07 Nov 2002 11:39:36 -0800
To: [e-mail]
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: RE: new version of draft on additional x509 certificate schema for LDAP
In-Reply-To: <[e-mail] .com>
References: <009601c28621$b9bd0310$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>> In LDAP you don't have a difference between empty value and
>>> non existant value.

Please note, in LDAP and X.500, there is a difference between
an attribute having an "empty" value and an attribute not being
present (has no values).  It's just that certain syntaxes
(e.g., Directory String syntax) don't allow "empty" values.
Many others (e.g. Octet String) do.

Kurt



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7GDYR07261 for ietf-pkix-bks; Thu, 7 Nov 2002 08:13:34 -0800 (PST)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA7GDVv07254 for <[e-mail]>; Thu, 7 Nov 2002 08:13:31 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 Nov 2002 16:13:33 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA06439; Thu, 7 Nov 2002 11:12:39 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id gA7G9ud10522; Thu, 7 Nov 2002 11:09:56 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWK414>; Thu, 7 Nov 2002 11:12:36 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.29]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWK41N; Thu, 7 Nov 2002 11:12:28 -0500
From: "Housley, Russ" <[e-mail]>
To: Norbert Klasen <[e-mail]>
Cc: Peter Gietz <[e-mail]>, [e-mail], David Chadwick <[e-mail]>, Steven Legg <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 07 Nov 2002 11:12:14 -0500
Subject: Re: new version of draft on additional x509 certificate schema for LDAP
In-Reply-To: <96688570.1036629652@[192.168.0.4]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Norbert:

>>I think that another MUST attribute is needed.  The certificate itself
>>MUST be stored as a binary blob.  We want to be able to get the
>>certificate from the repository in a manner that preserves the DER
>>encoding applied by the signer.
>
>Our intention was that the binary blob should be stored in a well known 
>attribute ("userCertificate" or "caCertificate"). These are allowed in an 
>x509certificate entry by including one of the auxiliary object classes 
>"pkiUser" or "pkiCA":
>
>   Entries of this structural object class MUST also have one of the
>   following auxiliary object classes: "pkiUser" or "pkiCA".  This way,
>   the entry can contain the certificate in the "userCertificate" or
>   "cacertificate" attribute.

Okay.  I missed this MUST statement.

Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7G8nr07061 for ietf-pkix-bks; Thu, 7 Nov 2002 08:08:49 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA7G8lv07057 for <[e-mail]>; Thu, 7 Nov 2002 08:08:48 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gA7G887n013799; Fri, 8 Nov 2002 05:08:08 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id FAA97026; Fri, 8 Nov 2002 05:08:06 +1300 (NZDT) (sender [e-mail])
Date: Fri, 8 Nov 2002 05:08:06 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas <[e-mail]> writes:

>Is it fine with Peter (S), Andrew, Peter (G) and Phil  ?

Well, one comment:

>    <AB>The statusString field of PKIStatusInfo MAY be used to include reason(s)
>    text such as "messageImprint field is not correctly formatted".<BB>

Maybe this should be left as "reason text" - what do you do if there is > 1
failure reason?  Pick the most important one?  Put a comma between them?  A
linefeed?  Use the Windows-style \0 + \0\0?  It's better to imply there's a
single string, and not do any more with it than that.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7FmIo05490 for ietf-pkix-bks; Thu, 7 Nov 2002 07:48:18 -0800 (PST)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA7FmGv05483 for <[e-mail]>; Thu, 7 Nov 2002 07:48:16 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 Nov 2002 15:48:18 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA03097; Thu, 7 Nov 2002 10:48:17 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id gA7FjZe06532; Thu, 7 Nov 2002 10:45:36 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWKT3M>; Thu, 7 Nov 2002 10:48:15 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.29]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWKT32; Thu, 7 Nov 2002 10:48:11 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 07 Nov 2002 10:31:53 -0500
Subject: RE: new version of draft on additional x509 certificate schema for LDAP
In-Reply-To: <009601c28621$b9bd0310$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steven:

> > In LDAP you don't have a difference between empty value and
> > non existant value.
>
>For the most part LDAP & X.500 attribute syntaxes don't allow
>empty values. Some do, and in these cases the difference between
>an empty value and an absent value is recognized and significant
>in LDAP & X.500.

This is the reason that x509subject should be MAY contain.

Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7FaO103920 for ietf-pkix-bks; Thu, 7 Nov 2002 07:36:24 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA7FaMv03912 for <[e-mail]>; Thu, 7 Nov 2002 07:36:22 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA15890; Thu, 7 Nov 2002 16:36:57 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id QAA24164; Thu, 7 Nov 2002 16:36:33 +0100
Message-ID: <[e-mail]>
Date: Thu, 07 Nov 2002 16:36:04 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Ricardo Barroso <[e-mail]>
CC: [e-mail]
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gA7FaNv03915
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ricardo,

Thank you for the proposal.

Is it fine with Peter (S), Andrew, Peter (G) and Phil  ?
Any proposal from any one else ?

Denis

> In my opion in RFC 3161/draft-ietf-pkix-rfc3161bis-00, section 2.4.2.:
> 
>    «When the TimeStampToken is not present, the failInfo indicates the
>    reason why the time-stamp request was rejected and may be one of the
>    following values.»
> 
> should be replace by something like this:
> 
>    «When the TimeStampToken is not present, the failInfo indicates one
>    or more reasons why the time-stamp request was rejected and may be
>    one or more of the following values.»
> 
> and:
> 
>    «The statusString field of PKIStatusInfo MAY be used to include reason
>    text such as "messageImprint field is not correctly formatted".»
> 
> should also be replaced by something like this:
> 
>    «The statusString field of PKIStatusInfo MAY be used to include reason(s)
>    text such as "messageImprint field is not correctly formatted".»
> 
> I have no experience in writing RFCs and I don't know if my English is 
> the best suited for this
> cases but it's my proposal.
> 
> Denis, I don't know if I got it right, when you say "is not crystal 
> clear when bits are described"
> do you mean that should be written something more about the bits inside 
> the PKIFailureInfo
> BIT STRING?
> 
> Best regards,
> Ricardo Barroso
> 
> MULTICERT S.A.
> www.multicert.com <http://www.multicert.com>
> 
> 
> Denis Pinkas wrote:
> 
>>
>> Since, you seem to all agree in principle, can some of you propose a 
>> full text remplacement, providing the old and new sentence ?
>>
>> "Only the following values MAY occur" is not crystal clear when bits 
>> are described.
>>
>> Denis
>>
>> PS. Remember that I am still awaiting an interoperability test so that 
>> we can progress the document on the Standards Track.
>>
>>
>>> Peter Sylvester wrote:
>>>
>>>>> Because with RFC 3161 it's possible that exist two compliant systems
>>>>> which can't interoperate properly in some situations because one 
>>>>> accepts that
>>>>> PKIFailueInfo contains more than one bit with value one (1) and the 
>>>>> other not!
>>>>>   
>>>>
>>>>
>>>>
>>>> It seems that the text could say 'MAY only be any of the following 
>>>> values'.
>>>> as the list is a restriction (and extension) of the values define in 
>>>> CMP.
>>>>
>>>> Or: 'Only the following values MAY occur'.
>>>>
>>>> I could detect an invalid hash algorithm and an unsupported extension,
>>>> an unacceptable policy, and even time source not available all 
>>>> together.
>>>
>>>
>>> Peter, I agree with you.
>>>
>>> Ricardo Barroso
>>>
>>>
>>>
>>
>>
>>
>>
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7EwvB01905 for ietf-pkix-bks; Thu, 7 Nov 2002 06:58:57 -0800 (PST)
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA7Ewtv01901 for <[e-mail]>; Thu, 7 Nov 2002 06:58:55 -0800 (PST)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 189o7B-0004Pc-00; Thu, 07 Nov 2002 09:58:37 -0500
Message-ID: <[e-mail]>
Date: Thu, 07 Nov 2002 09:58:21 -0500
From: "Phillip H. Griffin" <[e-mail]>
Organization: http://asn-1.com
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ricardo Barroso <[e-mail]>
CC: Denis Pinkas <[e-mail]>, [e-mail]
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/alternative; boundary="------------050401070409060905060609"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------050401070409060905060609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

It seems to me that you have a notation readily at hand that allows
you to assign names to any bit pattern you choose. For example,

   ErrorCodes ::= BIT STRING

   iMeanAllOfTheBits ErrorCodes ::= '1111111111111'B

Once you've assigned useful names to acceptable bit patterns, you gain
the advantage of being able to refer to them in English prose, such as
stating "when the value of type ErrorCodes is iManAllOfTheBits, the
receiving application should blah blah blah".

Phil


Ricardo Barroso wrote:

> In my opion in RFC 3161/draft-ietf-pkix-rfc3161bis-00, section 2.4.2.:
>
>    «When the TimeStampToken is not present, the failInfo indicates the
>    reason why the time-stamp request was rejected and may be one of the
>    following values.»
>
> should be replace by something like this:
>
>    «When the TimeStampToken is not present, the failInfo indicates one
>    or more reasons why the time-stamp request was rejected and may be
>    one or more of the following values.»
>
> and:
>
>    «The statusString field of PKIStatusInfo MAY be used to include reason
>    text such as "messageImprint field is not correctly formatted".»
>
> should also be replaced by something like this:
>
>    «The statusString field of PKIStatusInfo MAY be used to include 
> reason(s)
>    text such as "messageImprint field is not correctly formatted".»
>
> I have no experience in writing RFCs and I don't know if my English is 
> the best suited for this
> cases but it's my proposal.
>
> Denis, I don't know if I got it right, when you say "is not crystal 
> clear when bits are described"
> do you mean that should be written something more about the bits 
> inside the PKIFailureInfo
> BIT STRING?
>
> Best regards,
> Ricardo Barroso
>
> MULTICERT S.A.
> www.multicert.com <http://www.multicert.com>
>
>
> Denis Pinkas wrote:
>
>>
>> Since, you seem to all agree in principle, can some of you propose a 
>> full text remplacement, providing the old and new sentence ?
>>
>> "Only the following values MAY occur" is not crystal clear when bits 
>> are described.
>>
>> Denis
>>
>> PS. Remember that I am still awaiting an interoperability test so 
>> that we can progress the document on the Standards Track.
>>
>>
>>> Peter Sylvester wrote:
>>>
>>>>> Because with RFC 3161 it's possible that exist two compliant systems
>>>>> which can't interoperate properly in some situations because one 
>>>>> accepts that
>>>>> PKIFailueInfo contains more than one bit with value one (1) and 
>>>>> the other not!
>>>>>   
>>>>
>>>>
>>>>
>>>> It seems that the text could say 'MAY only be any of the following 
>>>> values'.
>>>> as the list is a restriction (and extension) of the values define 
>>>> in CMP.
>>>>
>>>> Or: 'Only the following values MAY occur'.
>>>>
>>>> I could detect an invalid hash algorithm and an unsupported extension,
>>>> an unacceptable policy, and even time source not available all 
>>>> together.
>>>
>>>
>>> Peter, I agree with you.
>>>
>>> Ricardo Barroso
>>>
>>>
>>>
>>
>>
>>
>>
>


--------------050401070409060905060609
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
It seems to me that you have a notation readily at hand that allows <br>
you to assign names to any bit pattern you choose. For example,<br>
<br>
&nbsp; &nbsp;ErrorCodes ::= BIT STRING<br>
<br>
&nbsp; &nbsp;iMeanAllOfTheBits&nbsp;ErrorCodes ::= '1111111111111'B<br>
<br>
Once you've assigned useful names to acceptable bit patterns, you gain<br>
the advantage of being able to refer to them in English prose, such as <br>
stating "when the value of type ErrorCodes is iManAllOfTheBits, the <br>
receiving application should blah blah blah".<br>
<br>
Phil<br>
<br>
<br>
Ricardo Barroso wrote:<br>
<blockquote type="cite" cite="[e-mail]">
  <title></title>
       In my opion in RFC 3161/draft-ietf-pkix-rfc3161bis-00, section 2.4.2.:<br>
 <br>
 &nbsp;&nbsp; &laquo;<tt>When the TimeStampToken is not present, the failInfo indicates the<br>
 &nbsp;&nbsp; reason why the time-stamp request was rejected and may be one of the<br>
 &nbsp;&nbsp; following values.</tt>&raquo;<br>
 <br>
 should be replace by something like this:<br>
 <br>
 &nbsp;&nbsp; &laquo;<tt>When the TimeStampToken is not present, the failInfo indicates one 
  <br>
 &nbsp;&nbsp; or more reasons why the time-stamp request was rejected and may be <br>
 &nbsp;&nbsp; one or more of the following values.</tt>&raquo;<br>
 <br>
 and:<br>
 <br>
 &nbsp;&nbsp; &laquo;<tt>The statusString field of PKIStatusInfo MAY be used to include reason<br>
 &nbsp;&nbsp; text such as "messageImprint field is not correctly formatted".</tt>&raquo;<br>
 <br>
 should also be replaced by something like this:<br>
 <br>
 &nbsp;&nbsp; &laquo;<tt>The statusString field of PKIStatusInfo MAY be used to include reason(s)<br>
 &nbsp;&nbsp; text such as "messageImprint field is not correctly formatted".</tt>&raquo;<br>
 <br>
 I have no experience in writing RFCs and I don't know if my English is the 
best suited for this <br>
 cases but it's my proposal.<br>
 <br>
 Denis, I don't know if I got it right, when you say "is not crystal clear 
when bits are  described" <br>
 do you mean that should be written something more about the bits inside
the PKIFailureInfo <br>
 BIT STRING?<br>
 <br>
 Best regards,<br>
 Ricardo Barroso<br>
 <br>
 MULTICERT S.A.<br>
 <a href="http://www.multicert.com">www.multicert.com</a><br>
 <br>
 <br>
 Denis Pinkas wrote:<br>
 
  <blockquote type="cite" cite="[e-mail]"> <br>
 Since, you seem to all agree in principle, can some of you propose a full 
 text remplacement, providing the old and new sentence ? <br>
  <br>
 "Only the following values MAY occur" is not crystal clear when bits are 
 described. <br>
  <br>
 Denis <br>
  <br>
 PS. Remember that I am still awaiting an interoperability test so that we 
 can progress the document on the Standards Track. <br>
  <br>
  <br>
   
    <blockquote type="cite">Peter Sylvester wrote: <br>
  <br>
     
      <blockquote type="cite">       
        <blockquote type="cite">Because with RFC 3161 it's possible that
exist two compliant systems <br>
 which can't interoperate properly in some situations because one  accepts 
that <br>
 PKIFailueInfo contains more than one bit with value one (1) and the  other 
not! <br>
 &nbsp;  </blockquote>
  <br>
  <br>
 It seems that the text could say 'MAY only be any of the following  values'.
       <br>
 as the list is a restriction (and extension) of the values define in CMP.
       <br>
  <br>
 Or: 'Only the following values MAY occur'. <br>
  <br>
 I could detect an invalid hash algorithm and an unsupported extension, <br>
 an unacceptable policy, and even time source not available all together.
        <br>
     </blockquote>
  <br>
 Peter, I agree with you. <br>
  <br>
 Ricardo Barroso <br>
  <br>
  <br>
  <br>
   </blockquote>
  <br>
  <br>
  <br>
  <br>
 </blockquote>
 <br>
 </blockquote>
<br>
</body>
</html>

--------------050401070409060905060609--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7DLLa21654 for ietf-pkix-bks; Thu, 7 Nov 2002 05:21:21 -0800 (PST)
Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA7DLHv21643 for <[e-mail]>; Thu, 7 Nov 2002 05:21:17 -0800 (PST)
Received: (qmail 4623 invoked from network); 7 Nov 2002 13:11:40 -0000
Received: from unknown (HELO multicert.com) (62.48.185.5) by mail0.sibs.pt with SMTP; 7 Nov 2002 13:11:40 -0000
Message-ID: <[e-mail]>
Date: Thu, 07 Nov 2002 13:18:53 +0000
From: Ricardo Barroso <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>, [e-mail]
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/alternative; boundary="------------000501070104050707040701"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------000501070104050707040701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

In my opion in RFC 3161/draft-ietf-pkix-rfc3161bis-00, section 2.4.2.:

   «When the TimeStampToken is not present, the failInfo indicates the
   reason why the time-stamp request was rejected and may be one of the
   following values.»

should be replace by something like this:

   «When the TimeStampToken is not present, the failInfo indicates one
   or more reasons why the time-stamp request was rejected and may be
   one or more of the following values.»

and:

   «The statusString field of PKIStatusInfo MAY be used to include reason
   text such as "messageImprint field is not correctly formatted".»

should also be replaced by something like this:

   «The statusString field of PKIStatusInfo MAY be used to include reason(s)
   text such as "messageImprint field is not correctly formatted".»

I have no experience in writing RFCs and I don't know if my English is 
the best suited for this
cases but it's my proposal.

Denis, I don't know if I got it right, when you say "is not crystal 
clear when bits are described"
do you mean that should be written something more about the bits inside 
the PKIFailureInfo
BIT STRING?

Best regards,
Ricardo Barroso

MULTICERT S.A.
www.multicert.com <http://www.multicert.com>


Denis Pinkas wrote:

>
> Since, you seem to all agree in principle, can some of you propose a 
> full text remplacement, providing the old and new sentence ?
>
> "Only the following values MAY occur" is not crystal clear when bits 
> are described.
>
> Denis
>
> PS. Remember that I am still awaiting an interoperability test so that 
> we can progress the document on the Standards Track.
>
>
>> Peter Sylvester wrote:
>>
>>>> Because with RFC 3161 it's possible that exist two compliant systems
>>>> which can't interoperate properly in some situations because one 
>>>> accepts that
>>>> PKIFailueInfo contains more than one bit with value one (1) and the 
>>>> other not!
>>>>   
>>>
>>>
>>>
>>> It seems that the text could say 'MAY only be any of the following 
>>> values'.
>>> as the list is a restriction (and extension) of the values define in 
>>> CMP.
>>>
>>> Or: 'Only the following values MAY occur'.
>>>
>>> I could detect an invalid hash algorithm and an unsupported extension,
>>> an unacceptable policy, and even time source not available all 
>>> together.
>>
>>
>> Peter, I agree with you.
>>
>> Ricardo Barroso
>>
>>
>>
>
>
>
>


--------------000501070104050707040701
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
In my opion in RFC 3161/draft-ietf-pkix-rfc3161bis-00, section 2.4.2.:<br>
<br>
&nbsp;&nbsp; &laquo;<tt>When the TimeStampToken is not present, the failInfo indicates the<br>
&nbsp;&nbsp; reason why the time-stamp request was rejected and may be one of the<br>
&nbsp;&nbsp; following values.</tt>&raquo;<br>
<br>
should be replace by something like this:<br>
<br>
&nbsp;&nbsp; &laquo;<tt>When the TimeStampToken is not present, the failInfo indicates one
<br>
&nbsp;&nbsp; or more reasons why the time-stamp request was rejected and may be <br>
&nbsp;&nbsp; one or more of the following values.</tt>&raquo;<br>
<br>
and:<br>
<br>
&nbsp;&nbsp; &laquo;<tt>The statusString field of PKIStatusInfo MAY be used to include reason<br>
&nbsp;&nbsp; text such as "messageImprint field is not correctly formatted".</tt>&raquo;<br>
<br>
should also be replaced by something like this:<br>
<br>
&nbsp;&nbsp; &laquo;<tt>The statusString field of PKIStatusInfo MAY be used to include reason(s)<br>
&nbsp;&nbsp; text such as "messageImprint field is not correctly formatted".</tt>&raquo;<br>
<br>
I have no experience in writing RFCs and I don't know if my English is the
best suited for this <br>
cases but it's my proposal.<br>
<br>
Denis, I don't know if I got it right, when you say "is not crystal clear
when bits are  described" <br>
do you mean that should be written something more about the bits inside the
PKIFailureInfo <br>
BIT STRING?<br>
<br>
Best regards,<br>
Ricardo Barroso<br>
<br>
MULTICERT S.A.<br>
<a href="http://www.multicert.com">www.multicert.com</a><br>
<br>
<br>
Denis Pinkas wrote:<br>
<blockquote type="cite" cite="[e-mail]"> <br>
Since, you seem to all agree in principle, can some of you propose a full
 text remplacement, providing the old and new sentence ? <br>
 <br>
"Only the following values MAY occur" is not crystal clear when bits are
 described. <br>
 <br>
Denis <br>
 <br>
PS. Remember that I am still awaiting an interoperability test so that we
 can progress the document on the Standards Track. <br>
 <br>
 <br>
  <blockquote type="cite">Peter Sylvester wrote: <br>
 <br>
    <blockquote type="cite">
      <blockquote type="cite">Because with RFC 3161 it's possible that exist
two compliant systems <br>
which can't interoperate properly in some situations because one  accepts
that <br>
PKIFailueInfo contains more than one bit with value one (1) and the  other
not! <br>
&nbsp;  </blockquote>
 <br>
 <br>
It seems that the text could say 'MAY only be any of the following  values'. 
      <br>
as the list is a restriction (and extension) of the values define in CMP. 
      <br>
 <br>
Or: 'Only the following values MAY occur'. <br>
 <br>
I could detect an invalid hash algorithm and an unsupported extension, <br>
an unacceptable policy, and even time source not available all together. <br>
    </blockquote>
 <br>
Peter, I agree with you. <br>
 <br>
Ricardo Barroso <br>
 <br>
 <br>
 <br>
  </blockquote>
 <br>
 <br>
 <br>
 <br>
</blockquote>
<br>
</body>
</html>

--------------000501070104050707040701--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7BTsJ13908 for ietf-pkix-bks; Thu, 7 Nov 2002 03:29:54 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA7BTrv13902 for <[e-mail]>; Thu, 7 Nov 2002 03:29:53 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11273; Thu, 7 Nov 2002 06:27:23 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-scvp-10.txt
Date: Thu, 07 Nov 2002 06:27:23 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-scvp-10.txt
	Pages		: 32
	Date		: 2002-11-6
	
The SCVP protocol allows a client to offload certificate handling to a
server. The server can give a variety of valuable information about
the certificate, such as whether or not the certificate is valid, a
certification path to a trust anchor, and so on. SCVP has many
purposes, including simplifying client implementations and allowing
companies to centralize their trust and policy management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-10.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-scvp-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-scvp-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-10.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-scvp-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7BISq13417 for ietf-pkix-bks; Thu, 7 Nov 2002 03:18:28 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA7BIQv13408 for <[e-mail]>; Thu, 7 Nov 2002 03:18:27 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA31088; Thu, 7 Nov 2002 12:19:01 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id MAA16618; Thu, 7 Nov 2002 12:18:38 +0100
Message-ID: <[e-mail]>
Date: Thu, 07 Nov 2002 12:17:11 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-cvp-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

Thank you for your interest in CVP.

>>I have issued a new version of CVP "Certificate Validation Protocol".
> 
> To some degree the critique that you made about functionality
> implemented by extensions may also apply to your text.
> 
> It is not quite clear to me why just for relaying and referal you
> use an extension mechanism and for example you have
> a direct option serverContextInfo which is not an extension.
> it seems that you are distinguishing optional service
> features from optional parameters in this way. 

The answer is quite simple.

Everything which is in the core protocol (i.e. what MUST be supported either 
for DPD or DPV) is not designed using extensions.

We specify here the client-to-server protocol. Extensions are being used for 
the server-to-server protocol, which is clearly an option.

serverContextInfo is necessary for DPD and thus MUST be supported by a DPD 
server since there may more than one path that satisfies the (path) 
discovery policy.

> "Using "Dump ASN.1" would allow to easily debug CVP, but not SCVP."
> Since you also use Extensions, this is true for your version, too.

Only the server to server protocol (which is an option that you requested 
and which is not present in SCVP) will be more difficult to look at.

> Not encapsulating data into an octet string but defining them
> as ANY DEFINED BY (to use an outdated asn1 term), is a mechanism that
> correct ASN1 implementations can handle. 

> You don't specify explicitely what to put into the ESScertid of a 
> relaying extension. 

ESSCertID is defined in RFC 2634 as:

    ESSCertID ::=  SEQUENCE {
         certHash                 Hash,
         issuerSerial             IssuerSerial OPTIONAL
    }

The OPTIONAL field is not necessary, but if it is there, it will not hurt, 
so why no further explanations have been given.

 > 'RelayInfo unambigously allows to identify the server'
> mean what? the requesting or the receivin gserver? Well, it may 
> be deduced from the loop detection procedure.

The text that is present provide many explanations, which seem to be sufficient:

"When a CVP server wishes to relay a request towards another CVP server
using this protocol, then, for each single request, it SHALL support
the relaying extension.

If a relaying extension was present in the request, then an additional
RelayInfo SHALL be added to the content of the Relaying extension and
included in the next request.

If a Relaying extension was not present in the request, then a Relaying
extension field shall be created and included in the next request."

If you still find the wording not clear enough, please provide an 
alternative proposal.

> What identifier should be set for servers that do not sign their
> responses?

Good question. Well, if they have a certificate, then they can still use 
ESSCertID. Maybe your next question will be: "... and if they don't ?"

I let you make a proposal.

Denis





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7BIRs13413 for ietf-pkix-bks; Thu, 7 Nov 2002 03:18:27 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA7BIQv13407 for <[e-mail]>; Thu, 7 Nov 2002 03:18:26 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA31086; Thu, 7 Nov 2002 12:19:00 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id MAA16616; Thu, 7 Nov 2002 12:18:35 +0100
Message-ID: <[e-mail]>
Date: Thu, 07 Nov 2002 11:19:21 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-ocspv2-ext-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

> Uhh, where on earth did this one come from?  The previous consensus on the
> list seemed to be do produce a minimal update with some more workable IDs and
> CRLDP info as suggested by Denis:
> 
> 
>>To be more precise, I do not care about the expired OCSP v2 draft, but I
>>care about fixing RFC 2560, while sticking to its original functionality:
>>individual certificate revocation information status check.
>>
>>Having said that, we should correct the major problem that exists in
>>RFC 2560, which is how the certificate can be defined.
>>
>>[...]
>>
>>I agree that, for defining an extension for handling a CRLDP extension
> 

> This thing is neither compatible with the previous OCSPv2, nor with what was
> discussed on the list... this is more like 2560bis-bis.  It seems to be
> contrary to everything that was discussed on the list.  

In the new draft :

- an extension for handling a CRLDP extension has been defined,
- in addition to the current way to define a certificate,
   two new ways have been defined.

This is fully aligned with the discussion on the list.

The only point is the extension to cover Attribute Certificates,
which is rather straightforward.

Anticipating one comment from you, the editors have already agree to change 
IssuerSerial by IssuerandSerialNumber in the next version.

If you have additional detailed comments on the draft, please post them.

Denis

> I already have an
> OCSPv2 draft done based on the previous discussion on the list, I was just
> waiting a bit longer to make sure none of the original v2 authors would feel
> slighted when I posted the new, minimal update to v1.

> Peter.






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA7BIOJ13404 for ietf-pkix-bks; Thu, 7 Nov 2002 03:18:24 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA7BIMv13400 for <[e-mail]>; Thu, 7 Nov 2002 03:18:22 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA14838 for <[e-mail]>; Thu, 7 Nov 2002 12:18:57 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id MAA18360 for <[e-mail]>; Thu, 7 Nov 2002 12:18:34 +0100
Message-ID: <[e-mail]>
Date: Thu, 07 Nov 2002 11:11:47 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Since, you seem to all agree in principle, can some of you propose a full 
text remplacement, providing the old and new sentence ?

"Only the following values MAY occur" is not crystal clear when bits are 
described.

Denis

PS. Remember that I am still awaiting an interoperability test so that we 
can progress the document on the Standards Track.


> Peter Sylvester wrote:
> 
>>> Because with RFC 3161 it's possible that exist two compliant systems
>>> which can't interoperate properly in some situations because one 
>>> accepts that
>>> PKIFailueInfo contains more than one bit with value one (1) and the 
>>> other not!
>>>   
>>
>>
>> It seems that the text could say 'MAY only be any of the following 
>> values'.
>> as the list is a restriction (and extension) of the values define in CMP.
>>
>> Or: 'Only the following values MAY occur'.
>>
>> I could detect an invalid hash algorithm and an unsupported extension,
>> an unacceptable policy, and even time source not available all together.
> 
> Peter, I agree with you.
> 
> Ricardo Barroso
> 
> 
> 





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA79l0r04333 for ietf-pkix-bks; Thu, 7 Nov 2002 01:47:00 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA79kwv04328 for <[e-mail]>; Thu, 7 Nov 2002 01:46:58 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA29164; Thu, 7 Nov 2002 10:47:31 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id KAA18548; Thu, 7 Nov 2002 10:47:03 +0100
Message-ID: <[e-mail]>
Date: Thu, 07 Nov 2002 09:43:48 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Trevor Freeman <[e-mail]>, "Housley, Russ" <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Denis,
> 
> We are ready to make a change to accommodate multiple community logos (thus
> keeping issuer and subject organization logos limited to 1 each).
> 
> The condition for this would be:
> 
> If multiple community logos are defined in a certificate, and if the client
> is designed to display just 1 community logo (or less than the number of
> logos included in the certificate), it will use the first logo in the
> sequence as the most preferred one and the last logo in the sequence as the
> least preferred one to be displayed.
> 
> It is though too late to issue a new ID before Atlanta.
> 
> Would this satisfy your needs?

Certainly. Thank you.

Denis

> /Stefan
> 
> 
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]]On Behalf Of Denis Pinkas
>>Sent: Monday, November 04, 2002 4:30 PM
>>To: Trevor Freeman
>>Cc: Housley, Russ; [e-mail]; Stefan Santesson
>>Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
>>
>>
>>
>>Trevor and Stefan,
>>
>>
>>>Denis,
>>
>>>There is a way to accomplish associating multiple community logos within
>>>the existing draft. We permit the use of the logotype extension within
>>>attribute certificates as well as identity certificates. It is therefore
>>>possible to have an identity certificate, issued by Last National Bank
>>>to merchant foo with a community of Visa, and an attribute certificate,
>>>issued by Utah Credit Union to merchant foo with a community logo of
>>>MasterCard. In this situation, the UI can legitimacy display a community
>>>logotype for each valid certificate.
>>
>>This does not solve the issue: there is still one single
>>community logo type
>>in a given certificate (whether it is a PKC or an AC).
>>
>>The real issue is what do we call a "community".
>>
>>Extracts from the present draft:
>>
>>"The community may represent the subscribers of a service or any
>>other group."
>>
>>"The community logotype - is the general mark for a community. It
>>identifies
>>a service concept for entity identification and certificate issuance."
>>
>>Well, the less that we can say is that this is not crystal clear !!! :-(
>>
>>Within that definition both the logo CB and the logo VISA have
>>their places.
>>
>>CB is a logo used by some banks grouped under the GIE "Cartes
>>Bancaire" and
>>recognized by many French merchants.
>>
>>VISA is a logo used by VISA and recognized by many merchants worldwide.
>>Both could be in a certificate.
>>
>>Extract from : http://www.cartes-bancaires.com/GB/Pages/FrameVie.htm
>>
>>A card bearing a "CB" logo is by definition an interbank card.
>>One feature
>>of the "CB" interbank system is that the card will be accepted
>>even if the
>>issuing bank is different from the merchant's bank or the bank
>>managing the
>>ATM.
>>
>>(...)
>>
>>In addition to the "CB" logo, "CB" cards can also have an international
>>acceptance logo (Visa or MasterCard).
>>
>>Denis
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>Trevor
>>>-----Original Message-----
>>>From: Stefan Santesson [mailto:[e-mail]]
>>>Sent: Thursday, October 31, 2002 6:06 AM
>>>To: Denis Pinkas
>>>Cc: Housley, Russ; [e-mail]
>>>Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
>>>
>>>
>>>Denis,
>>>
>>>I think you are mixing concepts and to some extent misreading the
>>>standard.
>>>
>>>I comment below;
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [e-mail]
>>>>[mailto:[e-mail]]On Behalf Of Denis Pinkas
>>>>Sent: Wednesday, October 30, 2002 2:47 PM
>>>>To: Stefan Santesson
>>>>Cc: Housley, Russ; [e-mail]
>>>>Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
>>>>
>>>>
>>>>
>>>
>>>
>>>stuff deleted...
>>>
>>>
>>>
>>>>>1) We expand the concept beyond the intended scope
>>>>>2) We make it harder and more complex for the GUI implementers
>>>>
>>>>to make a
>>>>
>>>>>distinct application.
>>>>
>>>>What is the "intended scope" ? Until it is clearly defined, you cannot
>>>
>>>say
>>>
>>>
>>>>that this is contradictory. So there is no demonstration here.
>>>
>>>
>>>Intentions and scopes are included in sections 1 and 2. The scope is
>>>clearly
>>>to allow issuers to claim that they issue a certificate as part of a
>>>community. The value of having just 1 community is that it brings
>>>clarity to
>>>the concept. There are numerous of examples in real life of this
>>>situation:
>>>
>>>1) Gasoline stations. They may be independent enterprises but they are
>>>sometimes members of A community (Shell, Esso etc)
>>>2) Shops.. same thing.
>>>3) Credit cards
>>>4) Airlines
>>>....
>>>....
>>>
>>>The common ground is that there is a point of issuing a service under
>>>JUST 1
>>>community. One big reason is that there generally is some kind of common
>>>explicit or implicit liability or protection of brand involved. If one
>>>service would be Both VISA AND MasterCard at the same time, or both
>>>SHELL
>>>AND ESSO or.... who would protect the brands, who would take
>>>responsibility
>>>for that ....
>>>
>>>To my knowledge that type of situation does not exist.
>>>
>>>All examples you state are not examples of multiple communities but
>>>examples
>>>of other aspects of reality.
>>>
>>>So a good thing with having just 1 community logotype proved by you
>>>here.
>>>That is that people can't abuse the standard and put any obscure
>>>logotype as
>>>1 of 10 community logos, making the GUI makers insane :-)
>>>
>>>
>>>
>>>>What is harder ? Display is always an option. We do not mandate
>>>>what MUST be
>>>>displayed.
>>>
>>>
>>>For a GUI of this kind, especially if we want to create a visual
>>>equivalent
>>>of an ID-card on the screen (in a standard format), it helps
>>>implementers to
>>>know if they will handle 1 or none logo, or if they must be prepared to
>>>handle any number of logos.
>>>
>>>As said above, if this is not limited, as GUI maker you MUST expect CA:s
>>>to
>>>put in a whole bunch of obscure logos here representing everything from
>>>loyalty scheme, accreditation scheme, partners, sponsors...... you name
>>>it.
>>>
>>>This is why the principle is good to say that the 3 main logotype types
>>>can
>>>only be 1 logo of each type.
>>>
>>>If you want to include more logos, you provide them as other logos,
>>>according to section 4.2. This is a good structured way that provide
>>>clear
>>>expectations for the GUI makers.
>>>
>>>
>>>
>>>>>Denis,
>>>>>
>>>>>We had this discussion in Yokohama and all examples you came
>>>>
>>>>up with had
>>>>
>>>>>to do with loyalty structures rather than communities. The
>>>>
>>>>community logo
>>>>
>>>>>represent THE community within which the issuer acts as issuer.
>>>>
>>>>Besides loyalty structures (BTW, where do you place them ?),
>>>>there is as an
>>>>example "t-scheme approved" or what ever other "scheme" in Asia or in
>>>
>>>the
>>>
>>>
>>>>US. Same question: where do you place that information ?
>>>>
>>>
>>>
>>>This is not a community. I don't issue certificate belonging to the
>>>t-scheme
>>>community. T-scheme, TTP-NL, Web trust or whatever are conformance
>>>schemes
>>>that has nothing to do with community. If you want to display any
>>>logotype
>>>related to this you must define a new "other logo" type in section 4.2.
>>>
>>>It could actually be a good idea to do that.
>>>
>>>
>>>
>>>
>>>>>Example - A credit card can never be both MasterCard and VISA at
>>>>
>>>the
>>>
>>>
>>>>>same time. If it would, who would be responsible for it if
>>>>
>>>something
>>>
>>>
>>>>>goes wrong???
>>>>
>>>>Some merchants are accepting credit cards from Visa, Eurocard, and
>>>
>>>AMEX.
>>>
>>>
>>>>How are you going to be able to include that information in a server
>>>>certificate ?
>>>
>>>
>>>You don't
>>>
>>>You may provide that information on the web page that is protected by
>>>the
>>>server certificate. But whatever you do, it is NOT part of the community
>>>logo in the server certificate.
>>>
>>>
>>>
>>>
>>>>Some cards in my country have both the CB logo (CB = Carte
>>>>Bancaire) and the
>>>>Eurocard or VISA Logo.
>>>>
>>>>How are you going to be able to include that information in a person
>>>>certificate issued by a bank ?
>>>
>>>
>>>The standard allows 2 issuer logos for co-branding, 1:st the logo
>>>representing the Issuer organization, 2:nd the logo representing the
>>>community.
>>>
>>>I'm not sure what function the CB logo has. If this is not covered by
>>>these
>>>logos, you can use some of the defined other logos (section 4.2), or
>>>define
>>>one for the purpose.
>>>
>>>
>>>
>>>>>If the community, within which the issuer operates when issuing a
>>>>>particular certificate, has a combined logo from two integrated
>>>>>community structures -
>>>>>Fine - This is then still just 1 community logo from the standards
>>>>>perspective.
>>>>
>>>>We never said that logos MUST be displayed. An application may look
>>>
>>>for a
>>>
>>>
>>>>given logo and chose to display it, if present. Combined logos would
>>>
>>>not
>>>
>>>
>>>>allow that feature and would be pretty big or unreadable since an
>>>>application would need to display, e.g. four, logos in a small
>>>>window size.
>>>>
>>>
>>>
>>>That's a feature, not a problem. This means that If the application
>>>display
>>>logo related to THE community, it can not screw up by showing just half
>>>of
>>>the relevant logo image data.
>>>
>>>
>>>
>>>>>I agree though that you can have multiple independent loyalty
>>>>
>>>schemes.
>>>
>>>
>>>>Fine. Where do you place them ?
>>>
>>>
>>>Read section 4.2
>>>
>>>Stuff deleted ...
>>>
>>>
>>>
>>>>Since a sentence is saying:
>>>>
>>>>    If a logotype is represented by more than one image file, then
>>>
>>>the
>>>
>>>
>>>>    image files MUST contain variants of the roughly the same image.
>>>>
>>>>My understanding is the following:
>>>>
>>>>image contains one or more variants of the roughly the same image. No
>>>
>>>more
>>>
>>>
>>>>that one of the LogotypeImage SHALL be displayed, since it is roughly
>>>
>>>the
>>>
>>>
>>>>same image.
>>>>
>>>>This does not permit to include images that are really different.
>>>
>>>
>>>Yes you are right. That is the defined meaning.
>>>
>>>
>>>
>>>>I am asking for:
>>>>
>>>>          communityLogo   [0] EXPLICIT SEQUENCE OF LogotypeInfo
>>>
>>>OPTIONAL,
>>>
>>>
>>>>instead of:
>>>>
>>>>          communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
>>>>
>>>>I hope that the above examples will be able to convince you.
>>>
>>>
>>>I regret to say that I'm not.
>>>
>>>I still think it would make the standard worse
>>>
>>>What would convince me is if anyone could show a realistic and relevant
>>>case
>>>where there are 2 independent communities, within which the issuer acts
>>>when
>>>issuing a certificate. I have yet to see that case.
>>>
>>>/Stefan
>>>
>>>
>>>
>>
>>
>>
> 
> 





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA774Z103467 for ietf-pkix-bks; Wed, 6 Nov 2002 23:04:35 -0800 (PST)
Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA774Yv03458 for <[e-mail]>; Wed, 6 Nov 2002 23:04:35 -0800 (PST)
Received: by aspams52.ca.com with Internet Mail Service (5.5.2656.59) id <WBBQKDAH>; Thu, 7 Nov 2002 18:04:33 +1100
Message-ID: <[e-mail]>
From: "Ramsay, Ron" <[e-mail]>
To: [e-mail], "'Peter Gietz'" <[e-mail]>, "'Housley, Russ'" <[e-mail]>
Cc: [e-mail], "'Norbert Klasen'" <[e-mail]>, "'David Chadwick'" <[e-mail]>
Subject: RE: new version of draft on additional x509 certificate schema  f orLDAP
Date: Thu, 7 Nov 2002 18:05:03 +1100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I should think a key advantage of subordinate certificate entries is that
you may return a single certificate. If all certificates are stored in the
user's entry, you would generally receive them all on a search.

Ron.

-----Original Message-----
From: Steven Legg [mailto:[e-mail]]
Sent: Thursday, 7 November 2002 4:52 PM
To: 'Peter Gietz'; 'Housley, Russ'
Cc: [e-mail]; 'Norbert Klasen'; 'David Chadwick'
Subject: RE: new version of draft on additional x509 certificate schema
forLDAP

<snip>

Since an implementation of component matching could always use internal
data structures that mimic the metadata approach, component matching is
theoretically no worse than the metadata approach. Component matching
obviously permits greater space efficiency since it does not require the
duplication of certificates as subordinate entries, and their component
parts as additional attributes (e.g. in our server implementation the
component parts of certificates, CRLs, etc, are indexed directly).
This has a positive effect on the overall efficiency of a directory
server, but the bigger win is in the clients which are free of the burden
of managing all the explicit redundancy entailed in metadata approach.

<snip>

Regards,
Steven



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA75qq626842 for ietf-pkix-bks; Wed, 6 Nov 2002 21:52:52 -0800 (PST)
Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id gA75qov26834 for <[e-mail]>; Wed, 6 Nov 2002 21:52:50 -0800 (PST)
Received: (qmail 30580 invoked from network); 7 Nov 2002 05:45:47 -0000
Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 7 Nov 2002 05:45:47 -0000
Reply-To: <[e-mail]>
From: "Steven Legg" <[e-mail]>
To: "'Peter Gietz'" <[e-mail]>, "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>, "'Norbert Klasen'" <[e-mail]>, "'David Chadwick'" <[e-mail]>
Subject: RE: new version of draft on additional x509 certificate schema  forLDAP
Date: Thu, 7 Nov 2002 16:51:31 +1100
Message-ID: <009601c28621$b9bd0310$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Importance: Normal
In-reply-to: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

Peter Gietz wrote:
> Therefore I say that 
> for a widely distributed and scalable service a CIP based indexing 
> system is a necessity. And such a system relies on attributes 
> that can 
> be stored in the index objects.

The Tagged Index Object for CIP relies on attributes. An improved
index object format that allowed attributes with optional component
references as the keys could always be defined.


> Housley, Russ wrote:
> > 3.  I think that section 3 is trying to tell me that the proposed 
> > scheme is compatible with the long-term design, yet it is also 
> > implementable in the short-term.  We do not have to wait for the 
> > vision of the long term to be realized.  Did I get that right? 
> 
> Well a soon as component matching is reality,

Adacel has a full implementation of component matching.

> the problem of multiple 
> certificates can be solved with it may be even better than with our 
> simple approach, allthough there might be performance issues. May be 
> Steven Legg can comment on this better.

Since an implementation of component matching could always use internal
data structures that mimic the metadata approach, component matching is
theoretically no worse than the metadata approach. Component matching
obviously permits greater space efficiency since it does not require the
duplication of certificates as subordinate entries, and their component
parts as additional attributes (e.g. in our server implementation the
component parts of certificates, CRLs, etc, are indexed directly).
This has a positive effect on the overall efficiency of a directory
server, but the bigger win is in the clients which are free of the burden
of managing all the explicit redundancy entailed in metadata approach.

> The two approaches are as 
> compatible as is our approach with the current "traditional" method: 
> they could live side by side.

Agreed. The solutions can co-exist.


> In LDAP you don't have a difference between empty value and 
> non existant 
> value.

For the most part LDAP & X.500 attribute syntaxes don't allow
empty values. Some do, and in these cases the difference between
an empty value and an absent value is recognized and significant
in LDAP & X.500.

Regards,
Steven



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6NmNB11824 for ietf-pkix-bks; Wed, 6 Nov 2002 15:48:23 -0800 (PST)
Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA6NmLv11817 for <[e-mail]>; Wed, 6 Nov 2002 15:48:21 -0800 (PST)
Received: from fwd03.sul.t-online.de  by mailout03.sul.t-online.com with smtp  id 189ZuF-0000E3-03; Thu, 07 Nov 2002 00:48:19 +0100
Received: from burgundy.dyndns.org (520009743106-0001@[80.132.171.111]) by fmrl03.sul.t-online.com with esmtp id 189Zu9-0IyvK4C; Thu, 7 Nov 2002 00:48:13 +0100
Received: from localhost (localhost [127.0.0.1]) by burgundy.dyndns.org (Postfix) with ESMTP id 6421B4A33; Thu,  7 Nov 2002 00:48:12 +0100 (CET)
Received: from [192.168.0.3] (trex.local [192.168.0.3]) by burgundy.dyndns.org (Postfix) with ESMTP id 9E5A449EB; Thu,  7 Nov 2002 00:48:09 +0100 (CET)
Date: Thu, 07 Nov 2002 00:48:09 +0100
From: Norbert Klasen <[e-mail]>
To: Peter Gietz <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, [e-mail], David Chadwick <[e-mail]>, Steven Legg <[e-mail]>
Subject: Re: new version of draft on additional x509 certificate schema  for LDAP
Message-ID: <97125168.1036630089@[192.168.0.4]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/2.2.1 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by AMaViS 0.3.12pre8
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Mittwoch, 6. November 2002 16:37 +0100 Peter Gietz 
<[e-mail]> wrote:

>>
>>> - should revocation information be stored in a similiar fashion. And
>>> if so how: 1.) Metadata attributes for CRLs or 2.) revocation
>>> relevant attributes attached to the certificate entries.
>>
>>
>> Storage of CRLs is very important.  Presently, clients have the same
>> issues with the multi-valued CRL attribute.  Storage in a separate
>> entry subordinate to the CRL Issuer makes most sense to me.  One issue
>> would be how long such entries need to remain on-line.  Another issue
>> is the storage of delta CRLs.
>
> This is the approach David is thinking about. We already did some work on
> defining an objectclass as subclass of x509certificate that could be
> included to the entries of a revoked certificates.

With hindsight, using a subclass of x509certificate seems not to be such a 
good idea. According to the standards, the structural object class of an 
entry must not change. So one would have delete the entry and then readd it 
with the new structural object class. I think that an auxiliary object 
class, which can be added to an existing entry, would be the better 
approach here.

Norbert


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6NfJE10905 for ietf-pkix-bks; Wed, 6 Nov 2002 15:41:19 -0800 (PST)
Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA6NfHv10901 for <[e-mail]>; Wed, 6 Nov 2002 15:41:17 -0800 (PST)
Received: from fwd05.sul.t-online.de  by mailout06.sul.t-online.com with smtp  id 189ZnF-000361-03; Thu, 07 Nov 2002 00:41:05 +0100
Received: from burgundy.dyndns.org (520009743106-0001@[80.132.171.111]) by fmrl05.sul.t-online.com with esmtp id 189ZnB-0LddcOC; Thu, 7 Nov 2002 00:41:01 +0100
Received: from localhost (localhost [127.0.0.1]) by burgundy.dyndns.org (Postfix) with ESMTP id F0DD64A2D; Thu,  7 Nov 2002 00:40:56 +0100 (CET)
Received: from [192.168.0.3] (trex.local [192.168.0.3]) by burgundy.dyndns.org (Postfix) with ESMTP id F0E0249EB; Thu,  7 Nov 2002 00:40:52 +0100 (CET)
Date: Thu, 07 Nov 2002 00:40:52 +0100
From: Norbert Klasen <[e-mail]>
To: "Housley, Russ" <[e-mail]>, Peter Gietz <[e-mail]>
Cc: [e-mail], David Chadwick <[e-mail]>, Steven Legg <[e-mail]>
Subject: Re: new version of draft on additional x509 certificate schema for LDAP
Message-ID: <96688570.1036629652@[192.168.0.4]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/2.2.1 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by AMaViS 0.3.12pre8
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

--On Mittwoch, 6. November 2002 16:48 -0500 "Housley, Russ" 
<[e-mail]> wrote:

> I think that another MUST attribute is needed.  The certificate itself
> MUST be stored as a binary blob.  We want to be able to get the
> certificate from the repository in a manner that preserves the DER
> encoding applied by the signer.

Our intention was that the binary blob should be stored in a well known 
attribute ("userCertificate" or "caCertificate"). These are allowed in an 
x509certificate entry by including one of the auxiliary object classes 
"pkiUser" or "pkiCA":

   Entries of this structural object class MUST also have one of the
   following auxiliary object classes: "pkiUser" or "pkiCA".  This way,
   the entry can contain the certificate in the "userCertificate" or
   "cacertificate" attribute.

Norbert


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6Lnlk06176 for ietf-pkix-bks; Wed, 6 Nov 2002 13:49:47 -0800 (PST)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA6Lnev06162 for <[e-mail]>; Wed, 6 Nov 2002 13:49:40 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 6 Nov 2002 21:49:43 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA22072; Wed, 6 Nov 2002 16:48:57 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id gA6LkGf09220; Wed, 6 Nov 2002 16:46:16 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWK2S9>; Wed, 6 Nov 2002 16:48:55 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.6]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWK2SZ; Wed, 6 Nov 2002 16:48:49 -0500
From: "Housley, Russ" <[e-mail]>
To: Peter Gietz <[e-mail]>
Cc: [e-mail], Norbert Klasen <[e-mail]>, David Chadwick <[e-mail]>, Steven Legg <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 06 Nov 2002 16:48:20 -0500
Subject: Re: new version of draft on additional x509 certificate schema for LDAP
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

Several of these issues are interrelated.  In particular, the points about 
referrals and DIT structure overlap.  If a client is referred to another 
LDAP server, the client cannot assume that the two servers are storing 
certificates in the same manner.  In this regard, the use of a flag in the 
rootDSE could be very helpful.

Also, something I missed in my first reading. The x509certificate is 
defined as:

    ( 1.3.6.1.4.1.10126.1.5.4.2.1
         NAME 'x509certificate'
         STRUCTURAL
         MUST ( x509serialNumber $ x509signatureAlgorithm $ x509issuer $
            x509validityNotBefore $ x509validityNotAfter $ x509subject $
            x509subjectPublicKeyInfoAlgorithm )
         MAY  ( mail $ x509authorityKeyIdentifier $
            x509authorityCertIssuer $ x509authorityCertSerialNumber $
            x509subjectKeyIdentifier $ x509keyUsage $
            x509policyInformationIdentifier $
            x509subjectAltNameRfc822Name $ x509subjectAltNameDnsName $
            x509subjectAltNameDirectoryName $ x509subjectAltNameURI $
            x509subjectAltNameIpAddress $
            x509subjectAltNameRegisteredID $
            x509isssuerAltNameRfc822Name $ x509isssuerAltNameDnsName $
            x509isssuerAltNameDirectoryName $ x509isssuerAltNameURI $
            x509isssuerAltNameIpAddress $
            x509isssuerAltNameRegisteredID $
            x509extKeyUsage $
            x509cRLDistributionPoint $ x509certificateHolder) )

I think that another MUST attribute is needed.  The certificate itself MUST 
be stored as a binary blob.  We want to be able to get the certificate from 
the repository in a manner that preserves the DER encoding applied by the 
signer.

I respond to a few of your comments below.

>Russ:
>
>Thanks a lot for your valuable and detailed comments, which definitely 
>will be reflected in the next version of the draft, which I intend to 
>submit some time after the Atlanta meeting. BTW the next version will also 
>fix some bugs that still remained in the examples, for which I herewith 
>apologize..
>
>Let me comment in line:
>
>Housley, Russ wrote:
>
>>Peter:
>>
>>The authors have clearly put in a lot of effort.  Thanks for your work on 
>>this important topic.
>>
>>I have a few comments and questions.
>>
>>1.  Section 2, 1st paragraph on page 5.  I am quite concerned about the 
>>duplication proposed.  If we take the proposed approach, there must be a 
>>transition period.  But the issues with duplication of the certificates 
>>(and CRLs) in multiple locations deserves more than a sentence.  Also, 
>>the discussion needs to include words like "consistency."
>
>Yes you are definitely right. Current clients expect the certificate to be 
>in the same directory entry than the person entry with searchable 
>attributes cn, mail and serialNumber of which we untill now only included 
>the mail attribute into the new object class, believing that that is the 
>attribute mostly searched for. Thus for these searches, the redundancy 
>proposed would not be needed. We are currently implementing the draft and 
>are making experiments with clients to see what else could be needed. A 
>transition period would only end, if standard clients start to use the new 
>schema proposed in our draft. This is one reason for us to want to make 
>this work a pkix draft to further such developments.
>
>For now I would propose to include some more language on the issue, such as:
>"Maintainers of repositories complying to this memo MUST make sure that 
>the same certificates are stored in the person entry and the respective 
>x509certificate entries and keep this consistency. Alternatively they MUST 
>leave out any certificates in the person entry."
>
>One could additionally define an algorithm which enables the client to 
>know, whether the new schema is supported by a server. This could either 
>be a bit more complicated, by searching the objectclass x509certificate in 
>the Subschema entry pointed to in the rootDSE entry, or by just specifying 
>a separate RootDSE attribute which specifies, if certificates are only 
>stored in the x509certificate entries, of if they are
>additionally stored the "traditional" way.
>
>>2.  The last paragraph of section 2 says:
>>
>>    A CIP based indexing system for a wide scale distributed certificate
>>    repository will only be possible by using the solution proposed here.
>>
>>This is a pretty strong statement.  Also, this is the first time that 
>>support for CIP has been raised as a requirement.  I am certainly not a 
>>CIP expert, and I hope that this discussion will not force me to become 
>>one, but I think that we need to understand why CIP is so important to 
>>LDAP server implementors.  Can you add a few sentences of rationale?
>
>Yes I could. My point here is that a service that is not maintained on one 
>single site up to now needs an indexing service to prevent a situation 
>where a client has to ask the same question to a large number of servers. 
>X.500 with the DISP protocoll provided a chaining mechanism so that a 
>client only had to ask one server and that server would know which other 
>servers to contact for the right answer via so called knowledge 
>information. We don't have this mechanism in LDAP, but only referalls. 
>There is a new RFC (RFC2396) specifying how referrals could be included 
>into the Directory tree to provide such pointers to other servers. But 
>even with this technology you would have a much bigger maintanence effort 
>than with an indexing system. Therefore I say that for a widely 
>distributed and scalable service a CIP based indexing system is a 
>necessity. And such a system relies on attributes that can be stored in 
>the index objects.
>
>>3.  I think that section 3 is trying to tell me that the proposed scheme 
>>is compatible with the long-term design, yet it is also implementable in 
>>the short-term.  We do not have to wait for the vision of the long term 
>>to be realized.  Did I get that right?
>
>Well a soon as component matching is reality, the problem of multiple 
>certificates can be solved with it may be even better than with our simple 
>approach, allthough there might be performance issues. May be Steven Legg 
>can comment on this better. The two approaches are as compatible as is our 
>approach with the current "traditional" method: they could live side by 
>side. As to to your second conclusion: yes, we believe that our approach 
>can be used today, without big implementation issues. We are currently 
>experimenting  to proove this.

Please post the results of you implementation experiments.

>>4.  Section 4.1.6 defines the attribute for subject name.  RFC 3280 
>>allows the subject name in an end-entity certificate to be an empty 
>>sequence.  In this case, the subject alternative name must be 
>>present.  What should happen here?  Should the attribute be present with 
>>an empty name?  Does RFC 2253 handle empty names?  I could not figure it 
>>out with a quick scan.  Also, section 4.4 indicates that x509subject must 
>>be present.
>
>Oops, you are right x509subject should rather be a MAY attribute.
>
>In LDAP you don't have a difference between empty value and non existant 
>value. The idea behind the draft is to have a piece of software (a 
>prototype of which is allready implemented by us) that analyzes a 
>certificate and creates the apropriate LDIF with the new schema. Thus a 
>certificate conforming to RFC 3280 will have a conforming representation 
>in LDAP.  But of course we could include additional text that duplicates 
>the respective rules of RFC 3280:
>"If x509subject is empty, at least one of the following attributes MUST 
>include a value: x509subjectAltNameRfc822Name, x509subjectAltNameDnsName, 
>x509subjectAltNameDirectoryName, x509subjectAltNameURI , 
>x509subjectAltNameIpAddress, x509subjectAltNameRegisteredID."

Correct.  I do not know if you want the schema document to capture this 
difference or not, but CA certificates must have a subject distinguished 
name, while end entity certificates may have an empty subject distinguished 
name.

>>[SNIP]

>>9.  Section 5 requires a name form that uses a multi-valued RDN.  I 
>>believe that many LDAP implementations cannot handle this construct.
>>Perhaps there is an alternative.  Will the Issuer DN followed by the 
>>serial number work?  For example (building on an example in the document):
>>
>>    SN=1234567,OU=VeriSign Trust Network,
>>    OU=(c) 1998 VeriSign\2c Inc. - For authorized use only,
>>    OU=Class 1 Public Primary Certification Authority - G2,
>>    O=VeriSign\2c Inc.,C=US
>
>Yes, I had some discussions about this with David Chadwick, and I allready 
>agreed to include another alternate name form for implementations that are 
>not fully LDAPv3 compliant. I just didn't have enough time before the 
>cut-off date for submission.
>
>The nameform should have DN syntax and should be constructed by an 
>serialnumber attribute (SN or rather x509SerialNumber ?) and the IssuerDN: 
>Thus (using a more simple example for conveniance):
>
>x509SerialIssuer=x509SerialNumber\3D12345\2Co\3DsomeCA\2Cc\3Dsomecountry,ou=somedepartment,o=someorg,c=somecountry
>
>Since the first part is only one single attribute all ',' and '=' have to 
>be hex escaped.
>
>This is something, David and I sort of agreed upon, but as I put this as 
>one of my questions to the list, this is open for discussion.
>
>As to sn vs x509SerialNumber:
>
>serialNumber was defined in X.520 and RFC 2256 as:
>
>"This attribute contains the serial number of a device."
>
>It thus was rather meant for hardware than for software. But it seems that 
>it is now quite regulary used in the pkix context. My question is 1.) 
>should both attributes exist in parallel,
>2.) or should I rather exchange x509SerialNumber with the RFC 2256 
>attribute serialNumber    (in analogy of the attribute mail taken from RFC 
>2798.
>3.) or should we try to standardize the sole use of x509serialNumber

I have no problem using x509SerialNumber instead of serialNumber.  Since no 
one has deployed any of this stuff yet, it is probably best to pick a 
single way to handle it.

>>[SNIP]

>>>- The draft does only describe fields described in RFC 3280. Should it 
>>>also deal with Qualified certificates (RFC 3039)?
>>
>>I think it would be useful to search on some of the information that QCs 
>>store in subject directory attributes extension.
>
>OK I will work on that in the next version. Input as to which information 
>might be interesting to search for is most welcome.

RFC 3039 says:

    Compliant implementations SHALL be able to interpret the following
    attributes:

       title;
       dateOfBirth;
       placeOfBirth;
       gender;
       countryOfCitizenship; and
       countryOfResidence.

These all look like reasonable search criteria.

>>>- should revocation information be stored in a similiar fashion. And if 
>>>so how: 1.) Metadata attributes for CRLs or 2.) revocation relevant 
>>>attributes attached to the certificate entries.
>>
>>Storage of CRLs is very important.  Presently, clients have the same 
>>issues with the multi-valued CRL attribute.  Storage in a separate entry 
>>subordinate to the CRL Issuer makes most sense to me.  One issue would be 
>>how long such entries need to remain on-line.  Another issue is the 
>>storage of delta CRLs.
>
>This is the approach David is thinking about. We already did some work on 
>defining an objectclass as subclass of x509certificate that could be 
>included to the entries of a revoked certificates. This would make dynamic 
>creation of CRLs possible, make delta CRLs unneccessary and would also 
>ease the use of directory information for an OCSP service. But I see 
>advantages of CRL entries as well, since that is the authoritative and 
>signed information on revocation. But a CA could also sign every 
>certificate entry by means of  RFC 2645. I don't really know how accepted 
>that mechanism is though. I am looking forward to discussions about this.
>
>>>- should attribute certificates be stored in a similiar fashion?
>>
>>Presently, clients have the same issues with the multi-valued attribute 
>>certificate attribute. If this solution is adopted for certificates, it 
>>should be adopted for attribute certificates and CRLs too.
>
>Agreed. Again it seems that people begin thinking about this allready.
>
>>Russ
>
>Peter Gietz

Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6Jir800669 for ietf-pkix-bks; Wed, 6 Nov 2002 11:44:53 -0800 (PST)
Received: from tierra.stl.es (tierra.stl.es [195.235.83.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA6Jikv00660 for <[e-mail]>; Wed, 6 Nov 2002 11:44:51 -0800 (PST)
Received: from zurbaran.stl.es (IDENT:[e-mail] [172.20.144.84]) by tierra.stl.es (8.11.6/8.11.6) with ESMTP id gA6JdXT02613; Wed, 6 Nov 2002 20:39:33 +0100
Received: from stl.es (j-sanchez.stl.es [172.20.17.130]) by zurbaran.stl.es (8.11.6/8.11.6) with ESMTP id gA6JdWD06312; Wed, 6 Nov 2002 20:39:32 +0100
Message-ID: <[e-mail]>
Date: Wed, 06 Nov 2002 20:38:37 +0100
From: Julio Sanchez <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; es-ES; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: es-es, es
MIME-Version: 1.0
To: Peter Gietz <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, [e-mail], Norbert Klasen <[e-mail]>, David Chadwick <[e-mail]>, Steven Legg <[e-mail]>
Subject: Re: new version of draft on additional x509 certificate schema  for LDAP
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gietz escribió:

> As to sn vs x509SerialNumber: 
> serialNumber was defined in X.520 and RFC 2256 as:
>
> "This attribute contains the serial number of a device."
>
> It thus was rather meant for hardware than for software. But it seems 
> that it is now quite regulary used in the pkix context. My question is 
> 1.) should both attributes exist in parallel,
> 2.) or should I rather exchange x509SerialNumber with the RFC 2256 
> attribute serialNumber    (in analogy of the attribute mail taken from 
> RFC 2798.
> 3.) or should we try to standardize the sole use of x509serialNumber 

The syntax for serialNumber is 1.3.6.1.4.1.1466.115.121.1.44 (Printable 
String) and does not have an ordering matching rule.

Since it is a string, all kind of things appear there, it is not 
uncommon to see different hex encodings used and you have to get it 
right everytime: left zero filling or not, separating colons or not, 
etc. If serialNumber is used, it should be very well defined how is the 
integer encoded.

I think that further use of serialNumber to hold certificate serial 
numbers should be discouraged.

Julio




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6HqeK20673 for ietf-pkix-bks; Wed, 6 Nov 2002 09:52:40 -0800 (PST)
Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA6HqRv20653 for <[e-mail]>; Wed, 6 Nov 2002 09:52:28 -0800 (PST)
Received: (qmail 10743 invoked from network); 6 Nov 2002 17:42:51 -0000
Received: from unknown (HELO multicert.com) (62.48.185.5) by mail0.sibs.pt with SMTP; 6 Nov 2002 17:42:51 -0000
Message-ID: <[e-mail]>
Date: Wed, 06 Nov 2002 17:50:10 +0000
From: Ricardo Barroso <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Sylvester wrote:

>>Because with RFC 3161 it's possible that exist two compliant systems
>>which can't interoperate properly in some situations because one accepts that
>>PKIFailueInfo contains more than one bit with value one (1) and the other not!
>>    
>>
>
>It seems that the text could say 'MAY only be any of the following values'.
>as the list is a restriction (and extension) of the values define in CMP.
>
>Or: 'Only the following values MAY occur'.
>
>I could detect an invalid hash algorithm and an unsupported extension,
>an unacceptable policy, and even time source not available all together. 
>
Peter, I agree with you.

Ricardo Barroso




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6Hd3F20379 for ietf-pkix-bks; Wed, 6 Nov 2002 09:39:03 -0800 (PST)
Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA6Hcpv20372 for <[e-mail]>; Wed, 6 Nov 2002 09:38:51 -0800 (PST)
Received: (qmail 10197 invoked from network); 6 Nov 2002 17:29:18 -0000
Received: from unknown (HELO multicert.com) (62.48.185.5) by mail0.sibs.pt with SMTP; 6 Nov 2002 17:29:18 -0000
Message-ID: <[e-mail]>
Date: Wed, 06 Nov 2002 17:36:38 +0000
From: Ricardo Barroso <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
References: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------040103060302080200080509"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------040103060302080200080509
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Peter Sylvester wrote:

>>Because with RFC 3161 it's possible that exist two compliant systems
>>which can't
>>interoperate properly in some situations because one accepts that
>>PKIFailueInfo
>>contains more than one bit with value one (1) and the other not!
>>
>>    
>>
>
>A client signals an error in both cases. If there is no time stamp
>token available, if any of the values are set, then there is an error, 
>the difference may only be that the client do not get the same local
>error message.  
>
>The actual text does not specify different possible actions depending
>in different errors, a server cannot indicate that there is only
>a temporary error, no logic that provokes a different behaviour
>of the client depending on the values or combinations of them
>can be deduced from the actual text. 
>
Peter, that depends on your ASN.1 coder/decoder implementation...
If you have implicitly in your ASN.1 co/decoder that a PKIFailureInfo 
can't have
multiple bits with value one (1) then the client difficultly or 
even won't be able to
decode the TSA response!**

I don't know if you agree with my startegy but I think a better approach 
would be if you can
make implicitly your ASN.1 co/decoder only generate/accept (code/decode) 
valid RFC 3161 /
compliant/ ASN.1 definitions (or other context appliable). This will 
prevent some errors
you can stop there to be expanded (outside the scope of the 
coder/decoder) to somewhere in
your system. Possibly this is more a question about Software Engineering 
than in the scope
of IETF-PKIX, I don't know.

Best regards,
Ricardo Barroso

MULTICERT S.A.
www.multicert.com <http://www.multicert.com>


--------------040103060302080200080509
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Peter Sylvester wrote:<br>
<blockquote type="cite"
 cite="[e-mail]">
  <blockquote type="cite">
    <pre wrap="">Because with RFC 3161 it's possible that exist two compliant systems
which can't
interoperate properly in some situations because one accepts that
PKIFailueInfo
contains more than one bit with value one (1) and the other not!

    </pre>
  </blockquote>
  <pre wrap=""><!---->
A client signals an error in both cases. If there is no time stamp
token available, if any of the values are set, then there is an error, 
the difference may only be that the client do not get the same local
error message.  

The actual text does not specify different possible actions depending
in different errors, a server cannot indicate that there is only
a temporary error, no logic that provokes a different behaviour
of the client depending on the values or combinations of them
can be deduced from the actual text. </pre>
</blockquote>
Peter, that depends on your ASN.1 coder/decoder implementation...<br>
If you have implicitly in your ASN.1 co/decoder that a <tt>PKIFailureInfo</tt>
can't have <br>
multiple bits with value one (1) then the client difficultly or even&nbsp;won't
be able to <br>
decode the TSA response!<b><font size="-1" face="arial,sans-serif"></font></b><br>
<br>
I don't know if you agree with my startegy but I think a better approach
would be if you can <br>
make implicitly your ASN.1 co/decoder only generate/accept (code/decode)
valid RFC 3161 <i><br>
compliant</i> ASN.1 definitions (or other context appliable). This will prevent
some errors <br>
you can stop there to be expanded (outside the scope of the coder/decoder)
to somewhere in <br>
your system. Possibly this is more a question about Software Engineering
than in the scope <br>
of IETF-PKIX, I don't know.<br>
<br>
Best regards,<br>
Ricardo Barroso<br>
<br>
 MULTICERT S.A. <br>
 <a href="http://www.multicert.com">www.multicert.com</a><br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap=""></pre>
</blockquote>
</body>
</html>

--------------040103060302080200080509--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6HCdf19212 for ietf-pkix-bks; Wed, 6 Nov 2002 09:12:39 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA6HCQv19187 for <[e-mail]>; Wed, 6 Nov 2002 09:12:26 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA23114; Wed, 6 Nov 2002 18:12:22 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Wed, 6 Nov 2002 18:12:22 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id SAA17816; Wed, 6 Nov 2002 18:12:21 +0100 (MET)
Date: Wed, 6 Nov 2002 18:12:21 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Because with RFC 3161 it's possible that exist two compliant systems
> which can't
> interoperate properly in some situations because one accepts that
> PKIFailueInfo
> contains more than one bit with value one (1) and the other not!
> 

A client signals an error in both cases. If there is no time stamp
token available, if any of the values are set, then there is an error, 
the difference may only be that the client do not get the same local
error message.  

The actual text does not specify different possible actions depending
in different errors, a server cannot indicate that there is only
a temporary error, no logic that provokes a different behaviour
of the client depending on the values or combinations of them
can be deduced from the actual text. 

 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6H4VG17877 for ietf-pkix-bks; Wed, 6 Nov 2002 09:04:31 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA6H4Jv17850 for <[e-mail]>; Wed, 6 Nov 2002 09:04:19 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA23075; Wed, 6 Nov 2002 18:04:11 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Wed, 6 Nov 2002 18:04:12 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id SAA17770; Wed, 6 Nov 2002 18:04:09 +0100 (MET)
Date: Wed, 6 Nov 2002 18:04:09 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Because with RFC 3161 it's possible that exist two compliant systems
> which can't interoperate properly in some situations because one accepts that
> PKIFailueInfo contains more than one bit with value one (1) and the other not!

It seems that the text could say 'MAY only be any of the following values'.
as the list is a restriction (and extension) of the values define in CMP.

Or: 'Only the following values MAY occur'.

I could detect an invalid hash algorithm and an unsupported extension,
an unacceptable policy, and even time source not available all together. 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6FcXk13627 for ietf-pkix-bks; Wed, 6 Nov 2002 07:38:33 -0800 (PST)
Received: from isis.directory.dfn.de (isis.directory.dfn.de [134.2.217.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA6FcQv13609 for <[e-mail]>; Wed, 6 Nov 2002 07:38:31 -0800 (PST)
Received: from clara.directory.dfn.de (clara.directory.dfn.de [134.2.217.66]) by isis.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id gA6FbiE23991; Wed, 6 Nov 2002 16:37:45 +0100
Received: from daasi.de (mercury.directory.dfn.de [134.2.217.50]) by clara.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id gA6Fbi712711; Wed, 6 Nov 2002 16:37:44 +0100
Message-ID: <[e-mail]>
Date: Wed, 06 Nov 2002 16:37:44 +0100
From: Peter Gietz <[e-mail]>
Organization: DAASI International GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: de-de, en-us, en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail], Norbert Klasen <[e-mail]>, David Chadwick <[e-mail]>, Steven Legg <[e-mail]>
Subject: Re: new version of draft on additional x509 certificate schema  for LDAP
References: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gA6FcWv13622
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ:

Thanks a lot for your valuable and detailed comments, which definitely 
will be reflected in the next version of the draft, which I intend to 
submit some time after the Atlanta meeting. BTW the next version will 
also fix some bugs that still remained in the examples, for which I 
herewith apologize..

Let me comment in line:

Housley, Russ wrote:

> Peter:
>
> The authors have clearly put in a lot of effort.  Thanks for your work 
> on this important topic.
>
> I have a few comments and questions.
>
> 1.  Section 2, 1st paragraph on page 5.  I am quite concerned about 
> the duplication proposed.  If we take the proposed approach, there 
> must be a transition period.  But the issues with duplication of the 
> certificates (and CRLs) in multiple locations deserves more than a 
> sentence.  Also, the discussion needs to include words like 
> "consistency." 

Yes you are definitely right. Current clients expect the certificate to 
be in the same directory entry than the person entry with searchable 
attributes cn, mail and serialNumber of which we untill now only 
included the mail attribute into the new object class, believing that 
that is the attribute mostly searched for. Thus for these searches, the 
redundancy proposed would not be needed. We are currently implementing 
the draft and are making experiments with clients to see what else could 
be needed. A transition period would only end, if standard clients start 
to use the new schema proposed in our draft. This is one reason for us 
to want to make this work a pkix draft to further such developments.

For now I would propose to include some more language on the issue, such as:
"Maintainers of repositories complying to this memo MUST make sure that 
the same certificates are stored in the person entry and the respective 
x509certificate entries and keep this consistency. Alternatively they 
MUST leave out any certificates in the person entry."

One could additionally define an algorithm which enables the client to 
know, whether the new schema is supported by a server. This could either 
be a bit more complicated, by searching the objectclass x509certificate 
in the Subschema entry pointed to in the rootDSE entry, or by just 
specifying a separate RootDSE attribute which specifies, if certificates 
are only stored in the x509certificate entries, of if they are
additionally stored the "traditional" way.

>
>
> 2.  The last paragraph of section 2 says:
>
>    A CIP based indexing system for a wide scale distributed certificate
>    repository will only be possible by using the solution proposed here.
>
> This is a pretty strong statement.  Also, this is the first time that 
> support for CIP has been raised as a requirement.  I am certainly not 
> a CIP expert, and I hope that this discussion will not force me to 
> become one, but I think that we need to understand why CIP is so 
> important to LDAP server implementors.  Can you add a few sentences of 
> rationale? 

Yes I could. My point here is that a service that is not maintained on 
one single site up to now needs an indexing service to prevent a 
situation where a client has to ask the same question to a large number 
of servers. X.500 with the DISP protocoll provided a chaining mechanism 
so that a client only had to ask one server and that server would know 
which other servers to contact for the right answer via so called 
knowledge information. We don't have this mechanism in LDAP, but only 
referalls. There is a new RFC (RFC2396) specifying how referrals could 
be included into the Directory tree to provide such pointers to other 
servers. But even with this technology you would have a much bigger 
maintanence effort than with an indexing system. Therefore I say that 
for a widely distributed and scalable service a CIP based indexing 
system is a necessity. And such a system relies on attributes that can 
be stored in the index objects.

>
>
> 3.  I think that section 3 is trying to tell me that the proposed 
> scheme is compatible with the long-term design, yet it is also 
> implementable in the short-term.  We do not have to wait for the 
> vision of the long term to be realized.  Did I get that right? 

Well a soon as component matching is reality, the problem of multiple 
certificates can be solved with it may be even better than with our 
simple approach, allthough there might be performance issues. May be 
Steven Legg can comment on this better. The two approaches are as 
compatible as is our approach with the current "traditional" method: 
they could live side by side. As to to your second conclusion: yes, we 
believe that our approach can be used today, without big implementation 
issues. We are currently experimenting  to proove this.

>
>
> 4.  Section 4.1.6 defines the attribute for subject name.  RFC 3280 
> allows the subject name in an end-entity certificate to be an empty 
> sequence.  In this case, the subject alternative name must be 
> present.  What should happen here?  Should the attribute be present 
> with an empty name?  Does RFC 2253 handle empty names?  I could not 
> figure it out with a quick scan.  Also, section 4.4 indicates that 
> x509subject must be present. 

Oops, you are right x509subject should rather be a MAY attribute.

In LDAP you don't have a difference between empty value and non existant 
value. The idea behind the draft is to have a piece of software (a 
prototype of which is allready implemented by us) that analyzes a 
certificate and creates the apropriate LDIF with the new schema. Thus a 
certificate conforming to RFC 3280 will have a conforming representation 
in LDAP.  But of course we could include additional text that duplicates 
the respective rules of RFC 3280:
"If x509subject is empty, at least one of the following attributes MUST 
include a value: x509subjectAltNameRfc822Name, 
x509subjectAltNameDnsName, x509subjectAltNameDirectoryName, 
x509subjectAltNameURI , x509subjectAltNameIpAddress, 
x509subjectAltNameRegisteredID."

>
>
> 5.  Please rewrite the first sentence in section 4.1.7.  I propose:
>
>    OID identifying the algorithm associated with the certified public 
> key. 

ACK. I was thinking of rephrasing the sentence while working on the new 
version, but then this idea somehow got lost.

>
>
> 6.  The extended key usage extension contains a sequence of OIDs, 
> which identify the key purposes.  If the sequence contains more than 
> one OID, does this attribute get instantiated more than once? 

Yes, all attributes not marked with the keyword SINGLE-VALUE can have 
multiple values.

>
>
> 7.  Given the limitations that are imposed on the CRL distribution 
> point attribute in section 4.2.8, wouldn't it be better to include 
> "FullCRL" in the attribute name? 

Ok, good idea.

>
>
> 8.  Please add descriptive text to section 4.3.1.  I think that this 
> attribute would be placed in the directory entry associated with the 
> certificate subject, not in the directory entry of the certificate.   
> Did I get that right? 

Another Oops, somehow the commetary on this attribute got lost :-(

Yes you got it right. There is some language about this under 4.5 but of 
course there has to be a similiar statement here with a reference to 
4.5. That is what I will do in the next version.

>
>
> 9.  Section 5 requires a name form that uses a multi-valued RDN.  I 
> believe that many LDAP implementations cannot handle this construct.  
> Perhaps there is an alternative.  Will the Issuer DN followed by the 
> serial number work?  For example (building on an example in the 
> document):
>
>    SN=1234567,OU=VeriSign Trust Network,
>    OU=(c) 1998 VeriSign\2c Inc. - For authorized use only,
>    OU=Class 1 Public Primary Certification Authority - G2,
>    O=VeriSign\2c Inc.,C=US 

Yes, I had some discussions about this with David Chadwick, and I 
allready agreed to include another alternate name form for 
implementations that are not fully LDAPv3 compliant. I just didn't have 
enough time before the cut-off date for submission.

The nameform should have DN syntax and should be constructed by an 
serialnumber attribute (SN or rather x509SerialNumber ?) and the 
IssuerDN: Thus (using a more simple example for conveniance):

x509SerialIssuer=x509SerialNumber\3D12345\2Co\3DsomeCA\2Cc\3Dsomecountry,ou=somedepartment,o=someorg,c=somecountry

Since the first part is only one single attribute all ',' and '=' have 
to be hex escaped.

This is something, David and I sort of agreed upon, but as I put this as 
one of my questions to the list, this is open for discussion.

As to sn vs x509SerialNumber:  

serialNumber was defined in X.520 and RFC 2256 as:

"This attribute contains the serial number of a device."

It thus was rather meant for hardware than for software. But it seems that it is now quite regulary 
used in the pkix context. My question is 
1.) should both attributes exist in parallel,
2.) or should I rather exchange x509SerialNumber with the RFC 2256 attribute serialNumber 
    (in analogy of the attribute mail taken from RFC 2798.
3.) or should we try to standardize the sole use of x509serialNumber 

>
>
> Next, I respond to some of the questions in your posting.
>
>> - Can and should this draft be work of the pkix group and should the 
>> discussion about it be held on this list instead of in private email 
>> communications?
>
>
> I think that this topic is very important to the PKIX WG.  I think it 
> should be discussed on the PKIX WG list. 

Thank you.

>
>
>> - The draft does only describe fields described in RFC 3280. Should 
>> it also deal with Qualified certificates (RFC 3039)?
>
>
> I think it would be useful to search on some of the information that 
> QCs store in subject directory attributes extension.

OK I will work on that in the next version. Input as to which 
information might be interesting to search for is most welcome.

>
>> - should revocation information be stored in a similiar fashion. And 
>> if so how: 1.) Metadata attributes for CRLs or 2.) revocation 
>> relevant attributes attached to the certificate entries.
>
>
> Storage of CRLs is very important.  Presently, clients have the same 
> issues with the multi-valued CRL attribute.  Storage in a separate 
> entry subordinate to the CRL Issuer makes most sense to me.  One issue 
> would be how long such entries need to remain on-line.  Another issue 
> is the storage of delta CRLs. 

This is the approach David is thinking about. We already did some work 
on defining an objectclass as subclass of x509certificate that could be 
included to the entries of a revoked certificates. This would make 
dynamic creation of CRLs possible, make delta CRLs unneccessary and 
would also ease the use of directory information for an OCSP service. 
But I see advantages of CRL entries as well, since that is the 
authoritative and signed information on revocation. But a CA could also 
sign every certificate entry by means of  RFC 2645. I don't really know 
how accepted that mechanism is though. I am looking forward to 
discussions about this.

>
>
>> - should attribute certificates be stored in a similiar fashion?
>
>
> Presently, clients have the same issues with the multi-valued 
> attribute certificate attribute. If this solution is adopted for 
> certificates, it should be adopted for attribute certificates and CRLs 
> too. 

Agreed. Again it seems that people begin thinking about this allready.

>
>
> Russ



-- 
_______________________________________________________________________
 
Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]  
D-72074 Tübingen                        email: [e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA6FRIk12653 for ietf-pkix-bks; Wed, 6 Nov 2002 07:27:18 -0800 (PST)
Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA6FR6v12647 for <[e-mail]>; Wed, 6 Nov 2002 07:27:06 -0800 (PST)
Received: (qmail 5148 invoked from network); 6 Nov 2002 15:17:17 -0000
Received: from unknown (HELO multicert.com) (62.48.185.5) by mail0.sibs.pt with SMTP; 6 Nov 2002 15:17:17 -0000
Message-ID: <[e-mail]>
Date: Wed, 06 Nov 2002 15:24:38 +0000
From: Ricardo Barroso <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Andrew Fan <[e-mail]>, IETF-PKIX <[e-mail]>, Peter Gutmann <[e-mail]>
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
References: <[e-mail]> <[e-mail]>
Content-Type: multipart/alternative; boundary="------------020204030808080205070403"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------020204030808080205070403
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit

Thanks you Peter and Andrew!

Peter, I would like to suggest you(if you haven't done it already) that
you or
someone else of the IETF take a note about that ambiguous/doubtful point
since I think it would be useful to clarify that doubt in a possible new
future
draft/RFC (e.g. draft-ietf-pkix-rfc3161bis-00
<http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3161bis-00.txt>).
Because with RFC 3161 it's possible that exist two compliant systems
which can't
interoperate properly in some situations because one accepts that
PKIFailueInfo
contains more than one bit with value one (1) and the other not!

Best regards,
Ricardo Barroso


Andrew Fan wrote:

>Ricardo Barroso wrote:
>
>  
>
>>Hello!
>>
>>RFC 3161 (TSP) says in 2.4.2:
>>
>>"... When the TimeStampToken is not present, the failInfo indicates the
>>reason why the time-stamp request was rejected and may be one of the
>>following values.
>>
>>PKIFailureInfo ::= BIT STRING {
>>badAlg (0),
>>-- unrecognized or unsupported Algorithm Identifier
>>badRequest (2),
>>-- transaction not permitted or supported
>>badDataFormat (5),
>>-- the data submitted has the wrong format
>>timeNotAvailable (14),
>>-- the TSA's time source is not available
>>unacceptedPolicy (15),
>>-- the requested TSA policy is not supported by the TSA
>>unacceptedExtension (16),
>>-- the requested extension is not supported by the TSA
>>addInfoNotAvailable (17)
>>-- the additional information requested could not be understood
>>-- or is not available
>>systemFailure (25)
>>-- the request cannot be handled due to system failure }
>>
>>These are the only values of PKIFailureInfo that SHALL be supported.
>>
>>Compliant servers SHOULD NOT produce any other values. Compliant
>>clients MUST generate an error if values it does not understand are
>>present. ...".
>>
>>Since a BIT STRING can hold several bit values that can be either 1 or 0,
>>is it supposed that a BIT STRING representing a PKIFailureInfo MUST has
>>ONLY one bit (correspondent to one of the defined possible values) or can
>>a PKIFailuereInfo has more than one bit with value 1 wich means that it
>>can indicates more than one valid failure reasons?
>>
>>    
>>
>Indeed, from the Encoding technology of ASN.1, PKIFailureInfo must have
>25 bits, if bit 0 set to 1, badAlg is one reason of this failure, and so on.
>
>  
>
>>Using another words, in:
>>
>>"When the TimeStampToken is not present, the failInfo indicates the
>>reason why the time-stamp request was rejected and may be one of the
>>following values."
>>
>>"may be one" doesn't implies that compliant servers can't generate
>>PKIFailusInfo's with more than one valid value, am I right?
>>    
>>
>
>"may be one of the ..." will be more understandable.
>
>  
>
>>Thanks in advance,
>>Ricardo Barroso
>>
>>MULTICERT S.A.
>>www.multicert.com <http://www.multicert.com>
>>    
>>
>
>
>
>
>  
>


--------------020204030808080205070403
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
<tt>Thanks you Peter and Andrew!<br>
 <br>
 </tt><tt>Peter, I would like to suggest you&nbsp;</tt><tt>(if you haven't done
it already)</tt><tt> that you or <br>
 someone else of the IETF take a note about that ambiguous/doubtful point
<br>
 since I think it would be useful to clarify that doubt in a possible new
future <br>
draft/RFC (e.g. <a
 href="http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3161bis-00.txt">draft-ietf-pkix-rfc3161bis-00</a></tt><tt>).
<br>
Because with RFC 3161 it's possible that exist two compliant systems which
can't <br>
interoperate properly in some situations because one accepts that PKIFailueInfo
<br>
contains more than one bit with value one (1) and the other not!<br>
 <br>
 Best regards, <br>
 Ricardo Barroso<br>
 <br>
</tt><br>
Andrew Fan wrote:<br>
<blockquote type="cite" cite="[e-mail]">
  <pre wrap="">
Ricardo Barroso wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Hello!

RFC 3161 (TSP) says in 2.4.2:

"... When the TimeStampToken is not present, the failInfo indicates the
reason why the time-stamp request was rejected and may be one of the
following values.

PKIFailureInfo ::= BIT STRING {
badAlg (0),
-- unrecognized or unsupported Algorithm Identifier
badRequest (2),
-- transaction not permitted or supported
badDataFormat (5),
-- the data submitted has the wrong format
timeNotAvailable (14),
-- the TSA's time source is not available
unacceptedPolicy (15),
-- the requested TSA policy is not supported by the TSA
unacceptedExtension (16),
-- the requested extension is not supported by the TSA
addInfoNotAvailable (17)
-- the additional information requested could not be understood
-- or is not available
systemFailure (25)
-- the request cannot be handled due to system failure }

These are the only values of PKIFailureInfo that SHALL be supported.

Compliant servers SHOULD NOT produce any other values. Compliant
clients MUST generate an error if values it does not understand are
present. ...".

Since a BIT STRING can hold several bit values that can be either 1 or 0,
is it supposed that a BIT STRING representing a PKIFailureInfo MUST has
ONLY one bit (correspondent to one of the defined possible values) or can
a PKIFailuereInfo has more than one bit with value 1 wich means that it
can indicates more than one valid failure reasons?

    </pre>
  </blockquote>
  <pre wrap=""><!---->Indeed, from the Encoding technology of ASN.1, PKIFailureInfo must have
25 bits, if bit 0 set to 1, badAlg is one reason of this failure, and so on.

  </pre>
  <blockquote type="cite">
    <pre wrap="">Using another words, in:

"When the TimeStampToken is not present, the failInfo indicates the
reason why the time-stamp request was rejected and may be one of the
following values."

"may be one" doesn't implies that compliant servers can't generate
PKIFailusInfo's with more than one valid value, am I right?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
"may be one of the ..." will be more understandable.

  </pre>
  <blockquote type="cite">
    <pre wrap="">Thanks in advance,
Ricardo Barroso

MULTICERT S.A.
<a class="moz-txt-link-abbreviated" href="http://www.multicert.com">www.multicert.com</a> <a class="moz-txt-link-rfc2396E" href="http://www.multicert.com">&lt;http://www.multicert.com&gt;</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->



  </pre>
</blockquote>
<br>
</body>
</html>

--------------020204030808080205070403--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA69wqO16712 for ietf-pkix-bks; Wed, 6 Nov 2002 01:58:52 -0800 (PST)
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA69wmv16707 for <[e-mail]>; Wed, 6 Nov 2002 01:58:52 -0800 (PST)
Received: from sport-mail1.PRC.Sun.COM ([129.158.216.23]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA15564; Wed, 6 Nov 2002 01:58:42 -0800 (PST)
Received: from sun.com (triplejump [129.158.217.124]) by sport-mail1.PRC.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.1p1) with ESMTP id gA69wc913819; Wed, 6 Nov 2002 17:58:40 +0800 (CST)
Message-ID: <[e-mail]>
Date: Wed, 06 Nov 2002 18:01:16 +0800
From: Andrew Fan <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us, zh-cn
MIME-Version: 1.0
To: Ricardo Barroso <[e-mail]>
CC: IETF-PKIX <[e-mail]>
Subject: Re: [TSP/RFC3161] PKIFailureInfo values
References: <[e-mail]>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ricardo Barroso wrote:

> Hello!
>
> RFC 3161 (TSP) says in 2.4.2:
>
> "... When the TimeStampToken is not present, the failInfo indicates the
> reason why the time-stamp request was rejected and may be one of the
> following values.
>
> PKIFailureInfo ::= BIT STRING {
> badAlg (0),
> -- unrecognized or unsupported Algorithm Identifier
> badRequest (2),
> -- transaction not permitted or supported
> badDataFormat (5),
> -- the data submitted has the wrong format
> timeNotAvailable (14),
> -- the TSA's time source is not available
> unacceptedPolicy (15),
> -- the requested TSA policy is not supported by the TSA
> unacceptedExtension (16),
> -- the requested extension is not supported by the TSA
> addInfoNotAvailable (17)
> -- the additional information requested could not be understood
> -- or is not available
> systemFailure (25)
> -- the request cannot be handled due to system failure }
>
> These are the only values of PKIFailureInfo that SHALL be supported.
>
> Compliant servers SHOULD NOT produce any other values. Compliant
> clients MUST generate an error if values it does not understand are
> present. ...".
>
> Since a BIT STRING can hold several bit values that can be either 1 or 0,
> is it supposed that a BIT STRING representing a PKIFailureInfo MUST has
> ONLY one bit (correspondent to one of the defined possible values) or can
> a PKIFailuereInfo has more than one bit with value 1 wich means that it
> can indicates more than one valid failure reasons?
>
Indeed, from the Encoding technology of ASN.1, PKIFailureInfo must have
25 bits, if bit 0 set to 1, badAlg is one reason of this failure, and so on.

>
> Using another words, in:
>
> "When the TimeStampToken is not present, the failInfo indicates the
> reason why the time-stamp request was rejected and may be one of the
> following values."
>
> "may be one" doesn't implies that compliant servers can't generate
> PKIFailusInfo's with more than one valid value, am I right?

"may be one of the ..." will be more understandable.

>
> Thanks in advance,
> Ricardo Barroso
>
> MULTICERT S.A.
> www.multicert.com <http://www.multicert.com>





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA65pFD10691 for ietf-pkix-bks; Tue, 5 Nov 2002 21:51:15 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA65pDv10684 for <[e-mail]>; Tue, 5 Nov 2002 21:51:14 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gA65pCVw003711 for <[e-mail]>; Wed, 6 Nov 2002 18:51:12 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA80088 for [e-mail]; Wed, 6 Nov 2002 18:51:12 +1300 (NZDT) (sender [e-mail])
Date: Wed, 6 Nov 2002 18:51:12 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-ocspv2-ext-00.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Uhh, where on earth did this one come from?  The previous consensus on the
list seemed to be do produce a minimal update with some more workable IDs and
CRLDP info as suggested by Denis:

>To be more precise, I do not care about the expired OCSP v2 draft, but I
>care about fixing RFC 2560, while sticking to its original functionality:
>individual certificate revocation information status check.
>
>Having said that, we should correct the major problem that exists in
>RFC 2560, which is how the certificate can be defined.
>
>[...]
>
>I agree that, for defining an extension for handling a CRLDP extension

This thing is neither compatible with the previous OCSPv2, nor with what was
discussed on the list... this is more like 2560bis-bis.  It seems to be
contrary to everything that was discussed on the list.  I already have an
OCSPv2 draft done based on the previous discussion on the list, I was just
waiting a bit longer to make sure none of the original v2 authors would feel
slighted when I posted the new, minimal update to v1.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA65VNu08396 for ietf-pkix-bks; Tue, 5 Nov 2002 21:31:23 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA65VLv08387 for <[e-mail]>; Tue, 5 Nov 2002 21:31:21 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gA65VIVw003403; Wed, 6 Nov 2002 18:31:19 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA79979; Wed, 6 Nov 2002 18:31:13 +1300 (NZDT) (sender [e-mail])
Date: Wed, 6 Nov 2002 18:31:13 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  [TSP/RFC3161] PKIFailureInfo values
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ricardo Barroso <[e-mail]> writes:

>Since a BIT STRING can hold several bit values that can be either 1 or 0, is
>it supposed that a BIT STRING representing a PKIFailureInfo MUST has ONLY one
>bit (correspondent to one of the defined possible values) or can a
>PKIFailuereInfo has more than one bit with value 1 wich means that it can
>indicates more than one valid failure reasons?

I think this stuff was taken from RFC 2511... the assumption is that you can
return several values, the practice is that no-one ever does, so it ends up
acting as a clunky enum.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5N5V622462 for ietf-pkix-bks; Tue, 5 Nov 2002 15:05:31 -0800 (PST)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5N5Sv22454 for <[e-mail]>; Tue, 5 Nov 2002 15:05:29 -0800 (PST)
Received: from Santesson ([213.64.1.149]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Nov 2002 00:05:14 +0100
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Trevor Freeman" <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
Date: Wed, 6 Nov 2002 00:05:12 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Importance: Normal
X-OriginalArrivalTime: 05 Nov 2002 23:05:15.0015 (UTC) FILETIME=[CD085170:01C2851F]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

We are ready to make a change to accommodate multiple community logos (thus
keeping issuer and subject organization logos limited to 1 each).

The condition for this would be:

If multiple community logos are defined in a certificate, and if the client
is designed to display just 1 community logo (or less than the number of
logos included in the certificate), it will use the first logo in the
sequence as the most preferred one and the last logo in the sequence as the
least preferred one to be displayed.

It is though too late to issue a new ID before Atlanta.

Would this satisfy your needs?

/Stefan

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Monday, November 04, 2002 4:30 PM
> To: Trevor Freeman
> Cc: Housley, Russ; [e-mail]; Stefan Santesson
> Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
>
>
>
> Trevor and Stefan,
>
> > Denis,
>
> > There is a way to accomplish associating multiple community logos within
> > the existing draft. We permit the use of the logotype extension within
> > attribute certificates as well as identity certificates. It is therefore
> > possible to have an identity certificate, issued by Last National Bank
> > to merchant foo with a community of Visa, and an attribute certificate,
> > issued by Utah Credit Union to merchant foo with a community logo of
> > MasterCard. In this situation, the UI can legitimacy display a community
> > logotype for each valid certificate.
>
> This does not solve the issue: there is still one single
> community logo type
> in a given certificate (whether it is a PKC or an AC).
>
> The real issue is what do we call a "community".
>
> Extracts from the present draft:
>
> "The community may represent the subscribers of a service or any
> other group."
>
> "The community logotype - is the general mark for a community. It
> identifies
> a service concept for entity identification and certificate issuance."
>
> Well, the less that we can say is that this is not crystal clear !!! :-(
>
> Within that definition both the logo CB and the logo VISA have
> their places.
>
> CB is a logo used by some banks grouped under the GIE "Cartes
> Bancaire" and
> recognized by many French merchants.
>
> VISA is a logo used by VISA and recognized by many merchants worldwide.
> Both could be in a certificate.
>
> Extract from : http://www.cartes-bancaires.com/GB/Pages/FrameVie.htm
>
> A card bearing a "CB" logo is by definition an interbank card.
> One feature
> of the "CB" interbank system is that the card will be accepted
> even if the
> issuing bank is different from the merchant's bank or the bank
> managing the
> ATM.
>
> (...)
>
> In addition to the "CB" logo, "CB" cards can also have an international
> acceptance logo (Visa or MasterCard).
>
> Denis
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> > Trevor
> > -----Original Message-----
> > From: Stefan Santesson [mailto:[e-mail]]
> > Sent: Thursday, October 31, 2002 6:06 AM
> > To: Denis Pinkas
> > Cc: Housley, Russ; [e-mail]
> > Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
> >
> >
> > Denis,
> >
> > I think you are mixing concepts and to some extent misreading the
> > standard.
> >
> > I comment below;
> >
> >
> >>-----Original Message-----
> >>From: [e-mail]
> >>[mailto:[e-mail]]On Behalf Of Denis Pinkas
> >>Sent: Wednesday, October 30, 2002 2:47 PM
> >>To: Stefan Santesson
> >>Cc: Housley, Russ; [e-mail]
> >>Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
> >>
> >>
> >>
> >
> >
> > stuff deleted...
> >
> >
> >> > 1) We expand the concept beyond the intended scope
> >> > 2) We make it harder and more complex for the GUI implementers
> >>to make a
> >> > distinct application.
> >>
> >>What is the "intended scope" ? Until it is clearly defined, you cannot
> >
> > say
> >
> >>that this is contradictory. So there is no demonstration here.
> >
> >
> > Intentions and scopes are included in sections 1 and 2. The scope is
> > clearly
> > to allow issuers to claim that they issue a certificate as part of a
> > community. The value of having just 1 community is that it brings
> > clarity to
> > the concept. There are numerous of examples in real life of this
> > situation:
> >
> > 1) Gasoline stations. They may be independent enterprises but they are
> > sometimes members of A community (Shell, Esso etc)
> > 2) Shops.. same thing.
> > 3) Credit cards
> > 4) Airlines
> > ....
> > ....
> >
> > The common ground is that there is a point of issuing a service under
> > JUST 1
> > community. One big reason is that there generally is some kind of common
> > explicit or implicit liability or protection of brand involved. If one
> > service would be Both VISA AND MasterCard at the same time, or both
> > SHELL
> > AND ESSO or.... who would protect the brands, who would take
> > responsibility
> > for that ....
> >
> > To my knowledge that type of situation does not exist.
> >
> > All examples you state are not examples of multiple communities but
> > examples
> > of other aspects of reality.
> >
> > So a good thing with having just 1 community logotype proved by you
> > here.
> > That is that people can't abuse the standard and put any obscure
> > logotype as
> > 1 of 10 community logos, making the GUI makers insane :-)
> >
> >
> >>What is harder ? Display is always an option. We do not mandate
> >>what MUST be
> >>displayed.
> >
> >
> > For a GUI of this kind, especially if we want to create a visual
> > equivalent
> > of an ID-card on the screen (in a standard format), it helps
> > implementers to
> > know if they will handle 1 or none logo, or if they must be prepared to
> > handle any number of logos.
> >
> > As said above, if this is not limited, as GUI maker you MUST expect CA:s
> > to
> > put in a whole bunch of obscure logos here representing everything from
> > loyalty scheme, accreditation scheme, partners, sponsors...... you name
> > it.
> >
> > This is why the principle is good to say that the 3 main logotype types
> > can
> > only be 1 logo of each type.
> >
> > If you want to include more logos, you provide them as other logos,
> > according to section 4.2. This is a good structured way that provide
> > clear
> > expectations for the GUI makers.
> >
> >
> >> > Denis,
> >> >
> >> > We had this discussion in Yokohama and all examples you came
> >>up with had
> >> > to do with loyalty structures rather than communities. The
> >>community logo
> >> > represent THE community within which the issuer acts as issuer.
> >>
> >>Besides loyalty structures (BTW, where do you place them ?),
> >>there is as an
> >>example "t-scheme approved" or what ever other "scheme" in Asia or in
> >
> > the
> >
> >>US. Same question: where do you place that information ?
> >>
> >
> >
> > This is not a community. I don't issue certificate belonging to the
> > t-scheme
> > community. T-scheme, TTP-NL, Web trust or whatever are conformance
> > schemes
> > that has nothing to do with community. If you want to display any
> > logotype
> > related to this you must define a new "other logo" type in section 4.2.
> >
> > It could actually be a good idea to do that.
> >
> >
> >
> >> > Example - A credit card can never be both MasterCard and VISA at
> >
> > the
> >
> >> > same time. If it would, who would be responsible for it if
> >
> > something
> >
> >> > goes wrong???
> >>
> >>Some merchants are accepting credit cards from Visa, Eurocard, and
> >
> > AMEX.
> >
> >>How are you going to be able to include that information in a server
> >>certificate ?
> >
> >
> > You don't
> >
> > You may provide that information on the web page that is protected by
> > the
> > server certificate. But whatever you do, it is NOT part of the community
> > logo in the server certificate.
> >
> >
> >
> >>Some cards in my country have both the CB logo (CB = Carte
> >>Bancaire) and the
> >>Eurocard or VISA Logo.
> >>
> >>How are you going to be able to include that information in a person
> >>certificate issued by a bank ?
> >
> >
> > The standard allows 2 issuer logos for co-branding, 1:st the logo
> > representing the Issuer organization, 2:nd the logo representing the
> > community.
> >
> > I'm not sure what function the CB logo has. If this is not covered by
> > these
> > logos, you can use some of the defined other logos (section 4.2), or
> > define
> > one for the purpose.
> >
> >
> >> > If the community, within which the issuer operates when issuing a
> >> > particular certificate, has a combined logo from two integrated
> >> > community structures -
> >> > Fine - This is then still just 1 community logo from the standards
> >> > perspective.
> >>
> >>We never said that logos MUST be displayed. An application may look
> >
> > for a
> >
> >>given logo and chose to display it, if present. Combined logos would
> >
> > not
> >
> >>allow that feature and would be pretty big or unreadable since an
> >>application would need to display, e.g. four, logos in a small
> >>window size.
> >>
> >
> >
> > That's a feature, not a problem. This means that If the application
> > display
> > logo related to THE community, it can not screw up by showing just half
> > of
> > the relevant logo image data.
> >
> >
> >> > I agree though that you can have multiple independent loyalty
> >
> > schemes.
> >
> >>Fine. Where do you place them ?
> >
> >
> > Read section 4.2
> >
> > Stuff deleted ...
> >
> >
> >>Since a sentence is saying:
> >>
> >>     If a logotype is represented by more than one image file, then
> >
> > the
> >
> >>     image files MUST contain variants of the roughly the same image.
> >>
> >>My understanding is the following:
> >>
> >>image contains one or more variants of the roughly the same image. No
> >
> > more
> >
> >>that one of the LogotypeImage SHALL be displayed, since it is roughly
> >
> > the
> >
> >>same image.
> >>
> >>This does not permit to include images that are really different.
> >
> >
> > Yes you are right. That is the defined meaning.
> >
> >
> >>I am asking for:
> >>
> >>           communityLogo   [0] EXPLICIT SEQUENCE OF LogotypeInfo
> >
> > OPTIONAL,
> >
> >>instead of:
> >>
> >>           communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
> >>
> >>I hope that the above examples will be able to convince you.
> >
> >
> > I regret to say that I'm not.
> >
> > I still think it would make the standard worse
> >
> > What would convince me is if anyone could show a realistic and relevant
> > case
> > where there are 2 independent communities, within which the issuer acts
> > when
> > issuing a certificate. I have yet to see that case.
> >
> > /Stefan
> >
> >
> >
>
>
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5KINY14306 for ietf-pkix-bks; Tue, 5 Nov 2002 12:18:23 -0800 (PST)
Received: from smtp-1.llnl.gov (smtp-1.llnl.gov [128.115.250.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5KIMv14302 for <[e-mail]>; Tue, 5 Nov 2002 12:18:22 -0800 (PST)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-1.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id MAA15558; Tue, 5 Nov 2002 12:18:08 -0800 (PST)
Received: from [128.115.222.68] (HELO catalyst2b.llnl.gov) by poptop.llnl.gov (CommuniGate Pro SMTP 3.5.9) with ESMTP id 5190114; Tue, 05 Nov 2002 12:18:07 -0800
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 05 Nov 2002 12:21:18 -0800
To: Stephen Kent <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Biometric Data not in DOD Certificate [was; Re:   Certificate profile   for  Biometrics information.]
Cc: [e-mail]
In-Reply-To: <p05100302b9edd244d87c@[128.89.88.34]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p0510031cb9ecadb687a7@[128.89.88.34]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 02:54 PM 11/5/2002 -0500, Stephen Kent wrote:
>At 4:33 PM -0800 11/4/02, Tony Bartoletti wrote:
>>>Note that when we discussed inclusion of biometric data in a cert in the 
>>>Qualified Certificate RFC, we intentionally limited it to data for 
>>>verification by a human being, e.g., a photograph, not a fingerprint, 
>>>voiceprint, etc.
>>
>>Hmmm.  Well, most humans have a hard time reading voiceprints, and even 
>>fingerprints ... but I don't think machines will have a hard time reading 
>>photographs, certainly not for long.
>>
>>Cheers!  ____tony____
>
>Tony,
>
>The focus is on the complementary set, i.e., we wanted to reject 
>biometrics that only machines could process.
>
>Steve

Ok.  Got it.  That makes sense.

You want to ENABLE "human-in-the-loop" verification, as
opposed to DISABLE "no-human-in-the-loop" verification.

Cheers!  ____tony____



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5K46x12819 for ietf-pkix-bks; Tue, 5 Nov 2002 12:04:06 -0800 (PST)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5K45v12813 for <[e-mail]>; Tue, 5 Nov 2002 12:04:05 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02646; Tue, 5 Nov 2002 15:03:41 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100302b9edd244d87c@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p0510031cb9ecadb687a7@[128.89.88.34]> <[e-mail]> <[e-mail]>
Date: Tue, 5 Nov 2002 14:54:38 -0500
To: Tony Bartoletti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Biometric Data not in DOD Certificate [was; Re:   Certificate profile   for  Biometrics information.]
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 4:33 PM -0800 11/4/02, Tony Bartoletti wrote:
>>Note that when we discussed inclusion of biometric data in a cert 
>>in the Qualified Certificate RFC, we intentionally limited it to 
>>data for verification by a human being, e.g., a photograph, not a 
>>fingerprint, voiceprint, etc.
>
>Hmmm.  Well, most humans have a hard time reading voiceprints, and 
>even fingerprints ... but I don't think machines will have a hard 
>time reading photographs, certainly not for long.
>
>Cheers!  ____tony____

Tony,

The focus is on the complementary set, i.e., we wanted to reject 
biometrics that only machines could process.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5GhM200543 for ietf-pkix-bks; Tue, 5 Nov 2002 08:43:22 -0800 (PST)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA5GhKv00539 for <[e-mail]>; Tue, 5 Nov 2002 08:43:20 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 5 Nov 2002 16:43:21 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA03644 for <[e-mail]>; Tue, 5 Nov 2002 11:43:20 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id gA5GecN21785 for <[e-mail]>; Tue, 5 Nov 2002 11:40:38 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWJQJY>; Tue, 5 Nov 2002 11:43:18 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.23]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWJQJ4; Tue, 5 Nov 2002 11:43:09 -0500
From: "Housley, Russ" <[e-mail]>
To: Peter Gietz <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 05 Nov 2002 11:43:02 -0500
Subject: Re: new version of draft on additional x509 certificate schema for LDAP
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

The authors have clearly put in a lot of effort.  Thanks for your work on 
this important topic.

I have a few comments and questions.

1.  Section 2, 1st paragraph on page 5.  I am quite concerned about the 
duplication proposed.  If we take the proposed approach, there must be a 
transition period.  But the issues with duplication of the certificates 
(and CRLs) in multiple locations deserves more than a sentence.  Also, the 
discussion needs to include words like "consistency."

2.  The last paragraph of section 2 says:

    A CIP based indexing system for a wide scale distributed certificate
    repository will only be possible by using the solution proposed here.

This is a pretty strong statement.  Also, this is the first time that 
support for CIP has been raised as a requirement.  I am certainly not a CIP 
expert, and I hope that this discussion will not force me to become one, 
but I think that we need to understand why CIP is so important to LDAP 
server implementors.  Can you add a few sentences of rationale?

3.  I think that section 3 is trying to tell me that the proposed scheme is 
compatible with the long-term design, yet it is also implementable in the 
short-term.  We do not have to wait for the vision of the long term to be 
realized.  Did I get that right?

4.  Section 4.1.6 defines the attribute for subject name.  RFC 3280 allows 
the subject name in an end-entity certificate to be an empty sequence.  In 
this case, the subject alternative name must be present.  What should 
happen here?  Should the attribute be present with an empty name?  Does RFC 
2253 handle empty names?  I could not figure it out with a quick 
scan.  Also, section 4.4 indicates that x509subject must be present.

5.  Please rewrite the first sentence in section 4.1.7.  I propose:

    OID identifying the algorithm associated with the certified public key.

6.  The extended key usage extension contains a sequence of OIDs, which 
identify the key purposes.  If the sequence contains more than one OID, 
does this attribute get instantiated more than once?

7.  Given the limitations that are imposed on the CRL distribution point 
attribute in section 4.2.8, wouldn't it be better to include "FullCRL" in 
the attribute name?

8.  Please add descriptive text to section 4.3.1.  I think that this 
attribute would be placed in the directory entry associated with the 
certificate subject, not in the directory entry of the certificate.   Did I 
get that right?

9.  Section 5 requires a name form that uses a multi-valued RDN.  I believe 
that many LDAP implementations cannot handle this construct.  Perhaps there 
is an alternative.  Will the Issuer DN followed by the serial number 
work?  For example (building on an example in the document):

    SN=1234567,OU=VeriSign Trust Network,
    OU=(c) 1998 VeriSign\2c Inc. - For authorized use only,
    OU=Class 1 Public Primary Certification Authority - G2,
    O=VeriSign\2c Inc.,C=US

Next, I respond to some of the questions in your posting.

>- Can and should this draft be work of the pkix group and should the 
>discussion about it be held on this list instead of in private email 
>communications?

I think that this topic is very important to the PKIX WG.  I think it 
should be discussed on the PKIX WG list.

>- The draft does only describe fields described in RFC 3280. Should it 
>also deal with Qualified certificates (RFC 3039)?

I think it would be useful to search on some of the information that QCs 
store in subject directory attributes extension.

>- should revocation information be stored in a similiar fashion. And if so 
>how: 1.) Metadata attributes for CRLs or 2.) revocation relevant 
>attributes attached to the certificate entries.

Storage of CRLs is very important.  Presently, clients have the same issues 
with the multi-valued CRL attribute.  Storage in a separate entry 
subordinate to the CRL Issuer makes most sense to me.  One issue would be 
how long such entries need to remain on-line.  Another issue is the storage 
of delta CRLs.

>- should attribute certificates be stored in a similiar fashion?

Presently, clients have the same issues with the multi-valued attribute 
certificate attribute. If this solution is adopted for certificates, it 
should be adopted for attribute certificates and CRLs too.

Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5Eud924771 for ietf-pkix-bks; Tue, 5 Nov 2002 06:56:39 -0800 (PST)
Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5Euav24765 for <[e-mail]>; Tue, 5 Nov 2002 06:56:36 -0800 (PST)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18957v-0000cw-00; Tue, 05 Nov 2002 09:56:23 -0500
Message-ID: <[e-mail]>
Date: Tue, 05 Nov 2002 09:56:01 -0500
From: "Phillip H. Griffin" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Certificate profile for Biometrics information.
References: <[e-mail]> <[e-mail]> <p0510031eb9ecb0a938ee@[128.89.88.34]>
Content-Type: multipart/alternative; boundary="------------080109060603020509030600"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------080109060603020509030600
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Steve,

Stephen Kent wrote:

> Phil,
>
>>> For individuals and/or organizations that are concerned about privacy
>>> issues, one could consider support of an encryption option where 
>>> selected
>>> "trusted readers" could be enabled using specific session-key tokens,
>>> possibly included (under user or organization control) on the same
>>> smart-card that holds the certificate(s) with the biometrics 
>>> extension(s).
>>>  
>>
>> Privacy objects are already available in X9.84 and XCBF and rely on
>> the familiar EnvelopedData and EncryptedData, and a named variant of
>> EncryptedData. But biometric information is public, not private. It's 
>> in your
>> hair left on the brush in the hotel, in your prints left on the glass 
>> at dinner, and
>> by anyone who wishes to scan or photograph for the purpose of trying 
>> to mimic
>> another.
>
>
> i think there is some confusion here. My fingerprints and other 
> biometrics are not secrets, but many folks consider them to be 
> "private." The concern I coted is that anyone with access to a 
> plaintext template, and knowledge of the scoring algorithm used by a 
> vendor, could engage in analysis to try to construct a digital input 
> which would be accepted by the algorithm as a match for the template 
> in question. This, as Tony noted, represents a distinct form of attack 
> from the covert acquisition of physical biometric samples, and it is a 
> form of attack that is easy to effect from a distance, perhaps for 
> thousands of individuals whose templates might be disclosed. So, I do 
> think there is good cause to take precautions to prevent disclosure of 
> this data wherever it is stored, transmitted, etc.

A possibility of course, but I think that there are much easier attacks 
to launch.
And this one depends on being able to guess algorithm details and to be 
able to
spoof input samples into a matching system where the biometric data in the
templates may have been obscurred or encrypted. And it is an overall 
security
system, which may integrate biometrics along with other factors, that 
must be
attacked, and not simply the biometric.

In all US standards, a template contains two basic parts, header 
information
and biometric data. At the message level, the  later is treated as 
opaque, having
no specified structural details. In fact there are details, but these 
are generally held
private by vendors as are the details of their processing algorithms and 
matching
methods, which frequently incorporate safeguards against spoofing the 
inputs.

Depending on the vendor, and where and how the template is used, the 
biometric
data portion of a template may be encrypted or otherwise obscured. Over 
the past
several years, I've heard of the data being protected by everything from 
Triple
DES, to strong cryptography but I can't tell you what it is, to it's a 
proprietary
format that you'll never be able to guess.

Now this may sound bad at first blush. But there is a great range of 
products
to consider that can provide varying levels of security for protecting 
assets
with different values at different costs. At the low end, PKI and encryption
may be out of the question. At the high end, biometrics will likely be used
as part of a security solution along with other measures and factors. And
beyond the template format itself are the issues of just how inputs are
processed to create a template in the first place and how sample inputs
are processed or validated validated before a system attempts a match.

We'll eventually evolve I think to standards in all three of these 
areas. We've
only recently gotten to the point of defining common header formats. The 
data
format for some biometric types will come next I think, and algorithms and
matching methods last if this ever happens at all. Most likely is that 
specific
algorithms and methods will become identified (perhaps named with an OID).
The point of enrollment and the enrollment process is of course critical 
to control.
And you are correct that there is no standard way to tell that Fred may 
have
your fingerprints and my irises.

But how enrollment data is collected and processed to form a template, and
how samples are used to perform matches are points at which there are often
safeguards that must be used against spoofing the system, perhaps even the
encryption of some or all parts of the data. An example being the Afgan 
girl's
iris data being detected as coming from a photograph and not a valid 
iris scan
camera. This on top of the proprietary methods being used, environmental
controls and hardware.

In X9.84 and XCBF, when signature mechanisms are used for sample or
template protection, they must be used as part of an overall solution.These
standards support four basic mechanisms, SignedData, AuthenticatedData
and an ordinary digital signature like the one used to sign a 
certificate, and a
MAC (HMAC). A digital certificate then is really just another package for
biometric information, one that extends an ordinary signature to 
identify the
key of the signer and provide support for a hierarchy.

It's a tool then that can be used to create a security solution, not 
necessarily
an end in itself.

>
>
>> So rather than opt for creating a certificate extension payload from 
>> a value of
>> type BiometricSyntaxSets, I decided that the encoded value of a series of
>> biometric objects was probably enough. Some communities of course will
>> need privacy, but the general public will not. Authentication will 
>> likely do for
>
>> templates.
>
>
> I disagree with the suggestion that the general public will not demand 
> privacy for this data.

That's rational. But I think that fear and consumption will mitigate such
demands. People are willing to have a perfect stranger pat their thighs and
buttocks and run their hands inside the tops of their pants just to get 
on an
airplane. People are willing to be monitored by camera in parking decks
to feel more secure, and searched by machines and dogs to enter public
venues. People are willing to divulge their frequency of use and brand
preference of sanitary products just to get price discounts.

In most systems, I don't believe that privacy will be an issue for 
templates
at the message level. But here privacy will be needed for some communities
even for the header data. For example, knowing which version of vendor
product is being used or the age of a record of some biometric type may
assist an attacker.

I think that biometric samples, how they are treated when they are collected
and processed to form a template, what becomes of them after this process,
and how they are treated when they are collected to perform a match, will
become the dominant points of public concern. I wouldn't much mind your
having my photograph if I knew that no system would grant you access to
something I valued based on your having a copy. I wouldn't mind your
collecting my fingerprint to match against the template on my smart card
if I knew the sample were handled properly - not retained or shared with
others.

>> Biometric information seems destined to become the financial 
>> identifier that one
>> day replaces the social security number. There's much interest in 
>> using it to try
>> to combat identity fraud, said to be the fastest rising crime. On 
>> another front,
>> a DOD pilot is to use a biometric extension in a smart card certificate.
>
>
> I think this is a very questionable assertion. The SSN is an ID and a 
> convenient one. it is dangerous one in that people rely on it in the 
> absence of any secure means of verifying that the individual asserting 
> the SSN is the :owner" of that ID.  Biometric data is

SSNs can be reassigned, so they are not necessarily unique.

And I agree, and the point I tried to make above is that if
systems do not care who, what or where an input comes from,
then all bets are off.

> not an ID. It varies from sample to sample and thus is a poor 
> substitute for any form of static, globally unique ID. Also, as you 
> noted, templates are vendor-specific, which makes this for of ID not 
> useful for identifying the same individual in two contexts where 
> different biometric systems from different vendors have been employed.

Not unlike having the same keys being certified by different authorities.

>
>>
>> The BiometricObject in X9.84 and XCBF contains a 'hole' that can carry an
>> arbitrary payload relevant to an application. There are many things 
>> this might
>> be, the blinded hash of a customer PAN as used in SET for cardholder 
>> common
>> names, an encrypted smart identifier, etc. This type can also carry 
>> the biometric
>> processing algorithm and matching method needed by a relying party. 
>> And most
>> importantly, a set of these can carry multiple occurances of a 
>> biometric, say three
>> fingerprints, or sets of mutiple biometric types, say ten 
>> fingerprints and two iris
>
>> images.
>
>
> I don't think the representational flexibility you describe here 
> addresses the fundamental security and privacy issues being raised.

I believe that the capability of binding access to an account, to a 
specific token,
and to a means of identifying the particular individual authorized to 
use the token
and thereby to access the account, can be used to address security 
issues. If the
template is stored only on the token and not on a centralized data base, 
then there
are also privacy issues that might be addressed.

>
> Steve

I just got your call late yesterday. I'll try to reach you.

Phil


--------------080109060603020509030600
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Steve,<br>
<br>
Stephen Kent wrote:<br>
<blockquote type="cite"
 cite="midp0510031eb9ecb0a938ee@%5B128.89.88.34%5D"> 
  <style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style>
  <title>Re: Certificate profile for Biometrics information.</title>
 
  <div>Phil,</div>
 
  <div><br>
  </div>
 
  <blockquote type="cite" cite=""> 
    <blockquote type="cite" cite=""><tt>For individuals and/or organizations 
that are concerned about privacy<br>
 issues, one could consider support of an encryption option where selected<br>
 "trusted readers" could be enabled using specific session-key tokens,<br>
 possibly included (under user or organization control) on the same<br>
 smart-card that holds the certificate(s) with the biometrics extension(s).<br>
 &nbsp;</tt><br>
 </blockquote>
 </blockquote>
 
  <blockquote type="cite" cite="">Privacy objects are already available in 
X9.84 and XCBF and rely on<br>
 the familiar<font face="Courier New" size="-1"><b> EnvelopedData</b></font>
and<font face="Courier New" size="-1"><b> EncryptedData,</b></font> and a
named variant of<br>
 <font face="Courier New" size="-1"><b>EncryptedData</b></font>. But biometric
information is public, not private. It's in your<br>
 hair left on the brush in the hotel, in your prints left on the glass at
dinner, and<br>
 by anyone who wishes to scan or photograph for the purpose of trying to
mimic<br>
 another.</blockquote>
 
  <div><br>
  </div>
 
  <div>i think there is some confusion here. My fingerprints and other biometrics
are not secrets, but many folks consider them to be "private." The concern
I coted is that anyone with access to a plaintext template, and knowledge
of the scoring algorithm used by a vendor, could engage in analysis to try
to construct a digital input which would be accepted by the algorithm as
a match for the template in question. This, as Tony noted, represents a distinct
form of attack from the covert acquisition of physical biometric samples,
and it is a form of attack that is easy to effect from a distance, perhaps
for thousands of individuals whose templates might be disclosed. So, I do 
think there is good cause to take precautions to prevent disclosure of this
data wherever it is stored, transmitted, etc.</div>
</blockquote>
A possibility of course, but I think that there are much easier attacks to
launch.<br>
And this one depends on being able to guess algorithm details and to be able
to<br>
spoof input samples into a matching system where the biometric data in the
<br>
templates may have been obscurred or encrypted. And it is an overall security<br>
system, which may integrate biometrics along with other factors, that must
be <br>
attacked, and not simply the biometric.<br>
<br>
In all US standards, a template contains two basic parts, header information
<br>
and biometric data. At the message level, the&nbsp; later is treated as opaque,
having <br>
no specified structural details. In fact there are details, but these are
generally held<br>
private by vendors as are the details of their processing algorithms and
matching <br>
methods, which frequently incorporate safeguards against spoofing the inputs.
<br>
<br>
Depending on the vendor, and where and how the template is used, the biometric<br>
data portion of a template may be encrypted or otherwise obscured. Over the
past<br>
several years, I've heard of the data being protected by everything from
Triple<br>
DES, to strong cryptography but I can't tell you what it is, to it's a proprietary<br>
format that you'll never be able to guess. <br>
<br>
Now this may sound bad at first blush. But there is a great range of products
<br>
to consider that can provide varying levels of security for protecting assets
<br>
with different values at different costs. At the low end, PKI and encryption<br>
may be out of the question. At the high end, biometrics will likely be used<br>
as part of a security solution along with other measures and factors. And<br>
beyond the template format itself are the issues of just how inputs are <br>
processed to create a template in the first place and how sample inputs <br>
are processed or validated validated before a system attempts a match.<br>
<br>
We'll eventually evolve I think to standards in all three of these areas.
We've<br>
only recently gotten to the point of defining common header formats. The
data<br>
format for some biometric types will come next I think, and algorithms and<br>
matching methods last if this ever happens at all. Most likely is that specific<br>
algorithms and methods will become identified (perhaps named with an OID).<br>
The point of enrollment and the enrollment process is of course critical
to control.<br>
And you are correct that there is no standard way to tell that Fred may have
<br>
your fingerprints and my irises.<br>
<br>
But how enrollment data is collected and processed to form a template, and<br>
how samples are used to perform matches are points at which there are often<br>
safeguards that must be used against spoofing the system, perhaps even the<br>
encryption of some or all parts of the data. An example being the Afgan girl's
<br>
iris data being detected as coming from a photograph and not a valid iris
scan<br>
camera.  This on top of the proprietary methods being used, environmental
<br>
controls and hardware. <br>
<br>
In X9.84 and XCBF, when signature mechanisms are used for sample or <br>
template protection, they must be used as part of an overall solution.These<br>
standards support four basic mechanisms, SignedData, AuthenticatedData<br>
and an ordinary digital signature like the one used to sign a certificate,
and a<br>
MAC (HMAC). A digital certificate then is really just another package for
<br>
biometric information, one that extends an ordinary signature to identify
the<br>
key of the signer and provide support for a hierarchy.<br>
<br>
It's a tool then that can be used to create a security solution, not necessarily
<br>
an end in itself. <br>
<blockquote type="cite"
 cite="midp0510031eb9ecb0a938ee@%5B128.89.88.34%5D">
  <div><br>
 <br>
 </div>
 
  <blockquote type="cite" cite="">So rather than opt for creating a certificate
extension payload from a value of<br>
 type<font face="Courier New" size="-1"><b> BiometricSyntaxSets,</b></font>
I decided that the encoded value of a series of<br>
 biometric objects was probably enough. Some communities of course will<br>
 need privacy, but the general public will not. Authentication will likely
do for</blockquote>
 
  <blockquote type="cite" cite="">templates.</blockquote>
 
  <div><br>
  </div>
 
  <div>I disagree with the suggestion that the general public will not demand
privacy for this data.</div>
</blockquote>
That's rational. But I think that fear and consumption will mitigate such
<br>
demands. People are willing to have a perfect stranger pat their thighs and<br>
buttocks and run their hands inside the tops of their pants just to get on
an<br>
airplane. People are willing to be monitored by camera in parking decks <br>
to feel more secure, and searched by machines and dogs to enter public <br>
venues. People are willing to divulge their frequency of use and brand<br>
preference of sanitary products just to get price discounts.<br>
<br>
In most systems, I don't believe that privacy will be an issue for templates
<br>
at the message level. But here privacy will be needed for some communities
<br>
even for the header data. For example, knowing which version of vendor<br>
product is being used or the age of a record of some biometric type may<br>
assist an attacker. <br>
<br>
I think that biometric samples, how they are treated when they are collected<br>
and processed to form a template, what becomes of them after this process,<br>
and how they are treated when they are collected to perform a match, will
<br>
become the dominant points of public concern. I wouldn't much mind your<br>
having my photograph if I knew that no system would grant you access to<br>
something I valued based on your having a copy. I wouldn't mind your <br>
collecting my fingerprint to match against the template on my smart card<br>
if I knew the sample were handled properly - not retained or shared with<br>
others.<br>
<br>
<blockquote type="cite"
 cite="midp0510031eb9ecb0a938ee@%5B128.89.88.34%5D">  
  <blockquote type="cite" cite="">Biometric information seems destined to 
become the financial identifier that one<br>
 day replaces the social security number. There's much interest in using
it to try<br>
 to combat identity fraud, said to be the fastest rising crime. On another
front,<br>
 a DOD pilot is to use a biometric extension in a smart card certificate.</blockquote>
 
  <div><br>
  </div>
 
  <div>I think this is a very questionable assertion. The SSN is an ID and
a convenient one. it is dangerous one in that people rely on it in the absence
of any secure means of verifying that the individual asserting the SSN is
the :owner" of that ID.&nbsp; Biometric data is </div>
</blockquote>
SSNs can be reassigned, so they are not necessarily unique.<br>
<br>
And I agree, and the point I tried to make above is that if<br>
systems do not care who, what or where an input comes from, <br>
then all bets are off. <br>
<blockquote type="cite"
 cite="midp0510031eb9ecb0a938ee@%5B128.89.88.34%5D">
  <div>not an ID. It varies from sample to sample and thus is a poor substitute
for any form of static, globally unique ID. Also, as you noted, templates
are vendor-specific, which makes this for of ID not useful for identifying
the same individual in two contexts where different biometric systems from
different vendors have been employed.</div>
 </blockquote>
Not unlike having the same keys being certified by different authorities.<br>
<blockquote type="cite"
 cite="midp0510031eb9ecb0a938ee@%5B128.89.88.34%5D">
  <div><br>
  </div>
 
  <blockquote type="cite" cite=""><br>
 The<font face="Courier New" size="-1"><b> BiometricObject</b></font> in
X9.84 and XCBF contains a 'hole' that can carry an<br>
 arbitrary payload relevant to an application. There are many things this
might<br>
 be, the blinded hash of a customer PAN as used in SET for cardholder common<br>
 names, an encrypted smart identifier, etc. This type can also carry the
biometric<br>
 processing algorithm and matching method needed by a relying party. And
most<br>
 importantly, a set of these can carry multiple occurances of a biometric,
say three<br>
 fingerprints, or sets of mutiple biometric types, say ten fingerprints and
two iris</blockquote>
 
  <blockquote type="cite" cite="">images.<br>
 </blockquote>
 
  <div><br>
  </div>
 
  <div>I don't think the representational flexibility you describe here addresses
the fundamental security and privacy issues being raised.</div>
 </blockquote>
I believe that the capability of binding access to an account, to a specific
token,<br>
and to a means of identifying the particular individual authorized to use
the token<br>
and thereby to access the account, can be used to address security issues.
If the <br>
template is stored only on the token and not on a centralized data base,
then there<br>
are also privacy issues that might be addressed.<br>
<br>
<blockquote type="cite"
 cite="midp0510031eb9ecb0a938ee@%5B128.89.88.34%5D">
  <div><br>
  </div>
 
  <div>Steve</div>
 </blockquote>
I just got your call late yesterday. I'll try to reach you.<br>
<br>
Phil<br>
<br>
</body>
</html>

--------------080109060603020509030600--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5Ehfl24369 for ietf-pkix-bks; Tue, 5 Nov 2002 06:43:41 -0800 (PST)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5Ehdv24365 for <[e-mail]>; Tue, 5 Nov 2002 06:43:40 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25869; Tue, 5 Nov 2002 09:43:36 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100300b9ed88ed9d50@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 5 Nov 2002 09:41:49 -0500
To: Andrew Fan <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: What about SPKI
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>?
>What about SPKI WG? Why now they are inactive?

The WG terminated because there was little or no support from the 
broad IETF community for that style of PKI technology, especially 
vendors involved in PKI products or services.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5ER9e22141 for ietf-pkix-bks; Tue, 5 Nov 2002 06:27:09 -0800 (PST)
Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA5ER7v22131 for <[e-mail]>; Tue, 5 Nov 2002 06:27:08 -0800 (PST)
Received: (qmail 30700 invoked from network); 5 Nov 2002 14:17:26 -0000
Received: from unknown (HELO multicert.com) (62.48.185.5) by mail0.sibs.pt with SMTP; 5 Nov 2002 14:17:26 -0000
Message-ID: <[e-mail]>
Date: Tue, 05 Nov 2002 14:25:01 +0000
From: Ricardo Barroso <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF-PKIX <[e-mail]>
Subject: [TSP/RFC3161] PKIFailureInfo values
Content-Type: multipart/alternative; boundary="------------030301010805080202070003"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------030301010805080202070003
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello!

RFC 3161 (TSP) says in 2.4.2:

   "... When the TimeStampToken is not present, the failInfo indicates the
   reason why the time-stamp request was rejected and may be one of the
   following values.

PKIFailureInfo ::= BIT STRING {
   badAlg               (0),
     -- unrecognized or unsupported Algorithm Identifier
   badRequest           (2),
     -- transaction not permitted or supported
   badDataFormat        (5),
     -- the data submitted has the wrong format
   timeNotAvailable    (14),
     -- the TSA's time source is not available
   unacceptedPolicy    (15),
     -- the requested TSA policy is not supported by the TSA
   unacceptedExtension (16),
     -- the requested extension is not supported by the TSA
    addInfoNotAvailable (17)
      -- the additional information requested could not be understood
      -- or is not available
    systemFailure       (25)
      -- the request cannot be handled due to system failure  }

   These are the only values of PKIFailureInfo that SHALL be supported.

   Compliant servers SHOULD NOT produce any other values. Compliant
   clients MUST generate an error if values it does not understand are
   present. ...".

Since a BIT STRING can hold several bit values that can be either 1 or 0,
is it supposed that a BIT STRING representing a PKIFailureInfo MUST has
ONLY one bit (correspondent to one of the defined possible values) or can
a PKIFailuereInfo has more than one bit with value 1 wich means that it
can indicates more than one valid failure reasons?


Using another words, in:

   "When the TimeStampToken is not present, the failInfo indicates the
   reason why the time-stamp request was rejected and *may be one* of the
   following values."

"may be one" doesn't implies that compliant servers can't generate
PKIFailusInfo's with more than one valid value, am I right?

Thanks in advance,
Ricardo Barroso

MULTICERT S.A.
www.multicert.com <http://www.multicert.com>

--------------030301010805080202070003
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
<tt>Hello!<br>
<br>
RFC 3161 (TSP) says in 2.4.2: <br>
<br>
&nbsp;&nbsp; "... When the TimeStampToken is not present, the failInfo indicates the<br>
&nbsp;&nbsp; reason why the time-stamp request was rejected and may be one of the<br>
&nbsp;&nbsp; following values.<br>
<br>
PKIFailureInfo ::= BIT STRING {<br>
&nbsp;&nbsp; badAlg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (0),<br>
&nbsp;&nbsp;&nbsp;&nbsp; -- unrecognized or unsupported Algorithm Identifier<br>
&nbsp;&nbsp; badRequest&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (2),<br>
&nbsp;&nbsp;&nbsp;&nbsp; -- transaction not permitted or supported<br>
&nbsp;&nbsp; badDataFormat&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (5),<br>
&nbsp;&nbsp;&nbsp;&nbsp; -- the data submitted has the wrong format<br>
&nbsp;&nbsp; timeNotAvailable&nbsp;&nbsp;&nbsp; (14),<br>
&nbsp;&nbsp;&nbsp;&nbsp; -- the TSA's time source is not available<br>
&nbsp;&nbsp; unacceptedPolicy&nbsp;&nbsp;&nbsp; (15),<br>
&nbsp;&nbsp;&nbsp;&nbsp; -- the requested TSA policy is not supported by the TSA<br>
&nbsp;&nbsp; unacceptedExtension (16),<br>
&nbsp;&nbsp;&nbsp;&nbsp; -- the requested extension is not supported by the TSA<br>
&nbsp;&nbsp;&nbsp; addInfoNotAvailable (17)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- the additional information requested could not be understood<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- or is not available<br>
&nbsp;&nbsp;&nbsp; systemFailure&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (25)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- the request cannot be handled due to system failure&nbsp; }<br>
<br>
&nbsp;&nbsp; These are the only values of PKIFailureInfo that SHALL be supported.<br>
<br>
&nbsp;&nbsp; Compliant servers SHOULD NOT produce any other values. Compliant<br>
&nbsp;&nbsp; clients MUST generate an error if values it does not understand are<br>
&nbsp;&nbsp; present. ...".<br>
<br>
Since a BIT STRING can hold several bit values that can be either 1 or 0,
<br>
is it supposed that a BIT STRING representing a PKIFailureInfo MUST has <br>
ONLY one bit (correspondent to one of the defined possible values) or can
<br>
a PKIFailuereInfo has more than one bit with value 1 wich means that it <br>
can indicates more than one valid failure reasons?<br>
<br>
<br>
Using another words, in:<br>
<br>
</tt><tt>&nbsp;&nbsp; "When the TimeStampToken is not present, the failInfo indicates
the<br>
 &nbsp;&nbsp; reason why the time-stamp request was rejected and <b>may be one</b>
of the<br>
 &nbsp;&nbsp; following values."<br>
<br>
"may be one" doesn't implies that compliant servers can't generate <br>
PKIFailusInfo's with more than one valid value, am I right?<br>
<br>
Thanks in advance,<br>
Ricardo Barroso<br>
<br>
MULTICERT S.A. <br>
<a href="http://www.multicert.com">www.multicert.com</a></tt><br>
</body>
</html>

--------------030301010805080202070003--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5DC6814877 for ietf-pkix-bks; Tue, 5 Nov 2002 05:12:06 -0800 (PST)
Received: from isis.directory.dfn.de (isis.directory.dfn.de [134.2.217.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5DBxv14862 for <[e-mail]>; Tue, 5 Nov 2002 05:12:04 -0800 (PST)
Received: from clara.directory.dfn.de (clara.directory.dfn.de [134.2.217.66]) by isis.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id gA5DBsE00826 for <[e-mail]>; Tue, 5 Nov 2002 14:11:54 +0100
Received: from daasi.de (mercury.directory.dfn.de [134.2.217.50]) by clara.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id gA5DBr730808 for <[e-mail]>; Tue, 5 Nov 2002 14:11:53 +0100
Message-ID: <[e-mail]>
Date: Tue, 05 Nov 2002 14:11:52 +0100
From: Peter Gietz <[e-mail]>
Organization: DAASI International GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: de-de, en-us, en
MIME-Version: 1.0
To: Ietf-Pkix <[e-mail]>
Subject: new version of draft on additional x509 certificate schema for LDAP
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gA5DC5v14873
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello all,

There is a new version of  "An LDAPv3 Schema for X.509 certificates", 
which I sent to the Internet Drafts Editor.

You can find the document at 
http://www.directory.dfn.de/docs/draft-klasen-ldap-x509certificate-schema-01.txt

The changes to version 00 are noted in Apendix C.
You might remember my short presentation of the initial version at the 
pkix meeting at IETF 53.

There are still some questions to handel:

- Is it possible to get a short time-slot at thje Atlanta meeting for 
presenting the changes of this new version?

- Can and should this draft be work of the pkix group and should the 
discussion about it be held on this list instead of in private email
 communications?
- The draft introduces new naming attributes that should be included 
into David's Draft "LDAPv3 DN strings for use with PKIs"
  <draft-ietf-pkix-dnstrings-00.txt>. Besides x509issuer and 
x509serialNumber the allready widely used attribute emailaddress (email)
  should be taken into account.
- The draft does not yet address the problem that there are "LDAPish" 
implementations that are not able to support multi-valueelds RDNs
 (e.g.  x509serialNumber=1234+x509issuer=<dn of a CA>).
  Shall this be addressed by including a third name form with yet 
another naming attribute x509issuerSerial?
- The draft does only describe fields described in RFC 3280. Should it 
also deal with Qualified certificates (RFC 3039)?
- Should it also take into account things like userGroupName 
(draft-ietf-pkix-usergroup-01)
- Should it also take into account things like Permanent Identifier 
(draft-ietf-pkix-pi-05.txt and draft-chadwick-pkix-pidn-00.txt)?

I wanted to get some feedback on these questions before including 
respective language into the draft.

Two more questions:

- should revocation information be stored in a similiar fashion. And if 
so how: 1.) Metadata attributes for CRLs or 2.) revocation relevant 
attributes attached to the certificate entries.
- should attribute certificates be stored in a similiar fashion?


I would love to receive comments on all this from this group.

Cheers,

Peter


-- 
_______________________________________________________________________
 
Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]  
D-72074 Tübingen                        email: [e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA5BDLe07104 for ietf-pkix-bks; Tue, 5 Nov 2002 03:13:21 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA5BDKv07098 for <[e-mail]>; Tue, 5 Nov 2002 03:13:20 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11241; Tue, 5 Nov 2002 06:10:51 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ocspv2-ext-00.txt
Date: Tue, 05 Nov 2002 06:10:51 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: X.509 Internet Public Key Infrastructure
                          Online Certificate Status Protocol, version 2
	Author(s)	: M. Myers, A. Malpani, D. Pinkas
	Filename	: draft-ietf-pkix-ocspv2-ext-00.txt
	Pages		: 30
	Date		: 2002-11-4
	
The Online Certificate Status Protocol (OCSP) enables applications to
determine on line the revocation status of a certificate. This 
document specifies one extension for the OCSP protocol and defines 
a version v2 for that protocol which allows additional means to 
designate the certificate for which the revocation status is 
requested. It also allows to ask for the revocation status of either 
a public key certificate (PKC) or an attribute certificate (AC).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocspv2-ext-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ocspv2-ext-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ocspv2-ext-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ocspv2-ext-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ocspv2-ext-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA53RTg15731 for ietf-pkix-bks; Mon, 4 Nov 2002 19:27:29 -0800 (PST)
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA53RSv15726 for <[e-mail]>; Mon, 4 Nov 2002 19:27:28 -0800 (PST)
Received: from sport-mail1.PRC.Sun.COM ([129.158.216.23]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA23774 for <[e-mail]>; Mon, 4 Nov 2002 19:27:26 -0800 (PST)
Received: from sun.com (triplejump [129.158.217.124]) by sport-mail1.PRC.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.1p1) with ESMTP id gA53RP900448 for <[e-mail]>; Tue, 5 Nov 2002 11:27:25 +0800 (CST)
Message-ID: <[e-mail]>
Date: Tue, 05 Nov 2002 11:30:02 +0800
From: Andrew Fan <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us, zh-cn
MIME-Version: 1.0
To: [e-mail]
Subject: What about SPKI
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

What about SPKI WG? Why now they are inactive?



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4NdtF03901 for ietf-pkix-bks; Mon, 4 Nov 2002 15:39:55 -0800 (PST)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4Ndsv03894 for <[e-mail]>; Mon, 4 Nov 2002 15:39:54 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20097; Mon, 4 Nov 2002 18:40:09 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510031eb9ecb0a938ee@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Mon, 4 Nov 2002 18:36:33 -0500
To: "Phillip H. Griffin" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate profile for Biometrics information.
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-1175669224==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1175669224==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Phil,

>>For individuals and/or organizations that are concerned about privacy
>>issues, one could consider support of an encryption option where selected
>>"trusted readers" could be enabled using specific session-key tokens,
>>possibly included (under user or organization control) on the same
>>smart-card that holds the certificate(s) with the biometrics extension(s).
>>
>>
>Privacy objects are already available in X9.84 and XCBF and rely on
>the familiar EnvelopedData and EncryptedData, and a named variant of
>EncryptedData. But biometric information is public, not private. It's in your
>hair left on the brush in the hotel, in your prints left on the 
>glass at dinner, and
>by anyone who wishes to scan or photograph for the purpose of trying to mimic
>another.

i think there is some confusion here. My fingerprints and other 
biometrics are not secrets, but many folks consider them to be 
"private." The concern I coted is that anyone with access to a 
plaintext template, and knowledge of the scoring algorithm used by a 
vendor, could engage in analysis to try to construct a digital input 
which would be accepted by the algorithm as a match for the template 
in question. This, as Tony noted, represents a distinct form of 
attack from the covert acquisition of physical biometric samples, and 
it is a form of attack that is easy to effect from a distance, 
perhaps for thousands of individuals whose templates might be 
disclosed. So, I do think there is good cause to take precautions to 
prevent disclosure of this data wherever it is stored, transmitted, 
etc.


>So rather than opt for creating a certificate extension payload from 
>a value of
>type BiometricSyntaxSets, I decided that the encoded value of a series of
>biometric objects was probably enough. Some communities of course will
>need privacy, but the general public will not. Authentication will 
>likely do for
>templates.

I disagree with the suggestion that the general public will not 
demand privacy for this data.

>Biometric information seems destined to become the financial 
>identifier that one
>day replaces the social security number. There's much interest in 
>using it to try
>to combat identity fraud, said to be the fastest rising crime. On 
>another front,
>a DOD pilot is to use a biometric extension in a smart card certificate.

I think this is a very questionable assertion. The SSN is an ID and a 
convenient one. it is dangerous one in that people rely on it in the 
absence of any secure means of verifying that the individual 
asserting the SSN is the :owner" of that ID.  Biometric data is not 
an ID. It varies from sample to sample and thus is a poor substitute 
for any form of static, globally unique ID. Also, as you noted, 
templates are vendor-specific, which makes this for of ID not useful 
for identifying the same individual in two contexts where different 
biometric systems from different vendors have been employed.

>
>The BiometricObject in X9.84 and XCBF contains a 'hole' that can carry an
>arbitrary payload relevant to an application. There are many things this might
>be, the blinded hash of a customer PAN as used in SET for cardholder common
>names, an encrypted smart identifier, etc. This type can also carry 
>the biometric
>processing algorithm and matching method needed by a relying party. And most
>importantly, a set of these can carry multiple occurances of a 
>biometric, say three
>fingerprints, or sets of mutiple biometric types, say ten 
>fingerprints and two iris
>images.
>

I don't think the representational flexibility you describe here 
addresses the fundamental security and privacy issues being raised.

Steve
--============_-1175669224==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: Certificate profile for Biometrics
information.</title></head><body>
<div>Phil,</div>
<div><br></div>
<blockquote type="cite" cite>
<blockquote type="cite" cite><tt>For individuals and/or organizations
that are concerned about privacy<br>
issues, one could consider support of an encryption option where
selected<br>
&quot;trusted readers&quot; could be enabled using specific
session-key tokens,<br>
possibly included (under user or organization control) on the same<br>
smart-card that holds the certificate(s) with the biometrics
extension(s).<br>
&nbsp;</tt><br>
</blockquote>
</blockquote>
<blockquote type="cite" cite>Privacy objects are already available in
X9.84 and XCBF and rely on<br>
the familiar<font face="Courier New" size="-1"><b>
EnvelopedData</b></font> and<font face="Courier New" size="-1"><b>
EncryptedData,</b></font> and a named variant of<br>
<font face="Courier New" size="-1"><b>EncryptedData</b></font>. But
biometric information is public, not private. It's in your<br>
hair left on the brush in the hotel, in your prints left on the glass
at dinner, and<br>
by anyone who wishes to scan or photograph for the purpose of trying
to mimic<br>
another.</blockquote>
<div><br></div>
<div>i think there is some confusion here. My fingerprints and other
biometrics are not secrets, but many folks consider them to be
&quot;private.&quot; The concern I coted is that anyone with access to
a plaintext template, and knowledge of the scoring algorithm used by a
vendor, could engage in analysis to try to construct a digital input
which would be accepted by the algorithm as a match for the template
in question. This, as Tony noted, represents a distinct form of attack
from the covert acquisition of physical biometric samples, and it is a
form of attack that is easy to effect from a distance, perhaps for
thousands of individuals whose templates might be disclosed. So, I do
think there is good cause to take precautions to prevent disclosure of
this data wherever it is stored, transmitted, etc.</div>
<div><br>
<br>
</div>
<blockquote type="cite" cite>So rather than opt for creating a
certificate extension payload from a value of<br>
type<font face="Courier New" size="-1"><b>
BiometricSyntaxSets,</b></font> I decided that the encoded value of a
series of<br>
biometric objects was probably enough. Some communities of course
will<br>
need privacy, but the general public will not. Authentication will
likely do for</blockquote>
<blockquote type="cite" cite>templates.</blockquote>
<div><br></div>
<div>I disagree with the suggestion that the general public will not
demand privacy for this data.</div>
<div><br></div>
<blockquote type="cite" cite>Biometric information seems destined to
become the financial identifier that one<br>
day replaces the social security number. There's much interest in
using it to try<br>
to combat identity fraud, said to be the fastest rising crime. On
another front,<br>
a DOD pilot is to use a biometric extension in a smart card
certificate.</blockquote>
<div><br></div>
<div>I think this is a very questionable assertion. The SSN is an ID
and a convenient one. it is dangerous one in that people rely on it in
the absence of any secure means of verifying that the individual
asserting the SSN is the :owner&quot; of that ID.&nbsp; Biometric data
is not an ID. It varies from sample to sample and thus is a poor
substitute for any form of static, globally unique ID. Also, as you
noted, templates are vendor-specific, which makes this for of ID not
useful for identifying the same individual in two contexts where
different biometric systems from different vendors have been
employed.</div>
<div><br></div>
<blockquote type="cite" cite><br>
The<font face="Courier New" size="-1"><b> BiometricObject</b></font>
in X9.84 and XCBF contains a 'hole' that can carry an<br>
arbitrary payload relevant to an application. There are many things
this might<br>
be, the blinded hash of a customer PAN as used in SET for cardholder
common<br>
names, an encrypted smart identifier, etc. This type can also carry
the biometric<br>
processing algorithm and matching method needed by a relying party.
And most<br>
importantly, a set of these can carry multiple occurances of a
biometric, say three<br>
fingerprints, or sets of mutiple biometric types, say ten fingerprints
and two iris</blockquote>
<blockquote type="cite" cite>images.<br>
</blockquote>
<div><br></div>
<div>I don't think the representational flexibility you describe here
addresses the fundamental security and privacy issues being
raised.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1175669224==_ma============--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA519UB10311 for ietf-pkix-bks; Mon, 4 Nov 2002 17:09:30 -0800 (PST)
Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA519Tv10307 for <[e-mail]>; Mon, 4 Nov 2002 17:09:29 -0800 (PST)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 188sDY-0000LH-00; Mon, 04 Nov 2002 20:09:20 -0500
Message-ID: <[e-mail]>
Date: Mon, 04 Nov 2002 20:08:57 -0500
From: "Phillip H. Griffin" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Biometric Data not in DOD Certificate [was; Re:  Certificate profile   for  Biometrics information.]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p0510031cb9ecadb687a7@[128.89.88.34]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Too late. Technology already available.
http://www.webdesk.com/afghan-girl/
Phil


Tony Bartoletti wrote:

>
>> Note that when we discussed inclusion of biometric data in a cert in 
>> the Qualified Certificate RFC, we intentionally limited it to data 
>> for verification by a human being, e.g., a photograph, not a 
>> fingerprint, voiceprint, etc.
>
>
> Hmmm.  Well, most humans have a hard time reading voiceprints, and 
> even fingerprints ... but I don't think machines will have a hard time 
> reading photographs, certainly not for long.
>
> Cheers!  ____tony____
>
>




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA50UMa09537 for ietf-pkix-bks; Mon, 4 Nov 2002 16:30:22 -0800 (PST)
Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA50ULv09533 for <[e-mail]>; Mon, 4 Nov 2002 16:30:21 -0800 (PST)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id QAA29912; Mon, 4 Nov 2002 16:29:55 -0800 (PST)
Received: from [128.115.222.68] (HELO catalyst2b.llnl.gov) by poptop.llnl.gov (CommuniGate Pro SMTP 3.5.9) with ESMTP id 5111765; Mon, 04 Nov 2002 16:29:55 -0800
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 04 Nov 2002 16:33:08 -0800
To: Stephen Kent <[e-mail]>, "Phillip H. Griffin" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Biometric Data not in DOD Certificate [was; Re: Certificate profile   for  Biometrics information.]
Cc: [e-mail]
In-Reply-To: <p05100322b9ecb6bba601@[128.89.88.34]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p0510031cb9ecadb687a7@[128.89.88.34]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Note that when we discussed inclusion of biometric data in a cert in the 
>Qualified Certificate RFC, we intentionally limited it to data for 
>verification by a human being, e.g., a photograph, not a fingerprint, 
>voiceprint, etc.

Hmmm.  Well, most humans have a hard time reading voiceprints, and even 
fingerprints ... but I don't think machines will have a hard time reading 
photographs, certainly not for long.

Cheers!  ____tony____



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4Nqr705404 for ietf-pkix-bks; Mon, 4 Nov 2002 15:52:53 -0800 (PST)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4Nqqv05397 for <[e-mail]>; Mon, 4 Nov 2002 15:52:52 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25985; Mon, 4 Nov 2002 18:53:07 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100322b9ecb6bba601@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p0510031cb9ecadb687a7@[128.89.88.34]> <[e-mail]>
Date: Mon, 4 Nov 2002 18:54:06 -0500
To: "Phillip H. Griffin" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Biometric Data not in DOD Certificate [was; Re: Certificate profile   for  Biometrics information.]
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Phil,

>I don't think so. I got the idea that it was an on card matching situation
>and that it was X.509 certificates, not attribute certificates to be used.
>But I'm not involved in the work.

I am an advisor to the Executive Director for the DoD PKI and earlier 
this completed an analysis of most aspects of this PKI, the one that 
uses the CAC. I can speak with considerable confidence that this is 
NOT how it is used today.

I am willing to believe that someone who wants to promote the use of 
biometrics might be running some pilot somewhere in which this sort 
of thing is done, storing a template on a card for use in local 
verification, but it is almost certain that the template is not part 
of any cert. The cards have a facility to store data for private 
(i.e., local) application uses such as stored value systems. one 
could store a template in this fashion, using the controls offered by 
the Java applets for managing access to such data, so that only a set 
of authorized readers would be able to get the template.

>For biometrics, I see certificate formats as just another package for
>the data. I certainly don't envision biometrics becoming part of path
>processing for example. And the biometric data components are
>often encrypted or otherwise obscured, the details available only to
>a given vendor. But header information, such as validity information,
>quality or type, are becoming standardized and benefit from being
>signed.

There might be some scenarios in which encrypted template data could 
be carried in a cert and be acceptably protected. The question Russ 
asked is what are those scenarios. We know of lots of bad ideas on 
how to store this data in certs and we don't want to condone that.

Note that when we discussed inclusion of biometric data in a cert in 
the Qualified Certificate RFC, we intentionally limited it to data 
for verification by a human being, e.g., a photograph, not a 
fingerprint, voiceprint, etc.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4NTJi03381 for ietf-pkix-bks; Mon, 4 Nov 2002 15:29:19 -0800 (PST)
Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4NTIv03377 for <[e-mail]>; Mon, 4 Nov 2002 15:29:18 -0800 (PST)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 188qef-00031m-00; Mon, 04 Nov 2002 18:29:13 -0500
Message-ID: <[e-mail]>
Date: Mon, 04 Nov 2002 18:28:49 -0500
From: "Phillip H. Griffin" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Biometric Data not in DOD Certificate [was; Re: Certificate profile for  Biometrics information.]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p0510031cb9ecadb687a7@[128.89.88.34]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:

> At 5:01 PM -0500 11/4/02, Phillip H. Griffin wrote:
>
>> Sam Schaen wrote:
>>
>>>
>>> "Phillip H. Griffin" wrote:
>>> [snip]
>>>
>>>
>>>
>>>>
>>>> Biometric information seems destined to become the financial
>>>> identifier that one
>>>> day replaces the social security number. There's much interest in
>>>> using it to try
>>>> to combat identity fraud, said to be the fastest rising crime. On
>>>> another front,
>>>> a DOD pilot is to use a biometric extension in a smart card
>>>> certificate.
>>>>
>>>>   
>>>
>>>
>>> [snip]
>>>
>>> As someone responsible for documenting  the DOD PKI certificate profile
>>> and verifying that numerous certificates have satisfied that profile, I
>>> can say with assurance that there is no biometric data in the
>>> certificate itself.
>>>
>>> With somewhat less assurance, since I am not intimately familiar with
>>> the process, it is my understanding that the fingerprint indicia are
>>> stored centrally--not even on the smart card containing the
>>> certificates.
>>>
>>> Sam Schaen
>>>
>>>
>> I omitted "said" above in "is to use". Hearsay on my part from a vendor
>> involved in producing product.
>>
>> Phil
>
>
> maybe wishful thinking on the part of a vendor ...
>
> Steve
>
I don't think so. I got the idea that it was an on card matching situation
and that it was X.509 certificates, not attribute certificates to be used.
But I'm not involved in the work.

For biometrics, I see certificate formats as just another package for
the data. I certainly don't envision biometrics becoming part of path
processing for example. And the biometric data components are
often encrypted or otherwise obscured, the details available only to
a given vendor. But header information, such as validity information,
quality or type, are becoming standardized and benefit from being
signed.

Phil




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4NEOv03069 for ietf-pkix-bks; Mon, 4 Nov 2002 15:14:24 -0800 (PST)
Received: from dc-mx13.cluster1.charter.net (dc-mx13.cluster1.charter.net [209.225.8.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4NENv03065 for <[e-mail]>; Mon, 4 Nov 2002 15:14:23 -0800 (PST)
Received: from [66.189.150.200] (HELO pc1) by dc-mx13.cluster1.charter.net (CommuniGate Pro SMTP 3.5.9) with SMTP id 20569377; Mon, 04 Nov 2002 17:08:33 -0500
From: "Ebbe Hansen" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, "Sam Schaen" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>
Subject: RE: Certificate profile for Biometrics information.
Date: Mon, 4 Nov 2002 14:08:09 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ, Sam,

Yes - a hash of the template would suffice in cases where the template (and
other bio-parameters) can be obtained (securely) by other means. However, in
cases where such secure infrastructure is not available (or difficult to
manage), I think the encrypted Attribute extension as defined in RFC-3281
could be helpful.

One of the problems that may arise using encrypted Attribute extensions is a
possible need to add "recipients" to the list of trusted recipients already
included in a previously issued AC (holding an encrypted Attribute
extension).  One might consider issuing an additional AC (linking to the
previous AC, or the original PKC?) that will be used primarily to
"distribute" decryption tokens to the additional recipients?

Is their any immediate limitation on how many ACs that may be "linked" to a
previously issued PKC or AC?

Ebbe.

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Monday, November 04, 2002 1:17 PM
To: Sam Schaen
Cc: Stephen Kent; Ebbe Hansen; [e-mail]
Subject: Re: Certificate profile for Biometrics information.

Sam:

That would allow someone who validated the certificate to determine whether
a particular biometric template was known to the CA at the time the
certificate was signed.  The relying party would need to obtain the
template and an input form other sources.

I do not know the problem that Ebbe is trying to solve, so I do not know if
this meets his needs.

Russ

At 03:42 PM 11/4/2002 -0500, Sam Schaen wrote:

>Would an acceptable approach be to create a one-way function between the
>biometric data and the digest?  Similar to the hash algorithm used for
>signatures, the objective would be to make it virtually unlikely that two
>biometric captures could lead to the same digest but that having the
>digest, it
>would not be feasible to obtain the biometric.  Certainly a hash meeting
those
>characteristics could be included in a certificate without violating
privacy
>concerns and without making imperonation of the biometric characteristics
>easier
>than they currently are.
>
>-Sam
>
>Stephen Kent wrote:
>
> > At 11:12 AM -0800 11/4/02, Ebbe Hansen wrote:
> > >Steve,
> > >
> > >I would consider storing of a biometrics "digest" (sometimes also
called a
> > >template) to be the minimum biometrics information that could be
> included in
> > >a certificate (possible in an Attribute Certificate). Type of
biometrics
> > >(finger, iris, facial, etc), "digest/template" algorithm, etc. could
> also be
> > >useful. I just learned the XML working group already has a draft out
(Ref.
> > >http://www.oasis-open.org/committees/xcbf/#documents).
> > >
> > >For individuals and/or organizations that are concerned about privacy
> > >issues, one could consider support of an encryption option where
selected
> > >"trusted readers" could be enabled using specific session-key tokens,
> > >possibly included (under user or organization control) on the same
> > >smart-card that holds the certificate(s) with the biometrics
extension(s).
> > >
> > >Ebbe
> > >
> >
> > Ebbe,
> >
> > I suspected that templates were what you envisioned putting in certs.
> > The problem is that unless these values are encrypted, exposing
> > templates makes them available for the sort of off line guessing
> > attacks I mentioned.  This is not only a "privacy" issue, but very
> > much a security issue. Certs are generally viewed as being
> > transmitted over insecure channels and stored in repositories that
> > are not necessarily confidentiality-secure.
> >
> > If it is necessary to encrypt these values for security, as suggested
> > above, then I would want to see a proposed solution that provides
> > confidentiality in a fashion consistent with some credible example
> > scenarios. Note that if the template in the extension is encrypted
> > prior to inclusion in the cert (as I would expect), then the key
> > management process for disclosing this data to a "trusted reader" is
> > a lot more complex than typical "session key" management schemes of
> > the sort I think you alluded to above.
> >
> > Steve



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4NAg002951 for ietf-pkix-bks; Mon, 4 Nov 2002 15:10:42 -0800 (PST)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4NAev02943 for <[e-mail]>; Mon, 4 Nov 2002 15:10:40 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09013; Mon, 4 Nov 2002 18:10:51 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510031bb9ecad54708f@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p0510030fb9ec79e65b41@[128.89.88.34]> <[e-mail]> <p05100315b9ec8ff28942@[128.89.88.34]> <[e-mail]>
Date: Mon, 4 Nov 2002 18:05:16 -0500
To: "Phillip H. Griffin" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate profile for Biometrics information.
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 4:59 PM -0500 11/4/02, Phillip H. Griffin wrote:
>Stephen Kent wrote:
>
>>
>>At 3:42 PM -0500 11/4/02, Sam Schaen wrote:
>>
>>>Would an acceptable approach be to create a one-way function between the
>>>biometric data and the digest?  Similar to the hash algorithm used for
>>>signatures, the objective would be to make it virtually unlikely that two
>>>biometric captures could lead to the same digest but that having 
>>>the digest, it
>>>would not be feasible to obtain the biometric.  Certainly a hash 
>>>meeting those
>>>characteristics could be included in a certificate without violating privacy
>>>concerns and without making imperonation of the biometric 
>>>characteristics easier
>>>than they currently are.
>>>
>>>-Sam
>>
>>
>>Sam,
>>
>>That approach generally does not work, because a verifier needs to 
>>"score" the captured biometric data against the template values. 
>>It's never an exact match, unlike with passwords.
>>
>>Steve
>>
>The matching methods and sample collections are also vendor specific
>and proprietary. There's a place holder for processing algorithms and
>matching methods to be identified by NIST in X9.84, but to date none
>have been registered. This situation will likely not change for at least the
>near future.
>
>Phil

Phil,

I agree that the templates and scoring systems are vendor-specific, 
but that does not change the problem to which I alluded, i.e., the 
scoring generally requires access to the original values, not to a 
1-way function of those values.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4NAgY02952 for ietf-pkix-bks; Mon, 4 Nov 2002 15:10:42 -0800 (PST)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4NAev02944 for <[e-mail]>; Mon, 4 Nov 2002 15:10:40 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09027; Mon, 4 Nov 2002 18:10:52 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510031cb9ecadb687a7@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 4 Nov 2002 18:05:48 -0500
To: "Phillip H. Griffin" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Biometric Data not in DOD Certificate [was; Re: Certificate profile  for  Biometrics information.]
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 5:01 PM -0500 11/4/02, Phillip H. Griffin wrote:
>Sam Schaen wrote:
>
>>
>>"Phillip H. Griffin" wrote:
>>[snip]
>>
>>
>>
>>>
>>>Biometric information seems destined to become the financial
>>>identifier that one
>>>day replaces the social security number. There's much interest in
>>>using it to try
>>>to combat identity fraud, said to be the fastest rising crime. On
>>>another front,
>>>a DOD pilot is to use a biometric extension in a smart card
>>>certificate.
>>>
>>>    
>>>
>>
>>[snip]
>>
>>As someone responsible for documenting  the DOD PKI certificate profile
>>and verifying that numerous certificates have satisfied that profile, I
>>can say with assurance that there is no biometric data in the
>>certificate itself.
>>
>>With somewhat less assurance, since I am not intimately familiar with
>>the process, it is my understanding that the fingerprint indicia are
>>stored centrally--not even on the smart card containing the
>>certificates.
>>
>>Sam Schaen
>>
>>
>I omitted "said" above in "is to use". Hearsay on my part from a vendor
>involved in producing product.
>
>Phil

maybe wishful thinking on the part of a vendor ...

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4M7gw29631 for ietf-pkix-bks; Mon, 4 Nov 2002 14:07:42 -0800 (PST)
Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4M7eW29627 for <[e-mail]>; Mon, 4 Nov 2002 14:07:40 -0800 (PST)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 188pNn-00006N-00 for [e-mail]; Mon, 04 Nov 2002 17:07:43 -0500
Message-ID: <[e-mail]>
Date: Mon, 04 Nov 2002 17:07:20 -0500
From: "Phillip H. Griffin" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Certificate profile for Biometrics information.
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony Bartoletti wrote:

> At 03:37 PM 11/4/2002 -0500, Phillip H. Griffin wrote:
>
>> Privacy objects are already available in X9.84 and XCBF and rely on
>> the familiar EnvelopedData and EncryptedData, and a named variant of
>> EncryptedData. But biometric information is public, not private. It's 
>> in your
>> hair left on the brush in the hotel, in your prints left on the glass 
>> at dinner, and
>> by anyone who wishes to scan or photograph for the purpose of trying 
>> to mimic
>> another.
>
>
> I think there is a world of difference.  It is one thing for an 
> individual to risk exposing themselves by physically following me 
> around to gather hair from my comb, fingerprints from my dinner glass, 
> etc.  It is another thing for someone half a world away to issue a 
> query and obtain countless such samples.

I didn't speak of samples, but templates.

>
> The threat of the former capability does not justify enabling the 
> latter capability.
> (And if biometric data is essentially "public", what value has it in 
> certification?)
>
> Cheers!  ____tony____
>
>> Tony Bartoletti 925-422-3881 <[e-mail]>
>
> Information Operations and Assurance Center
> Lawrence Livermore National Laboratory
> Livermore, CA 94551-9900
>
>




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4M1gd29345 for ietf-pkix-bks; Mon, 4 Nov 2002 14:01:42 -0800 (PST)
Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4M1cW29339 for <[e-mail]>; Mon, 4 Nov 2002 14:01:38 -0800 (PST)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 188pHx-0007s3-00 for [e-mail]; Mon, 04 Nov 2002 17:01:41 -0500
Message-ID: <[e-mail]>
Date: Mon, 04 Nov 2002 17:01:17 -0500
From: "Phillip H. Griffin" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Biometric Data not in DOD Certificate [was; Re: Certificate profile for  Biometrics information.]
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/alternative; boundary="------------010606000404050704030304"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------010606000404050704030304
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Sam Schaen wrote:

>"Phillip H. Griffin" wrote:
>[snip]
>
>  
>
>>Biometric information seems destined to become the financial
>>identifier that one
>>day replaces the social security number. There's much interest in
>>using it to try
>>to combat identity fraud, said to be the fastest rising crime. On
>>another front,
>>a DOD pilot is to use a biometric extension in a smart card
>>certificate.
>>
>>    
>>
>
>[snip]
>
>As someone responsible for documenting  the DOD PKI certificate profile
>and verifying that numerous certificates have satisfied that profile, I
>can say with assurance that there is no biometric data in the
>certificate itself.
>
>With somewhat less assurance, since I am not intimately familiar with
>the process, it is my understanding that the fingerprint indicia are
>stored centrally--not even on the smart card containing the
>certificates.
>
>Sam Schaen
>  
>
I omitted "said" above in "is to use". Hearsay on my part from a vendor
involved in producing product.

Phil

>
>
>
>  
>


--------------010606000404050704030304
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
<br>
<br>
Sam Schaen wrote:<br>
<blockquote type="cite" cite="[e-mail]">
  <pre wrap="">
"Phillip H. Griffin" wrote:
[snip]

  </pre>
  <blockquote type="cite">
    <pre wrap="">
Biometric information seems destined to become the financial
identifier that one
day replaces the social security number. There's much interest in
using it to try
to combat identity fraud, said to be the fastest rising crime. On
another front,
a DOD pilot is to use a biometric extension in a smart card
certificate.

    </pre>
  </blockquote>
  <pre wrap=""><!---->
[snip]

As someone responsible for documenting  the DOD PKI certificate profile
and verifying that numerous certificates have satisfied that profile, I
can say with assurance that there is no biometric data in the
certificate itself.

With somewhat less assurance, since I am not intimately familiar with
the process, it is my understanding that the fingerprint indicia are
stored centrally--not even on the smart card containing the
certificates.

Sam Schaen
  </pre>
</blockquote>
I omitted "said" above in "is to use". Hearsay on my part from a vendor<br>
involved in producing product. <br>
<br>
Phil<br>
<br>
<blockquote type="cite" cite="[e-mail]">
  <pre wrap="">



  </pre>
</blockquote>
<br>
</body>
</html>

--------------010606000404050704030304--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4LxsR29251 for ietf-pkix-bks; Mon, 4 Nov 2002 13:59:54 -0800 (PST)
Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4LxqW29246 for <[e-mail]>; Mon, 4 Nov 2002 13:59:52 -0800 (PST)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 188pGF-0007iH-00 for [e-mail]; Mon, 04 Nov 2002 16:59:55 -0500
Message-ID: <[e-mail]>
Date: Mon, 04 Nov 2002 16:59:32 -0500
From: "Phillip H. Griffin" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Certificate profile for Biometrics information.
References: <[e-mail]> <p0510030fb9ec79e65b41@[128.89.88.34]> <[e-mail]> <p05100315b9ec8ff28942@[128.89.88.34]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:

>
> At 3:42 PM -0500 11/4/02, Sam Schaen wrote:
>
>> Would an acceptable approach be to create a one-way function between the
>> biometric data and the digest?  Similar to the hash algorithm used for
>> signatures, the objective would be to make it virtually unlikely that 
>> two
>> biometric captures could lead to the same digest but that having the 
>> digest, it
>> would not be feasible to obtain the biometric.  Certainly a hash 
>> meeting those
>> characteristics could be included in a certificate without violating 
>> privacy
>> concerns and without making imperonation of the biometric 
>> characteristics easier
>> than they currently are.
>>
>> -Sam
>
>
> Sam,
>
> That approach generally does not work, because a verifier needs to 
> "score" the captured biometric data against the template values. It's 
> never an exact match, unlike with passwords.
>
> Steve
>
The matching methods and sample collections are also vendor specific
and proprietary. There's a place holder for processing algorithms and
matching methods to be identified by NIST in X9.84, but to date none
have been registered. This situation will likely not change for at least the
near future.

Phil



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4LfIL28477 for ietf-pkix-bks; Mon, 4 Nov 2002 13:41:18 -0800 (PST)
Received: from smtp-1.llnl.gov (smtp-1.llnl.gov [128.115.250.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4LfHW28468 for <[e-mail]>; Mon, 4 Nov 2002 13:41:18 -0800 (PST)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-1.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id NAA11304; Mon, 4 Nov 2002 13:40:50 -0800 (PST)
Received: from [128.115.222.68] (HELO catalyst2b.llnl.gov) by poptop.llnl.gov (CommuniGate Pro SMTP 3.5.9) with ESMTP id 5095004; Mon, 04 Nov 2002 13:36:23 -0800
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 04 Nov 2002 13:39:36 -0800
To: "Phillip H. Griffin" <[e-mail]>, Ebbe Hansen <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Certificate profile for Biometrics information.
Cc: Stephen Kent <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 03:37 PM 11/4/2002 -0500, Phillip H. Griffin wrote:
>Privacy objects are already available in X9.84 and XCBF and rely on
>the familiar EnvelopedData and EncryptedData, and a named variant of
>EncryptedData. But biometric information is public, not private. It's in your
>hair left on the brush in the hotel, in your prints left on the glass at 
>dinner, and
>by anyone who wishes to scan or photograph for the purpose of trying to mimic
>another.

I think there is a world of difference.  It is one thing for an individual 
to risk exposing themselves by physically following me around to gather 
hair from my comb, fingerprints from my dinner glass, etc.  It is another 
thing for someone half a world away to issue a query and obtain countless 
such samples.

The threat of the former capability does not justify enabling the latter 
capability.

(And if biometric data is essentially "public", what value has it in 
certification?)


Cheers!  ____tony____

>

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4LUMC27855 for ietf-pkix-bks; Mon, 4 Nov 2002 13:30:22 -0800 (PST)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4LULW27851 for <[e-mail]>; Mon, 4 Nov 2002 13:30:21 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03784; Mon, 4 Nov 2002 16:30:27 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100317b9ec95bde58d@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 4 Nov 2002 16:25:06 -0500
To: Sam Schaen <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Biometric Data not in DOD Certificate [was; Re: Certificate profile for   Biometrics information.]
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 4:18 PM -0500 11/4/02, Sam Schaen wrote:
>"Phillip H. Griffin" wrote:
>[snip]
>
>>
>>
>>  Biometric information seems destined to become the financial
>>  identifier that one
>>  day replaces the social security number. There's much interest in
>>  using it to try
>>  to combat identity fraud, said to be the fastest rising crime. On
>>  another front,
>>  a DOD pilot is to use a biometric extension in a smart card
>>  certificate.
>>
>
>[snip]
>
>As someone responsible for documenting  the DOD PKI certificate profile
>and verifying that numerous certificates have satisfied that profile, I
>can say with assurance that there is no biometric data in the
>certificate itself.
>
>With somewhat less assurance, since I am not intimately familiar with
>the process, it is my understanding that the fingerprint indicia are
>stored centrally--not even on the smart card containing the
>certificates.
>
>Sam Schaen

I can verify Sam's comment. The DoD Common Access Card (CAC) does not 
store biometric data in any form at this time. The fingerprint data 
are stored in a central database and that database is accessed when a 
user must authenticate him/herself to a verification officer to have 
a CAC issued or reissued.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4LK9d27002 for ietf-pkix-bks; Mon, 4 Nov 2002 13:20:09 -0800 (PST)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA4LK7W26997 for <[e-mail]>; Mon, 4 Nov 2002 13:20:07 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Nov 2002 21:20:10 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA16352; Mon, 4 Nov 2002 16:20:09 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id gA4LHTn15137; Mon, 4 Nov 2002 16:17:29 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWJCWH>; Mon, 4 Nov 2002 16:20:07 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.17]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWJCVT; Mon, 4 Nov 2002 16:19:53 -0500
From: "Housley, Russ" <[e-mail]>
To: Sam Schaen <[e-mail]>
Cc: Stephen Kent <[e-mail]>, Ebbe Hansen <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 04 Nov 2002 16:17:17 -0500
Subject: Re: Certificate profile for Biometrics information.
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p0510030fb9ec79e65b41@[128.89.88.34]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam:

That would allow someone who validated the certificate to determine whether 
a particular biometric template was known to the CA at the time the 
certificate was signed.  The relying party would need to obtain the 
template and an input form other sources.

I do not know the problem that Ebbe is trying to solve, so I do not know if 
this meets his needs.

Russ

At 03:42 PM 11/4/2002 -0500, Sam Schaen wrote:

>Would an acceptable approach be to create a one-way function between the
>biometric data and the digest?  Similar to the hash algorithm used for
>signatures, the objective would be to make it virtually unlikely that two
>biometric captures could lead to the same digest but that having the 
>digest, it
>would not be feasible to obtain the biometric.  Certainly a hash meeting those
>characteristics could be included in a certificate without violating privacy
>concerns and without making imperonation of the biometric characteristics 
>easier
>than they currently are.
>
>-Sam
>
>Stephen Kent wrote:
>
> > At 11:12 AM -0800 11/4/02, Ebbe Hansen wrote:
> > >Steve,
> > >
> > >I would consider storing of a biometrics "digest" (sometimes also called a
> > >template) to be the minimum biometrics information that could be 
> included in
> > >a certificate (possible in an Attribute Certificate). Type of biometrics
> > >(finger, iris, facial, etc), "digest/template" algorithm, etc. could 
> also be
> > >useful. I just learned the XML working group already has a draft out (Ref.
> > >http://www.oasis-open.org/committees/xcbf/#documents).
> > >
> > >For individuals and/or organizations that are concerned about privacy
> > >issues, one could consider support of an encryption option where selected
> > >"trusted readers" could be enabled using specific session-key tokens,
> > >possibly included (under user or organization control) on the same
> > >smart-card that holds the certificate(s) with the biometrics extension(s).
> > >
> > >Ebbe
> > >
> >
> > Ebbe,
> >
> > I suspected that templates were what you envisioned putting in certs.
> > The problem is that unless these values are encrypted, exposing
> > templates makes them available for the sort of off line guessing
> > attacks I mentioned.  This is not only a "privacy" issue, but very
> > much a security issue. Certs are generally viewed as being
> > transmitted over insecure channels and stored in repositories that
> > are not necessarily confidentiality-secure.
> >
> > If it is necessary to encrypt these values for security, as suggested
> > above, then I would want to see a proposed solution that provides
> > confidentiality in a fashion consistent with some credible example
> > scenarios. Note that if the template in the extension is encrypted
> > prior to inclusion in the cert (as I would expect), then the key
> > management process for disclosing this data to a "trusted reader" is
> > a lot more complex than typical "session key" management schemes of
> > the sort I think you alluded to above.
> >
> > Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4LIw426906 for ietf-pkix-bks; Mon, 4 Nov 2002 13:18:58 -0800 (PST)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4LItW26898 for <[e-mail]>; Mon, 4 Nov 2002 13:18:55 -0800 (PST)
Received: from corben (corben.ncsl.nist.gov [129.6.54.128]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id gA4LIlTv004980; Mon, 4 Nov 2002 16:18:48 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 04 Nov 2002 16:21:01 -0500
To: <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: PKIX agenda for Atlanta
Cc: "Christopher S. Francis" <[e-mail]>
In-Reply-To: <[e-mail] m>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

It is time to draft the agenda for the Atlanta PKIX meeting.

The first order of business for PKIX has to be the DPD/DPV protocol 
discussion.  We have four different editors (or editing groups) that have 
proposed or produced protocol drafts.  Now that the DPD/DPV requirements 
are complete, we need to make a decision on which protocol or protocols to 
pursue.

Only one of these protocols will survive and progress to RFC.  There are 
real advantages to selecting a winner early, rather than late.  This way, 
we waste the least number of cycles on drafts that are not going 
forward.  To that end, I would like to give each of those groups as much 
time as possible, as well as discussion from the floor.

I will try to accommodate any other agenda requests I receive, but please 
recognize that your time will be limited.  If you wish to be on the agenda 
(for DPD/DPV or otherwise) please drop me a note with agenda in the subject 
line.

Thanks,

Tim Polk




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4LIrm26889 for ietf-pkix-bks; Mon, 4 Nov 2002 13:18:53 -0800 (PST)
Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [192.160.51.75]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4LIpW26879 for <[e-mail]>; Mon, 4 Nov 2002 13:18:51 -0800 (PST)
Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id gA4LId400426; Mon, 4 Nov 2002 16:18:39 -0500 (EST)
Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id gA4LIaY16970; Mon, 4 Nov 2002 16:18:36 -0500 (EST)
Received: from mm109667-2k.mitre.org (128.29.162.216) by mailhub2.mitre.org with SMTP id 18372; Mon, 04 Nov 2002 16:18:28 -0500
Message-ID: <[e-mail]>
Date: Mon, 04 Nov 2002 16:18:28 -0500
From: Sam Schaen <[e-mail]>
Organization: The MITRE Corporation
X-Mailer: Mozilla 4.79 [en]C-20020130M  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Phillip H. Griffin" <[e-mail]>
CC: Ebbe Hansen <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: Biometric Data not in DOD Certificate [was; Re: Certificate profile for  Biometrics information.]
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Phillip H. Griffin" wrote:
[snip]

>
>
> Biometric information seems destined to become the financial
> identifier that one
> day replaces the social security number. There's much interest in
> using it to try
> to combat identity fraud, said to be the fastest rising crime. On
> another front,
> a DOD pilot is to use a biometric extension in a smart card
> certificate.
>

[snip]

As someone responsible for documenting  the DOD PKI certificate profile
and verifying that numerous certificates have satisfied that profile, I
can say with assurance that there is no biometric data in the
certificate itself.

With somewhat less assurance, since I am not intimately familiar with
the process, it is my understanding that the fingerprint indicia are
stored centrally--not even on the smart card containing the
certificates.

Sam Schaen






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4L0TO24763 for ietf-pkix-bks; Mon, 4 Nov 2002 13:00:29 -0800 (PST)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4L0SW24752 for <[e-mail]>; Mon, 4 Nov 2002 13:00:28 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17662; Mon, 4 Nov 2002 16:00:37 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100315b9ec8ff28942@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p0510030fb9ec79e65b41@[128.89.88.34]> <[e-mail]>
Date: Mon, 4 Nov 2002 15:59:39 -0500
To: Sam Schaen <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate profile for Biometrics information.
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 3:42 PM -0500 11/4/02, Sam Schaen wrote:
>Would an acceptable approach be to create a one-way function between the
>biometric data and the digest?  Similar to the hash algorithm used for
>signatures, the objective would be to make it virtually unlikely that two
>biometric captures could lead to the same digest but that having the 
>digest, it
>would not be feasible to obtain the biometric.  Certainly a hash meeting those
>characteristics could be included in a certificate without violating privacy
>concerns and without making imperonation of the biometric 
>characteristics easier
>than they currently are.
>
>-Sam

Sam,

That approach generally does not work, because a verifier needs to 
"score" the captured biometric data against the template values. 
It's never an exact match, unlike with passwords.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4KhIo24215 for ietf-pkix-bks; Mon, 4 Nov 2002 12:43:18 -0800 (PST)
Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [192.160.51.75]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4KhHW24211 for <[e-mail]>; Mon, 4 Nov 2002 12:43:17 -0800 (PST)
Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id gA4Kgx424057; Mon, 4 Nov 2002 15:42:59 -0500 (EST)
Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id gA4KguY08904; Mon, 4 Nov 2002 15:42:56 -0500 (EST)
Received: from mm109667-2k.mitre.org (128.29.162.216) by mailhub2.mitre.org with SMTP id 17521; Mon, 04 Nov 2002 15:42:52 -0500
Message-ID: <[e-mail]>
Date: Mon, 04 Nov 2002 15:42:51 -0500
From: Sam Schaen <[e-mail]>
Organization: The MITRE Corporation
X-Mailer: Mozilla 4.79 [en]C-20020130M  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Ebbe Hansen <[e-mail]>, [e-mail]
Subject: Re: Certificate profile for Biometrics information.
References: <[e-mail]> <p0510030fb9ec79e65b41@[128.89.88.34]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Would an acceptable approach be to create a one-way function between the
biometric data and the digest?  Similar to the hash algorithm used for
signatures, the objective would be to make it virtually unlikely that two
biometric captures could lead to the same digest but that having the digest, it
would not be feasible to obtain the biometric.  Certainly a hash meeting those
characteristics could be included in a certificate without violating privacy
concerns and without making imperonation of the biometric characteristics easier
than they currently are.

-Sam

Stephen Kent wrote:

> At 11:12 AM -0800 11/4/02, Ebbe Hansen wrote:
> >Steve,
> >
> >I would consider storing of a biometrics "digest" (sometimes also called a
> >template) to be the minimum biometrics information that could be included in
> >a certificate (possible in an Attribute Certificate). Type of biometrics
> >(finger, iris, facial, etc), "digest/template" algorithm, etc. could also be
> >useful. I just learned the XML working group already has a draft out (Ref.
> >http://www.oasis-open.org/committees/xcbf/#documents).
> >
> >For individuals and/or organizations that are concerned about privacy
> >issues, one could consider support of an encryption option where selected
> >"trusted readers" could be enabled using specific session-key tokens,
> >possibly included (under user or organization control) on the same
> >smart-card that holds the certificate(s) with the biometrics extension(s).
> >
> >Ebbe
> >
>
> Ebbe,
>
> I suspected that templates were what you envisioned putting in certs.
> The problem is that unless these values are encrypted, exposing
> templates makes them available for the sort of off line guessing
> attacks I mentioned.  This is not only a "privacy" issue, but very
> much a security issue. Certs are generally viewed as being
> transmitted over insecure channels and stored in repositories that
> are not necessarily confidentiality-secure.
>
> If it is necessary to encrypt these values for security, as suggested
> above, then I would want to see a proposed solution that provides
> confidentiality in a fashion consistent with some credible example
> scenarios. Note that if the template in the extension is encrypted
> prior to inclusion in the cert (as I would expect), then the key
> management process for disclosing this data to a "trusted reader" is
> a lot more complex than typical "session key" management schemes of
> the sort I think you alluded to above.
>
> Steve




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4KcbH24100 for ietf-pkix-bks; Mon, 4 Nov 2002 12:38:37 -0800 (PST)
Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4KcYW24096 for <[e-mail]>; Mon, 4 Nov 2002 12:38:34 -0800 (PST)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 188nz0-0000Y4-00; Mon, 04 Nov 2002 15:38:02 -0500
Message-ID: <[e-mail]>
Date: Mon, 04 Nov 2002 15:37:38 -0500
From: "Phillip H. Griffin" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ebbe Hansen <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Certificate profile for Biometrics information.
References: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------050609060409050502070904"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------050609060409050502070904
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Ebbe and Steve,

Ebbe Hansen wrote:

>Steve,
>
>I would consider storing of a biometrics "digest" (sometimes also called a
>template) to be the minimum biometrics information that could be included in
>a certificate (possible in an Attribute Certificate). Type of biometrics
>(finger, iris, facial, etc), "digest/template" algorithm, etc. could also be
>useful. I just learned the XML working group already has a draft out (Ref.
>http://www.oasis-open.org/committees/xcbf/#documents).
>
This contains exactly the same types being defined in the X9.84 revision
that it is my turn to edit this week. The text states (for now):

Additional mechanisms can be used to provide integrity protection to
biometric information, when it is being conveyed with other data (e.g.,
a financial transaction).  Biometric templates in the form of
EncodedBiometricObjects can be bound to a public key associated
with a private key in a digital certificate.

This standard supports biometric certificate extensions that can be
incorporated into values of types Certificate and AttributeCertificate,
as defined in the Directory series of standards, and type DomainCertificate
as defined in X9.68 [???]. Biometric certificate extension values can be 
encoded
in either the Distinguished Encoding Rules (DER) or the canonical 
variant of the
XML Encoding Rules (cXER):

biometricTemplates EXTENSION ::= {
   SYNTAX         EncodedBiometricObjects  -- DER or cXER --
   IDENTIFIED BY  x509-biometricTemplates
}

domainBiometricTemplates PRIVATE ::= {
   NAME  oid : x968-biometricTemplates
   TYPE  EncodedBiometricObjects  -- DER or cXER --
}

>For individuals and/or organizations that are concerned about privacy
>issues, one could consider support of an encryption option where selected
>"trusted readers" could be enabled using specific session-key tokens,
>possibly included (under user or organization control) on the same
>smart-card that holds the certificate(s) with the biometrics extension(s).
>  
>
Privacy objects are already available in X9.84 and XCBF and rely on
the familiar EnvelopedData and EncryptedData, and a named variant of
EncryptedData. But biometric information is public, not private. It's in 
your
hair left on the brush in the hotel, in your prints left on the glass at 
dinner, and
by anyone who wishes to scan or photograph for the purpose of trying to 
mimic
another.

Tracking the fameous girl in Afganistan on the cover of National 
Geographic to
a woman some twenty years later was done by iris scan analysis of the 
eyes in
the photographs. So, biometric information in most cases is just public 
data that
when used in open networks needs to have integrity and to be 
authenticated in
order to be trusted and relied upon.

So rather than opt for creating a certificate extension payload from a 
value of
type BiometricSyntaxSets, I decided that the encoded value of a series of
biometric objects was probably enough. Some communities of course will
need privacy, but the general public will not. Authentication will 
likely do for
templates.

Biometric information seems destined to become the financial identifier 
that one
day replaces the social security number. There's much interest in using 
it to try
to combat identity fraud, said to be the fastest rising crime. On 
another front,
a DOD pilot is to use a biometric extension in a smart card certificate.

The BiometricObject in X9.84 and XCBF contains a 'hole' that can carry an
arbitrary payload relevant to an application. There are many things this 
might
be, the blinded hash of a customer PAN as used in SET for cardholder common
names, an encrypted smart identifier, etc. This type can also carry the 
biometric
processing algorithm and matching method needed by a relying party. And most
importantly, a set of these can carry multiple occurances of a 
biometric, say three
fingerprints, or sets of mutiple biometric types, say ten fingerprints 
and two iris
images.

Phil

>Ebbe
>
>-----Original Message-----
>From: Stephen Kent [mailto:[e-mail]]
>Sent: Monday, November 04, 2002 10:34 AM
>To: Ebbe Hansen
>Cc: [e-mail]
>Subject: Re: Certificate profile for Biometrics information.
>
>  
>
>>I am looking for biometrics profile-definitions on how biometrics reference
>>information may be encoded and embedded into X.509 certificates (Public Key
>>Certificates as well as Attribute Certificates). The only
>>"biometrics-data-extension" I have found so far is included in RFC 3039 as
>>the "biometricInfo" extension.
>>
>>Are there other biometrics profiles that have been defined at this time?
>>
>>Regards Ebbe Hansen
>>    
>>
>
>Ebbe,
>
>Many sorts of biometric info are inappropriate to place in a cert,
>due to concerns about disclosure of that info, e.g., to enable off
>line guessing attacks. This, in part, is why we don't have any
>extension defined for this purpose. Could you explain in more detail
>what sort of biometric info you envision storing in certs, and how it
>would be used?  That might help us better understand what might be
>appropriate.
>
>Thanks,
>
>Steve
>
>
>  
>


--------------050609060409050502070904
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Ebbe and Steve,<br>
<br>
Ebbe Hansen wrote:<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">Steve,

I would consider storing of a biometrics "digest" (sometimes also called a
template) to be the minimum biometrics information that could be included in
a certificate (possible in an Attribute Certificate). Type of biometrics
(finger, iris, facial, etc), "digest/template" algorithm, etc. could also be
useful. I just learned the XML working group already has a draft out (Ref.
<a class="moz-txt-link-freetext" href="http://www.oasis-open.org/committees/xcbf/#documents">http://www.oasis-open.org/committees/xcbf/#documents</a>).</pre>
</blockquote>
This contains exactly the same types being defined in the X9.84 revision<br>
that it is my turn to edit this week. The text states (for now):<br>
<br>
Additional mechanisms can be used to provide integrity protection to <br>
biometric information, when it is being conveyed with other data (e.g., <br>
a financial transaction).&nbsp; Biometric templates in the form of <br>
<b><small><font face="Courier New, Courier, monospace">EncodedBiometricObjects</font></small></b>
can be bound to a public key associated<br>
with a private key in a digital certificate. <br>
<br>
This standard supports biometric certificate extensions that can be <br>
incorporated into values of types <b><small><font
 face="Courier New, Courier, monospace">Certificate </font></small></b>and
<b><small><font face="Courier New, Courier, monospace">AttributeCertificate,<br>
</font></small></b>as defined in the Directory series of standards, and type
<b><small><font face="Courier New, Courier, monospace">DomainCertificate
</font></small></b><br>
as defined in X9.68 [???]. Biometric certificate extension values can be
encoded<br>
in either the Distinguished Encoding Rules (DER) or the canonical variant
of the <br>
XML Encoding Rules (cXER):<br>
<br>
<b><small><font face="Courier New, Courier, monospace">biometricTemplates
EXTENSION ::= {<br>
&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EncodedBiometricObjects&nbsp; </font></small></b><small><font
 face="Courier New, Courier, monospace">-- DER or cXER --<br>
<b>&nbsp;&nbsp; IDENTIFIED BY&nbsp; x509-biometricTemplates</b></font></small><b><small><font
 face="Courier New, Courier, monospace"><br>
}</font></small></b><br>
<br>
<small><font face="Courier New, Courier, monospace"><b>domainBiometricTemplates
PRIVATE ::= {<br>
&nbsp;&nbsp; NAME&nbsp; oid : x968-biometricTemplates <br>
&nbsp;&nbsp; TYPE&nbsp; EncodedBiometricObjects&nbsp; </b>-- DER or cXER --<br>
<b>}</b></font></small>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">
For individuals and/or organizations that are concerned about privacy
issues, one could consider support of an encryption option where selected
"trusted readers" could be enabled using specific session-key tokens,
possibly included (under user or organization control) on the same
smart-card that holds the certificate(s) with the biometrics extension(s).
  </pre>
</blockquote>
Privacy objects are already available in X9.84 and XCBF and rely on<br>
the familiar <small><font face="Courier New, Courier, monospace"><b>EnvelopedData
</b></font></small>and <small><font
 face="Courier New, Courier, monospace"><b>EncryptedData, </b></font></small>and
a named variant of<br>
<small><font face="Courier New, Courier, monospace"><b>EncryptedData</b></font></small>.
But biometric information is public, not private. It's in your<br>
hair left on the brush in the hotel, in your prints left on the glass at
dinner, and<br>
by anyone who wishes to scan or photograph for the purpose of trying to mimic<br>
another. <br>
<br>
Tracking the fameous girl in Afganistan on the cover of National Geographic
to<br>
a woman some twenty years later was done by iris scan analysis of the eyes
in<br>
the photographs. So, biometric information in most cases is just public data
that<br>
when used in open networks needs to have integrity and to be authenticated
in<br>
order to be trusted and relied upon. <br>
<br>
So rather than opt for creating a certificate extension payload from a value
of<br>
type <b><small><font face="Courier New, Courier, monospace">BiometricSyntaxSets,
</font></small></b>I decided that the encoded value of a series of <br>
biometric objects was probably enough. Some communities of course will<br>
need privacy, but the general public will not. Authentication will likely
do for<br>
templates.<br>
<br>
Biometric information seems destined to become the financial identifier that
one<br>
 day replaces the social security number. There's much interest in using
it to try<br>
 to combat identity fraud, said to be the fastest rising crime. On another
front,<br>
 a DOD pilot is to use a biometric extension in a smart card certificate.<br>
<br>
The <small><font face="Courier New, Courier, monospace"><b>BiometricObject
</b></font></small>in X9.84 and XCBF contains a 'hole' that can carry an<br>
arbitrary payload relevant to an application. There are many things this
might <br>
be, the blinded hash of a customer PAN as used in SET for cardholder common<br>
names, an encrypted smart identifier, etc. This type can also carry the biometric<br>
processing algorithm and matching method needed by a relying party. And most<br>
importantly, a set of these can carry multiple occurances of a biometric,
say three<br>
fingerprints, or sets of mutiple biometric types, say ten fingerprints and
two iris<br>
images. <br>
<br>
Phil<br>
<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">
Ebbe

-----Original Message-----
From: Stephen Kent [<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>]
Sent: Monday, November 04, 2002 10:34 AM
To: Ebbe Hansen
Cc: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
Subject: Re: Certificate profile for Biometrics information.

  </pre>
  <blockquote type="cite">
    <pre wrap="">I am looking for biometrics profile-definitions on how biometrics reference
information may be encoded and embedded into X.509 certificates (Public Key
Certificates as well as Attribute Certificates). The only
"biometrics-data-extension" I have found so far is included in RFC 3039 as
the "biometricInfo" extension.

Are there other biometrics profiles that have been defined at this time?

Regards Ebbe Hansen
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Ebbe,

Many sorts of biometric info are inappropriate to place in a cert,
due to concerns about disclosure of that info, e.g., to enable off
line guessing attacks. This, in part, is why we don't have any
extension defined for this purpose. Could you explain in more detail
what sort of biometric info you envision storing in certs, and how it
would be used?  That might help us better understand what might be
appropriate.

Thanks,

Steve


  </pre>
</blockquote>
<br>
</body>
</html>

--------------050609060409050502070904--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4K0ai22775 for ietf-pkix-bks; Mon, 4 Nov 2002 12:00:36 -0800 (PST)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4K0YW22770 for <[e-mail]>; Mon, 4 Nov 2002 12:00:35 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21200; Mon, 4 Nov 2002 15:00:40 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510030fb9ec79e65b41@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 4 Nov 2002 14:56:49 -0500
To: "Ebbe Hansen" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Certificate profile for Biometrics information.
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:12 AM -0800 11/4/02, Ebbe Hansen wrote:
>Steve,
>
>I would consider storing of a biometrics "digest" (sometimes also called a
>template) to be the minimum biometrics information that could be included in
>a certificate (possible in an Attribute Certificate). Type of biometrics
>(finger, iris, facial, etc), "digest/template" algorithm, etc. could also be
>useful. I just learned the XML working group already has a draft out (Ref.
>http://www.oasis-open.org/committees/xcbf/#documents).
>
>For individuals and/or organizations that are concerned about privacy
>issues, one could consider support of an encryption option where selected
>"trusted readers" could be enabled using specific session-key tokens,
>possibly included (under user or organization control) on the same
>smart-card that holds the certificate(s) with the biometrics extension(s).
>
>Ebbe
>

Ebbe,

I suspected that templates were what you envisioned putting in certs. 
The problem is that unless these values are encrypted, exposing 
templates makes them available for the sort of off line guessing 
attacks I mentioned.  This is not only a "privacy" issue, but very 
much a security issue. Certs are generally viewed as being 
transmitted over insecure channels and stored in repositories that 
are not necessarily confidentiality-secure.

If it is necessary to encrypt these values for security, as suggested 
above, then I would want to see a proposed solution that provides 
confidentiality in a fashion consistent with some credible example 
scenarios. Note that if the template in the extension is encrypted 
prior to inclusion in the cert (as I would expect), then the key 
management process for disclosing this data to a "trusted reader" is 
a lot more complex than typical "session key" management schemes of 
the sort I think you alluded to above.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4JweC22664 for ietf-pkix-bks; Mon, 4 Nov 2002 11:58:40 -0800 (PST)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA4JwcW22659 for <[e-mail]>; Mon, 4 Nov 2002 11:58:38 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Nov 2002 19:58:41 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA08784 for <[e-mail]>; Mon, 4 Nov 2002 14:58:40 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id gA4JtxO06142 for <[e-mail]>; Mon, 4 Nov 2002 14:55:59 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWJBB6>; Mon, 4 Nov 2002 14:58:38 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.17]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWJBBW; Mon, 4 Nov 2002 14:58:28 -0500
From: "Housley, Russ" <[e-mail]>
To: Ebbe Hansen <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 04 Nov 2002 14:56:40 -0500
Subject: RE: Certificate profile for Biometrics information.
In-Reply-To: <[e-mail]>
References: <p05100309b9ec6d726e2f@[128.89.88.34]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ebbe:

In general, I expect certificates to contain public information.  In some 
systems, the biometric template allows an attacker to compose a matching 
input.  This is essentially the information needed to masquerade.  For this 
reason, I do not want to see them in certificates.

Attribute certificates contain a mechanism for encrypting attributes in a 
manner that only intended recipients can decrypt them.  This seems like a 
better location for biometric templates.

Russ


At 11:12 AM 11/4/2002 -0800, Ebbe Hansen wrote:

>Steve,
>
>I would consider storing of a biometrics "digest" (sometimes also called a
>template) to be the minimum biometrics information that could be included in
>a certificate (possible in an Attribute Certificate). Type of biometrics
>(finger, iris, facial, etc), "digest/template" algorithm, etc. could also be
>useful. I just learned the XML working group already has a draft out (Ref.
>http://www.oasis-open.org/committees/xcbf/#documents).
>
>For individuals and/or organizations that are concerned about privacy
>issues, one could consider support of an encryption option where selected
>"trusted readers" could be enabled using specific session-key tokens,
>possibly included (under user or organization control) on the same
>smart-card that holds the certificate(s) with the biometrics extension(s).
>
>Ebbe
>
>-----Original Message-----
>From: Stephen Kent [mailto:[e-mail]]
>Sent: Monday, November 04, 2002 10:34 AM
>To: Ebbe Hansen
>Cc: [e-mail]
>Subject: Re: Certificate profile for Biometrics information.
>
> >I am looking for biometrics profile-definitions on how biometrics reference
> >information may be encoded and embedded into X.509 certificates (Public Key
> >Certificates as well as Attribute Certificates). The only
> >"biometrics-data-extension" I have found so far is included in RFC 3039 as
> >the "biometricInfo" extension.
> >
> >Are there other biometrics profiles that have been defined at this time?
> >
> >Regards Ebbe Hansen
>
>Ebbe,
>
>Many sorts of biometric info are inappropriate to place in a cert,
>due to concerns about disclosure of that info, e.g., to enable off
>line guessing attacks. This, in part, is why we don't have any
>extension defined for this purpose. Could you explain in more detail
>what sort of biometric info you envision storing in certs, and how it
>would be used?  That might help us better understand what might be
>appropriate.
>
>Thanks,
>
>Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4JF4m19751 for ietf-pkix-bks; Mon, 4 Nov 2002 11:15:04 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4JF1W19741 for <[e-mail]>; Mon, 4 Nov 2002 11:15:02 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA14022; Mon, 4 Nov 2002 20:15:01 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Mon, 4 Nov 2002 20:15:01 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id UAA09306; Mon, 4 Nov 2002 20:15:00 +0100 (MET)
Date: Mon, 4 Nov 2002 20:15:00 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-cvp-01.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> I have issued a new version of CVP "Certificate Validation Protocol".
> 

To some degree the critique that you made about functionality
implemented by extensions may also apply to your text.

It is not quite clear to me why just for relaying and referal you
use an extension mechanism and for example you have
a direct option serverContextInfo which is not an extension.
it seems that you are distinguishing optional service
features from optional parameters in this way. 

"Using "Dump ASN.1" would allow to easily debug CVP, but not SCVP."
Since you also use Extensions, this is true for your version, too.

Not encapsulating data into an octet string but defining them
as ANY DEFINED BY (to use an outdated asn1 term), is a mechanism that
correct ASN1 implementations can handle. 

You don't specify explicitely what to put into the ESScertid of a 
relaying extension. 'RelayInfo unambigously allows to identify the server'
mean what? the requesting or the receivin gserver? Well, it may 
be deduced from the loop detection procedure.

What identifier should be set for servers that do not sign their
responses?

-- 

It is not possible to use a DPV response from a relay server
in a reponse from a server UNLESS the initial server does not
sign anything, authenticates itself via SSL, and just forwards
the obtained relayed reponse as is. 

--

The usage of 'minorstatus MinorStatus OPTIONAL' probably needs a tag. 


can you tell why you use 

  version [0] EXPLICIT INTEGER DEFAULT v1 

and in the PolicyRequest instead of simply using an INTEGER as
in request: 

  version INTEGER DEFAULT v1 

In fact, it is not important because the field will never be present anyway,
and since all possible extensions are done with Extensions, there is 
probably never a requirement for a version v2. Othewise the syntax should
have a ... in any sequene with a version field. ...
 
--

There are many places whether CHOICES and optional fields cannot be detected. 

--

The PolicyResponse should probaly be better defined as

PolicyResponse ::= SEQUENCE (1..MAX) CHOICE { [0] valPolicy ValOrDiscPolicy ; [1] dispolicy ValOrDisPolicy 

--

ValOrDiscPolicy contain an ambigouos CHOICE. 

What is 'NAME' and 'Name'. Who do define a URL as 'NAME'?

-- 

A policy request cannot be replay protected? 

--
I think you have misunderstood the requirement of putting the identification 
of the server identity in the response. The ESScertid is not an identification 
of the server, but an identification of a signing certificate.
 
--

How are the number of time stamps and the TSAs indicated in the policy?

The definition of simplePolicy does not contain this.

--

I think it would have been better to separate the signature authentication
mechanism from the rest for example by using a CMS security envelope, unless
you believe that time stamp will never be used.

-- 

not saying anything about the rest doesn't mean that I agree with it. 

---

regards 

 









Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4JDG219514 for ietf-pkix-bks; Mon, 4 Nov 2002 11:13:16 -0800 (PST)
Received: from dc-mx12.cluster1.charter.net (dc-mx12.cluster1.charter.net [209.225.8.22]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4JDFW19507 for <[e-mail]>; Mon, 4 Nov 2002 11:13:15 -0800 (PST)
Received: from [66.189.150.200] (HELO pc1) by dc-mx12.cluster1.charter.net (CommuniGate Pro SMTP 3.5.9) with SMTP id 35972755; Mon, 04 Nov 2002 14:13:07 -0500
From: "Ebbe Hansen" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Certificate profile for Biometrics information.
Date: Mon, 4 Nov 2002 11:12:45 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <p05100309b9ec6d726e2f@[128.89.88.34]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

I would consider storing of a biometrics "digest" (sometimes also called a
template) to be the minimum biometrics information that could be included in
a certificate (possible in an Attribute Certificate). Type of biometrics
(finger, iris, facial, etc), "digest/template" algorithm, etc. could also be
useful. I just learned the XML working group already has a draft out (Ref.
http://www.oasis-open.org/committees/xcbf/#documents).

For individuals and/or organizations that are concerned about privacy
issues, one could consider support of an encryption option where selected
"trusted readers" could be enabled using specific session-key tokens,
possibly included (under user or organization control) on the same
smart-card that holds the certificate(s) with the biometrics extension(s).

Ebbe

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Monday, November 04, 2002 10:34 AM
To: Ebbe Hansen
Cc: [e-mail]
Subject: Re: Certificate profile for Biometrics information.

>I am looking for biometrics profile-definitions on how biometrics reference
>information may be encoded and embedded into X.509 certificates (Public Key
>Certificates as well as Attribute Certificates). The only
>"biometrics-data-extension" I have found so far is included in RFC 3039 as
>the "biometricInfo" extension.
>
>Are there other biometrics profiles that have been defined at this time?
>
>Regards Ebbe Hansen

Ebbe,

Many sorts of biometric info are inappropriate to place in a cert,
due to concerns about disclosure of that info, e.g., to enable off
line guessing attacks. This, in part, is why we don't have any
extension defined for this purpose. Could you explain in more detail
what sort of biometric info you envision storing in certs, and how it
would be used?  That might help us better understand what might be
appropriate.

Thanks,

Steve



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4IfJ417855 for ietf-pkix-bks; Mon, 4 Nov 2002 10:41:19 -0800 (PST)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4IfIW17851 for <[e-mail]>; Mon, 4 Nov 2002 10:41:18 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12270; Mon, 4 Nov 2002 13:40:51 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100309b9ec6d726e2f@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 4 Nov 2002 13:33:30 -0500
To: "Ebbe Hansen" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate profile for Biometrics information.
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>I am looking for biometrics profile-definitions on how biometrics reference
>information may be encoded and embedded into X.509 certificates (Public Key
>Certificates as well as Attribute Certificates). The only
>"biometrics-data-extension" I have found so far is included in RFC 3039 as
>the "biometricInfo" extension.
>
>Are there other biometrics profiles that have been defined at this time?
>
>Regards Ebbe Hansen

Ebbe,

Many sorts of biometric info are inappropriate to place in a cert, 
due to concerns about disclosure of that info, e.g., to enable off 
line guessing attacks. This, in part, is why we don't have any 
extension defined for this purpose. Could you explain in more detail 
what sort of biometric info you envision storing in certs, and how it 
would be used?  That might help us better understand what might be 
appropriate.

Thanks,

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4HmJZ14839 for ietf-pkix-bks; Mon, 4 Nov 2002 09:48:19 -0800 (PST)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA4HmIW14835 for <[e-mail]>; Mon, 4 Nov 2002 09:48:18 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Nov 2002 17:48:20 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA24515 for <[e-mail]>; Mon, 4 Nov 2002 12:48:19 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id gA4HjdM19473 for <[e-mail]>; Mon, 4 Nov 2002 12:45:39 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPW29FK>; Mon, 4 Nov 2002 12:48:18 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.17]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPW29FH; Mon, 4 Nov 2002 12:48:07 -0500
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 04 Nov 2002 12:29:31 -0500
Subject: Re: Criticality and SCVP Extensions
In-Reply-To: <[e-mail]>
References: <001701c283a6$374da380$1e00a8c0@Chokhani>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

I think that the authors agree that there is an issue with the extensions 
semantics, that is why it is on the open issues list in the document.

The use of OIDs in the "checks" and "wantBack" areas reduces the need for 
extensions.  By defining additional OIDs for these areas, the server can 
perform additional checks and provide additional information.  I think this 
is desirable.

Personally, I agree that the approach taken for criticality in RFC 3280 is 
the appropriate approach.  This statement has not been coordinated with the 
other SCVP authors...

Russ

At 03:18 PM 11/4/2002 +0100, Denis Pinkas wrote:
>Russ,
>
>The major problem with SCVP is that extensions are used in a way for which 
>they were not intended for. It is some kind of "new way" of programming, 
>where nearly all requests and responses have OIDs, even for the standard 
>requests and responses that are defined in the draft ! With that 
>programming style, the criticality bit is loosing its original meaning.
>
>We already have a common approach which is the one consistant with both
>RFC 3280 and RFC 3161. We do not need a new one.
>
>However, we do not need the new way of programming of SCVP. So we can get 
>rid of this issue by changing the programming style from SCVP.
>
>Denis
>
>>Russ:
>>The new TSP approach is consistent with what X.509 did about 1-2 years
>>ago.  Thus, both the request and reply in SCVP should also follow that
>>approach.  The approach (at the risk of repeating Denis and You) is:
>>1.  If you recognize an extension, you must process it, regardless of
>>its criticality.
>>2.  If you encounter an extension that is critical and you do not
>>recognize it, you must reject the object (i.e., transaction in the case
>>of SCVP).  Now, in the case of SCVP, there may be some situations where
>>the criticality of the extension may not matter.  For example, for some
>>of the statusCode and for some of the replyStatus, it may not matter
>>what a critical extension says; you know the response is bad and why.
>>But, rather than a detailed treatment of possibilities, a general
>>statement about rejection may be sufficient.
>>3.  If you encounter an extension that is non-critical and you do not
>>recognize it, you shall process the object by ignoring the extension
>>(i.e., transaction in the case of SCVP).
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]]
>>On Behalf Of Housley, Russ
>>Sent: Sunday, November 03, 2002 2:13 PM
>>To: [e-mail]
>>Subject: Criticality and SCVP Extensions
>>
>>The open issues section in SCVP has highlighted extension criticality
>>for many months.  Yet, it has not really been discussed.  Recently, Denis 
>>Pinkas raised this issue as part of a much longer posting.  I think it 
>>deserves a thread of its own.
>>In SCVP, there are two extensions levels: reqExtension and
>>queryExtensions. Extensions are there to allow for future unplanned 
>>standard extensions and/or for private extensions.
>>Denis pointed out that a similar discussion was held in the context of
>>RFC 3161, where the interpretation of the criticality bit was the following:
>>     If an extension, whether it is marked critical or not critical, is
>>     used by a requester but is not recognized by a time-stamping server,
>>     the server SHALL not issue a token and SHALL return a failure
>>In RFC 3161bis, this has been changed to:
>>     A server that does not recognize a non-critical extension SHALL
>>ignore
>>     the extension and SHALL NOT return an error for this. A server that
>>     recognizes an extension SHALL process the extension regardless of
>>     the value of the criticality flag. A server MUST reject the request
>>if it
>>     encounters a critical extension it does not recognize and in that
>>case
>>     SHALL return a failure.
>>This represents the current consensus for TSP. This is different from
>>the treatment that is indicated in the SCVP draft:
>>     In a request, if the critical item is TRUE, the server MUST NOT
>>     process the request unless it understands the extension.
>>     In a reply, if the critical item is TRUE, the client MUST NOT
>>process
>>     the response unless it understands the extension.
>>It would be nice if all of the PKIX WG protocols had a common extension 
>>approach, but that is not absolutely mandatory.
>>What should we do in SCVP?
>>Russ
>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4GwDn11491 for ietf-pkix-bks; Mon, 4 Nov 2002 08:58:13 -0800 (PST)
Received: from titan.solar.com.br (titan.solar.com.br [200.199.212.42]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA4GwCW11486 for <[e-mail]>; Mon, 4 Nov 2002 08:58:12 -0800 (PST)
Received: (qmail 23278 invoked from network); 4 Nov 2002 14:58:45 -0200
Received: from 200-163-14-249-bsace7014.dsl.telebrasilia.net.br (HELO eseclucianoN) (200.163.14.249) by 0 with SMTP; 4 Nov 2002 14:58:45 -0200
Message-ID: <012b01c2842b$ef000010$f902a8c0@ESEC>
Reply-To: "Luciano da Silva Coelho" <[e-mail]>
From: "Luciano da Silva Coelho" <[e-mail]>
To: <[e-mail]>
Subject: Doubt about  Revocation Message from CMP
Date: Mon, 4 Nov 2002 14:59:32 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Guys,

    Could you help me with a doubt about the message "Revocation Response"
from CMP (RFC 2010).
    Suppose the following scenario:

    - The CA has five certificates issued for two entities (X and Y).
        - Entity X has two certificates (serialNumber=1 and serialNumber=2)
        - Entiry Y has three certificates (serialNumber=3, serialNumber=4
and serialNumber=5)
    - A RA wants to revoke one certificate from X and all the certificates
from Y

    To do that the RA sends the Revocation Request Message:

    RevReqContent {
        RevDetails {
            CertTemplate {
                issuer = CA
                serialNumber = 1
            }
        },
        RevDetails {
            CertTemplate {
                issuer = CA
                subject = Y
            }
        }
    }

    Suppose that all the requests were attempts with status "granted".

    Now, what Revocation Response Message must I expect? I need receive all
the Revoked Certificates' CertIds.

    My doubt is how the CertIds are returned. The RFC 3280's text

"
The response to the above message. If produced, this is sent to the
   requester of the revocation. (A separate revocation announcement
   message MAY be sent to the subject of the certificate for which
   revocation was requested.)

  RevRepContent ::= SEQUENCE {
      status        SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
      -- in same order as was sent in RevReqContent
      revCerts  [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
      -- IDs for which revocation was requested (same order as status)
      crls      [1] SEQUENCE SIZE (1..MAX) OF CertificateList  OPTIONAL
      -- the resulting CRLs (there may be more than one)
  }
"
    It isn't sufficient clear for me when it says "...IDs for which
revocation was requested (same order as status)...".
    IMHO, the revCerts should be :
        revCerts [0] SEQUENCE SIZE (1..MAX) OF SEQUENCE OF CertId OPTIONAL.
    In this case, there will be one element in the first SEQUENCE for each
element at the status SEQUENCE. And, It could have more than one CertId for
the same status (for the case the CA has revoked more than one certificate
from one request).


    Thanks in advance.

    Luciano Coelho
    [e-mail]
    e-Sec Data Security Technology
    http://www.esec.com.br



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4Fcih06648 for ietf-pkix-bks; Mon, 4 Nov 2002 07:38:44 -0800 (PST)
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4FciW06639 for <[e-mail]>; Mon, 4 Nov 2002 07:38:44 -0800 (PST)
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id gA4FcdMP012022; Mon, 4 Nov 2002 07:38:40 -0800
From: "Ambarish Malpani" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, <[e-mail]>
Subject: RE: Criticality and SCVP Extensions
Date: Mon, 4 Nov 2002 07:38:51 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The intent in SCVP was the same as 3161bis.

I agree.

Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Housley, Russ
> Sent: Sunday, November 03, 2002 11:13 AM
> To: [e-mail]
> Subject: Criticality and SCVP Extensions
>
>
>
> The open issues section in SCVP has highlighted extension criticality for
> many months.  Yet, it has not really been discussed.  Recently, Denis
> Pinkas raised this issue as part of a much longer posting.  I think it
> deserves a thread of its own.
>
> In SCVP, there are two extensions levels: reqExtension and
> queryExtensions.
> Extensions are there to allow for future unplanned standard extensions
> and/or for private extensions.
>
> Denis pointed out that a similar discussion was held in the
> context of RFC
> 3161, where the interpretation of the criticality bit was the following:
>
>     If an extension, whether it is marked critical or not critical, is
>     used by a requester but is not recognized by a time-stamping server,
>     the server SHALL not issue a token and SHALL return a failure
>
> In RFC 3161bis, this has been changed to:
>
>     A server that does not recognize a non-critical extension SHALL ignore
>     the extension and SHALL NOT return an error for this. A server that
>     recognizes an extension SHALL process the extension regardless of
>     the value of the criticality flag. A server MUST reject the
> request if it
>     encounters a critical extension it does not recognize and in that case
>     SHALL return a failure.
>
> This represents the current consensus for TSP. This is different from the
> treatment that is indicated in the SCVP draft:
>
>     In a request, if the critical item is TRUE, the server MUST NOT
>     process the request unless it understands the extension.
>
>     In a reply, if the critical item is TRUE, the client MUST NOT process
>     the response unless it understands the extension.
>
> It would be nice if all of the PKIX WG protocols had a common extension
> approach, but that is not absolutely mandatory.
>
> What should we do in SCVP?
>
> Russ
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4FTgW06409 for ietf-pkix-bks; Mon, 4 Nov 2002 07:29:42 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4FTeW06405 for <[e-mail]>; Mon, 4 Nov 2002 07:29:40 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA26732; Mon, 4 Nov 2002 16:30:11 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id QAA16952; Mon, 4 Nov 2002 16:29:39 +0100
Message-ID: <[e-mail]>
Date: Mon, 04 Nov 2002 16:29:34 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, [e-mail], Stefan Santesson <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor and Stefan,

> Denis,

> There is a way to accomplish associating multiple community logos within
> the existing draft. We permit the use of the logotype extension within
> attribute certificates as well as identity certificates. It is therefore
> possible to have an identity certificate, issued by Last National Bank
> to merchant foo with a community of Visa, and an attribute certificate,
> issued by Utah Credit Union to merchant foo with a community logo of
> MasterCard. In this situation, the UI can legitimacy display a community
> logotype for each valid certificate.

This does not solve the issue: there is still one single community logo type 
in a given certificate (whether it is a PKC or an AC).

The real issue is what do we call a "community".

Extracts from the present draft:

"The community may represent the subscribers of a service or any other group."

"The community logotype - is the general mark for a community. It identifies 
a service concept for entity identification and certificate issuance."

Well, the less that we can say is that this is not crystal clear !!! :-(

Within that definition both the logo CB and the logo VISA have their places.

CB is a logo used by some banks grouped under the GIE "Cartes Bancaire" and 
recognized by many French merchants.

VISA is a logo used by VISA and recognized by many merchants worldwide.
Both could be in a certificate.

Extract from : http://www.cartes-bancaires.com/GB/Pages/FrameVie.htm

A card bearing a "CB" logo is by definition an interbank card. One feature 
of the "CB" interbank system is that the card will be accepted even if the 
issuing bank is different from the merchant's bank or the bank managing the 
ATM.

(...)

In addition to the "CB" logo, "CB" cards can also have an international 
acceptance logo (Visa or MasterCard).

Denis




















> Trevor
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]] 
> Sent: Thursday, October 31, 2002 6:06 AM
> To: Denis Pinkas
> Cc: Housley, Russ; [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
> 
> 
> Denis,
> 
> I think you are mixing concepts and to some extent misreading the
> standard.
> 
> I comment below;
> 
> 
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]]On Behalf Of Denis Pinkas
>>Sent: Wednesday, October 30, 2002 2:47 PM
>>To: Stefan Santesson
>>Cc: Housley, Russ; [e-mail]
>>Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
>>
>>
>>
> 
> 
> stuff deleted...
> 
> 
>> > 1) We expand the concept beyond the intended scope
>> > 2) We make it harder and more complex for the GUI implementers
>>to make a
>> > distinct application.
>>
>>What is the "intended scope" ? Until it is clearly defined, you cannot
> 
> say
> 
>>that this is contradictory. So there is no demonstration here.
> 
> 
> Intentions and scopes are included in sections 1 and 2. The scope is
> clearly
> to allow issuers to claim that they issue a certificate as part of a
> community. The value of having just 1 community is that it brings
> clarity to
> the concept. There are numerous of examples in real life of this
> situation:
> 
> 1) Gasoline stations. They may be independent enterprises but they are
> sometimes members of A community (Shell, Esso etc)
> 2) Shops.. same thing.
> 3) Credit cards
> 4) Airlines
> ....
> ....
> 
> The common ground is that there is a point of issuing a service under
> JUST 1
> community. One big reason is that there generally is some kind of common
> explicit or implicit liability or protection of brand involved. If one
> service would be Both VISA AND MasterCard at the same time, or both
> SHELL
> AND ESSO or.... who would protect the brands, who would take
> responsibility
> for that ....
> 
> To my knowledge that type of situation does not exist.
> 
> All examples you state are not examples of multiple communities but
> examples
> of other aspects of reality.
> 
> So a good thing with having just 1 community logotype proved by you
> here.
> That is that people can't abuse the standard and put any obscure
> logotype as
> 1 of 10 community logos, making the GUI makers insane :-)
> 
> 
>>What is harder ? Display is always an option. We do not mandate
>>what MUST be
>>displayed.
> 
> 
> For a GUI of this kind, especially if we want to create a visual
> equivalent
> of an ID-card on the screen (in a standard format), it helps
> implementers to
> know if they will handle 1 or none logo, or if they must be prepared to
> handle any number of logos.
> 
> As said above, if this is not limited, as GUI maker you MUST expect CA:s
> to
> put in a whole bunch of obscure logos here representing everything from
> loyalty scheme, accreditation scheme, partners, sponsors...... you name
> it.
> 
> This is why the principle is good to say that the 3 main logotype types
> can
> only be 1 logo of each type.
> 
> If you want to include more logos, you provide them as other logos,
> according to section 4.2. This is a good structured way that provide
> clear
> expectations for the GUI makers.
> 
> 
>> > Denis,
>> >
>> > We had this discussion in Yokohama and all examples you came
>>up with had
>> > to do with loyalty structures rather than communities. The
>>community logo
>> > represent THE community within which the issuer acts as issuer.
>>
>>Besides loyalty structures (BTW, where do you place them ?),
>>there is as an
>>example "t-scheme approved" or what ever other "scheme" in Asia or in
> 
> the
> 
>>US. Same question: where do you place that information ?
>>
> 
> 
> This is not a community. I don't issue certificate belonging to the
> t-scheme
> community. T-scheme, TTP-NL, Web trust or whatever are conformance
> schemes
> that has nothing to do with community. If you want to display any
> logotype
> related to this you must define a new "other logo" type in section 4.2.
> 
> It could actually be a good idea to do that.
> 
> 
> 
>> > Example - A credit card can never be both MasterCard and VISA at
> 
> the
> 
>> > same time. If it would, who would be responsible for it if
> 
> something
> 
>> > goes wrong???
>>
>>Some merchants are accepting credit cards from Visa, Eurocard, and
> 
> AMEX.
> 
>>How are you going to be able to include that information in a server
>>certificate ?
> 
> 
> You don't
> 
> You may provide that information on the web page that is protected by
> the
> server certificate. But whatever you do, it is NOT part of the community
> logo in the server certificate.
> 
> 
> 
>>Some cards in my country have both the CB logo (CB = Carte
>>Bancaire) and the
>>Eurocard or VISA Logo.
>>
>>How are you going to be able to include that information in a person
>>certificate issued by a bank ?
> 
> 
> The standard allows 2 issuer logos for co-branding, 1:st the logo
> representing the Issuer organization, 2:nd the logo representing the
> community.
> 
> I'm not sure what function the CB logo has. If this is not covered by
> these
> logos, you can use some of the defined other logos (section 4.2), or
> define
> one for the purpose.
> 
> 
>> > If the community, within which the issuer operates when issuing a
>> > particular certificate, has a combined logo from two integrated
>> > community structures -
>> > Fine - This is then still just 1 community logo from the standards
>> > perspective.
>>
>>We never said that logos MUST be displayed. An application may look
> 
> for a
> 
>>given logo and chose to display it, if present. Combined logos would
> 
> not
> 
>>allow that feature and would be pretty big or unreadable since an
>>application would need to display, e.g. four, logos in a small
>>window size.
>>
> 
> 
> That's a feature, not a problem. This means that If the application
> display
> logo related to THE community, it can not screw up by showing just half
> of
> the relevant logo image data.
> 
> 
>> > I agree though that you can have multiple independent loyalty
> 
> schemes.
> 
>>Fine. Where do you place them ?
> 
> 
> Read section 4.2
> 
> Stuff deleted ...
> 
> 
>>Since a sentence is saying:
>>
>>     If a logotype is represented by more than one image file, then
> 
> the
> 
>>     image files MUST contain variants of the roughly the same image.
>>
>>My understanding is the following:
>>
>>image contains one or more variants of the roughly the same image. No
> 
> more
> 
>>that one of the LogotypeImage SHALL be displayed, since it is roughly
> 
> the
> 
>>same image.
>>
>>This does not permit to include images that are really different.
> 
> 
> Yes you are right. That is the defined meaning.
> 
> 
>>I am asking for:
>>
>>           communityLogo   [0] EXPLICIT SEQUENCE OF LogotypeInfo
> 
> OPTIONAL,
> 
>>instead of:
>>
>>           communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
>>
>>I hope that the above examples will be able to convince you.
> 
> 
> I regret to say that I'm not.
> 
> I still think it would make the standard worse
> 
> What would convince me is if anyone could show a realistic and relevant
> case
> where there are 2 independent communities, within which the issuer acts
> when
> issuing a certificate. I have yet to see that case.
> 
> /Stefan
> 
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4F92a03835 for ietf-pkix-bks; Mon, 4 Nov 2002 07:09:02 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4F91W03831 for <[e-mail]>; Mon, 4 Nov 2002 07:09:01 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16696; Mon, 4 Nov 2002 10:06:34 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-sim-00.txt
Date: Mon, 04 Nov 2002 10:06:33 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Subject 
                          Identification Method (SIM)
	Author(s)	: J. Park et al.
	Filename	: draft-ietf-pkix-sim-00.txt
	Pages		: 12
	Date		: 2002-11-1
	
This document provides the new straightforward approach to generate 
and verify unique information for identifying of the certificate 
subject. 
A Virtual ID(VID) may be put into the 'othername' field of the X.509 
subjectAltName certificate extension to make provisions for 
identifying the subject.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sim-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-sim-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-sim-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-sim-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-sim-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4F05M03445 for ietf-pkix-bks; Mon, 4 Nov 2002 07:00:05 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4F00W03432 for <[e-mail]>; Mon, 4 Nov 2002 07:00:00 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA25242; Mon, 4 Nov 2002 16:00:29 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id PAA14042; Mon, 4 Nov 2002 15:59:38 +0100
Message-ID: <[e-mail]>
Date: Mon, 04 Nov 2002 15:18:24 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "'Housley, Russ'" <[e-mail]>, [e-mail]
Subject: Re: Criticality and SCVP Extensions
References: <001701c283a6$374da380$1e00a8c0@Chokhani>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

The major problem with SCVP is that extensions are used in a way for which 
they were not intended for. It is some kind of "new way" of programming, 
where nearly all requests and responses have OIDs, even for the standard 
requests and responses that are defined in the draft ! With that programming 
style, the criticality bit is loosing its original meaning.

We already have a common approach which is the one consistant with both
RFC 3280 and RFC 3161. We do not need a new one.

However, we do not need the new way of programming of SCVP. So we can get 
rid of this issue by changing the programming style from SCVP.

Denis

> Russ:
> 
> The new TSP approach is consistent with what X.509 did about 1-2 years
> ago.  Thus, both the request and reply in SCVP should also follow that
> approach.  The approach (at the risk of repeating Denis and You) is:
> 
> 1.  If you recognize an extension, you must process it, regardless of
> its criticality.
> 
> 2.  If you encounter an extension that is critical and you do not
> recognize it, you must reject the object (i.e., transaction in the case
> of SCVP).  Now, in the case of SCVP, there may be some situations where
> the criticality of the extension may not matter.  For example, for some
> of the statusCode and for some of the replyStatus, it may not matter
> what a critical extension says; you know the response is bad and why.
> But, rather than a detailed treatment of possibilities, a general
> statement about rejection may be sufficient.
> 
> 3.  If you encounter an extension that is non-critical and you do not
> recognize it, you shall process the object by ignoring the extension
> (i.e., transaction in the case of SCVP).
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Housley, Russ
> Sent: Sunday, November 03, 2002 2:13 PM
> To: [e-mail]
> Subject: Criticality and SCVP Extensions
> 
> 
> 
> The open issues section in SCVP has highlighted extension criticality
> for 
> many months.  Yet, it has not really been discussed.  Recently, Denis 
> Pinkas raised this issue as part of a much longer posting.  I think it 
> deserves a thread of its own.
> 
> In SCVP, there are two extensions levels: reqExtension and
> queryExtensions. 
> Extensions are there to allow for future unplanned standard extensions 
> and/or for private extensions.
> 
> Denis pointed out that a similar discussion was held in the context of
> RFC 
> 3161, where the interpretation of the criticality bit was the following:
> 
>     If an extension, whether it is marked critical or not critical, is
>     used by a requester but is not recognized by a time-stamping server,
>     the server SHALL not issue a token and SHALL return a failure
> 
> In RFC 3161bis, this has been changed to:
> 
>     A server that does not recognize a non-critical extension SHALL
> ignore
>     the extension and SHALL NOT return an error for this. A server that
>     recognizes an extension SHALL process the extension regardless of
>     the value of the criticality flag. A server MUST reject the request
> if it
>     encounters a critical extension it does not recognize and in that
> case
>     SHALL return a failure.
> 
> This represents the current consensus for TSP. This is different from
> the 
> treatment that is indicated in the SCVP draft:
> 
>     In a request, if the critical item is TRUE, the server MUST NOT
>     process the request unless it understands the extension.
> 
>     In a reply, if the critical item is TRUE, the client MUST NOT
> process
>     the response unless it understands the extension.
> 
> It would be nice if all of the PKIX WG protocols had a common extension 
> approach, but that is not absolutely mandatory.
> 
> What should we do in SCVP?
> 
> Russ
> 
> 





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4F00203439 for ietf-pkix-bks; Mon, 4 Nov 2002 07:00:00 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4ExwW03426 for <[e-mail]>; Mon, 4 Nov 2002 06:59:59 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA25034 for <[e-mail]>; Mon, 4 Nov 2002 16:00:30 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id QAA12512 for <[e-mail]>; Mon, 4 Nov 2002 16:00:02 +0100
Message-ID: <[e-mail]>
Date: Mon, 04 Nov 2002 15:57:49 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-cvp-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have issued a new version of CVP "Certificate Validation Protocol".

The previous version was only covering DPV requirements. This new version 
now includes DPD requirements and the possibility to list the policies that 
are supported by the server.

It is now believed that this draft fully conforms with the requirements 
present in RFC 3379.

Section 5 on page 7 provides an overall description of the structure of a 
DPV/DPD request, while page 8 provides an overall description of the 
structure of a DPV/DPD response.

In the mean time, I have been in touch with the SCVP co-authors and we have 
been exchanging a few e-mails.

One of the major concerns I have with SCVP is its "programming style" which 
makes use of OIDs nearly everywhere. Another issue is the use of CMS. SCVP 
makes use of CMS, while CVP makes use of the signed structure used by PKC 
and ACs. Using "Dump ASN.1" would allow to easily debug CVP, but not SCVP. 
Besides these high level issues, there are other issues, which are more 
important.

FYI, I have posted about 9 pages of comments on SCVP to the co-authors and
I have received a response from Russ, today. So, we are still discussing ...

Denis

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
> 	Title		: Certificate Validation Protocol
> 	Author(s)	: D. Pinkas
> 	Filename	: draft-ietf-pkix-cvp-01.txt
> 	Pages		: 29
> 	Date		: 2002-10-31
> 	
> This document defines a protocol called Certificate Validation Protocol 
> (CVP) that can be used to:
> (1) query the validation or discovery policies supported by 
> a CVP server, 
> (2) validate one or more public key certificates according to a 
> single validation policy, or
> (3) obtain one or more certification paths for one or more certificates 
> according to a single discovery policy.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-cvp-01.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-pkix-cvp-01.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[e-mail].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-pkix-cvp-01.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA4ASqd16460 for ietf-pkix-bks; Mon, 4 Nov 2002 02:28:52 -0800 (PST)
Received: from mail1.belgacom.be (mail1.belgacom.be [195.13.15.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA4ASnW16456 for <[e-mail]>; Mon, 4 Nov 2002 02:28:50 -0800 (PST)
Received: from exhub01.bc (exchange.bc [45.34.4.231]) by mail1.belgacom.be  with SMTP id KAA27781; Mon, 4 Nov 2002 10:28:43 GMT
From: [e-mail]
Received: from 127.0.0.1 by exhub01.bc (InterScan E-Mail VirusWall NT); Mon, 04 Nov 2002 11:28:38 +0100
Received: by exhub01.bc with Internet Mail Service (5.5.2653.19) id <WG893GWJ>; Mon, 4 Nov 2002 11:28:38 +0100
Message-ID: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Legal entities who sign
Date: Mon, 4 Nov 2002 11:28:33 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jimi,

There is a profile for certification authorities issuing public key certificates and qualified certificates. Such profiles are based on RFC 2459 and are compliant with the european directive on electronic signature. I has also to be noted that country's internal laws on electroic signatures shall also comply with the requirements of the european directive.

So IMHO, i think that whether it has to be a commercial or governmental authority is of no worth if the corresponding authority doesn't comply with the country law and directives governing the issuiance of PK certificates and electronic signatures.

Anders,

I find very elegant the idea of using X509 certificates to express and implement "Legally signing certifificates" but where are we hence from the terms "signature policy", "committment textes", that where suggnested as a mean to define particular legal and contractual contexts? Does this mean that the certificate policy under which you issue "legally signing certificates" will stand for and replace the "signature policy"?

IMHO, i still think that the most important issue that still need to be resolved is an elegant, easy and standard mean to implement the "delegated signing capabilities".

Best regards,

malek.

-----Original Message-----
From: Jimi Thompson [mailto:[e-mail]]
Sent: 04 November 2002 03:31
To: Anders Rundgren; [e-mail]; J Adrian Pickering; Ing.
Raffaello Galli
Subject: Re: Legal entities who sign



Anders and others,

I tend to agree with you.  There needs to be a legally and probably
governmentally recognized issuing body for the certificates, for a couple of
reasons.  First off, it will halt any squabbling over who the ultimate CA is
going to be.  I also think that this responsibility should move away from
commercial CA's since they have a financial incentive to issue as many certs
as possible and not that much incentive for verification.  In addition, I
find that the fees that they charge are quite high and might prohibit
participation from certain areas of the world.  I think that the Post Office
is probably fairly wise since they tend to be highly physically available in
most parts of the world.   I think that the only thing that's really missing
is a DNS-like standard which would allow verification of authenticity,
parameters of validity, or revocation.

Another 2 cents,

Jimi Thompson

**** DISCLAIMER **** 
"This e-mail and any attachments thereto may contain information 
which is confidential and/or protected by intellectual property 
rights and are intended for the sole use of the recipient(s) named above. 
Any use of the information contained herein (including, but not limited to, 
total or partial reproduction, communication or distribution in any form) 
by persons other than the designated recipient(s) is prohibited. 
If you have received this e-mail in error, please notify the sender either 
by telephone or by e-mail and delete the material from any computer. 
Thank you for your cooperation."



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA421mT03359 for ietf-pkix-bks; Sun, 3 Nov 2002 18:01:48 -0800 (PST)
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA421lW03353 for <[e-mail]>; Sun, 3 Nov 2002 18:01:47 -0800 (PST)
Received: from Chokhani ([12.91.131.53]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20021104020128.QJSQ28413.mtiwmhc12.worldnet.att.net@Chokhani>; Mon, 4 Nov 2002 02:01:28 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Subject: RE: Criticality and SCVP Extensions
Date: Sun, 3 Nov 2002 21:02:22 -0500
Message-ID: <001701c283a6$374da380$1e00a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ:

The new TSP approach is consistent with what X.509 did about 1-2 years
ago.  Thus, both the request and reply in SCVP should also follow that
approach.  The approach (at the risk of repeating Denis and You) is:

1.  If you recognize an extension, you must process it, regardless of
its criticality.

2.  If you encounter an extension that is critical and you do not
recognize it, you must reject the object (i.e., transaction in the case
of SCVP).  Now, in the case of SCVP, there may be some situations where
the criticality of the extension may not matter.  For example, for some
of the statusCode and for some of the replyStatus, it may not matter
what a critical extension says; you know the response is bad and why.
But, rather than a detailed treatment of possibilities, a general
statement about rejection may be sufficient.

3.  If you encounter an extension that is non-critical and you do not
recognize it, you shall process the object by ignoring the extension
(i.e., transaction in the case of SCVP).

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Housley, Russ
Sent: Sunday, November 03, 2002 2:13 PM
To: [e-mail]
Subject: Criticality and SCVP Extensions



The open issues section in SCVP has highlighted extension criticality
for 
many months.  Yet, it has not really been discussed.  Recently, Denis 
Pinkas raised this issue as part of a much longer posting.  I think it 
deserves a thread of its own.

In SCVP, there are two extensions levels: reqExtension and
queryExtensions. 
Extensions are there to allow for future unplanned standard extensions 
and/or for private extensions.

Denis pointed out that a similar discussion was held in the context of
RFC 
3161, where the interpretation of the criticality bit was the following:

    If an extension, whether it is marked critical or not critical, is
    used by a requester but is not recognized by a time-stamping server,
    the server SHALL not issue a token and SHALL return a failure

In RFC 3161bis, this has been changed to:

    A server that does not recognize a non-critical extension SHALL
ignore
    the extension and SHALL NOT return an error for this. A server that
    recognizes an extension SHALL process the extension regardless of
    the value of the criticality flag. A server MUST reject the request
if it
    encounters a critical extension it does not recognize and in that
case
    SHALL return a failure.

This represents the current consensus for TSP. This is different from
the 
treatment that is indicated in the SCVP draft:

    In a request, if the critical item is TRUE, the server MUST NOT
    process the request unless it understands the extension.

    In a reply, if the critical item is TRUE, the client MUST NOT
process
    the response unless it understands the extension.

It would be nice if all of the PKIX WG protocols had a common extension 
approach, but that is not absolutely mandatory.

What should we do in SCVP?

Russ



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA40U7G29549 for ietf-pkix-bks; Sun, 3 Nov 2002 16:30:07 -0800 (PST)
Received: from smtpauth2-ext.prodigy.net (smtpauth2-ext.prodigy.net [207.115.63.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA40U5W29542 for <[e-mail]>; Sun, 3 Nov 2002 16:30:05 -0800 (PST)
Received: from swift (crtntx1-ar1-4-60-242-193.crtntx1.dsl-verizon.net [4.60.242.193]) (authenticated) by smtpauth2-ext.prodigy.net (8.11.0/8.11.0) with ESMTP id gA40Tvl349568; Sun, 3 Nov 2002 19:29:57 -0500
Message-ID: <007001c283aa$30bb1080$c1f23c04@swift>
Reply-To: "Jimi Thompson" <[e-mail]>
From: "Jimi Thompson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>, "J Adrian Pickering" <[e-mail]>, "Ing. Raffaello Galli" <[e-mail]>
References: <003c01c280bc$3cc70c80$0500a8c0@arport> <009601c2824c$0c84cb70$c1f23c04@swift> <005901c28323$c1375c40$0500a8c0@arport>
Subject: Re: Legal entities who sign
Date: Sun, 3 Nov 2002 18:30:40 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders and others,

I tend to agree with you.  There needs to be a legally and probably
governmentally recognized issuing body for the certificates, for a couple of
reasons.  First off, it will halt any squabbling over who the ultimate CA is
going to be.  I also think that this responsibility should move away from
commercial CA's since they have a financial incentive to issue as many certs
as possible and not that much incentive for verification.  In addition, I
find that the fees that they charge are quite high and might prohibit
participation from certain areas of the world.  I think that the Post Office
is probably fairly wise since they tend to be highly physically available in
most parts of the world.   I think that the only thing that's really missing
is a DNS-like standard which would allow verification of authenticity,
parameters of validity, or revocation.

Another 2 cents,

Jimi Thompson



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA3KwAM18933 for ietf-pkix-bks; Sun, 3 Nov 2002 12:58:10 -0800 (PST)
Received: from gonzo.aus.rsa.com (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id gA3Kw8W18926 for <[e-mail]>; Sun, 3 Nov 2002 12:58:09 -0800 (PST)
Received: from grover by gonzo.aus.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Nov 2002 20:59:11 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id gA3L44q07664 for <[e-mail]>; Mon, 4 Nov 2002 07:04:04 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <QPRAH5PJ>; Mon, 4 Nov 2002 06:56:41 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.8]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPW24LR; Sun, 3 Nov 2002 15:57:45 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sun, 03 Nov 2002 14:12:41 -0500
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Criticality and SCVP Extensions
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The open issues section in SCVP has highlighted extension criticality for 
many months.  Yet, it has not really been discussed.  Recently, Denis 
Pinkas raised this issue as part of a much longer posting.  I think it 
deserves a thread of its own.

In SCVP, there are two extensions levels: reqExtension and queryExtensions. 
Extensions are there to allow for future unplanned standard extensions 
and/or for private extensions.

Denis pointed out that a similar discussion was held in the context of RFC 
3161, where the interpretation of the criticality bit was the following:

    If an extension, whether it is marked critical or not critical, is
    used by a requester but is not recognized by a time-stamping server,
    the server SHALL not issue a token and SHALL return a failure

In RFC 3161bis, this has been changed to:

    A server that does not recognize a non-critical extension SHALL ignore
    the extension and SHALL NOT return an error for this. A server that
    recognizes an extension SHALL process the extension regardless of
    the value of the criticality flag. A server MUST reject the request if it
    encounters a critical extension it does not recognize and in that case
    SHALL return a failure.

This represents the current consensus for TSP. This is different from the 
treatment that is indicated in the SCVP draft:

    In a request, if the critical item is TRUE, the server MUST NOT
    process the request unless it understands the extension.

    In a reply, if the critical item is TRUE, the client MUST NOT process
    the response unless it understands the extension.

It would be nice if all of the PKIX WG protocols had a common extension 
approach, but that is not absolutely mandatory.

What should we do in SCVP?

Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA3BZpp12017 for ietf-pkix-bks; Sun, 3 Nov 2002 03:35:51 -0800 (PST)
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA3BZaW12010 for <[e-mail]>; Sun, 3 Nov 2002 03:35:37 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailf.telia.com (8.12.5/8.12.5) with SMTP id gA3BZM7p005357; Sun, 3 Nov 2002 12:35:22 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <005901c28323$c1375c40$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Jimi Thompson" <[e-mail]>, <[e-mail]>, "J Adrian Pickering" <[e-mail]>, "Ing. Raffaello Galli" <[e-mail]>
References: <003c01c280bc$3cc70c80$0500a8c0@arport> <009601c2824c$0c84cb70$c1f23c04@swift>
Subject: Re: Legal entities who sign
Date: Sun, 3 Nov 2002 11:28:20 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanx for your comments Jimi, Adrian, Lynn and Raffaello.

My [long-winding] response is probably a bit "orthogonal" as
the question from  _my_ point of view is really how to "map" the
de-facto standard since 20-30 years back, for sending common
e-business documents like purchase orders and invoices between
companies, into PKI.  The de-facto standard constitutes of leased
lines, shared secrets, VPNs, and EDI partner IDs.

BEFORE the advent of PKI, legal issues in _this_ context (with
respect to repudiation of sent documents), were not perceived as
a problem.  The same goes for authorization as the general feeling
is that business documents  that "look authentic", are also assumed
to be "authorized", regardless if the "signature" is an almost
unreadable figure on paper, or just a well-known e-mail address.

TRUST in the sense that you trust your business partners for
"executing" (paying, shipping, selling etc) is, and will _continue_
to be the major business issue.   PKI doesn't not change this.

The PROBLEM: To go from current "crude-but-working" solutions,
to not very well understood PKI-structures depending on a multitude
of CAs and layered external authorization-schemes requires a
_major_ rewrite of all business systems, including support for
entirely new and _extremely_awkward_ business (?)-processes like
add external CA-root, renew external CA-root, set-up certificate
mapping scheme, add external user, remove external user, etc.
My "gut-feeling" tells me this will never happen on a grand scale.

======================================================
- TTP-issued Legal-entity-only-certificates OTOH, simply extend current
  schemes while adding considerable technical strength and trust.

- Properly applied,  such certificates can also enable _globally_working_
  message-based "VPNs", costing FRACTIONS of current alternatives.

- Legal-entity-only signed messages allow adding arbitrarily sophisticated
  authorization data as message _payload_, when and if such data is needed
  and agreed upon, in effect offering a virtually unlimited path to the future.

- Legal-entity-only-certificates do not depend on X.500-directories, neither
  internally nor externally.  An organization may optionally "publish" such a
  certificate on their home-page.

- And then addressing much, much more, including Web Services, privacy,
  archiving, on-line authorization control, client-side PKI independence,
  interoperability, system protection, SAML, etc. etc...
======================================================

               So WHERE do we (the PKI community), go from here?

It's ALIVE!

Although I am moderately impressed with PKI-activities going on
in Sweden, I note with great satisfaction that the Swedish authorities
apparently plan to communicate through nodes equipped with the
authorities' "stamp-certificates".  Using https and XML BTW.

Due to the fact that globally operating CAs, including VeriSign, Identrus,
and GlobalSign, do not yet even seem to understand the "concept" of
legal-entity-only-certificates, the "stamp-certificates" will be
produced by the Swedish Post Office.

Best Regards
Anders Rundgren
Senior e-Commerce Architect






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA30ujG18024 for ietf-pkix-bks; Sat, 2 Nov 2002 16:56:45 -0800 (PST)
Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA30uhW18019 for <[e-mail]>; Sat, 2 Nov 2002 16:56:43 -0800 (PST)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18894I-0006vZ-00; Sat, 02 Nov 2002 19:56:46 -0500
Message-ID: <[e-mail]>
Date: Sat, 02 Nov 2002 19:56:17 -0500
From: "Phillip H. Griffin" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ebbe Hansen <[e-mail]>
CC: [e-mail]
Subject: Re: Certificate profile for Biometrics information.
References: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------050509090808080208020306"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------050509090808080208020306
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

See http://www.oasis-open.org/committees/xcbf/#documents,

    * XML Common Biometric Format (XCBF) Working Draft
      <http://oasis-open.org/committees/xcbf/docs/XCBF20021024.zip>
      October 24, 2002

    * XCBF ASN.1 Schema for XML Markup
      <http://oasis-open.org/committees/xcbf/docs/XCBFSchema20021024.zip>
      October 24, 2002

Certificate extensions have been defined here for both X.509 Certificate and
AttributeCertificate types, and for X.9.68 Digital Certificates for Mobile/
Remote and High Volume Transaction Systems for Financial Services. These can
be encoded in either ASN.1 Distinguished Encoding Rules (DER) or using 
the new
XML Encoding Rules (XER).

I'm cutting the same definitions into the current revision of X9.84 
Biometric Information
Management and Security this week. We hope to have this revision 
completed and into
X9 ballot by the end of the year. After this, the US will likely propose 
this revision into
ISO TC 68/SC2 Security and General Banking Operations as a new work item.

Working code from my company and from others already supports this 
certificate
extension payload. See http://asn-1.com/biolojava.htm for more information.

Phil Griffin


Ebbe Hansen wrote:

>I am looking for biometrics profile-definitions on how biometrics reference
>information may be encoded and embedded into X.509 certificates (Public Key
>Certificates as well as Attribute Certificates). The only
>"biometrics-data-extension" I have found so far is included in RFC 3039 as
>the "biometricInfo" extension.
>
>Are there other biometrics profiles that have been defined at this time?
>
>Regards Ebbe Hansen
>
>
>
>
>  
>


--------------050509090808080208020306
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
See <a class="moz-txt-link-freetext" href="http://www.oasis-open.org/committees/xcbf/#documents">http://www.oasis-open.org/committees/xcbf/#documents</a>,
<ul>
  <li>     <a
 href="http://oasis-open.org/committees/xcbf/docs/XCBF20021024.zip"
 target="_blank">        XML Common Biometric Format (XCBF) Working Draft</a>
October 24, 2002<br>
    <br>
   </li>
  <li>     <a
 href="http://oasis-open.org/committees/xcbf/docs/XCBFSchema20021024.zip"
 target="_blank">        XCBF ASN.1 Schema for XML Markup</a> October 24,
2002<br>
  </li>
</ul>
Certificate extensions have been defined here for both X.509 <small><font
 face="Courier New, Courier, monospace">Certificate </font></small>and<br>
<small><font face="Courier New, Courier, monospace">AttributeCertificate
</font></small>types, and for X.9.68 <i>Digital Certificates for Mobile/<br>
Remote and High Volume Transaction Systems for Financial Services</i>. These
can<br>
be encoded in either ASN.1 Distinguished Encoding Rules (DER) or using the
new<br>
XML Encoding Rules (XER).<br>
<br>
I'm cutting the same definitions into the current revision of X9.84 Biometric
Information<br>
Management and Security this week. We hope to have this revision completed
and into<br>
X9 ballot by the end of the year. After this, the US will likely propose
this revision into<br>
ISO TC 68/SC2 Security and General Banking Operations as a new work item.<br>
<br>
Working code from my company and from others already supports this certificate<br>
extension payload. See <a class="moz-txt-link-freetext" href="http://asn-1.com/biolojava.htm">http://asn-1.com/biolojava.htm</a> for more information.<br>
<br>
Phil Griffin<br>
<br>
<br>
Ebbe Hansen wrote:<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">I am looking for biometrics profile-definitions on how biometrics reference
information may be encoded and embedded into X.509 certificates (Public Key
Certificates as well as Attribute Certificates). The only
"biometrics-data-extension" I have found so far is included in RFC 3039 as
the "biometricInfo" extension.

Are there other biometrics profiles that have been defined at this time?

Regards Ebbe Hansen




  </pre>
</blockquote>
<br>
</body>
</html>

--------------050509090808080208020306--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA2NXBP13205 for ietf-pkix-bks; Sat, 2 Nov 2002 15:33:11 -0800 (PST)
Received: from dc-mx03.cluster1.charter.net (dc-mx03.cluster1.charter.net [209.225.8.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA2NX6W13200 for <[e-mail]>; Sat, 2 Nov 2002 15:33:10 -0800 (PST)
Received: from [66.189.150.200] (HELO pc1) by dc-mx03.cluster1.charter.net (CommuniGate Pro SMTP 3.5.9) with SMTP id 35649653 for [e-mail]; Sat, 02 Nov 2002 18:33:04 -0500
From: "Ebbe Hansen" <[e-mail]>
To: <[e-mail]>
Subject: Certificate profile for Biometrics information.
Date: Sat, 2 Nov 2002 15:32:42 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am looking for biometrics profile-definitions on how biometrics reference
information may be encoded and embedded into X.509 certificates (Public Key
Certificates as well as Attribute Certificates). The only
"biometrics-data-extension" I have found so far is included in RFC 3039 as
the "biometricInfo" extension.

Are there other biometrics profiles that have been defined at this time?

Regards Ebbe Hansen





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA2LGTP05955 for ietf-pkix-bks; Sat, 2 Nov 2002 13:16:29 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA2LGRW05943 for <[e-mail]>; Sat, 2 Nov 2002 13:16:28 -0800 (PST)
Subject: Re: Legal entities who sign
To: "Jimi Thompson" <[e-mail]>
Cc: "Anders Rundgren" <[e-mail]>, [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sat, 2 Nov 2002 14:15:54 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 11/02/2002 04:19:08 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

there may be two separate issues. there is contract with human
demonstrating that they intended to sign what was signed. Some of this is
analogous to some of the click-thru stuff ... where it is demonstrated that
there is a high probability that a human actually had to look at the T&Cs
as part of doing the click (placing the click at the bottom of long page
where the person had to scroll down thru the page to get to the click
button).  legal signature can carry with it the concept that the person
read, understood, agrees, and intended to sign what was signed.

as referenced in the past .... there is a computerized process that
involves secure hash and asymmetric cryptography that has a label "digital
signature". At the basic level ... the use of the term "signature" in
"digital signature" and the term "signature" in "legal signature" .... may
only have purely superficial relationship to each other. it is possible to
have secure hash and asymmetric cryptography that meets all the technical
specifications of a digital signature and carries with it none of the
characteristics of a legal signature.

once parties have a binding contract ... the contract can specify all sorts
of processes that can be binding for the parties ... aka a particular
automated mechanism doing something that is deemed acceptable by both
parties. the signing of something by an automated agent can be accepted on
good faith if the contract stipulates that it is to be accepted (i.e. say
in the case of a PO).



jimit@prodigy net at 11/2/2002 1:44 am wrote:


In order to establish non-repudiation, I would say that you probably need
to have the CEO sign the authorized agents signature agreeing that they are
authorized under the parameters issued.  This should satisfy the
"non-repudiation" needs and still provide for statement about delegation of
authority.  I think that this solves your problem, as the only time a CEO's
key is needed would be to authorize a new agent.  The other, more
accessible people, would be available to handle day to day business.





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA2GjIp21085 for ietf-pkix-bks; Sat, 2 Nov 2002 08:45:18 -0800 (PST)
Received: from nemesis.systems.pipex.net (nemesis.systems.pipex.net [62.241.160.8]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA2GjHW21081 for <[e-mail]>; Sat, 2 Nov 2002 08:45:17 -0800 (PST)
Received: from home.ecs.soton.ac.uk (81-86-178-22.dsl.pipex.com [81.86.178.22]) by nemesis.systems.pipex.net (Postfix) with ESMTP id 7ED6916008020 for <[e-mail]>; Sat,  2 Nov 2002 16:44:58 +0000 (GMT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sat, 02 Nov 2002 16:44:29 +0000
To: <[e-mail]>
From: J Adrian Pickering <[e-mail]>
Subject: Re: Legal entities who sign
In-Reply-To: <009601c2824c$0c84cb70$c1f23c04@swift>
References: <003c01c280bc$3cc70c80$0500a8c0@arport>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 08:44 02/11/2002, Jimi Thompson wrote:

><SNIP>
> > According to "e-lawyers", legal entities cannot sign as even
> > a delegated signer must be physical person.
></SNIP>
>
>IMHO, secretaries and/or administrative assistants have been signing
>documents for their CEO's for decades.  I know of several that are so good
>that the signatures are virtually indistinguishable.  How is this any
>different that having the CEO have more than one i-key (for example) so that
>his assistant can sign documents in his absence?
>
>Is the CEO really the ONLY person on the planet that has signing authority
>for the company?  Most certainly not in the case of an ink signature.  All
>sorts of people throughout any company have the ability to sign things.  In
>legal-ese, authorized agents abound.  Procurement people sign things every
>day, using their own pen-and-ink signature, but binding the company.
>Shipping and receiving folks sign things every day, using their own
>signature, also binding the company.

They should not really be signing with their own signature but one 
identifying them in their delegated role. Most people have a repertoire of 
signatures which they use according to the role they are performing. The 
'forgery' you suggest above is, of course, OK because the person doing it 
acting in the role the CEO is allowing them to be: the CEO would not deny 
it is his/her own signature because of the relationship of trust that 
exists. It is a shame that this sort of signature use is necessary! Also, I 
hope most CFOs do not use the same signature on their personal cheques as 
printed on the corporate ones!

>   Most of these folks have a limit of
>some kind on what they are allowed to sign.  Procurement folks, for example,
>usually have a dollar limit.  I think that the real question is how to
>include the limits and/or parameters into the certificate ( i.e. JoeBob's
>certificate from Procurement at XYZ Corp is good but only up to $5000.00).
>The XML folks might have some answers there.

Again, in an earlier version of this thread, I was asking why Attribute 
Certificates do not seem to being treated as the solution to this. The 
individual signs in their role. The CEO and the company manage the 
delegation/authorisation matters internally and individuals qualify their 
signatures with them. In the example above JoeBob may sign as a US citizen 
(a certified, live human) and the XYZ-managed AC says he does so as 
Procurement at XYZ Corp with authority to $5k.

Note that this approach does add a benefit that the person signing is a 
'guaranteed real human' and there is a recognised authority attesting to 
this (such as the US government or their agents). This satisifies the 
lawyers. If you combine the individual and the role then you have an 
explosion of certificates for everyone to manage.


>In order to establish non-repudiation, I would say that you probably need to
>have the CEO sign the authorized agents signature agreeing that they are
>authorized under the parameters issued.  This should satisfy the
>"non-repudiation" needs and still provide for statement about delegation of
>authority.  I think that this solves your problem, as the only time a CEO's
>key is needed would be to authorize a new agent.  The other, more accessible
>people, would be available to handle day to day business.
>
>You have a live human signing documents, which makes the "e-lawyers" happy.
>It handles the "real world" delegation of authority that happens inside
>companies.  I think that this solution satisfies all the criteria.  If I've
>missed something, I'm sure that someone on the list will happily point it
>out :)

Echoed. I think solutions that map reasonably clearly onto current custom 
and practice have a much better chance of adoption. I know there may be 
better ways of doing this in the future, but we have to engineer solutions 
for the real world to get used to now.


>Just my extremely humble 2 cents,

...and my further 2 pence.

Regards,

Adrian Pickering/
University of Southampton UK



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA26hkj21246 for ietf-pkix-bks; Fri, 1 Nov 2002 22:43:46 -0800 (PST)
Received: from smtpauth2-ext.prodigy.net (smtpauth2-ext.prodigy.net [207.115.63.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA26hhW21236 for <[e-mail]>; Fri, 1 Nov 2002 22:43:43 -0800 (PST)
Received: from swift (crtntx1-ar1-4-60-242-193.crtntx1.dsl-verizon.net [4.60.242.193]) (authenticated) by smtpauth2-ext.prodigy.net (8.11.0/8.11.0) with ESMTP id gA26hjl223466; Sat, 2 Nov 2002 01:43:45 -0500
Message-ID: <009601c2824c$0c84cb70$c1f23c04@swift>
Reply-To: "Jimi Thompson" <[e-mail]>
From: "Jimi Thompson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
References: <003c01c280bc$3cc70c80$0500a8c0@arport>
Subject: Re: Legal entities who sign
Date: Sat, 2 Nov 2002 00:44:21 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<SNIP>
> According to "e-lawyers", legal entities cannot sign as even
> a delegated signer must be physical person.
</SNIP>

IMHO, secretaries and/or administrative assistants have been signing
documents for their CEO's for decades.  I know of several that are so good
that the signatures are virtually indistinguishable.  How is this any
different that having the CEO have more than one i-key (for example) so that
his assistant can sign documents in his absence?

Is the CEO really the ONLY person on the planet that has signing authority
for the company?  Most certainly not in the case of an ink signature.  All
sorts of people throughout any company have the ability to sign things.  In
legal-ese, authorized agents abound.  Procurement people sign things every
day, using their own pen-and-ink signature, but binding the company.
Shipping and receiving folks sign things every day, using their own
signature, also binding the company.  Most of these folks have a limit of
some kind on what they are allowed to sign.  Procurement folks, for example,
usually have a dollar limit.  I think that the real question is how to
include the limits and/or parameters into the certificate ( i.e. JoeBob's
certificate from Procurement at XYZ Corp is good but only up to $5000.00).
The XML folks might have some answers there.

In order to establish non-repudiation, I would say that you probably need to
have the CEO sign the authorized agents signature agreeing that they are
authorized under the parameters issued.  This should satisfy the
"non-repudiation" needs and still provide for statement about delegation of
authority.  I think that this solves your problem, as the only time a CEO's
key is needed would be to authorize a new agent.  The other, more accessible
people, would be available to handle day to day business.

You have a live human signing documents, which makes the "e-lawyers" happy.
It handles the "real world" delegation of authority that happens inside
companies.  I think that this solution satisfies all the criteria.  If I've
missed something, I'm sure that someone on the list will happily point it
out :)

Just my extremely humble 2 cents,

Jimi



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gA1Djt528630 for ietf-pkix-bks; Fri, 1 Nov 2002 05:45:55 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA1DjsW28626 for <[e-mail]>; Fri, 1 Nov 2002 05:45:54 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06478; Fri, 1 Nov 2002 08:43:28 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cvp-01.txt
Date: Fri, 01 Nov 2002 08:43:28 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Certificate Validation Protocol
	Author(s)	: D. Pinkas
	Filename	: draft-ietf-pkix-cvp-01.txt
	Pages		: 29
	Date		: 2002-10-31
	
This document defines a protocol called Certificate Validation Protocol 
(CVP) that can be used to:
(1) query the validation or discovery policies supported by 
a CVP server, 
(2) validate one or more public key certificates according to a 
single validation policy, or
(3) obtain one or more certification paths for one or more certificates 
according to a single discovery policy.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cvp-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cvp-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cvp-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cvp-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cvp-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--