RE: I-D ACTION:draft-ietf-pkix-logotypes-07.txt

["Trevor Freeman" <[e-mail]>]

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.
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 g9VIMFh02306 for ietf-pkix-bks; Thu, 31 Oct 2002 10:22:15 -0800 (PST)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VIMBW02301 for <[e-mail]>; Thu, 31 Oct 2002 10:22:11 -0800 (PST)
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 31 Oct 2002 10:22:03 -0800
Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 31 Oct 2002 10:22:03 -0800
Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 31 Oct 2002 10:22:03 -0800
Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 31 Oct 2002 10:22:02 -0800
Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Thu, 31 Oct 2002 10:22:02 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6771.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
Date: Thu, 31 Oct 2002 10:22:01 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
Thread-Index: AcKA50OIIK57xvTITtilCQT8bnUdZgAISpNw
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, <[e-mail]>, "Stefan Santesson" <[e-mail]>
X-OriginalArrivalTime: 31 Oct 2002 18:22:02.0853 (UTC) FILETIME=[68D96950:01C2810A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9VIMEW02303
Sender: [e-mail]
Precedence: 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,
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.
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 g9VFsGj22081 for ietf-pkix-bks; Thu, 31 Oct 2002 07:54:16 -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 g9VFsEW22071 for <[e-mail]>; Thu, 31 Oct 2002 07:54:14 -0800 (PST)
Subject: Re: Legal entities who sign
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, 31 Oct 2002 08:37:55 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 10/31/2002 10:56:55 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>

lot of legal signature stuff touches on the non-repudiation subject ....
which has requirements pretty much orthogonal to anything that might be
stated in a certificate (this was discussed some time ago regarding what
does a "non-repudiation" flag actually mean ... aka you can place thousands
of bits and megabytes of prose in a certificate ... and it doesn't change
the situation).

past refs:
http://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary &
taxonomy
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#12 TOC for world bank e-security
paper
http://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security
Issues
http://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep2 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
http://www.garlic.com/~lynn/2002g.html#37 Security Issues of using Internet
Banking
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
http://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you
are?
http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman  schema
belong to Public Key schema family?
http://www.garlic.com/~lynn/2002i.html#77 Does Diffie-Hellman  schema
belong to Public Key schema family?
http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
http://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and
hashing
http://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce
using POWF
http://www.garlic.com/~lynn/2002n.html#16 Help! Good protocol for national
ID card?
http://www.garlic.com/~lynn/2002n.html#19 Help! Good protocol for national
ID card?



                                                                                                                       
                     "Anders Rundgren"                                                                                 
                    <anders.rundgren@t     To:      <[e-mail]>                                                
                             elia.com>     cc:                                                                         
                              Sent by:     Subject:      Legal entities who sign                                       
                    owner-ietf-pkix@ma                                                                                 
                            il.imc.org                                                                                 
                                                                                                                       
                                                                                                                       
                      10/31/2002 02:02                                                                                 
                                    AM                                                                                 
                                                                                                                       
                                                                                                                       





According to "e-lawyers", legal entities cannot sign as even
a delegated signer must be physical person.  This creates
huge practical problems and is also quite ridiculous, here
thinking of a CEO-certificate/key stored in a locked server-
room that not even the CEO may have a key to, and used by
business-systems, often completely out of the CEO's control.

Question: Would it be completely unthinkable that a
certificate policy stated that the owner of this certificate
(which only identifies a legal entity) has through its
management approved that the legal entity is to be held
legally responsible for all documents signed by this
certificate and associated key?'

This solution seems a bit related to Alexander the great
and the Gordian knot...

cheers,
Anders Rundgren







Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9VE6Hx14381 for ietf-pkix-bks; Thu, 31 Oct 2002 06:06:17 -0800 (PST)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VE6FW14377 for <[e-mail]>; Thu, 31 Oct 2002 06:06:15 -0800 (PST)
Received: from Santesson ([192.168.101.118]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 31 Oct 2002 15:06:14 +0100
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
Date: Thu, 31 Oct 2002 15:06:13 +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: 31 Oct 2002 14:06:14.0203 (UTC) FILETIME=[AC5748B0:01C280E6]
Sender: [e-mail]
Precedence: 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 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 g9VDEux11151 for ietf-pkix-bks; Thu, 31 Oct 2002 05:14:56 -0800 (PST)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VDEtW11144 for <[e-mail]>; Thu, 31 Oct 2002 05:14:55 -0800 (PST)
Received: from chrisf (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id IAA26233 for <[e-mail]>; Thu, 31 Oct 2002 08:14:50 -0500
From: "Christopher S. Francis" <[e-mail]>
To: "Ietf-Pkix" <[e-mail]>
Subject: Tim Polk.  You out there?  I need an agenda slot.
Date: Thu, 31 Oct 2002 08:14:49 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C280B5.95812560"
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
Sender: [e-mail]
Precedence: 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_0012_01C280B5.95812560
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Tim,
=20
I have tried several times to contact you via e-mail, but have been =
unsuccessful.  If there=92s space on the PKIX agenda in Atlanta, I=92d =
like to get a slot to brief the AC Policies draft.
=20
Please advise.
=20
Chris
=20

------=_NextPart_000_0012_01C280B5.95812560
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C280B5.92F94200">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:"Comic Sans MS";
	panose-1:3 15 7 2 3 3 2 2 2 4;
	mso-font-charset:0;
	mso-generic-font-family:script;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 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";}
h1
	{mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:16.0pt;
	font-family:Arial;
	mso-font-kerning:16.0pt;}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
	{margin-top:13.2pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:1.0in;
	margin-bottom:.0001pt;
	line-height:120%;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:11.0pt;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	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";}
span.EmailStyle15
	{mso-style-type:personal-compose;
	mso-ansi-font-size:12.0pt;
	mso-ascii-font-family:"Comic Sans MS";
	mso-hansi-font-family:"Comic Sans MS";
	mso-bidi-font-family:Arial;
	color:black;}
p.Heading1NoTOC, li.Heading1NoTOC, div.Heading1NoTOC
	{mso-style-name:"Heading 1 No TOC";
	mso-style-parent:"Heading 1";
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-align:center;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:14.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:14.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
p.TableText, li.TableText, div.TableText
	{mso-style-name:"Table Text";
	margin-top:3.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	line-height:110%;
	mso-pagination:widow-orphan lines-together;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:10.0pt;}
p.TableTextTitle, li.TableTextTitle, div.TableTextTitle
	{mso-style-name:"Table Text Title";
	mso-style-parent:"Table Text";
	margin-top:3.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	line-height:110%;
	mso-pagination:widow-orphan lines-together;
	font-size:10.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:10.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
span.TBD
	{mso-style-name:TBD;
	color:navy;
	font-weight:bold;
	font-style:italic;}
@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>
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans =
MS"'>Tim,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>I
have tried several times to contact you via e-mail, but have been
unsuccessful.<span style=3D"mso-spacerun: yes">&nbsp; </span>If =
there&#8217;s space on
the PKIX agenda in Atlanta, I&#8217;d like to get a slot to brief the AC =
Policies
draft.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Please
advise.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoAutoSig><!--[if supportFields]><font color=3Dblack><span=20
style=3D'color:black'><span =
style=3D'mso-element:field-begin'></span><span=20
style=3D"mso-spacerun: yes">&nbsp;</span>AUTOTEXTLIST \s &quot;E-mail=20
Signature&quot; <span =
style=3D'mso-element:field-separator'></span></span></font><![endif]--><f=
ont
color=3Dblack face=3D"Arial Black"><span style=3D'font-family:"Arial =
Black";
color:black'>Chris</span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><!--[if supportFields]><font color=3Dblack><span=20
style=3D'color:black'><span =
style=3D'mso-element:field-end'></span></span></font><![endif]--><font
color=3Dblack><span style=3D'color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

</div>

</body>

</html>

------=_NextPart_000_0012_01C280B5.95812560--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9VCYsW08136 for ietf-pkix-bks; Thu, 31 Oct 2002 04:34:54 -0800 (PST)
Received: from firewall.andxor.com ([195.223.2.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VCYnW08129 for <[e-mail]>; Thu, 31 Oct 2002 04:34:51 -0800 (PST)
Received: from com-and.com (lello.andxor.it [195.223.2.223]) by firewall.andxor.com (8.12.3/8.12.3) with ESMTP id g9VCYgED026972; Thu, 31 Oct 2002 13:34:46 +0100 (CET) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 31 Oct 2002 13:35:22 +0100
From: "Ing. Raffaello Galli" <[e-mail]>
Organization: C&A   - Improving Your Security -
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1
X-Accept-Language: en-us, en, it
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>, [e-mail]
Subject: Re: Legal entities who sign
References: <003c01c280bc$3cc70c80$0500a8c0@arport>
Content-Type: multipart/alternative; boundary="------------010808040908040604000400"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------010808040908040604000400
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Anders,
The solution to this is quite easy.

The key is stored in a locked server-room (or better in a tamper 
proof/evident
machine).
The CEO cannot access to this room or to the phisical key stored.
Let call this delegated Key Holder.

The CEO (only him) can use through a new secure protocol his/her own key.
Let call her/him the Key Owner.

The other interesting thing about this protocol is that it can bypass
the untrusted terminal that the CEO can find on his way (hotel, banks,
airports etc.).
Let call this terminal untrusted terminal.

CEO and not only them are seeking for a mobile digital signature solution.

This is the way we work it out.

The law require the subject to own the Key.
The law require the subject to use his/her own Key.
The law doens't specify any requirements about untrusted terminal or 
application.
  
Raffaello Galli
C&A



Anders Rundgren wrote:

>According to "e-lawyers", legal entities cannot sign as even
>a delegated signer must be physical person.  This creates
>huge practical problems and is also quite ridiculous, here
>thinking of a CEO-certificate/key stored in a locked server-
>room that not even the CEO may have a key to, and used by
>business-systems, often completely out of the CEO's control.
>
>Question: Would it be completely unthinkable that a
>certificate policy stated that the owner of this certificate
>(which only identifies a legal entity) has through its
>management approved that the legal entity is to be held
>legally responsible for all documents signed by this
>certificate and associated key?'
>
>This solution seems a bit related to Alexander the great
>and the Gordian knot...
>
>cheers,
>Anders Rundgren
>
>
>
>  
>

-- 

Raffaello Galli
Chief Executive Officer
C&A  - Improving Your Security -

( Voice:   +39 02.24791823 
( Mobile: [phone]

+ E-mail:   [e-mail]
& Web:    www.com-and.com





--------------010808040908040604000400
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>
Anders,<br>
The solution to this is quite easy.<br>
<br>
The key is stored in a locked server-room (or better in a tamper proof/evident<br>
machine).<br>
The CEO cannot access to this room or to the phisical key stored.<br>
Let call this delegated Key Holder.<br>
<br>
The CEO (only him) can use through a new secure protocol his/her own key.<br>
Let call her/him the Key Owner.<br>
<br>
The other interesting thing about this protocol is that it can bypass<br>
the untrusted terminal that the CEO can find on his way (hotel, banks,<br>
airports etc.).<br>
Let call this terminal untrusted terminal.<br>
<br>
CEO and not only them are seeking for a mobile digital signature solution.<br>
<br>
This is the way we work it out.<br>
<br>
The law require the subject to own the Key.<br>
The law require the subject to use his/her own Key.<br>
The law doens't specify any requirements about untrusted terminal or application.<br>
&nbsp;&nbsp;<br>
Raffaello Galli<br>
C&amp;A<br>
<br>
<br>
<br>
Anders Rundgren wrote:<br>
<blockquote type="cite" cite="mid003c01c280bc$3cc70c80$0500a8c0@arport">
  <pre wrap="">According to "e-lawyers", legal entities cannot sign as even
a delegated signer must be physical person.  This creates
huge practical problems and is also quite ridiculous, here
thinking of a CEO-certificate/key stored in a locked server-
room that not even the CEO may have a key to, and used by
business-systems, often completely out of the CEO's control.

Question: Would it be completely unthinkable that a
certificate policy stated that the owner of this certificate
(which only identifies a legal entity) has through its
management approved that the legal entity is to be held
legally responsible for all documents signed by this
certificate and associated key?'

This solution seems a bit related to Alexander the great
and the Gordian knot...

cheers,
Anders Rundgren



  </pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<title></title>
       
<p align="left"><font size="2"><span
 style="font-weight: bold; font-size: 10pt; color: navy; font-family: Arial;">Raffaello 
Galli</span></font><br>
 Chief Executive Officer <br>
 <font face="Times New Roman, Times, serif"><big>C&amp;A</big></font>&nbsp; -
Improving Your Security -</p>
 
<p align="left"><font size="2"><font face="Wingdings" color="gray"
 size="3"><span style="color: gray; font-family: Wingdings;">(</span></font><font
 face="Arial" color="gray" size="1"><span
 style="font-size: 8pt; color: gray; font-family: Arial;"></span></font></font>&nbsp;Voice:&nbsp; 
&nbsp;+39 02.24791823&nbsp; <br>
 <font size="2"><font face="Wingdings" color="gray" size="3"><span
 style="color: gray; font-family: Wingdings;">(</span></font><font
 face="Arial" color="gray" size="1"><span
 style="font-size: 8pt; color: gray; font-family: Arial;"></span></font></font>&nbsp;Mobile: 
+39 348.2877460<br>
 <font size="2"><font face="Wingdings" color="gray" size="3"><span
 style="color: gray; font-family: Wingdings;"><br>
 +</span></font></font>&nbsp;E-mail: &nbsp; <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> <br>
 <font size="2"><font face="Wingdings" color="gray" size="3"><span
 style="color: gray; font-family: Wingdings;">&amp;</span></font><font
 face="Arial" color="gray" size="1"><span
 style="font-size: 8pt; color: gray; font-family: Arial;"></span></font></font>&nbsp;Web:&nbsp;&nbsp;&nbsp; 
<a class="moz-txt-link-abbreviated" href="http://www.com-and.com">www.com-and.com</a><br>
 </p>
 
<p align="left"><br>
 <br>
 </p>
 </div>
<br>
</body>
</html>

--------------010808040908040604000400--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9VA9fZ21311 for ietf-pkix-bks; Thu, 31 Oct 2002 02:09:41 -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 g9VA9dW21306 for <[e-mail]>; Thu, 31 Oct 2002 02:09:39 -0800 (PST)
Received: from arport ([62.119.75.13]) by blooper.utfors.se (8.12.6/8.12.6) with SMTP id g9VA9X28027582 for <[e-mail]>; Thu, 31 Oct 2002 11:09:33 +0100 (MET)
Message-ID: <003c01c280bc$3cc70c80$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Legal entities who sign
Date: Thu, 31 Oct 2002 10:02:27 +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>

According to "e-lawyers", legal entities cannot sign as even
a delegated signer must be physical person.  This creates
huge practical problems and is also quite ridiculous, here
thinking of a CEO-certificate/key stored in a locked server-
room that not even the CEO may have a key to, and used by
business-systems, often completely out of the CEO's control.

Question: Would it be completely unthinkable that a
certificate policy stated that the owner of this certificate
(which only identifies a legal entity) has through its
management approved that the legal entity is to be held
legally responsible for all documents signed by this
certificate and associated key?'

This solution seems a bit related to Alexander the great
and the Gordian knot...

cheers,
Anders Rundgren



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UFhC122749 for ietf-pkix-bks; Wed, 30 Oct 2002 07:43:12 -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 g9UFhAW22745 for <[e-mail]>; Wed, 30 Oct 2002 07:43:10 -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 g9UFh5Vw023989 for <[e-mail]>; Thu, 31 Oct 2002 04:43:05 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id EAA242459 for [e-mail]; Thu, 31 Oct 2002 04:43:01 +1300 (NZDT) (sender [e-mail])
Date: Thu, 31 Oct 2002 04:43:01 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: [Badly-named] PKI newsgroup
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

For those who don't normally read news:

-- Snip --

                     FIRST CALL FOR VOTES (of 2)
           unmoderated group comp.security.public-key-infra

This CFV is to be distributed only by the votetaker.  It is not to be
posted to newsgroups, or mailed to mailing lists or individuals, except by
the votetaker.  Ballots or CFVs provided by anyone else will be invalid.

Newsgroups line:
comp.security.public-key-infra  Discussion group for public key infrastructure.

Votes must be received by 23:59:59 UTC, 19 Nov 2002.

This vote is being conducted by a neutral third party.  Questions
about the proposed group should be directed to the proponent.

This vote is being conducted by a neutral third party.  Questions
about the proposed group should be directed to the proponent.

Proponent: Niranjan Rajaghatta <[e-mail]>
Votetaker: Neil Crellin <[e-mail]>

RATIONALE: comp.security.public-key-infra

Currently there exists no single newsgroup which exclusively is
devoted to the discussion of Public Key Infrastructure. Discussion of
PKI and related aspects are done in groups like sci.crypt,
alt.computer.security, *.crypto, sci.crypt.research etc., In order to
create more awareness of PKI, its uses, implementation, end-user
problems, solutions and all other related aspects there is a
requirement to have a newsgroup devoted to PKI.

CHARTER: comp.security.public-key-infra

This group will focus on discussions about PKI, deployment,
application of PKI in government, private and public sectors,
advantages and disadvantages, solution to end-user problems of PKI and
all other PKI-related aspects. This newsgroup will serve as a forum to
bring to focus PKI strengths and weaknesses and allow the general
public to voice their opinion on all PKI related matters.

END CHARTER.

IMPORTANT VOTING PROCEDURE NOTES: READ THIS BEFORE VOTING

The purpose of a Usenet vote is to determine the genuine interest in
reading the proposed newsgroup, and soliciting votes from uninterested
parties defeats this purpose.  Do *not* distribute this CFV;  instead,
direct people to the official CFV as posted to news.announce.newgroups.
parties defeats this purpose.  Do *not* distribute this CFV;  instead,
direct people to the official CFV as posted to news.announce.newgroups.
Distributing specific voting instructions or pre-marked copies of
this CFV is considered vote fraud.

This is a public vote:  All email addresses, names and votes will be
listed in the final RESULT post.  The name used may be either a real
name or an established Usenet handle.

At most one vote is allowed per person or per account.  Duplicate
votes will be resolved in favor of the most recent valid vote.

Voters must mail their ballots directly to the votetaker.  Anonymous,
forwarded, or proxy votes are not valid, nor are votes mailed from
WWW/HTML/CGI forms (which should not exist).  Votes from nonexistent
accounts or with munged, spam-blocked, or undeliverable addresses are
invalid and will NOT be counted.

Please direct any questions to the votetaker at <[e-mail]>

HOW TO VOTE:

Extract the ballot from the CFV by deleting everything before and after
the "BEGINNING OF BALLOT" and "END OF BALLOT" lines.  Don't worry about
the spacing of the columns or any quote characters (">") that your
reply inserts.  Please, DO NOT send the entire CFV back to me!

Fill in the ballot as shown below.  Please provide your real name
(or established Usenet handle) and indicate your desired vote in the
appropriate locations inside the ballot.

Examples of how to properly indicate your vote:

Examples of how to properly indicate your vote:

  [ YES     ]  example.yes.vote
  [ NO      ]  example.no.vote
  [ ABSTAIN ]  example.abstention
  [ CANCEL  ]  example.cancellation

DO NOT modify, alter or delete any information in this ballot!
If you do, the voting software will probably reject your ballot.

When finished, MAIL the ballot to: < [e-mail] >
Just "replying" to this message should work, but check the "To:" line.

If you do not receive an acknowledgment of your vote within three
days contact the votetaker about the problem.  You are responsible
for reading your ack and making sure your vote is registered correctly.

If these instructions are unclear, please consult the Introduction to
Usenet Voting or the Usenet Voting FAQ at http://www.stanford.edu/~neilc/uvv.

======== BEGINNING OF BALLOT: Delete everything before this line =======
.-----------------------------------------------------------------------
| 1ST CALL FOR VOTES: comp.security.public-key-infra
| Official Usenet Voting Ballot <CSP-0001> (Do not remove this line!)
|-----------------------------------------------------------------------
| Please provide your real name, or your vote may be rejected.  Established
| Usenet handles are also acceptable.  Place ONLY your name (ie. do NOT
| include your e-mail address or any other information; ONLY your name)
| after the colon on the following line:

Voter name:

| Insert YES, NO, ABSTAIN, or CANCEL inside the brackets for each
| Insert YES, NO, ABSTAIN, or CANCEL inside the brackets for each
| newsgroup listed below (do not delete the newsgroup name):

 Your Vote   Newsgroup
 ---------   -----------------------------------------------------------
[         ]  comp.security.public-key-infra

======== END OF BALLOT: Delete everything after this line ==============


This CFV was created with uvpq 1.0 (Feb  6 1999).
PQ datestamp: 980322

--
Voting address: [e-mail]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UEoiw21263 for ietf-pkix-bks; Wed, 30 Oct 2002 06:50:44 -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 g9UEoWW21230 for <[e-mail]>; Wed, 30 Oct 2002 06:50:42 -0800 (PST)
Received: from [128.33.238.95] (tc238-095.bbn.com [128.33.238.95]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07020; Wed, 30 Oct 2002 09:50:02 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100300b9e44b26b0ea@[128.89.88.34]>
In-Reply-To: <00b901c27f10$918d3530$0500a8c0@arport>
References: <[e-mail]> <001901c26791$025c7dd0$0500a8c0@arport> <p05100315b9e37d4150f2@[128.89.88.34]> <00b901c27f10$918d3530$0500a8c0@arport>
Date: Wed, 30 Oct 2002 09:50:55 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-usergroup-01.txt
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 7:01 AM +0100 10/29/02, Anders Rundgren wrote:
><snip>
>>Another disadvantage to mapping is that it creates another
>>opportunity to make errors, i.e., in mapping from the certificate
>>space to the application space. the database needed to perform the
>>map is an additional source of errors, or an additional attack point,
>>and generally lacks the integrity afforded to certs.
>
>Dear Steve,
>
>In other more established sectors of the IT-industry, the need
>for mappings have been reduced by introducing globally
>agreed-upon identifiers like UNSPC for product codes.
>PKI is literally decades behind, where people still are fighting
>about the very basics, like where to put and how to interpret identity
>information, here referring to Subject DNs, SubjectAltNames,
>URIs, PIs, e-mail addresses, DUNS numbers, etc.
>
>Unless we are talking private and closed PKIs, mapping
>is still a necessary evil for most systems.

We have lots of options for globally unique identifiers, but none are 
globally meaningful, which is the root cause of this problem.

Could it be that focusing on a model of global, TTP PKIs creates the 
need for mapping to which you allude? If so, there there is an easy 
way to avoid this problem, right?

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UDniP16737 for ietf-pkix-bks; Wed, 30 Oct 2002 05:49:44 -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 g9UDnhW16733 for <[e-mail]>; Wed, 30 Oct 2002 05:49:43 -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 OAA11704; Wed, 30 Oct 2002 14:50:04 +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 OAA24940; Wed, 30 Oct 2002 14:46:48 +0100
Message-ID: <[e-mail]>
Date: Wed, 30 Oct 2002 14:46:36 +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: "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>

Stefan,

 > I argue against multiple logotypes,

Let us see what your arguments are.

 > We have already a structure for different versions of the same logotype.

I would not say "versions", I would say "presentations" or "variants".

 > if we add the possibility to have multiple logos, and for each logo,
 > we may have different version (different resolutions, color sets,
 > sizes...) then we do 2 bad things.

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

What is harder ? Display is always an option. We do not mandate what MUST be
displayed.

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

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

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 ?

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

 > I agree though that you can have multiple independent loyalty schemes.

Fine. Where do you place them ?

 > Last time you raised this, we gave you the multiple and independent
 > loyalty logos and you where satisfied with that, What has changed?

You showed me that a sequence was present in the ASN.1 syntax and thus that
the need what covered. While looking more carefully, there is indeed a
sequence but it cannot be used in this way.

     image           SEQUENCE OF LogotypeImage OPTIONAL,

There are very few (i.e. not enough explanations about the various fields).
In particular the image field is not explained (and it should !) and thus
there is no conformance clause for it (i.e. no SHALL or SHOULD).

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.

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.

Denis


 > /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 g9UCrvF12068 for ietf-pkix-bks; Wed, 30 Oct 2002 04:53:57 -0800 (PST)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UCruW12064 for <[e-mail]>; Wed, 30 Oct 2002 04:53:56 -0800 (PST)
Received: from chrisf (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id HAA11070 for <[e-mail]>; Wed, 30 Oct 2002 07:53:55 -0500
From: "Christopher S. Francis" <[e-mail]>
To: "Ietf-Pkix" <[e-mail]>
Subject: Steve Kent.  Can I get a spot on the agenda for Atlanta?
Date: Wed, 30 Oct 2002 07:53:54 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C27FE9.7ECDCFC0"
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
Sender: [e-mail]
Precedence: 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_0001_01C27FE9.7ECDCFC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Steve,
=20
I=92m trying to get a spot on the PKIX agenda to brief the latest =
version of the AC Policies Extension draft.  I tried contacting you a =
few days ago by e-mail, but have not received an answer.
=20
Please let me know as I need to make travel arrangements.  Thanks.
=20
Chris
=20

------=_NextPart_000_0001_01C27FE9.7ECDCFC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C27FE9.7C9E93B0">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:"Comic Sans MS";
	panose-1:3 15 7 2 3 3 2 2 2 4;
	mso-font-charset:0;
	mso-generic-font-family:script;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 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";}
h1
	{mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:16.0pt;
	font-family:Arial;
	mso-font-kerning:16.0pt;}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
	{margin-top:13.2pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:1.0in;
	margin-bottom:.0001pt;
	line-height:120%;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:11.0pt;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	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";}
span.EmailStyle15
	{mso-style-type:personal-compose;
	mso-ansi-font-size:12.0pt;
	mso-ascii-font-family:"Comic Sans MS";
	mso-hansi-font-family:"Comic Sans MS";
	mso-bidi-font-family:Arial;
	color:black;}
p.Heading1NoTOC, li.Heading1NoTOC, div.Heading1NoTOC
	{mso-style-name:"Heading 1 No TOC";
	mso-style-parent:"Heading 1";
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-align:center;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:14.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:14.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
p.TableText, li.TableText, div.TableText
	{mso-style-name:"Table Text";
	margin-top:3.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	line-height:110%;
	mso-pagination:widow-orphan lines-together;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:10.0pt;}
p.TableTextTitle, li.TableTextTitle, div.TableTextTitle
	{mso-style-name:"Table Text Title";
	mso-style-parent:"Table Text";
	margin-top:3.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	line-height:110%;
	mso-pagination:widow-orphan lines-together;
	font-size:10.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:10.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
span.TBD
	{mso-style-name:TBD;
	color:navy;
	font-weight:bold;
	font-style:italic;}
@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>
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans =
MS"'>Steve,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>I&#8217;m
trying to get a spot on the PKIX agenda to brief the latest version of =
the AC
Policies Extension draft.<span style=3D"mso-spacerun: yes">&nbsp; =
</span>I tried
contacting you a few days ago by e-mail, but have not received an =
answer.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Please
let me know as I need to make travel arrangements.<span =
style=3D"mso-spacerun:
yes">&nbsp; </span>Thanks.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoAutoSig><!--[if supportFields]><font color=3Dblack><span=20
style=3D'color:black'><span =
style=3D'mso-element:field-begin'></span><span=20
style=3D"mso-spacerun: yes">&nbsp;</span>AUTOTEXTLIST \s &quot;E-mail=20
Signature&quot; <span =
style=3D'mso-element:field-separator'></span></span></font><![endif]--><f=
ont
color=3Dblack face=3D"Arial Black"><span style=3D'font-family:"Arial =
Black";
color:black'>Chris</span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><!--[if supportFields]><font color=3Dblack><span=20
style=3D'color:black'><span =
style=3D'mso-element:field-end'></span></span></font><![endif]--><font
color=3Dblack><span style=3D'color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

</div>

</body>

</html>

------=_NextPart_000_0001_01C27FE9.7ECDCFC0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UCTFv09400 for ietf-pkix-bks; Wed, 30 Oct 2002 04:29: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 g9UCTDW09388 for <[e-mail]>; Wed, 30 Oct 2002 04:29: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 NAA05370; Wed, 30 Oct 2002 13:29:38 +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 NAA19486; Wed, 30 Oct 2002 13:29:20 +0100
Message-ID: <[e-mail]>
Date: Wed, 30 Oct 2002 13:29:08 +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: "Housley, Russ" <[e-mail]>
CC: [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>

Russ,

Thank you for this notice.

> 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

The second issue is not correctly worded. Rephrase as:
      2) Support for more than one logotype for the community category.

Denis


> 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 g9TM2JY26999 for ietf-pkix-bks; Tue, 29 Oct 2002 14:02:19 -0800 (PST)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TM2GW26993 for <[e-mail]>; Tue, 29 Oct 2002 14:02:17 -0800 (PST)
Received: from Santesson ([213.64.1.18]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Oct 2002 23:02:01 +0100
From: "Stefan Santesson" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, <[e-mail]>, "Denis Pinkas" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
Date: Tue, 29 Oct 2002 23:02:00 +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: 29 Oct 2002 22:02:01.0999 (UTC) FILETIME=[CF53C1F0:01C27F96]
Sender: [e-mail]
Precedence: 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 argue against multiple logotypes,

We have already a structure for different versions of the same logotype. if
we add the possibility to have multiple logos, and for each logo, we may
have different version (different resolutions, color sets, sizes...) then we
do 2 bad things.


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.

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

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.

I agree though that you can have multiple independent loyalty schemes.

Last time you raised this, we gave you the multiple and independent loyalty
logos and you where satisfied with that, What has changed?

/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 g9TFrqA03629 for ietf-pkix-bks; Tue, 29 Oct 2002 07:53:52 -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 g9TFroW03625 for <[e-mail]>; Tue, 29 Oct 2002 07:53:50 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 29 Oct 2002 15:53:52 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 KAA11464 for <[e-mail]>; Tue, 29 Oct 2002 10:53:51 -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 g9TFpEX17938 for <[e-mail]>; Tue, 29 Oct 2002 10:51:14 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWGM02>; Tue, 29 Oct 2002 10:53:50 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.4]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWGM0G; Tue, 29 Oct 2002 10:53:45 -0500
From: "Housley, Russ" <[e-mail]>
To: Takashi ITO <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 29 Oct 2002 10:53:39 -0500
Subject: Re: RFC 3280 : anyPolicy in the policy mapping extension
In-Reply-To: <00a001c27f03$e285bc80$[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>

You are reading correctly.  The algorithm prohibits mapping from 
any-policy.  The text says that one should not map to any-policy either.

Russ


At 01:30 PM 10/29/2002 +0900, Takashi ITO wrote:

>Hello,
>
>I am studying certificate path validation in RFC 3280. And I have a
>question about the policy mapping.
>
>In clause 4.2.1.6, RFC 3280 says:
>
>     Policies SHOULD NOT be mapped either to or from the special value
>     anyPolicy (section 4.2.1.5).
>
>However, Certification Path Processing in clause 6.1.4 says:
>
>     (a)  If a policy mapping extension is present, verify that the
>     special value anyPolicy does not appear as an issuerDomainPolicy
>     or a subjectDomainPolicy.
>
>The above procedure seems to mean checking the prohibition of using
>anyPolicy in the policy mapping extension.
>
>So I think that anyPolicy in this extension described in clause 4.2.1.6
>should be prohibited, by replacing "SHOULD NOT" with "SHALL NOT" as the
>following:
>
>     Policies SHALL NOT be mapped either to or from the special value
>     anyPolicy (section 4.2.1.5).
>
>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 g9TEWHn29173 for ietf-pkix-bks; Tue, 29 Oct 2002 06:32:17 -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 g9TEWFW29167 for <[e-mail]>; Tue, 29 Oct 2002 06:32:15 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 29 Oct 2002 14:32:16 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 JAA00484 for <[e-mail]>; Tue, 29 Oct 2002 09:32:11 -0500 (EST)
Received: from exno02.eu.rsa.net (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g9TETWc05304 for <[e-mail]>; Tue, 29 Oct 2002 09:29:32 -0500 (EST)
Received: by exno02.eu.rsa.net with Internet Mail Service (5.5.2653.19) id <3KDZ7VSF>; Tue, 29 Oct 2002 15:35:50 +0100
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.4]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWGKX0; Tue, 29 Oct 2002 09:17:03 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 29 Oct 2002 09:17:00 -0500
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
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>

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 g9TBLoT15601 for ietf-pkix-bks; Tue, 29 Oct 2002 03:21:50 -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 g9TBLnW15593 for <[e-mail]>; Tue, 29 Oct 2002 03:21: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 GAA28193; Tue, 29 Oct 2002 06:19:26 -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-07.txt
Date: Tue, 29 Oct 2002 06:19:26 -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-07.txt
	Pages		: 21
	Date		: 2002-10-28
	
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-07.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-07.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-07.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-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-logotypes-07.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 g9TA6i809620 for ietf-pkix-bks; Tue, 29 Oct 2002 02:06:44 -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 g9TA0pW08431; Tue, 29 Oct 2002 02:00:51 -0800 (PST)
Received: from exhub01.bc (exchange.bc [45.34.4.231]) by mail1.belgacom.be  with SMTP id KAA01737; Tue, 29 Oct 2002 10:00:42 GMT
From: [e-mail]
Received: from 127.0.0.1 by exhub01.bc (InterScan E-Mail VirusWall NT); Tue, 29 Oct 2002 11:00:36 +0100
Received: by exhub01.bc with Internet Mail Service (5.5.2653.19) id <VYQQ5CT1>; Tue, 29 Oct 2002 11:00:36 +0100
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: delegation attribute within a signed message
Date: Tue, 29 Oct 2002 11:00:30 +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>

Denis,

I understand that when adding the signature polcy as a signed attribute, the signer explicitely indicates that he agrees and applied the policy contents.

I also understand that when adding a commitemnt text as a signed attribute, the signer indicates that he is endorsing a particular act or will.

To be honest i didn't understand what it does express to add an attribute certificate as signed attribute within a CMS signed data? 

Of course, we may consider a closed community having its own dedicated or outsourced AC authority implementing a "signature delegation" having the following functioning:

- The AC receives a request from the "SUPERIOR" (namely the person who will delegates his signature to the end-entity) requesting an AC for the end-entity. This AC will contain propriatary attributes for signature delegation (attributes not defined within RFC 3281).
- The end-entity receives its AC and may hence include it as signed attribute within messages it signs.

The above scheme seems to work but it suffers from my point of view from several questions must be explicitely addressed:

- The superior shall have the privileges to provide "the signature delegation" privilege (attribute) to the end entity (via the AC authority)

- The AC provided to the end-entity should address the problem of a SUPERIOR denying having provided a particular signature delegation privilege (attribute) to the end-entity.

- A signature policy must explicitely specify the context of signature delegation so that bothe the superior and the end-entity are liable and cannot deny a particular signing act

- When the end-entity signs by delegation a particular message, a signature receiving and verifying agent shall be able to adequately verify the signature. This verifying agent, unless within the closed community, won't be able to verify the CMS signed data in a standard way.


So leads me conclude my argumentation by saying:

- An attribute certificate chain constituted from at least 3 AC's shall be provided to the signing and verifying entity. 
	- The first AC in the chain should be the AC authority root key 
	- The second one should be the SUPERIOR AC where the signature delegation capabilities of 	- the superior will be expressed.
	- The last AC is the end-entity AC.

- A "signature delegation policy" is needed. It may live in its own dedicated contex of may be included in a more general "signature policy". 

- The definition od standard attributes for signature delegation. 

When i will have more time i will write a short document containing a solution to the "signature delgation" with non-repudiation and in a standard way.

Regards,

malek.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: 25 October 2002 16:11
To: [e-mail]
Cc: [e-mail]; S-MIME / IETF
Subject: Re: delegation attribute within a signed message


Malek,

I have presented some slides on that topic at the IETF meeting in Salt Lake
City in December 2001. The presentation is called "Signature delegation".

The main idea is to use an Attribute Certificate. Since Attribute 
Certificates may incorporated in a CMS structure (see RFC 3126),
then no addition to the signature format is necessary.

In such a case, there would be two documents to produce:

1) a profile for an Attribute Certificate usable for delegation,
    (a PKIW work item),

2) a document saying how such an Attribute Cetificate is verified when
    present in the CMS structure defined in RFC 3126, (an S-MIME work item).

Hence why I am posting this document to the S-MIME working group too.

Denis

 > I am trying to investigate the possibility to implement a delegated 
electronic signature. I mean implement the fact that a signer has the 
necessary attributes to sign on behalf of some-one else.
 >
 > My understanding is that we should address this question from 2 angles:
 > 	1. The signer should express in his signed message the fact that he is 
signing on behalf of some-one else (fopr the sake of
 >                 simplicity, let's say the superior).
 > 	2. The signer should have the necessary privleges to sign on behalf of 
the superior
 >
 > If we take into consideration CMS signatures, a possible implementation 
of the above two points can be summarized as follows:
 >
 > - Defining an additional attribute: "Detegated Signature". The fields of 
this attributes may be a reference to the document where the
 >   privilege of signing on behalf someone else are expressed. It may 
simply be teh hash of the superior signing certificate.
 > - Adding this additional attribute as a signed attribute in the SigneInfo 
of the signed data within the CMS signature.
 > - Having a reference to the signature policy added a signed attribute. 
Within the sigature policy, we should exress the fact that when a "delegated 
signature" signature is added as a signed attribute, this mens that the 
signatory is signing on behalf a "superior".
 > - The document highlighting the privileges can be expressed within an 
X509 Attribute certificate. This means that the SUPERIOR will have its own 
ATTRIBUTE AUTHORITY. And the privilege withine the X509 attribute 
certificate can be expressed as follows:
 > 	Privilege type: OID describing the privilege of signature delegation
 > 	Superior reference: Signing certificate of teh superior.
 >
 > This solution doesn't seem to be simple to express but provided that the 
necessary ASN.1 structures exist, it is intuitive to implement.
 >
 > I have in mind several solutions but can you please tell me if signature 
delegation has already been specified within some standard or RCF (up to my 
knowledge, no such functionality has already been expressed in ETSI or PKIX 
standards). And if it doen't exist, what do you think about the solution i 
summarized above.
 >
 > regards,
 >
 > ___________________________________________________________
 > Malek Bechlaghem
 > e-Security Product Development Manager
 > Strategy, Business Development and Product Management (SBP)
 > Internet Business Unit (IBU)
 > Belgacom SA/NV
 > Bd du Roi Albert II, 27, B-1030 Brussels
 >
 > Tel.: [phone]
 > Fax: [phone]
 > E-mail: [e-mail]
 >
 > We bring security to the e-world : www.e-trust.be
 >
 >
 >
 >
 > **** 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."


**** 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 g9T78MP06080 for ietf-pkix-bks; Mon, 28 Oct 2002 23:08:22 -0800 (PST)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9T78KW06070 for <[e-mail]>; Mon, 28 Oct 2002 23:08:21 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maild.telia.com (8.12.5/8.12.5) with SMTP id g9T78Dns010078; Tue, 29 Oct 2002 08:08:13 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <00b901c27f10$918d3530$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <001901c26791$025c7dd0$0500a8c0@arport> <p05100315b9e37d4150f2@[128.89.88.34]>
Subject: Re: I-D ACTION:draft-ietf-pkix-usergroup-01.txt
Date: Tue, 29 Oct 2002 07:01:05 +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>

<snip>
>Another disadvantage to mapping is that it creates another 
>opportunity to make errors, i.e., in mapping from the certificate 
>space to the application space. the database needed to perform the 
>map is an additional source of errors, or an additional attack point, 
>and generally lacks the integrity afforded to certs.

Dear Steve,

In other more established sectors of the IT-industry, the need
for mappings have been reduced by introducing globally
agreed-upon identifiers like UNSPC for product codes.
PKI is literally decades behind, where people still are fighting
about the very basics, like where to put and how to interpret identity
information, here referring to Subject DNs, SubjectAltNames,
URIs, PIs, e-mail addresses, DUNS numbers, etc.

Unless we are talking private and closed PKIs, mapping
is still a necessary evil for most systems.

cheers,
Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9T4UUO24170 for ietf-pkix-bks; Mon, 28 Oct 2002 20:30:30 -0800 (PST)
Received: from mx03.melco.co.jp (mx03.melco.co.jp [192.218.140.143]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9T4USW24163 for <[e-mail]>; Mon, 28 Oct 2002 20:30:28 -0800 (PST)
Received: by mx03.melco.co.jp (mx03) id g9T4UVB14126; Tue, 29 Oct 2002 13:30:31 +0900 (JST)
Received: by mr03.melco.co.jp (mr03) id g9T4UPc20036; Tue, 29 Oct 2002 13:30:26 +0900 (JST)
Received: from elmail by elgw.isl.melco.co.jp (8.8.8/3.6W) id NAA10934; Tue, 29 Oct 2002 13:30:19 +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]>; Tue, 29 Oct 2002 13:30:18 +0900 (JST)
Received: from jos818 by iss.isl.melco.co.jp (8.8.8/3.6W) id NAA04907; Tue, 29 Oct 2002 13:30:17 +0900 (JST)
Date: Tue, 29 Oct 2002 13:30:17 +0900
From: Takashi ITO <[e-mail]>
Subject: RFC 3280 : anyPolicy in the policy mapping extension
To: [e-mail]
Message-id: <00a001c27f03$e285bc80$[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>

Hello,

I am studying certificate path validation in RFC 3280. And I have a
question about the policy mapping.

In clause 4.2.1.6, RFC 3280 says:

    Policies SHOULD NOT be mapped either to or from the special value
    anyPolicy (section 4.2.1.5).

However, Certification Path Processing in clause 6.1.4 says:

    (a)  If a policy mapping extension is present, verify that the
    special value anyPolicy does not appear as an issuerDomainPolicy
    or a subjectDomainPolicy.

The above procedure seems to mean checking the prohibition of using
anyPolicy in the policy mapping extension.

So I think that anyPolicy in this extension described in clause 4.2.1.6
should be prohibited, by replacing "SHOULD NOT" with "SHALL NOT" as the
following:

    Policies SHALL NOT be mapped either to or from the special value
    anyPolicy (section 4.2.1.5).

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 g9T2SV816035 for ietf-pkix-bks; Mon, 28 Oct 2002 18:28:31 -0800 (PST)
Received: from osprey.wedgetail.com (starling.wedgetail.com [202.83.95.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9T2SSW16031 for <[e-mail]>; Mon, 28 Oct 2002 18:28:29 -0800 (PST)
Received: from coot.wedgetail.com (coot.wedgetail.com [10.10.10.4]) by osprey.wedgetail.com (8.12.5/8.12.5) with ESMTP id g9T2RRNU001474; Tue, 29 Oct 2002 12:27:27 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh exmh 2.5 (2001-07-13) with nmh-1.0.4
From: Dean Povey <[e-mail]>
cc: "Housley, Russ" <[e-mail]>, [e-mail]
Subject: Re: Extra Security Considerations for Logotypes (was Re: draft-ietf-pkix-logotypes-06.txt) 
In-reply-to: Your message of "Tue, 29 Oct 2002 09:55:11 +1000." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 29 Oct 2002 12:27:26 +1000
X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: 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>
>
>On the security issue I raised, can we at least add something like the
>following text to the Security Considerations.

It occurred to me after I sent this, that the section on "Client use" may 
be a more appropriate place to put the text.

>"Applications that make use of certificate logotypes MUST ensure that 
>their presentation cannot be masqueraded by the display of other dynamic 
>mutlimedia content.  For example, it should not be possible for an image 
>or audio content on a web page to be confused with a logotype for a 
>certificate.  For image logotypes this MAY be done by reserving part of 
>the user interface for the display of logotype images, and ensuring that 
>no dynamic content can display an image at that location.  For audio 
>logotypes (particularly in applications for the visually impaired, where 
>all content is rendered solely in an audio form), there MUST be a 
>mechanism for the user to distinguish the logotype audio, such as by 
>requiring an action by the user before the audio is played."
-- 
Dean Povey,             |em: [e-mail]|JCSI: Java security toolkit
Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C PKI toolkit
Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C SSL toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML Signatures 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9T0cvu10292 for ietf-pkix-bks; Mon, 28 Oct 2002 16:38:57 -0800 (PST)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9T0ctW10287 for <[e-mail]>; Mon, 28 Oct 2002 16:38:55 -0800 (PST)
Received: from mail6.microsoft.com ([157.54.6.196]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 16:38:49 -0800
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 16:38:33 -0800
Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 28 Oct 2002 16:38:34 -0800
Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 16:38:33 -0800
Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 16:38:32 -0800
Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Mon, 28 Oct 2002 16:38:42 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6771.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Extra Security Considerations for Logotypes (was  Re: draft-ietf-pkix-logotypes-06.txt)
Date: Mon, 28 Oct 2002 16:38:41 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Extra Security Considerations for Logotypes (was  Re: draft-ietf-pkix-logotypes-06.txt)
Thread-Index: AcJ+3mWbqx5he/WhQ7a0JkcqbIw1kAABKE+g
From: "Trevor Freeman" <[e-mail]>
To: "Dean Povey" <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 29 Oct 2002 00:38:42.0472 (UTC) FILETIME=[88085A80:01C27EE3]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9T0cuW10289
Sender: [e-mail]
Precedence: 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 would only make a minor modification because there are classes of
visually impaired people who have some limited vision but would still
benefit from the audio logotypes.

For audio logotypes (particularly in applications for the visually
impaired, where some or all content is rendered in an audio form)....

-----Original Message-----
From: Dean Povey [mailto:[e-mail]] 
Sent: Monday, October 28, 2002 3:55 PM
To: Housley, Russ
Cc: [e-mail]
Subject: Extra Security Considerations for Logotypes (was Re:
draft-ietf-pkix-logotypes-06.txt)


On Fri, 25 Oct 2002 11:52:00 -0400, "Housley, Russ" wrote: 
>Dean:
>
>Reading the content of the certificate is what we are trying to avoid.
For 
>the people without disabilities, the image is intended to provide a
quickly 
>identifiable affiliation.  We want a similar aid to the visually
disabled.

While I agree with the sentiment, I'm not sure I agree with the
mechanism. 
However, I am willing to acquiesce in the interest of moving the draft
forward.

On the security issue I raised, can we at least add something like the
following text to the Security Considerations.

"Applications that make use of certificate logotypes MUST ensure that 
their presentation cannot be masqueraded by the display of other dynamic

mutlimedia content.  For example, it should not be possible for an image

or audio content on a web page to be confused with a logotype for a 
certificate.  For image logotypes this MAY be done by reserving part of 
the user interface for the display of logotype images, and ensuring that

no dynamic content can display an image at that location.  For audio 
logotypes (particularly in applications for the visually impaired, where

all content is rendered solely in an audio form), there MUST be a 
mechanism for the user to distinguish the logotype audio, such as by 
requiring an action by the user before the audio is played."
-- 
Dean Povey,             |em: [e-mail]|JCSI: Java security
toolkit
Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C PKI
toolkit
Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C SSL
toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML
Signatures 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SNu0w09152 for ietf-pkix-bks; Mon, 28 Oct 2002 15:56:00 -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 g9SNtxW09148 for <[e-mail]>; Mon, 28 Oct 2002 15:55:59 -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 SAA29077; Mon, 28 Oct 2002 18:55:43 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100315b9e37d4150f2@[128.89.88.34]>
In-Reply-To: <001901c26791$025c7dd0$0500a8c0@arport>
References: <[e-mail]> <001901c26791$025c7dd0$0500a8c0@arport>
Date: Mon, 28 Oct 2002 18:50:07 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-usergroup-01.txt
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 10:20 AM +0200 9/29/02, Anders Rundgren wrote:
>This is indeed an interesting topic...
>
>Essentially there are two ways to make certificates more adapted
>to their working environment:
>
>1. Clobber certificates with more "stuff" to as the draft suggests
>
>2. Use a mapping facility that maps a certificate into whatever
>     is needed by the working environment
>
>A major advantage with mapping is that you can use TTP-issued
>certificates (a.k.a. 100% outsourced PKI), and that the very same
>certificates can be used by multiple relying parties in many different
>environments.
>
>A major disadvantage with mapping is that Microsoft and probably
>most others as well, do not yet support this fundamental capability
>except to a very limited extent.  Contributing to that, is the fact that
>current PKI-standards do not offer the kind of manageble mapping
>support needed for efficient usage of TTP-issued certificates.
>
>If Microsoft and others are to upgrade their PKI support
>(which both solutions require), I really hope that they settle
>for a mapping solution.
>
>cheers,
>Anders

Another disadvantage to mapping is that it creates another 
opportunity to make errors, i.e., in mapping from the certificate 
space to the application space. the database needed to perform the 
map is an additional source of errors, or an additional attack point, 
and generally lacks the integrity afforded to certs.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SNtVP09127 for ietf-pkix-bks; Mon, 28 Oct 2002 15:55:31 -0800 (PST)
Received: from osprey.wedgetail.com (starling.wedgetail.com [202.83.95.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SNtTW09122 for <[e-mail]>; Mon, 28 Oct 2002 15:55:30 -0800 (PST)
Received: from coot.wedgetail.com (coot.wedgetail.com [10.10.10.4]) by osprey.wedgetail.com (8.12.5/8.12.5) with ESMTP id g9SNtCNU029111; Tue, 29 Oct 2002 09:55:12 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh exmh 2.5 (2001-07-13) with nmh-1.0.4
From: Dean Povey <[e-mail]>
To: "Housley, Russ" <[e-mail]>
cc: [e-mail]
Subject: Extra Security Considerations for Logotypes (was  Re: draft-ietf-pkix-logotypes-06.txt)
In-reply-to: Your message of "Fri, 25 Oct 2002 11:52:00 -0400." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 29 Oct 2002 09:55:11 +1000
X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: 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 Fri, 25 Oct 2002 11:52:00 -0400, "Housley, Russ" wrote: 
>Dean:
>
>Reading the content of the certificate is what we are trying to avoid.  For 
>the people without disabilities, the image is intended to provide a quickly 
>identifiable affiliation.  We want a similar aid to the visually disabled.

While I agree with the sentiment, I'm not sure I agree with the mechanism. 
However, I am willing to acquiesce in the interest of moving the draft forward.

On the security issue I raised, can we at least add something like the
following text to the Security Considerations.

"Applications that make use of certificate logotypes MUST ensure that 
their presentation cannot be masqueraded by the display of other dynamic 
mutlimedia content.  For example, it should not be possible for an image 
or audio content on a web page to be confused with a logotype for a 
certificate.  For image logotypes this MAY be done by reserving part of 
the user interface for the display of logotype images, and ensuring that 
no dynamic content can display an image at that location.  For audio 
logotypes (particularly in applications for the visually impaired, where 
all content is rendered solely in an audio form), there MUST be a 
mechanism for the user to distinguish the logotype audio, such as by 
requiring an action by the user before the audio is played."
-- 
Dean Povey,             |em: [e-mail]|JCSI: Java security toolkit
Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C PKI toolkit
Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C SSL toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML Signatures 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SK3gg27016 for ietf-pkix-bks; Mon, 28 Oct 2002 12:03:42 -0800 (PST)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SK3dW27012 for <[e-mail]>; Mon, 28 Oct 2002 12:03:39 -0800 (PST)
Received: from mail6.microsoft.com ([157.54.6.196]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 12:03:36 -0800
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 12:03:36 -0800
Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 28 Oct 2002 12:03:36 -0800
Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 12:03:35 -0800
Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 12:03:34 -0800
Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Mon, 28 Oct 2002 12:03:31 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6771.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-logotypes-06.txt
Date: Mon, 28 Oct 2002 12:03:59 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-logotypes-06.txt
Thread-Index: AcJ+iOk5GirgFOX4SqGOut1UQ+Tr2QAM1ghA
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: "Dean Povey" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 28 Oct 2002 20:03:31.0303 (UTC) FILETIME=[169BE770:01C27EBD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9SK3eW27013
Sender: [e-mail]
Precedence: 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 the staffing policy at Microsoft is at question here.
Unlike many organisations we do have a dedicated staff of people solely
focused on accessibility defining requirements. The audio content is a
serious requires and I don't see any useful purpose in splitting it from
this ID. It is an option I the draft so does not impede any
implementation not interested in this aspect.

Trevor
-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Monday, October 28, 2002 5:45 AM
To: Housley, Russ
Cc: Dean Povey; [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt

Russ,

> Denis:

>>> I agree that jingles are somewhat different than Logos.

>> OK. Since you agree it is different, let us make two documents (and 
>> hence let us define two extensions), one for visual logos, and
another 
>> one jingles.
> 
> 
> They are not that different!  Breaking them into separate documents 
> would defeat the alternate presentation to the blind.

If, as you mention, it is an *alternate* presentation, then since blind 
people do not need to see logos, there would be no problem to break the 
specification into two pieces: one for logos, one for jingles.

If, as you do not mention, it is supplementary information, hence not
for 
blind people but for fun, then you breaking it into two pieces would be
more 
difficult, but could still be done.

>> For the second one, it would make sense to query some blind people to

>> make sure that this would be really useful for them. We should hold
on 
>> the progression of the second document until we have verified this.
> 
> We have consulted with the people at Microsoft that write the 
> requirements for the "accessability" aspects of software.  These are
the 
> people that are responsible for making software that can be used by 
> disabled people.

Nancy questioned:

"Have any blind or otherwise visually-impaired users been consulted on
this 
issue, or weighed-in on the discussion in this forum?  If so, what has
their 
general opinion been?"

People at Microsoft are not *users*, nor are they all blind or otherwise

visually-impaired.

Additionally, the specification does not address internationalisations 
issues, which is not a problem with (visual) logos, but it is with
jingles.

The Oxford dictionary provides the following definition for logo:

logo / noun (pl. -os) a printed design or symbol that a company or an 
organization uses as its special sign.

Logos are only visual. Please deal with jingles separately.

The Oxford dictionary provides the following definition for jingle:

"a short song or tune that is easy to remember and is used in
advertising on radio or television".

Denis

> Russ

Now, if I had a certificate, it could well include the folling *two* 
following *community* logos. It would be up to your application, to
display 
none of them, one of them or both of them.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SJtBA26235 for ietf-pkix-bks; Mon, 28 Oct 2002 11:55:11 -0800 (PST)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SJt8W26231 for <[e-mail]>; Mon, 28 Oct 2002 11:55:08 -0800 (PST)
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 11:55:05 -0800
Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 28 Oct 2002 11:55:05 -0800
Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 11:55:04 -0800
Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 11:55:03 -0800
Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Mon, 28 Oct 2002 11:55:01 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6771.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-logotypes-06.txt
Date: Mon, 28 Oct 2002 11:55:27 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-logotypes-06.txt
Thread-Index: AcJ+jjixK/Ykr66IQwKNnII6b5T8LQAKW0kQ
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 28 Oct 2002 19:55:01.0179 (UTC) FILETIME=[E68D28B0:01C27EBB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9SJt9W26232
Sender: [e-mail]
Precedence: 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 am still not convinced about binding multiple community logos to a
single certificate. If we take the much overworked merchant\credit card
scenario, then that does not back having multiple community logos bound
to the certificate. A merchant may have multiple separate business
relationships with different credit card brands but how is that related
to a single instance of a credential. I would not expect the CA to make
assertions about someone's business relationships which is what is being
described by the merchant\credit card scenario. I expect the CA to make
assertions about identity of the business and to be reasonably able to
map the legal identify of that business to a set of images they are
legally able to use to represent themselves. When a merchant displays
the logos of the credit cards they accept, the merchant is making an
assertion that they have a business relationship with credit card
vendors. That has nothing to do with the identity of the business.

Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Monday, October 28, 2002 6:22 AM
To: Housley, Russ
Cc: [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt

Russ,

I have cut some pieces from the text to make it more readable.

(...)

>> The text says:
>>
>> Compliant applications MUST display more just one (or none) of the 
>> images *and* play just one (or none) of the audio sequences at the 
>> same time.
>>
>> The "and" does not make it optional.
> 
> 
> I think that displaying one image and playing zero audio sequences 
> conforms with this sentence.  if you disagree, please propose
alternate 
> wording for this sentence.

Displaying *zero* image and playing *zero* audio sequences conforms with

this sentence. Is it thus a conformance clause ?

Alternate wording: delete that sentence.

Then, when we will have fixed the minimum size of the logo to be
displayed, 
then we will be able to add a conformance clause for *client-enabled
logos* 
(i.e. clients able to display logos, if they wish to do so).

(...)

>> No. There is no requirement to necessarily show both logos. If they 
>> are combined, then it would be mandatory to display both.
>>
>> Your response is technology driven, since the current ASN.1 syntax 
>> does not allow for that case, your are trying to find a way to 
>> accomodate the need, without changing the syntax.
> 
> No.  The authors wrote the syntax after considering this argument,
> 
> Many merchants have stickers on the doors to their retail shops that 
> indicate the brands of credit cards that are accepted.  They have one 
> sticker with many logos.  This is useful to the consumer because the 
> logos always appear in the same configuration.  I believe that the
same 
> argument applies here.

In practice I have never seen a small retail shop getting the logos all
at 
once e.g. from VISA and AMEX on the same sticker. There are separate
logos. 
So your example is not a real life example.

>> The syntax needs to be changed.
>>
>> > If it is not consistent, then we have not helped the use
>>
>>> make a selection from a group of certificates without investigating 
>>> details.
>>
>>
>> It is still up to the client application to display or not when it
wants,
>> in that case:
>>
>> no logo (1), logo A (2), logo B (3), or both logo A and logo B (4).
> 
> 
> I clearly disagree.  The choice should be no logo and one logo image 
> (which may be a combination of several logos if appropriate).

We clearly disagree, but you do not provide arguments to support your
position.

Since apparently you missed the logo attachments in my other e-mail, and
you 
deleted the note :-( , I am sending them again, with the same comment:

Now, if I had a certificate, it could well include the *two* following 
*community* logos. It would be up to your application, to display none
of 
them, one of them or both of them.

Denis

> Russ



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SFd1M04800 for ietf-pkix-bks; Mon, 28 Oct 2002 07:39:01 -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 g9SFd0W04791 for <[e-mail]>; Mon, 28 Oct 2002 07:39:00 -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 PAA03056 for <[e-mail]>; Mon, 28 Oct 2002 15:39:00 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 g9SFcwWY017232 for <[e-mail]>; Mon, 28 Oct 2002 15:38:58 GMT
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 28 Oct 2002 15:44:10 +0000
To: "pkix" <[e-mail]>
From: J Adrian Pickering <[e-mail]>
Subject: RE: Attribute Certificate Policies Extension
In-Reply-To: <[e-mail] m>
References: <009b01c27cbd$258547b0$0500a8c0@arport>
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 13:39 28/10/2002, Christopher S. Francis wrote:
>Let me assure you that attribute certificates are being used industry in
>real products.

<snip>

>Since this group's charter focuses on X.509, and ACs are part of that
>standard, I disagree with your position that this topic is not worthy of
>discussion here.

Seconded. Despite some helpful replies to an earlier thread where I 
questioning why ACs seemed to have been sidelined, I am still not convinced 
that they are 'not worth having'. I'm encouraged that others still think 
that they are.

I may be missing something but I'm not clear what XML has to do with 
whether ACs are useful or not?!

Adrian Pickering/
Electronics and Computer Science,
University of Southampton, UK



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SEMHo25872 for ietf-pkix-bks; Mon, 28 Oct 2002 06:22:17 -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 g9SEMFW25861 for <[e-mail]>; Mon, 28 Oct 2002 06:22:15 -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 PAA14570; Mon, 28 Oct 2002 15:22:41 +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 PAA28148; Mon, 28 Oct 2002 15:22:19 +0100
Message-ID: <[e-mail]>
Date: Mon, 28 Oct 2002 15:22:07 +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: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------020408050105010904030400"
Sender: [e-mail]
Precedence: 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.
--------------020408050105010904030400
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Russ,

I have cut some pieces from the text to make it more readable.

(...)

>> The text says:
>>
>> Compliant applications MUST display more just one (or none) of the 
>> images *and* play just one (or none) of the audio sequences at the 
>> same time.
>>
>> The "and" does not make it optional.
> 
> 
> I think that displaying one image and playing zero audio sequences 
> conforms with this sentence.  if you disagree, please propose alternate 
> wording for this sentence.

Displaying *zero* image and playing *zero* audio sequences conforms with 
this sentence. Is it thus a conformance clause ?

Alternate wording: delete that sentence.

Then, when we will have fixed the minimum size of the logo to be displayed, 
then we will be able to add a conformance clause for *client-enabled logos* 
(i.e. clients able to display logos, if they wish to do so).

(...)

>> No. There is no requirement to necessarily show both logos. If they 
>> are combined, then it would be mandatory to display both.
>>
>> Your response is technology driven, since the current ASN.1 syntax 
>> does not allow for that case, your are trying to find a way to 
>> accomodate the need, without changing the syntax.
> 
> No.  The authors wrote the syntax after considering this argument,
> 
> Many merchants have stickers on the doors to their retail shops that 
> indicate the brands of credit cards that are accepted.  They have one 
> sticker with many logos.  This is useful to the consumer because the 
> logos always appear in the same configuration.  I believe that the same 
> argument applies here.

In practice I have never seen a small retail shop getting the logos all at 
once e.g. from VISA and AMEX on the same sticker. There are separate logos. 
So your example is not a real life example.

>> The syntax needs to be changed.
>>
>> > If it is not consistent, then we have not helped the use
>>
>>> make a selection from a group of certificates without investigating 
>>> details.
>>
>>
>> It is still up to the client application to display or not when it wants,
>> in that case:
>>
>> no logo (1), logo A (2), logo B (3), or both logo A and logo B (4).
> 
> 
> I clearly disagree.  The choice should be no logo and one logo image 
> (which may be a combination of several logos if appropriate).

We clearly disagree, but you do not provide arguments to support your position.

Since apparently you missed the logo attachments in my other e-mail, and you 
deleted the note :-( , I am sending them again, with the same comment:

Now, if I had a certificate, it could well include the *two* following 
*community* logos. It would be up to your application, to display none of 
them, one of them or both of them.

Denis

> Russ


--------------020408050105010904030400
Content-Type: image/gif;
 name="Thawte.gif"
Content-Disposition: inline;
 filename="Thawte.gif"
Content-Transfer-Encoding: base64

R0lGODlhVwA3APcAAAAAAP////z8/fT2+OXp7uIoM95rc8UMG8cTIcgWJcgZJ9YdK8odKtgg
L9YjMcohL9kkMsskMtgnNdgpN9QrOcwpNtgtO80uOtgzP9k2Q88zQNU2Q882Qt06RtA6RttA
TNNDT9VNWNhWYNpdaNlkbt9ze+CCiuCKkuWSmdWKkeiaoMeGjOmip/uvteursPy/xO64vPDB
xfLP0vXd3/3w8fzv8Pvu79RrdclpctFyfNV6g8FzfNeDjMOdodWSmt2gqNuqsa2Slv34+da2
vd7ByN/Jz9fIzJksTNvQ1ODY3dzT2rWztaCLopmEneHf4kIqZHh3et3d5CgoKe3t8qqqrT4+
PzMzNJ+foZmZm5GRk05OT0dHSN3d37Cwsm1tbmZmZ/7+//39/vr6+/j4+evr7OXl5uLi49zc
3dLS08bGx8HBwr6+v7e3uGhpfBccZBwhaB8laiInayMobCQpbCYrbScsbikuby4zcTE2czY7
dj1CelRYiGBjjEZLfm1xloGEoYyPqiIsb5uesrO0uycydXh+oJGWs6WpvLy/zMTH07K2xezt
8M3O0dDS1+bo7eXn7Nnb4NPW3eXo7sjKzsbIzO3v8+Pl6YCBg6WmqPf4+vb3+fX2+O3u8Ofo
6tDR0+rt8uns8ejr8Obp7uXo7eLm7OHl68rMz8nLzsjKzcXHyujq7dfZ3NXa4evu8urt8d3i
6Obq7+Lm68vQ1eXq7+Hm6+vu8fP19/L09vDy9Nnb3YiJivr7/O/w8ejp6ubn6Nna29bX2NPU
1c/Q0ePq8OXr8OLp7uXu8+bt8c3X3Obw9dLW2Pj6+93f4N/s8uLu8+b0+eXy9vH3+ezz9cLM
zu33+ef6/e79/8bNzunw8fL9/mhwcPf//x8gIPv//1RVVfz+/uvt7V1eXvz9/fHy8tXW1s3O
zsnKysTFxbq7u/r7+dTV0d7e2/z8+/j49/Dw7+vr6tzc29vb2tra2dnZ2NjY1/34+P78/Pb1
9f7+/u/v7+3t7eDg4NnZ2djY2BYWFv///yH5BAEAAP8ALAAAAABXADcAQAj/AF+d+PHKQBIg
JpqVIFKkRLOBBaMgVMjQ4cAoBiQmXNjw4Q+MUX6cUFiEiEMTQJwYeCWSpMlmKDGyHFmi5Ekg
SVaKrPYqgICfQIMKHUqUKJhdvX6RIwesqdOnwFTx0kdmH7MxYYpqHRrgFRJNt8KKHTvWlriz
aNEK2CUu3T5GnjyhmUdvXrC4cunV5XXPRQkU96LZ0uSCBIkZ2W5FsxGiQYECIXooaxcgzDcB
y9KiFXNLExIgz0I98nTKlOnTpk8xegQKV6I7dODwiWSq3B44c/Jc2u2nTuxDt/bEmWNHj/E5
dQI16SBhggQKQ9R4gDBhAoQew0C1gtRHzhw9pULZ/yoEJ04fKlQwoasUStoQH8ZIyZcfiZL9
+/cZ5RLjJZwWMQF8AUUAVqwRwBlS6BOAOdxgoUU4AXCjyxX7BCCFFWpocU8AwkgRQABsWBHA
FVUEgA46meAyxhbhZIEJPpd4gU+AunzoTThXqKHJMz7kAE0pQNICZCmvRDEJfvbJsgMDFSjg
AggIRAACCwg8EAMDMESQAAMG2KPBAxWE2SQMBzgJQgUuJBBmBCac4AICCsAQAgMMxIACCA+Q
gMIBMIgAJgcssMBkkz9Uk8MN1cBSyjleYNLCCA4Y8IIul6hBySSMcJFLON5AsYoY4YRThRq8
VAEFFJsIY0UvUpiRjxRbkP/RRRXhDKiLN7gKwMkiu6AjYRW3dBFOF1tsAkooYqxRxRe6iHEP
FFp8YU4AWHgTwDihVHMDogR06+234IYr7rjgwgILLZA0Ysp9qDASxbuQRPEKKeTWC662OWRT
yb789uvvvwDzG4oypjBi8MEII1wOMKHgEjC/1BRBggMLQNCACCkk4XDA1uRwwjaZbLIILuSc
YQYawKCRyy3LLBMKH3zsYUcd38HsRx9zyIZGOeoIIgcdcQgyTz+U4GFeb3AUMgJ1EjhQXXMT
WABCcxJo0AbMeNBBBx428zGHeeilNwgY3ZwAxIcfktHP2my33Q8wt2yixhJXdPELP/HQXbc8
Z3D/QQ4b6KzBhRprrFEh2umcc2IwuZwzDSQfhqGMGteYAQbaYqSxBjppCHD5GWqEXnjoaHwI
RBFopx5AGfLE4/rrZ+wjzTbUZJNNMtR0g8820BjzzYyqp24P8MEXb3wA4hB//IdgFBEF2uOo
8UUu2nCTRSpfdCGMPNzHg8T3SBghvhFJ2GD++einr74NNdCAfvvrpw//+TTUYP789QQgr08C
iLPLGLfAhTQqYYsx7OInYCCDLzbhCzFwZgyb+JD/LueTXaDtJ5U54IfwocEPBSUMGwzALy7h
C/79BIQBOMougBcGMaCwMl35gQm3QsMaakUcWREDLshQBjMwAxhnwIoN/2sIhh/8ABr2SqIS
uwWLUUShEaegBCqmSMUppiIVlGBEIyBBryWSCxo/IMLyxkjGD43jDPTgnhrXyEZ57OMdlBlj
PezEAhnYY3n2IAIPfjSkPvrxj4AEEileIQwsIumQlEiFLFghnyGRYhjF8GMzgICBBkgAAhnY
ASYQEYlXBBJIzuBBElJ3D3eEoRf2GMcYUjcFOtTBDrCMpXn4EBs/rAMe+zgEHewwh0PsIx7r
QMQd6lCHpBnAkhKQQQBE0ADnOIAFAXCBBJ7zhEAQIpawpIMe/BBLrcVmDx9Kwg2eMchTGBJJ
qWhEKQZpCWHGhg+xaEQahFMHObzBDW+Ag2/iAP8IZrBCD3G4wyCY4Qc4wOEPIqBOdRwgghBA
zToZWIInkaGHOchBD6yIQicKEQeaxcGee1jnM27Qkw9xwm0o7cc9wBCJYr5hD/KYhzz28IY3
6KERuBxEHODgBkT4AZ98EIQgrnAFLNzhDYFgQgca0IAQzG4IG7AYCaKBNnDooaZ4iGAACuEG
g3rVDX740CsQFYqyggISpUGNWhlhCV6owQy+MIMp0EAGc5ghF0uYmxnGEYwx3HUXnkAHG4Ax
hlNwwhbAyAQz0GEONnCiF4wo4CbQ8Qsx1OITqlRDOQSgCS6cwRZpOIdmxcCFzaXhFta4ASR2
kYnWuvZkwYitbIOxinH/dMF6pgqALqpwBW6UQwxo4EYvAnAOD+kCQv7AwhLMgY8q6EMKUgCh
OTwUgCWIaLqYqEIWAiAGTXwhC5fwUIw+9IVLfEgLXgCcJsIACR1sgyxiAYYw8IIXZOSgSg9g
wAVGEIEKeIABCvgvAjwQAgVc4AIiuACYwDSCEIzgAQqowAiqRCcGeAAB/k2AB0ZQAQSAQAQR
AJMGAjyCCyQABFsCAZMO8INt6IAI0eDXaKiQhSxggQpsSAXC7JuACEQASywoQQRcgIIEnEDD
MGDBh0NgABU/4MkPOIECfgwDFSgYygcwgYITYAIlc9kALEgAk7PsYwgbIARQRsAPskEEGYZh
/wzKgAIWWmCADJTgBbtZA1P6wYxeYCEcuohCGSyRj6xY8EO7AKEA+OdBFIaBLQvCAqOBUaOj
iMMnJgxAJ2JEhQ+ho7xlIK6kf4IPIyJxFJBYgy60gatwaCML5ygSI0wBiXPQqgqY+AYUvPEF
M/DiQeHghC+s4AUrmGERVgiGiWjVhQBgQgsPGkNZM7EEKXwhHLgIwCW44YtbwCIUy8DCsrZw
bC14Yws1uoI/wuGFTlDjB0NAAUEMMhGOWGTeGqFIRy6SkXpXxCMgaUlNXhKTjAjcJjABgkwO
TnCc6AQFQ0hBNYwximcQwBjQeMQziEGMZzyidxV3BMY1ToxZeBzkz/8Qxcg33vGPG4MAFl85
x1PeO1I4oxQrn0XLewfzUch85y9/hs+rwQMlLGMASE+60pfO9KY7nemb0EQmNIELS+RCGWgQ
BhpWwQxVaEITTw8705ehBCWU8exox8c9ynCG7r1uH77YxxnmbgZ2oH15SuDBNsTO975/3RW5
iAsaBk/4wpPD17cYAC5s0Xexb4MHOXhGLCZP+cpb/vKYtzwpnCiLcyISP5PAIiOUEYVSYP6R
GDeGM0iR+ck/IwdDkIYrZk/72tv+9rinfSsqAQm1+h41qlmFKD5RiVbknhruKIwFGgCCEiSh
Erl3hXtKevcyCqAM9OCH9rfP/e2nsReLJmP/DD7ggEtCIDLnIMMYX3E2MLj//fCPfxnFsA9y
pNRtwJBHL+5Rj0W7PwD3MAM1AH8BEAMU0EwQ8AE9MA3ggA/KEzyXAwSIIgoUKAqwYIHmEgoV
GAqvYAge+IEfeAiHYAiAIAimcArloAh/AAh/oAgnWBqGsIKGgAgisAALoAPJ8AxAcIALIAKP
cAzGYAALQAFHcARQUAggaAiCoAhJ6IGH0Ara4gPJ8AiPIAqvYAqvIAuNoAxsJQlVGAn5hBtz
8DVw8AZ50Adx8AZ8YBpoYAhyIAdwAAjlQAme4AdvQBxxgAdBgAES0AAjgALNtFAhIAPk5xxP
YFBjaFFliAd7MIZ1/4AHkHgHe3ALyeADUdBCmwAMTrAU/bAU5BAM+zAGAnAPa6AGhwAbccAH
aoAOS7AHP5MHMMMHfaA1QTMP7wAI+VQI6GA0feADT/NQVOM01nED6DA33fEdgVMO5HFRgNCM
h1AGAhAGUSBGAcAO+9A6r5ON/JAPaLMKsPEGfmCN68AHHWUHeXCOeeAbcKAIAXAIb2AejKAK
hmAH5rECEEA1EuADPqBQ1pEDizAj7nCMeqBVfwAHdHAHxpEHfhB+RKAD2eAwucAIwjCRFEmR
jLAKuKAJsoCKeyB4wnFR6HAO54AJvvEGiIAIcbBL54gH5/hNOtBMErABTtAMOIBMG4AEtv+w
eK+AM7khCrggDsuoB38wlH9wCJqQDTqgAz9STp9nH+k0C4nQB32wTahACebAB8axB4iACqZA
BVLZB4ewB1IpCJ5gMLJwDrKoB4WwAjeAA0EQBbMwDUGQAzsQBEJSCqMQCbLYB3tQeqAACF8Z
mIUACtCgA0aQk7iAC6oQDBJZkRV5kbjAC2WgFPzgBGbAD1zQD1zACbywCJ0wDqW0CfcwDgDi
E5pQGaDJCffQDd8QAGPgQmB3mt8AFrdgC2IgAOkwDpxwm6LYP2OgSuIgAGJgC9FgBM+TOqSF
jdnoOvBgBppQDv5QI/gABZfwDVtQDubgDdzgDZ24BdTyBQQSDl//wAYB4A+XQAYQcg5asJ36
cA7eOQ64YgXogDa7pgW6gA/gpW1WYAXb9QVbwCwfEgU+wF0OJAa7cA+/EAyeuKC/0AliIAVe
wA3TUl74gCEBwA9WoH7QeQm0EiFQoAsVsgVZwCLpwCHUhQ4iogteoGmdAENpcAneICPjFQBe
UCMB4A32OZ9g4APjRIU+KglyJUVVhAqy4As0hg/CcAnj4AtQ8AVXsAi+wAW6QAZi8Au6EAbo
cAUBAAVe4AVaqgvpgA5QMAaKdQmZAFw22gXM0gu6uQlrICBpACKY4ECYwAYOdAVf4AWXsAip
BQTJUIEbGAWnMKiEOqiyAAQp4AOJmgI8/6CPKfCoKhAoKhCpk4oCkRooLIACmiqpKICpksoC
kwqqlqoCmwqqlGqpoPqpLqACMqCDPUGAaKMKwOA29PAKOjAoFYACJyAlaWIlDAACKlACXGYC
MsAB/RUBHqACM3ACB2apBgAmFfAAMxACKBACCFBlIKAAMSADaEYCJ8AnSsYAJkACJvBgFZAA
LtAVQ6A6YwAOZsAFZiBf/cB9tsokD2AAJ+ABHAACMKBgMaAAKGAAHhABJRADJSAmYnIlD1AC
JxACLBBhFRABF+AXEBYDJ9AkMcAC3fqtMFACYAKw/BUmTgIGQ3AD1uAKtTAKjIAFsEYFL5oF
bNAuJ4gMK3ABHP9wszZ7sxrgAR6wszfLsxygATvLs0Q7tD37s0Tbs0VbtBrAAfrqtEZ7tER7
AUCQWikADbFQCqawGzIQBF47A3qKDvaBKZFQC52ADazQCLIgC6+QDMbwtnAbt8aQDG4rt8Yg
DYpRt8kgDdGAC3Qrt84wt5nQDdsgDtIgDeKwDWCgCXgbDW5bDNCQAkZHdafgpC9grSQgA3km
F8FQBmrQIFvABgNgBlcwLQFgBlQgDPgQPWOwBpuQLJgwXGrABmOAD5qgBtDimqvEBlKwBmcQ
AMAQDJPVXacZXtViC891XJI2oq65CWRndmlzBZgABD1AvUOABV1QFXzTC/0Aa1YwIN/4mz1l
wA35QAniEAxW8Fyd0A5WQA5bagUqGgBa0AVUoAWpg6L2IAVnIAAs8iJoswaYsAT+8FtYcA64
gg8OAkMBkHd7twm40AmTwwaDwAbn8AuqcAsAtAqQ4A7AgA7CwAubAA7lgAYA4g7pd2n7IAxm
8JrrcA+LdgZp4A4OGAzq8A7d9brjwAXmMA4BgJ4DIgabsAljAAbykAb54IDuYA7AAELugAZp
IAzt0A2QVw3JUHGzgHGO8AzH0HGjgHIEkAzOUHHHcAw0lwywsHE5KApaTMaiwHNoDA1qPMbP
4AhuDAvJAA2wQFXRMMd1fMdxzMbPkAwdZ8eGEhAAOw==
--------------020408050105010904030400
Content-Type: image/gif;
 name="TSCHEMEapproved.gif"
Content-Disposition: inline;
 filename="TSCHEMEapproved.gif"
Content-Transfer-Encoding: base64

R0lGODlhdgBvAPf/AP////f39+//90KUc63WxmOljABrQs7n3jGMayF7WpzOvRBzUoy9rVKc
hHOtnHu1pc7v573e1u/3997v78DAwO/n99bO3s7G1r2txufW79bG3s691lohc72lxntjhIRa
lM611satzq2UtXtKjHM5hL2cxntahGsxe8alzqWErZxzpXNSe6V7rZRrnJxrpaVzrZRjnIRS
jHtChGMxa1ohY4RKjIRCjHM5e3s5hGsxc3Mxe2Mpa+/n7/fv9//3/+fe5/fn997O3ufW5+/e
79bG1s69zu/W797G3ufO59a91r2lvcatxq2Urda11s6tzsalxs6lzsacxr2UvbWMtb2MvXta
e7WEtXNSc617raVrpYxajJxjnIRShJRalIxSjJxanIRKhJRSlHtCe2s5a4xKjIRChGMxY4xC
jGsxa4Q5hHMxczkYOWMpY1IhUoQxhEIYQlohWmMhY3spezEQMUoYSlIYUnMhczkQOUIQQmsY
a3MYc2sQa2MIY2sIY5xSlJRKjIxChJRCjIw5hIQxe3spc3shc3MYa2sQY61rpZxalIQ5e7V7
ra1zpaVjnL2Mtc6lxsaUvefG3gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAABQALAAAAAB2AG8AQAj/ACkIHEiwoMGD
CBMqXMiwocOHEBECmEixIoAIDwYY2Mixo8ePIEEuGPCAwASLKCdGXCkQpQQHHRcYGMngQMqb
OG9ibCBzY0+OP2f6BOoxqM+TFCNWdKAgp9OnUKNKBQChQM+fWAdQHBAh6UKKEYoaQDBAowEC
U9OqXQs1rIGuKhNS5CFnUZg0hBzdNJSnD58+PyqG4ECYwwcSOwjfTDGi8I4jbCOjNLsALgCF
FIXwMcTZ0JaUTfb47dMnCcUPNDioCBCgMAfEHBKT+EBYSGoOMibCiO2YtwoVOTiI4D0FgIjb
GwDQJpyY+YkULWh8qEjAo2WIFh+UjIDRKlDJ4MNP/5xwVajNuCwpVCwgliPSikG0ZClzQ4cK
Hfjz69/Pv/9+EfrJ4IIL/vF3Awz41aeDgjeoQcMaPXi10lLtGfCeBXTAkUOCC+rQhYIyxFBg
fwqSWCKHKHY4In5q5MAGHRBKmJ56FT0wVEeWiQeVAjH16FMBFs0oZEEVSYAAUWNJIJ4EZt1Y
YQLnyTjklF8V2eRGQOJ0gI9GCTUTWlBRKeaMWjqQQAJNASCBAg8w8AAEKI0pp5w6PjXnnTcp
cGRITjqJlVAy/dlnl4HyiQAD78UppEURBOpAonXqSIB3fHbZYwMTgXlZQxQZWWGOkYYa3kYV
VTmeEGc0skgjfwCiyCCEEP9iCB92ICHqrWv1xICUBFW0ByCw2sFZEBXJYYiweRxCGh8V8XBC
c82FAICzqU0XAg0kDMfbbc35AENqJPAA2wc1MMcBt7wV9kEAJ6TmggWJ7SBtRQkMVSpmFT2y
Bx/8jvbXIfwe8gSuBOMkgVFpbqoUWBUakEDBEEMg8cQS45ReRRpZ6kBFGNwgQ31TDPFEBlPc
MMSCQ2zxhA4uPKHCyi+zvPIQXmigwxA4n3zyzfvJwEIPOgCAMwg86yCCFRp4cfMWIegghwpC
DwHgDTvcoQSvD1XkVo8LQAyVABAcEPbYYpcN51R4VsRAnwgUfEC9SIa06713LmrlRwlLxV7c
PnL/lLfCdQdOpEUSMPDTAEp2KqiTDSRukQMI/DCAAgWUhbXgmEuUUuacd+755xNK9QN3bmqX
UVkDFGD6Awpw57hUoDt0UwB68ukn33H/aelHCRSgwOubC54SAXD3vRFZ2jHA3fLLE6CdAwPs
6WWlRBXa9+4FgAo4SyjBxBECv3ttMOXF3/6R9YByFOXlB1nEXgGQih/emlcGZT9HD0ykFfu9
WqRAAxwZgKbkR7A1ATCA61sAptAjF4qE5CoEjKBFJrCR6+ALABQ0gAMkwANIZIEMfzhDIqRQ
AQma0Hv5Y6BBKtIDRTgCC3/AixMqsgXO7EsPPEgJD0IgAhFoIIc54UEJ/z7wgRMkx4Rawx/7
KpIIP/xhEIXIQyKMUBEjRIEzeRBNH85QEdo0BwYBKAEHWjARHqhgWx8IgnMCcMbUjIAiInjW
uYTTAsLQAAZxTE0KAuCC1NBgXmzc1gmASBEC/CRKDZyIIAghBzsgqyJDsAMWksCXv/CBixMp
AQ0swIMRNIcwKrgNDQgJABLYMTlHaM4HVBCvc51ABAEAQGp2cAIACCFeZJRCYUpwAjvKZl5L
+UmWtrdCigyhD4c4xB7c4IOJAAEKg9iXJQ8BGYpI4ZOFyYG0vEiYE5TAOM0RwUTUpYEANMaO
r1ROc2KZrnGCMgAW6GW8SHDE8QxlAQ/jX//gk/8FOSxLDlsgFgDahMRQBcAobdOn5gBw0PNx
ZG4FBY9bgrKxIIVuImvj2kYqmpIgcGEMM2CDGURK0pGatKQoPalKU8rSlarUDDCNaUxJSgcT
kJKYpgIApXhnER5wIQwKEsIWkICfI2gACV7oAgiQcAQdwOAJSJgCC4aAAh1IQWkscEEZNDAE
BHUBCVy9gRx08AQWqOirSCiDDo4AgiNUVQdEI9pUkTpVECgIDm+gW9Yowp7y+I0iP2hDfWTw
hBvU5wky8AFTZbAFnKHgBl2YAn6m+tYYIGGwXHUCZEWmWfx0gasa8CoShiBZux7WrHDVwVQ1
EIOpCsEFhq3DGvSKHYr/ZHR6G0lUBsywhjv49g697e1vhUtc3xb3t8A1rnKRy9zhIle4z13u
HK4QS4UypCICgJtR4ie/A+wuJsDLSd0qMoF6GSWFXttb+sSygPXFrn0YW+9bRMWjPvENAa97
73WLhACjcHQtjbLvPTvyN/1e1La4/dtNPGU79BlAwRY18IHHMwCsrA/B1APK+kb3gAk8IAGG
RK+Ep5QSCXx4IwN4j3qttwAF08hOI56TZGJM4xrb+MY4Tht4cqzjgvL4gjk5AJuiZ7sibyQB
A3DAAyLA3ZvgGCcT+F+DcyffxdkuAQ2oCYxBpxP1cgm3Rg5z+r47FkSJN3B5Kt+ACUXlB7a5
/8h+9Qj4qhthKqHkAFe65wAYYJLITKA7R2Kx8QZNaAOkmLbcY1TxZNKA8MkPAhm5nkhwZ5T9
IZpT5JVe9iI6vAKUT1Bs/gh6rTsQ/23kAQLg9FQm5SWj6K4jWRomTovJ1wFcWNVrmQADFl3k
8yDOup0KL64ldUDdvYckwO5UnrE07DpJgDvxM7RCKSTgBTabYKTSJ8NutN1r48otFkzkRBfg
AFBNIDDeFpWNDADRnFYmAFgYBAgDkQYoJisLzUx3ncwiYiALQRCOWIQfgCWHNDTCCo2cVR4i
oe/5KVGFg5sIIxCxiCcS4gv5nggWvGCIPQCsEShJwRwLQ4NapmQ4NP8Ip6rX/WD+WfMPjQAE
IexQTYsAIQ+GABgfrFCRUBImBwxFDAkqEgANWEADDE1XLHlgdJQcnZMUOXoOi26BzFhACBah
ejlTgqMlUsQQrZq5HfIQBSbm4ewd55chKjKF3uQAAx/AuhDaZZheckCXspGjHXkQANpgy+7m
4gDgCUOC2xjGlnRfjnAe15FLt4QiexgErPhiByBUBOd5GPu++rAHigQgBHPnVmrMWJh5/YAH
H2jOCH6gAee0njBYOONrOtmcIPCgMCT4fLxSIHsOWGAEqYFaRbYUQG1PxAp5IEQhhEWGm5BB
NPxiBEVE/kYAnDFeg88hD8SpdOMwJwWKJ0H/CJopBTUSZjobsCMVAJCCeFkg5YSBAdZ3aBHt
GqDfiQTA84+Vh+JYBBIeZ0nNdxrmMkuxcS0FyAEpkH6xAQMTUXi8US6JYXgpoC07kBzLsQM5
RHeCBxuuwQH1pFMeQWc5BQBOEDDKokzJ1C9+wQcDYxE9EAQiMAU0uAF09gNSUAICBQA9oAFB
cATVFQIhQEpBMAUdsINMpwFYZ0s+uIRFMIQU0QMbIAKghxIsx2zJNhdn4C+W9BdpMAQNxxbr
VijvUVtPoQD1Ym1hCBVXuFGOZyr1xSe3toYp4WVHVmd7NRErdil06BTS4yXcdWDmFRLaYxEZ
sARLgAGJuIiK2IiM//iIjhiJkDiJkhiJHaAET9ABl6iJjRgCJYSH+6Um9ucR+YQSHQAGLtAF
NWADq9iKrPiKrhiLsDiLsliLtHiLq/iKulgDHwMHeIB0pPZ49mQ+EEURXfACanUDWOADLGBY
zviM0BiN0viMPGNYMMBZGjCN1KgDklUf3qgDYrAgaFAHHvCG8DWM3LYR60MEYJCMMkBUQiAD
OuADjKUBLkBUTzAFQyUDNXAy+egCRDMEMgACXSADOhMDBrkgNxADjqU08fhZ80gGaiCQWDAz
BhkiX2VVUyAHVHMHRRCMwggAxJeOXUMRRIAGOIAyLrAFKnAyQMMCIKACmuUELMA0OuAF/v8I
IE8wBF2gAxrAAmpAID0gA9e4IGKQVTfpkiKyBSaDH2UwBDZjMhfpBS4gkDLwIXLABndwASAZ
khkEEpYGACvABmoQjvuxM/axMhzyjSkiVmuZIG55Im25H98ol/kRB29QBV1ZaoqDWzIha0yA
BxlCAzTABoR5mIYZB4RpmIW5mI7ZmJDJmIypmIZZmZHpmJLZmJlJmG2AB3dABOZYgn/4E6M2
EUKAAUqQmqq5mqzZmq75mrAZm7G5BJ+4l+cIADDRJf9lQt5lZGG5ZXa2bUgiawSkAK4WNwNk
MWhWEaN5PBHkPQ1zPPllYEnkI3MYKQzmUNOTnDHmPiBRmnUSYOa502pqOGv6xV/nI2yRYYcD
VhTT+WTo6RHEuRYHID1WBhTtBYo3Rjh78hMQtiOTxmYF9mMRx1cJJhUSsIcC5iUDSqC3OREB
RppPcUDpCGYy8Z/6+WMosWsdgV83kVGh9hNQQhEP0AAVVgBtYzkQ56AvRh3lU4yZQpIfgQCp
xij5wzoGoDq2SWMpIQAn9iVq02C7CTssWoKdUjsLgF4c2hG2pigt6mRFmocpcQAOsGlnFqWc
kxZYuqX6FRAAOw==
--------------020408050105010904030400--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SE5pN24357 for ietf-pkix-bks; Mon, 28 Oct 2002 06:05:51 -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 g9SE5nW24351 for <[e-mail]>; Mon, 28 Oct 2002 06:05:49 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 Oct 2002 14:05:50 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 JAA10032 for <[e-mail]>; Mon, 28 Oct 2002 09:05:49 -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 g9SE3A623103 for <[e-mail]>; Mon, 28 Oct 2002 09:03:10 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWFY7V>; Mon, 28 Oct 2002 09:05:47 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.22]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWFY7S; Mon, 28 Oct 2002 09:05:36 -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, 28 Oct 2002 09:05:33 -0500
Subject: Re: draft-ietf-pkix-logotypes-06.txt
In-Reply-To: <[e-mail]>
References: <Your message of "Mon, 21 Oct 2002 13:57:51 -0400." <[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>

Denis:

>>>>I agree that jingles are somewhat different than Logos.
>
>>>OK. Since you agree it is different, let us make two documents (and 
>>>hence let us define two extensions), one for visual logos, and another 
>>>one jingles.
>>
>>They are not that different!  Breaking them into separate documents would 
>>defeat the alternate presentation to the blind.
>
>If, as you mention, it is an *alternate* presentation, then since blind 
>people do not need to see logos, there would be no problem to break the 
>specification into two pieces: one for logos, one for jingles.
>
>If, as you do not mention, it is supplementary information, hence not for 
>blind people but for fun, then you breaking it into two pieces would be 
>more difficult, but could still be done.

It is an option.  Dividing it into two documents is not going to change 
anything, except blur the relationship.


>>>For the second one, it would make sense to query some blind people to 
>>>make sure that this would be really useful for them. We should hold on 
>>>the progression of the second document until we have verified this.
>>We have consulted with the people at Microsoft that write the 
>>requirements for the "accessability" aspects of software.  These are the 
>>people that are responsible for making software that can be used by 
>>disabled people.
>
>Nancy questioned:
>
>"Have any blind or otherwise visually-impaired users been consulted on 
>this issue, or weighed-in on the discussion in this forum?  If so, what 
>has their general opinion been?"
>
>People at Microsoft are not *users*, nor are they all blind or otherwise 
>visually-impaired.
>
>Additionally, the specification does not address internationalisations 
>issues, which is not a problem with (visual) logos, but it is with jingles.
>
>The Oxford dictionary provides the following definition for logo:
>
>logo / noun (pl. -os) a printed design or symbol that a company or an 
>organization uses as its special sign.
>
>Logos are only visual. Please deal with jingles separately.
>
>The Oxford dictionary provides the following definition for jingle:
>
>"a short song or tune that is easy to remember and is used in
>advertising on radio or television".

I was not the one who raised jingles.  Consider the IBM logo.  The image 
file would contain the blue bars that make up the letters.  I am sure 
everyone is familiar with this logo.  I would expect the associated audio 
file to include a person's voice speaking "IBM."


I think that we have beat this topic to death....

Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SDjFu23108 for ietf-pkix-bks; Mon, 28 Oct 2002 05:45: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 g9SDjCW23096 for <[e-mail]>; Mon, 28 Oct 2002 05:45:12 -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 OAA21740; Mon, 28 Oct 2002 14:45:37 +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 OAA18838; Mon, 28 Oct 2002 14:45:10 +0100
Message-ID: <[e-mail]>
Date: Mon, 28 Oct 2002 14:44: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: "Housley, Russ" <[e-mail]>
CC: Dean Povey <[e-mail]>, [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt
References: <Your message of "Mon, 21 Oct 2002 13:57:51 -0400." <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------010603070702070206020604"
Sender: [e-mail]
Precedence: 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.
--------------010603070702070206020604
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Russ,

> Denis:

>>> I agree that jingles are somewhat different than Logos.

>> OK. Since you agree it is different, let us make two documents (and 
>> hence let us define two extensions), one for visual logos, and another 
>> one jingles.
> 
> 
> They are not that different!  Breaking them into separate documents 
> would defeat the alternate presentation to the blind.

If, as you mention, it is an *alternate* presentation, then since blind 
people do not need to see logos, there would be no problem to break the 
specification into two pieces: one for logos, one for jingles.

If, as you do not mention, it is supplementary information, hence not for 
blind people but for fun, then you breaking it into two pieces would be more 
difficult, but could still be done.

>> For the second one, it would make sense to query some blind people to 
>> make sure that this would be really useful for them. We should hold on 
>> the progression of the second document until we have verified this.
> 
> We have consulted with the people at Microsoft that write the 
> requirements for the "accessability" aspects of software.  These are the 
> people that are responsible for making software that can be used by 
> disabled people.

Nancy questioned:

"Have any blind or otherwise visually-impaired users been consulted on this 
issue, or weighed-in on the discussion in this forum?  If so, what has their 
general opinion been?"

People at Microsoft are not *users*, nor are they all blind or otherwise 
visually-impaired.

Additionally, the specification does not address internationalisations 
issues, which is not a problem with (visual) logos, but it is with jingles.

The Oxford dictionary provides the following definition for logo:

logo / noun (pl. -os) a printed design or symbol that a company or an 
organization uses as its special sign.

Logos are only visual. Please deal with jingles separately.

The Oxford dictionary provides the following definition for jingle:

"a short song or tune that is easy to remember and is used in
advertising on radio or television".

Denis

> Russ

Now, if I had a certificate, it could well include the folling *two* 
following *community* logos. It would be up to your application, to display 
none of them, one of them or both of them.

--------------010603070702070206020604
Content-Type: image/gif;
 name="Thawte.gif"
Content-Disposition: inline;
 filename="Thawte.gif"
Content-Transfer-Encoding: base64

R0lGODlhVwA3APcAAAAAAP////z8/fT2+OXp7uIoM95rc8UMG8cTIcgWJcgZJ9YdK8odKtgg
L9YjMcohL9kkMsskMtgnNdgpN9QrOcwpNtgtO80uOtgzP9k2Q88zQNU2Q882Qt06RtA6RttA
TNNDT9VNWNhWYNpdaNlkbt9ze+CCiuCKkuWSmdWKkeiaoMeGjOmip/uvteursPy/xO64vPDB
xfLP0vXd3/3w8fzv8Pvu79RrdclpctFyfNV6g8FzfNeDjMOdodWSmt2gqNuqsa2Slv34+da2
vd7ByN/Jz9fIzJksTNvQ1ODY3dzT2rWztaCLopmEneHf4kIqZHh3et3d5CgoKe3t8qqqrT4+
PzMzNJ+foZmZm5GRk05OT0dHSN3d37Cwsm1tbmZmZ/7+//39/vr6+/j4+evr7OXl5uLi49zc
3dLS08bGx8HBwr6+v7e3uGhpfBccZBwhaB8laiInayMobCQpbCYrbScsbikuby4zcTE2czY7
dj1CelRYiGBjjEZLfm1xloGEoYyPqiIsb5uesrO0uycydXh+oJGWs6WpvLy/zMTH07K2xezt
8M3O0dDS1+bo7eXn7Nnb4NPW3eXo7sjKzsbIzO3v8+Pl6YCBg6WmqPf4+vb3+fX2+O3u8Ofo
6tDR0+rt8uns8ejr8Obp7uXo7eLm7OHl68rMz8nLzsjKzcXHyujq7dfZ3NXa4evu8urt8d3i
6Obq7+Lm68vQ1eXq7+Hm6+vu8fP19/L09vDy9Nnb3YiJivr7/O/w8ejp6ubn6Nna29bX2NPU
1c/Q0ePq8OXr8OLp7uXu8+bt8c3X3Obw9dLW2Pj6+93f4N/s8uLu8+b0+eXy9vH3+ezz9cLM
zu33+ef6/e79/8bNzunw8fL9/mhwcPf//x8gIPv//1RVVfz+/uvt7V1eXvz9/fHy8tXW1s3O
zsnKysTFxbq7u/r7+dTV0d7e2/z8+/j49/Dw7+vr6tzc29vb2tra2dnZ2NjY1/34+P78/Pb1
9f7+/u/v7+3t7eDg4NnZ2djY2BYWFv///yH5BAEAAP8ALAAAAABXADcAQAj/AF+d+PHKQBIg
JpqVIFKkRLOBBaMgVMjQ4cAoBiQmXNjw4Q+MUX6cUFiEiEMTQJwYeCWSpMlmKDGyHFmi5Ekg
SVaKrPYqgICfQIMKHUqUKJhdvX6RIwesqdOnwFTx0kdmH7MxYYpqHRrgFRJNt8KKHTvWlriz
aNEK2CUu3T5GnjyhmUdvXrC4cunV5XXPRQkU96LZ0uSCBIkZ2W5FsxGiQYECIXooaxcgzDcB
y9KiFXNLExIgz0I98nTKlOnTpk8xegQKV6I7dODwiWSq3B44c/Jc2u2nTuxDt/bEmWNHj/E5
dQI16SBhggQKQ9R4gDBhAoQew0C1gtRHzhw9pULZ/yoEJ04fKlQwoasUStoQH8ZIyZcfiZL9
+/cZ5RLjJZwWMQF8AUUAVqwRwBlS6BOAOdxgoUU4AXCjyxX7BCCFFWpocU8AwkgRQABsWBHA
FVUEgA46meAyxhbhZIEJPpd4gU+AunzoTThXqKHJMz7kAE0pQNICZCmvRDEJfvbJsgMDFSjg
AggIRAACCwg8EAMDMESQAAMG2KPBAxWE2SQMBzgJQgUuJBBmBCac4AICCsAQAgMMxIACCA+Q
gMIBMIgAJgcssMBkkz9Uk8MN1cBSyjleYNLCCA4Y8IIul6hBySSMcJFLON5AsYoY4YRThRq8
VAEFFJsIY0UvUpiRjxRbkP/RRRXhDKiLN7gKwMkiu6AjYRW3dBFOF1tsAkooYqxRxRe6iHEP
FFp8YU4AWHgTwDihVHMDogR06+234IYr7rjgwgILLZA0Ysp9qDASxbuQRPEKKeTWC662OWRT
yb789uvvvwDzG4oypjBi8MEII1wOMKHgEjC/1BRBggMLQNCACCkk4XDA1uRwwjaZbLIILuSc
YQYawKCRyy3LLBMKH3zsYUcd38HsRx9zyIZGOeoIIgcdcQgyTz+U4GFeb3AUMgJ1EjhQXXMT
WABCcxJo0AbMeNBBBx428zGHeeilNwgY3ZwAxIcfktHP2my33Q8wt2yixhJXdPELP/HQXbc8
Z3D/QQ4b6KzBhRprrFEh2umcc2IwuZwzDSQfhqGMGteYAQbaYqSxBjppCHD5GWqEXnjoaHwI
RBFopx5AGfLE4/rrZ+wjzTbUZJNNMtR0g8820BjzzYyqp24P8MEXb3wA4hB//IdgFBEF2uOo
8UUu2nCTRSpfdCGMPNzHg8T3SBghvhFJ2GD++einr74NNdCAfvvrpw//+TTUYP789QQgr08C
iLPLGLfAhTQqYYsx7OInYCCDLzbhCzFwZgyb+JD/LueTXaDtJ5U54IfwocEPBSUMGwzALy7h
C/79BIQBOMougBcGMaCwMl35gQm3QsMaakUcWREDLshQBjMwAxhnwIoN/2sIhh/8ABr2SqIS
uwWLUUShEaegBCqmSMUppiIVlGBEIyBBryWSCxo/IMLyxkjGD43jDPTgnhrXyEZ57OMdlBlj
PezEAhnYY3n2IAIPfjSkPvrxj4AEEileIQwsIumQlEiFLFghnyGRYhjF8GMzgICBBkgAAhnY
ASYQEYlXBBJIzuBBElJ3D3eEoRf2GMcYUjcFOtTBDrCMpXn4EBs/rAMe+zgEHewwh0PsIx7r
QMQd6lCHpBnAkhKQQQBE0ADnOIAFAXCBBJ7zhEAQIpawpIMe/BBLrcVmDx9Kwg2eMchTGBJJ
qWhEKQZpCWHGhg+xaEQahFMHObzBDW+Ag2/iAP8IZrBCD3G4wyCY4Qc4wOEPIqBOdRwgghBA
zToZWIInkaGHOchBD6yIQicKEQeaxcGee1jnM27Qkw9xwm0o7cc9wBCJYr5hD/KYhzz28IY3
6KERuBxEHODgBkT4AZ98EIQgrnAFLNzhDYFgQgca0IAQzG4IG7AYCaKBNnDooaZ4iGAACuEG
g3rVDX740CsQFYqyggISpUGNWhlhCV6owQy+MIMp0EAGc5ghF0uYmxnGEYwx3HUXnkAHG4Ax
hlNwwhbAyAQz0GEONnCiF4wo4CbQ8Qsx1OITqlRDOQSgCS6cwRZpOIdmxcCFzaXhFta4ASR2
kYnWuvZkwYitbIOxinH/dMF6pgqALqpwBW6UQwxo4EYvAnAOD+kCQv7AwhLMgY8q6EMKUgCh
OTwUgCWIaLqYqEIWAiAGTXwhC5fwUIw+9IVLfEgLXgCcJsIACR1sgyxiAYYw8IIXZOSgSg9g
wAVGEIEKeIABCvgvAjwQAgVc4AIiuACYwDSCEIzgAQqowAiqRCcGeAAB/k2AB0ZQAQSAQAQR
AJMGAjyCCyQABFsCAZMO8INt6IAI0eDXaKiQhSxggQpsSAXC7JuACEQASywoQQRcgIIEnEDD
MGDBh0NgABU/4MkPOIECfgwDFSgYygcwgYITYAIlc9kALEgAk7PsYwgbIARQRsAPskEEGYZh
/wzKgAIWWmCADJTgBbtZA1P6wYxeYCEcuohCGSyRj6xY8EO7AKEA+OdBFIaBLQvCAqOBUaOj
iMMnJgxAJ2JEhQ+ho7xlIK6kf4IPIyJxFJBYgy60gatwaCML5ygSI0wBiXPQqgqY+AYUvPEF
M/DiQeHghC+s4AUrmGERVgiGiWjVhQBgQgsPGkNZM7EEKXwhHLgIwCW44YtbwCIUy8DCsrZw
bC14Yws1uoI/wuGFTlDjB0NAAUEMMhGOWGTeGqFIRy6SkXpXxCMgaUlNXhKTjAjcJjABgkwO
TnCc6AQFQ0hBNYwximcQwBjQeMQziEGMZzyidxV3BMY1ToxZeBzkz/8Qxcg33vGPG4MAFl85
x1PeO1I4oxQrn0XLewfzUch85y9/hs+rwQMlLGMASE+60pfO9KY7nemb0EQmNIELS+RCGWgQ
BhpWwQxVaEITTw8705ehBCWU8exox8c9ynCG7r1uH77YxxnmbgZ2oH15SuDBNsTO975/3RW5
iAsaBk/4wpPD17cYAC5s0Xexb4MHOXhGLCZP+cpb/vKYtzwpnCiLcyISP5PAIiOUEYVSYP6R
GDeGM0iR+ck/IwdDkIYrZk/72tv+9rinfSsqAQm1+h41qlmFKD5RiVbknhruKIwFGgCCEiSh
Erl3hXtKevcyCqAM9OCH9rfP/e2nsReLJmP/DD7ggEtCIDLnIMMYX3E2MLj//fCPfxnFsA9y
pNRtwJBHL+5Rj0W7PwD3MAM1AH8BEAMU0EwQ8AE9MA3ggA/KEzyXAwSIIgoUKAqwYIHmEgoV
GAqvYAge+IEfeAiHYAiAIAimcArloAh/AAh/oAgnWBqGsIKGgAgisAALoAPJ8AxAcIALIAKP
cAzGYAALQAFHcARQUAggaAiCoAhJ6IGH0Ara4gPJ8AiPIAqvYAqvIAuNoAxsJQlVGAn5hBtz
8DVw8AZ50Adx8AZ8YBpoYAhyIAdwAAjlQAme4AdvQBxxgAdBgAES0AAjgALNtFAhIAPk5xxP
YFBjaFFliAd7MIZ1/4AHkHgHe3ALyeADUdBCmwAMTrAU/bAU5BAM+zAGAnAPa6AGhwAbccAH
aoAOS7AHP5MHMMMHfaA1QTMP7wAI+VQI6GA0feADT/NQVOM01nED6DA33fEdgVMO5HFRgNCM
h1AGAhAGUSBGAcAO+9A6r5ON/JAPaLMKsPEGfmCN68AHHWUHeXCOeeAbcKAIAXAIb2AejKAK
hmAH5rECEEA1EuADPqBQ1pEDizAj7nCMeqBVfwAHdHAHxpEHfhB+RKAD2eAwucAIwjCRFEmR
jLAKuKAJsoCKeyB4wnFR6HAO54AJvvEGiIAIcbBL54gH5/hNOtBMErABTtAMOIBMG4AEtv+w
eK+AM7khCrggDsuoB38wlH9wCJqQDTqgAz9STp9nH+k0C4nQB32wTahACebAB8axB4iACqZA
BVLZB4ewB1IpCJ5gMLJwDrKoB4WwAjeAA0EQBbMwDUGQAzsQBEJSCqMQCbLYB3tQeqAACF8Z
mIUACtCgA0aQk7iAC6oQDBJZkRV5kbjAC2WgFPzgBGbAD1zQD1zACbywCJ0wDqW0CfcwDgDi
E5pQGaDJCffQDd8QAGPgQmB3mt8AFrdgC2IgAOkwDpxwm6LYP2OgSuIgAGJgC9FgBM+TOqSF
jdnoOvBgBppQDv5QI/gABZfwDVtQDubgDdzgDZ24BdTyBQQSDl//wAYB4A+XQAYQcg5asJ36
cA7eOQ64YgXogDa7pgW6gA/gpW1WYAXb9QVbwCwfEgU+wF0OJAa7cA+/EAyeuKC/0AliIAVe
wA3TUl74gCEBwA9WoH7QeQm0EiFQoAsVsgVZwCLpwCHUhQ4iogteoGmdAENpcAneICPjFQBe
UCMB4A32OZ9g4APjRIU+KglyJUVVhAqy4As0hg/CcAnj4AtQ8AVXsAi+wAW6QAZi8Au6EAbo
cAUBAAVe4AVaqgvpgA5QMAaKdQmZAFw22gXM0gu6uQlrICBpACKY4ECYwAYOdAVf4AWXsAip
BQTJUIEbGAWnMKiEOqiyAAQp4AOJmgI8/6CPKfCoKhAoKhCpk4oCkRooLIACmiqpKICpksoC
kwqqlqoCmwqqlGqpoPqpLqACMqCDPUGAaKMKwOA29PAKOjAoFYACJyAlaWIlDAACKlACXGYC
MsAB/RUBHqACM3ACB2apBgAmFfAAMxACKBACCFBlIKAAMSADaEYCJ8AnSsYAJkACJvBgFZAA
LtAVQ6A6YwAOZsAFZiBf/cB9tsokD2AAJ+ABHAACMKBgMaAAKGAAHhABJRADJSAmYnIlD1AC
JxACLBBhFRABF+AXEBYDJ9AkMcAC3fqtMFACYAKw/BUmTgIGQ3AD1uAKtTAKjIAFsEYFL5oF
bNAuJ4gMK3ABHP9wszZ7sxrgAR6wszfLsxygATvLs0Q7tD37s0Tbs0VbtBrAAfrqtEZ7tER7
AUCQWikADbFQCqawGzIQBF47A3qKDvaBKZFQC52ADazQCLIgC6+QDMbwtnAbt8aQDG4rt8Yg
DYpRt8kgDdGAC3Qrt84wt5nQDdsgDtIgDeKwDWCgCXgbDW5bDNCQAkZHdafgpC9grSQgA3km
F8FQBmrQIFvABgNgBlcwLQFgBlQgDPgQPWOwBpuQLJgwXGrABmOAD5qgBtDimqvEBlKwBmcQ
AMAQDJPVXacZXtViC891XJI2oq65CWRndmlzBZgABD1AvUOABV1QFXzTC/0Aa1YwIN/4mz1l
wA35QAniEAxW8Fyd0A5WQA5bagUqGgBa0AVUoAWpg6L2IAVnIAAs8iJoswaYsAT+8FtYcA64
gg8OAkMBkHd7twm40AmTwwaDwAbn8AuqcAsAtAqQ4A7AgA7CwAubAA7lgAYA4g7pd2n7IAxm
8JrrcA+LdgZp4A4OGAzq8A7d9brjwAXmMA4BgJ4DIgabsAljAAbykAb54IDuYA7AAELugAZp
IAzt0A2QVw3JUHGzgHGO8AzH0HGjgHIEkAzOUHHHcAw0lwywsHE5KApaTMaiwHNoDA1qPMbP
4AhuDAvJAA2wQFXRMMd1fMdxzMbPkAwdZ8eGEhAAOw==
--------------010603070702070206020604
Content-Type: image/gif;
 name="TSCHEMEapproved.gif"
Content-Disposition: inline;
 filename="TSCHEMEapproved.gif"
Content-Transfer-Encoding: base64

R0lGODlhdgBvAPf/AP////f39+//90KUc63WxmOljABrQs7n3jGMayF7WpzOvRBzUoy9rVKc
hHOtnHu1pc7v573e1u/3997v78DAwO/n99bO3s7G1r2txufW79bG3s691lohc72lxntjhIRa
lM611satzq2UtXtKjHM5hL2cxntahGsxe8alzqWErZxzpXNSe6V7rZRrnJxrpaVzrZRjnIRS
jHtChGMxa1ohY4RKjIRCjHM5e3s5hGsxc3Mxe2Mpa+/n7/fv9//3/+fe5/fn997O3ufW5+/e
79bG1s69zu/W797G3ufO59a91r2lvcatxq2Urda11s6tzsalxs6lzsacxr2UvbWMtb2MvXta
e7WEtXNSc617raVrpYxajJxjnIRShJRalIxSjJxanIRKhJRSlHtCe2s5a4xKjIRChGMxY4xC
jGsxa4Q5hHMxczkYOWMpY1IhUoQxhEIYQlohWmMhY3spezEQMUoYSlIYUnMhczkQOUIQQmsY
a3MYc2sQa2MIY2sIY5xSlJRKjIxChJRCjIw5hIQxe3spc3shc3MYa2sQY61rpZxalIQ5e7V7
ra1zpaVjnL2Mtc6lxsaUvefG3gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAABQALAAAAAB2AG8AQAj/ACkIHEiwoMGD
CBMqXMiwocOHEBECmEixIoAIDwYY2Mixo8ePIEEuGPCAwASLKCdGXCkQpQQHHRcYGMngQMqb
OG9ibCBzY0+OP2f6BOoxqM+TFCNWdKAgp9OnUKNKBQChQM+fWAdQHBAh6UKKEYoaQDBAowEC
U9OqXQs1rIGuKhNS5CFnUZg0hBzdNJSnD58+PyqG4ECYwwcSOwjfTDGi8I4jbCOjNLsALgCF
FIXwMcTZ0JaUTfb47dMnCcUPNDioCBCgMAfEHBKT+EBYSGoOMibCiO2YtwoVOTiI4D0FgIjb
GwDQJpyY+YkULWh8qEjAo2WIFh+UjIDRKlDJ4MNP/5xwVajNuCwpVCwgliPSikG0ZClzQ4cK
Hfjz69/Pv/9+EfrJ4IIL/vF3Awz41aeDgjeoQcMaPXi10lLtGfCeBXTAkUOCC+rQhYIyxFBg
fwqSWCKHKHY4In5q5MAGHRBKmJ56FT0wVEeWiQeVAjH16FMBFs0oZEEVSYAAUWNJIJ4EZt1Y
YQLnyTjklF8V2eRGQOJ0gI9GCTUTWlBRKeaMWjqQQAJNASCBAg8w8AAEKI0pp5w6PjXnnTcp
cGRITjqJlVAy/dlnl4HyiQAD78UppEURBOpAonXqSIB3fHbZYwMTgXlZQxQZWWGOkYYa3kYV
VTmeEGc0skgjfwCiyCCEEP9iCB92ICHqrWv1xICUBFW0ByCw2sFZEBXJYYiweRxCGh8V8XBC
c82FAICzqU0XAg0kDMfbbc35AENqJPAA2wc1MMcBt7wV9kEAJ6TmggWJ7SBtRQkMVSpmFT2y
Bx/8jvbXIfwe8gSuBOMkgVFpbqoUWBUakEDBEEMg8cQS45ReRRpZ6kBFGNwgQ31TDPFEBlPc
MMSCQ2zxhA4uPKHCyi+zvPIQXmigwxA4n3zyzfvJwEIPOgCAMwg86yCCFRp4cfMWIegghwpC
DwHgDTvcoQSvD1XkVo8LQAyVABAcEPbYYpcN51R4VsRAnwgUfEC9SIa06713LmrlRwlLxV7c
PnL/lLfCdQdOpEUSMPDTAEp2KqiTDSRukQMI/DCAAgWUhbXgmEuUUuacd+755xNK9QN3bmqX
UVkDFGD6Awpw57hUoDt0UwB68ukn33H/aelHCRSgwOubC54SAXD3vRFZ2jHA3fLLE6CdAwPs
6WWlRBXa9+4FgAo4SyjBxBECv3ttMOXF3/6R9YByFOXlB1nEXgGQih/emlcGZT9HD0ykFfu9
WqRAAxwZgKbkR7A1ATCA61sAptAjF4qE5CoEjKBFJrCR6+ALABQ0gAMkwANIZIEMfzhDIqRQ
AQma0Hv5Y6BBKtIDRTgCC3/AixMqsgXO7EsPPEgJD0IgAhFoIIc54UEJ/z7wgRMkx4Rawx/7
KpIIP/xhEIXIQyKMUBEjRIEzeRBNH85QEdo0BwYBKAEHWjARHqhgWx8IgnMCcMbUjIAiInjW
uYTTAsLQAAZxTE0KAuCC1NBgXmzc1gmASBEC/CRKDZyIIAghBzsgqyJDsAMWksCXv/CBixMp
AQ0swIMRNIcwKrgNDQgJABLYMTlHaM4HVBCvc51ABAEAQGp2cAIACCFeZJRCYUpwAjvKZl5L
+UmWtrdCigyhD4c4xB7c4IOJAAEKg9iXJQ8BGYpI4ZOFyYG0vEiYE5TAOM0RwUTUpYEANMaO
r1ROc2KZrnGCMgAW6GW8SHDE8QxlAQ/jX//gk/8FOSxLDlsgFgDahMRQBcAobdOn5gBw0PNx
ZG4FBY9bgrKxIIVuImvj2kYqmpIgcGEMM2CDGURK0pGatKQoPalKU8rSlarUDDCNaUxJSgcT
kJKYpgIApXhnER5wIQwKEsIWkICfI2gACV7oAgiQcAQdwOAJSJgCC4aAAh1IQWkscEEZNDAE
BHUBCVy9gRx08AQWqOirSCiDDo4AgiNUVQdEI9pUkTpVECgIDm+gW9Yowp7y+I0iP2hDfWTw
hBvU5wky8AFTZbAFnKHgBl2YAn6m+tYYIGGwXHUCZEWmWfx0gasa8CoShiBZux7WrHDVwVQ1
EIOpCsEFhq3DGvSKHYr/ZHR6G0lUBsywhjv49g697e1vhUtc3xb3t8A1rnKRy9zhIle4z13u
HK4QS4UypCICgJtR4ie/A+wuJsDLSd0qMoF6GSWFXttb+sSygPXFrn0YW+9bRMWjPvENAa97
73WLhACjcHQtjbLvPTvyN/1e1La4/dtNPGU79BlAwRY18IHHMwCsrA/B1APK+kb3gAk8IAGG
RK+Ep5QSCXx4IwN4j3qttwAF08hOI56TZGJM4xrb+MY4Tht4cqzjgvL4gjk5AJuiZ7sibyQB
A3DAAyLA3ZvgGCcT+F+DcyffxdkuAQ2oCYxBpxP1cgm3Rg5z+r47FkSJN3B5Kt+ACUXlB7a5
/8h+9Qj4qhthKqHkAFe65wAYYJLITKA7R2Kx8QZNaAOkmLbcY1TxZNKA8MkPAhm5nkhwZ5T9
IZpT5JVe9iI6vAKUT1Bs/gh6rTsQ/23kAQLg9FQm5SWj6K4jWRomTovJ1wFcWNVrmQADFl3k
8yDOup0KL64ldUDdvYckwO5UnrE07DpJgDvxM7RCKSTgBTabYKTSJ8NutN1r48otFkzkRBfg
AFBNIDDeFpWNDADRnFYmAFgYBAgDkQYoJisLzUx3ncwiYiALQRCOWIQfgCWHNDTCCo2cVR4i
oe/5KVGFg5sIIxCxiCcS4gv5nggWvGCIPQCsEShJwRwLQ4NapmQ4NP8Ip6rX/WD+WfMPjQAE
IexQTYsAIQ+GABgfrFCRUBImBwxFDAkqEgANWEADDE1XLHlgdJQcnZMUOXoOi26BzFhACBah
ejlTgqMlUsQQrZq5HfIQBSbm4ewd55chKjKF3uQAAx/AuhDaZZheckCXspGjHXkQANpgy+7m
4gDgCUOC2xjGlnRfjnAe15FLt4QiexgErPhiByBUBOd5GPu++rAHigQgBHPnVmrMWJh5/YAH
H2jOCH6gAee0njBYOONrOtmcIPCgMCT4fLxSIHsOWGAEqYFaRbYUQG1PxAp5IEQhhEWGm5BB
NPxiBEVE/kYAnDFeg88hD8SpdOMwJwWKJ0H/CJopBTUSZjobsCMVAJCCeFkg5YSBAdZ3aBHt
GqDfiQTA84+Vh+JYBBIeZ0nNdxrmMkuxcS0FyAEpkH6xAQMTUXi8US6JYXgpoC07kBzLsQM5
RHeCBxuuwQH1pFMeQWc5BQBOEDDKokzJ1C9+wQcDYxE9EAQiMAU0uAF09gNSUAICBQA9oAFB
cATVFQIhQEpBMAUdsINMpwFYZ0s+uIRFMIQU0QMbIAKghxIsx2zJNhdn4C+W9BdpMAQNxxbr
VijvUVtPoQD1Ym1hCBVXuFGOZyr1xSe3toYp4WVHVmd7NRErdil06BTS4yXcdWDmFRLaYxEZ
sARLgAGJuIiK2IiM//iIjhiJkDiJkhiJHaAET9ABl6iJjRgCJYSH+6Um9ucR+YQSHQAGLtAF
NWADq9iKrPiKrhiLsDiLsliLtHiLq/iKulgDHwMHeIB0pPZ49mQ+EEURXfACanUDWOADLGBY
zviM0BiN0viMPGNYMMBZGjCN1KgDklUf3qgDYrAgaFAHHvCG8DWM3LYR60MEYJCMMkBUQiAD
OuADjKUBLkBUTzAFQyUDNXAy+egCRDMEMgACXSADOhMDBrkgNxADjqU08fhZ80gGaiCQWDAz
BhkiX2VVUyAHVHMHRRCMwggAxJeOXUMRRIAGOIAyLrAFKnAyQMMCIKACmuUELMA0OuAF/v8I
IE8wBF2gAxrAAmpAID0gA9e4IGKQVTfpkiKyBSaDH2UwBDZjMhfpBS4gkDLwIXLABndwASAZ
khkEEpYGACvABmoQjvuxM/axMhzyjSkiVmuZIG55Im25H98ol/kRB29QBV1ZaoqDWzIha0yA
BxlCAzTABoR5mIYZB4RpmIW5mI7ZmJDJmIypmIZZmZHpmJLZmJlJmG2AB3dABOZYgn/4E6M2
EUKAAUqQmqq5mqzZmq75mrAZm7G5BJ+4l+cIADDRJf9lQt5lZGG5ZXa2bUgiawSkAK4WNwNk
MWhWEaN5PBHkPQ1zPPllYEnkI3MYKQzmUNOTnDHmPiBRmnUSYOa502pqOGv6xV/nI2yRYYcD
VhTT+WTo6RHEuRYHID1WBhTtBYo3Rjh78hMQtiOTxmYF9mMRx1cJJhUSsIcC5iUDSqC3OREB
RppPcUDpCGYy8Z/6+WMosWsdgV83kVGh9hNQQhEP0AAVVgBtYzkQ56AvRh3lU4yZQpIfgQCp
xij5wzoGoDq2SWMpIQAn9iVq02C7CTssWoKdUjsLgF4c2hG2pigt6mRFmocpcQAOsGlnFqWc
kxZYuqX6FRAAOw==
--------------010603070702070206020604--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SDeVA22836 for ietf-pkix-bks; Mon, 28 Oct 2002 05:40:31 -0800 (PST)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SDeUW22832 for <[e-mail]>; Mon, 28 Oct 2002 05:40:30 -0800 (PST)
Received: from chrisf (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id IAA20670; Mon, 28 Oct 2002 08:39:06 -0500
From: "Christopher S. Francis" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "pkix" <[e-mail]>
Subject: RE: Attribute Certificate Policies Extension
Date: Mon, 28 Oct 2002 08:39:05 -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 V6.00.2600.0000
Importance: Normal
In-Reply-To: <009b01c27cbd$258547b0$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>

Anders,

Let me assure you that attribute certificates are being used industry in
real products.  The TimeCheck service offered by WetStone technologies is
one of them (http://www.wetstonetech.com/timecheck.html).  In my view, it is
precisely this kind of change that will help to make attribute certificates
useful beyond the rather limited scope of access control where they have
admittedly had little commercial success.

Since this group's charter focuses on X.509, and ACs are part of that
standard, I disagree with your position that this topic is not worthy of
discussion here.

Christopher S. Francis
Director Programs and Services
WetStone Technologies, Inc.
Mangrove Bay Office Center
17755 US Hwy 19 North, Suite 150
Clearwater, FL   33764
vox: [phone] x180
cell: [phone]
http://www.wetstonetech.com/

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Anders Rundgren
Sent: Saturday, October 26, 2002 2:59 AM
To: Denis Pinkas; pkix
Subject: Re: Attribute Certificate Policies Extension


Denis,
I have a long time questioned the value of X.509 ACs.
What systems and SW do you know that today supports such?

If explicit authorizations is ever going to be a major inter-organization
issue, it seems that authorizations will rather be transferred in various
types of XML-formatted messages (like SAML), and that for a number
of good reasons such as:

- XML Schemas allow exact and easy-to-differentiate authorization
  profiles to be developed

- XML is an almost human-readable format

- XML is supported by free (or built-in) software and an abundance
   of people who knows how to use it

- Practically all vendors of the required authorization management
  SW are working with XML-based systems

This limits X.509 ACs to a few local systems of little general interest,
which makes me believe that the draft is redundant.  As policies for
internal use is implicit, and typically only can be interpreted by
humans, it does not fill a need for local enterprise systems either.

As a more constructive input, I advice you to join some of the AC-
related OASIS-groups, who at least have a chance (albeit slim), to
get their work accepted by the industry.

As indicated by others, it is maybe a good idea, to from time to time,
perform polls concerning new and existing PKIX-drafts' commercial
potential, instead of wasting energy on resurrecting a dead horse.

Just my 0.002 EUR

Anders

----- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "pkix" <[e-mail]>
Sent: Friday, October 25, 2002 15:23
Subject: Attribute Certificate Policies Extension



A new version of the draft on Attribute Certificate Policies Extension has
been posted. It is available at :

http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-01.txt

Whereas the previous draft was defining different extensions, the new draft
only covers a single extension allowing to designate the policy under which
an Atribute Certificate has been issued.

This extension is not applicable to Public Key Certificates.

Denis



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SDLMj20695 for ietf-pkix-bks; Mon, 28 Oct 2002 05:21: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 g9SDLKW20685 for <[e-mail]>; Mon, 28 Oct 2002 05:21:20 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 Oct 2002 13:21: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 IAA06804 for <[e-mail]>; Mon, 28 Oct 2002 08:21: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 g9SDIgI19349 for <[e-mail]>; Mon, 28 Oct 2002 08:18:42 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWFYKF>; Mon, 28 Oct 2002 08:21:19 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.22]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWFYK1; Mon, 28 Oct 2002 08:21:14 -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, 28 Oct 2002 08:21:10 -0500
Subject: Re: draft-ietf-pkix-logotypes-06.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
Sender: [e-mail]
Precedence: 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:

>>>>>1. Page 6. Section 3. Logotype data
>>>>>
>>>>>"Implementations MUST support image data; however, support for audio 
>>>>>data is
>>>>>OPTIONAL." Audio is a good joke, in the same way, as pheromones. We are
>>>>>supposed to deal with serious documents. Please delete.
>>>>
>>>>
>>>>I belive that the response from Tom Gindin shows that there is support 
>>>>for audio in support if disabled users.  I believe that the document is 
>>>>clear that the support is OPTIONAL.
>>>
>>>
>>>The document was not clear that the support is OPTIONAL. There is still 
>>>much controversy about the need for it. No convincing arguments have 
>>>been provided. Please delete or make a strawpoll.
>>
>>The first paragraph in section 3 says:
>>    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.
>>What is unclear?
>
>The text says:
>
>Compliant applications MUST display more just one (or none) of the images 
>*and* play just one (or none) of the audio sequences at the same time.
>
>The "and" does not make it optional.

I think that displaying one image and playing zero audio sequences conforms 
with this sentence.  if you disagree, please propose alternate wording for 
this sentence.


>>>>>5. Page 7. Section 4.1.
>>>>>
>>>>>We have:
>>>>>
>>>>>       communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
>>>>>
>>>>>       LogotypeInfo ::= CHOICE {
>>>>>          direct          [0] LogotypeData,
>>>>>          indirect        [1] LogotypeReference }
>>>>>
>>>>>       LogotypeData ::= SEQUENCE {
>>>>>          image           SEQUENCE OF LogotypeImage OPTIONAL,
>>>>>
>>>>>No explanations are given on the text about what to do for a client when
>>>>>there is more than one LogotypeImage present in a communityLogo.
>>>>>
>>>>>First of all, a communityLogo may contain more than one logo which belongs
>>>>>to one or more communities. However the client has no way to know whether
>>>>>the LogotypeData includes different versions from the same logo (e.g. in
>>>>>black and white or in color) or different logos.
>>>>
>>>>
>>>>This is not supported.  The certificate may only include one image.
>>>>That image could be a composite of many different logos, if 
>>>>appropriate.  We discussed this face-to-face in Yokohama.  Discussion 
>>>>with people what develop graphical interfaces do not think it is a good 
>>>>idea to allow this complexity.  Too many images will confuse the user.
>>>
>>>
>>>>When it is appropriate to include several community logos, they must be 
>>>>combined into one image to ensure that they are consistently displayed.
>>>>If this is not done, each client will render the images differently...
>>>
>>>
>>>We still have different views on that topic, which is far more important 
>>>than audio. To give a parallel: some banks are members of both VISA and 
>>>EuroCard. Transposed into certificates, this may mean two logos. In the 
>>>same way, a CA may be certifed by two laboratories. The logo of these 
>>>two laboratories may be displayed.
>>>
>>>So for community certificates, I am requesting the possibility to have 
>>>more than one logo. The use of combined logos is not appropraite to 
>>>solve this issue.
>
>>I do not believe that we can support this without creating significant 
>>confusion.
>
>This is not an argument.

It must be.  I just made it. ;-)

> > However, it is simple and straightforward for a CA to
>>generate an image file that contains a combination of logos.  This is the 
>>only way that I can see where the combined logo is consistently displayed.
>
>No. There is no requirement to necessarily show both logos. If they are 
>combined, then it would be mandatory to display both.
>
>Your response is technology driven, since the current ASN.1 syntax does 
>not allow for that case, your are trying to find a way to accomodate the 
>need, without changing the syntax.

No.  The authors wrote the syntax after considering this argument,

Many merchants have stickers on the doors to their retail shops that 
indicate the brands of credit cards that are accepted.  They have one 
sticker with many logos.  This is useful to the consumer because the logos 
always appear in the same configuration.  I believe that the same argument 
applies here.

>The syntax needs to be changed.
>
> > If it is not consistent, then we have not helped the use
>>make a selection from a group of certificates without investigating details.
>
>It is still up to the client application to display or not when it wants,
>in that case:
>
>no logo (1), logo A (2), logo B (3), or both logo A and logo B (4).

I clearly disagree.  The choice should be no logo and one logo image (which 
may be a combination of several logos if appropriate).

Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SDBT519521 for ietf-pkix-bks; Mon, 28 Oct 2002 05:11:29 -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 g9SDBQW19516 for <[e-mail]>; Mon, 28 Oct 2002 05:11:27 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 Oct 2002 13:11:28 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 IAA06193; Mon, 28 Oct 2002 08:11:27 -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 g9SD8lp18648; Mon, 28 Oct 2002 08:08:47 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWFYG4>; Mon, 28 Oct 2002 08:11:24 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.22]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWFYGQ; Mon, 28 Oct 2002 08:11:11 -0500
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: Dean Povey <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 28 Oct 2002 08:11:07 -0500
Subject: Re: draft-ietf-pkix-logotypes-06.txt
In-Reply-To: <[e-mail]>
References: <Your message of "Mon, 21 Oct 2002 13:57:51 -0400." <[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>

Denis:

>>I agree that jingles are somewhat different than Logos.
>
>OK. Since you agree it is different, let us make two documents (and hence 
>let us define two extensions), one for visual logos, and another one jingles.

They are not that different!  Breaking them into separate documents would 
defeat the alternate presentation to the blind.

>For the second one, it would make sense to query some blind people to make 
>sure that this would be really useful for them. We should hold on the 
>progression of the second document until we have verified this.

We have consulted with the people at Microsoft that write the requirements 
for the "accessability" aspects of software.  These are the people that are 
responsible for making software that can be used by disabled people.

Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SATFo01722 for ietf-pkix-bks; Mon, 28 Oct 2002 02:29: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 g9SATDW01717 for <[e-mail]>; Mon, 28 Oct 2002 02:29: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 LAA30976; Mon, 28 Oct 2002 11:29:37 +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 LAA28070; Mon, 28 Oct 2002 11:29:15 +0100
Message-ID: <[e-mail]>
Date: Mon, 28 Oct 2002 11:29:09 +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: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt
References: <[e-mail]> <[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>

Russ,

> Denis:
> 
> I have deleted portions of the growing message thread where we appear to 
> have reached agreement.  Hopefully, this will allow us to focus on the 
> remaining areas of disagreement.

Fine.

>>>>> Since we are still in Working Group Last Call, here are my 12 
>>>> comments on
>>>> that document.
>>>>
>>>> 1. Page 6. Section 3. Logotype data
>>>>
>>>> "Implementations MUST support image data; however, support for audio 
>>>> data is
>>>> OPTIONAL." Audio is a good joke, in the same way, as pheromones. We are
>>>> supposed to deal with serious documents. Please delete.
>>>
>>>
>>> I belive that the response from Tom Gindin shows that there is 
>>> support for audio in support if disabled users.  I believe that the 
>>> document is clear that the support is OPTIONAL.
>>
>>
>> The document was not clear that the support is OPTIONAL. There is 
>> still much controversy about the need for it. No convincing arguments 
>> have been provided. Please delete or make a strawpoll.
> 
> 
> The first paragraph in section 3 says:
> 
>    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.
> 
> What is unclear?

The text says:

Compliant applications MUST display more just one (or none) of the images 
*and* play just one (or none) of the audio sequences at the same time.

The "and" does not make it optional.

>>>> 5. Page 7. Section 4.1.
>>>>
>>>> We have:
>>>>
>>>>       communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
>>>>
>>>>       LogotypeInfo ::= CHOICE {
>>>>          direct          [0] LogotypeData,
>>>>          indirect        [1] LogotypeReference }
>>>>
>>>>       LogotypeData ::= SEQUENCE {
>>>>          image           SEQUENCE OF LogotypeImage OPTIONAL,
>>>>
>>>> No explanations are given on the text about what to do for a client 
>>>> when
>>>> there is more than one LogotypeImage present in a communityLogo.
>>>>
>>>> First of all, a communityLogo may contain more than one logo which 
>>>> belongs
>>>> to one or more communities. However the client has no way to know 
>>>> whether
>>>> the LogotypeData includes different versions from the same logo 
>>>> (e.g. in
>>>> black and white or in color) or different logos.
>>>
>>>
>>> This is not supported.  The certificate may only include one image.
>>> That image could be a composite of many different logos, if 
>>> appropriate.  We discussed this face-to-face in Yokohama.  Discussion 
>>> with people what develop graphical interfaces do not think it is a 
>>> good idea to allow this complexity.  Too many images will confuse the 
>>> user.
>>
>>
>>> When it is appropriate to include several community logos, they must 
>>> be combined into one image to ensure that they are consistently 
>>> displayed.
>>> If this is not done, each client will render the images differently...
>>
>>
>> We still have different views on that topic, which is far more 
>> important than audio. To give a parallel: some banks are members of 
>> both VISA and EuroCard. Transposed into certificates, this may mean 
>> two logos. In the same way, a CA may be certifed by two laboratories. 
>> The logo of these two laboratories may be displayed.
>>
>> So for community certificates, I am requesting the possibility to have 
>> more than one logo. The use of combined logos is not appropraite to 
>> solve this issue.

> I do not believe that we can support this without creating significant 
> confusion.  

This is not an argument.

 > However, it is simple and straightforward for a CA to
> generate an image file that contains a combination of logos.  This is 
> the only way that I can see where the combined logo is consistently 
> displayed.  

No. There is no requirement to necessarily show both logos. If they are 
combined, then it would be mandatory to display both.

Your response is technology driven, since the current ASN.1 syntax does not 
allow for that case, your are trying to find a way to accomodate the need, 
without changing the syntax.

The syntax needs to be changed.

 > If it is not consistent, then we have not helped the use
> make a selection from a group of certificates without investigating 
> details.

It is still up to the client application to display or not when it wants,
in that case:

no logo (1), logo A (2), logo B (3), or both logo A and logo B (4).

>>>> 6. Page 9. Section 4.1.
>>>>
>>>>       LogotypeImageInfo ::= SEQUENCE {
>>>>          fileSize        INTEGER,  -- In octets
>>>>          xSize           INTEGER,  -- In pixels
>>>>          ySize           INTEGER,  -- In pixels
>>>>          numColors       INTEGER } -- In bits
>>>>
>>>> Text is missing to explain this structure. How is a grey scale 
>>>> indicated for
>>>> jpeg and for gif ???
>>>
>>>
>>> Do you have a recommendation?
>>
>>
>> No. But I wonder whether the structure is correct. Has it been verifed 
>> by an image expert ? Many PDAs have B&N screens only because they are 
>> cheaper.
> 
> 
> It was generated from documents that describe image formats.  You may be 
> correct that a CHOICE is needed with one branch for color images and 
> another branch for grey scale.  I will do some further investigation.

Fine.

>>>> 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."
>>>
>>>
>>> We have tried to avoid such a statement.  Instead we allow the 
>>> inclusion of the same image at many different resolutions so that the 
>>> client can select the best fit.  This is also the reason that we use 
>>> MIME types to name the format.  It allows the greatest flexibility.
>>
>>
>>  ... but is does not provide any conformance clause.
>>
>> Can we say that a client is logo-enabled if it only supports 10 x 10
>> pixels ? Unless the minimumm size (whatever it is) is always present in
>> the logo, then it is not possible to say that the client is logo-enabled.
> 
> 
> I would like to hear from developers on this one.

Let us hear from other opinions.

>>>> 8. Page 9. Section 4.1.
>>>>
>>>>       LogotypeImageInfo ::= SEQUENCE {
>>>>          fileSize        INTEGER,  -- In octets
>>>>          xSize           INTEGER,  -- In pixels
>>>>          ySize           INTEGER,  -- In pixels
>>>>          numColors       INTEGER } -- In bits
>>>>
>>>> It would also be appropriate to say what to do when the image is in 
>>>> color
>>>> and that the client has no color display available. No display at all ?
>>>> Conversion into grey scale using which kind of transposition ?
>>>
>>>
>>> The client is always allowed to ignore the logotype altogether.  The 
>>> stronger language added in response to your third comment makes this 
>>> clear.
>>
>>
>> Do you mean that if the logo is defined in color and the terminal is 
>> only B&N then the logo shall not be displayed ? If so, this should be 
>> clearly said.
> 
> 
> To make such a statement, we need to implement the color vs. grey scale 
> CHOICE that I described earlier.  I will do further investigation.

Fine.

>>>> 12. Page 11. Section 5. Type of certificates
>>>>
>>>>    Logotypes MAY be present in three types of certificates:
>>>>
>>>>      - CA certificates
>>>>      - End-entity certificates
>>>>      - Attribute certificates
>>>>
>>>> Why is there such a limitation ? CRL Issuers, OCSP responders or 
>>>> TSUs may
>>>> have logotypes present in their certificates.
>>>>
>>>> Replace with : "Logotypes MAY be present in any type of certificate".
>>>
>>>
>>> David Cross spoke against this suggestion.
>>
>>
>> No. David Croos spoke about the *display* of the logo, not the 
>> *presence* of the logo. Please make the change or provide new arguments.
> 
> 
> I propose a complete rewrite of section 5:
> 
> 5. Type of certificates
> 
>    Logotypes MAY included in public key certificates and attribute
>    certificates at the discretion of the certificate issuer; however;
>    logotypes MUST NOT be part of certification path validation or any
>    type of automated processing. The sole purpose of logotypes is to
>    enhance display of a particular certificate, regardless of its
>    position in a certification path.

This solves my concern for that point. Thanks.

Denis

> Russ
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SAM3a01417 for ietf-pkix-bks; Mon, 28 Oct 2002 02:22:03 -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 g9SAM0W01410 for <[e-mail]>; Mon, 28 Oct 2002 02:22:01 -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 LAA25998; Mon, 28 Oct 2002 11:22:20 +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 LAA18640; Mon, 28 Oct 2002 11:21:37 +0100
Message-ID: <[e-mail]>
Date: Mon, 28 Oct 2002 11:07: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: "Housley, Russ" <[e-mail]>
CC: Dean Povey <[e-mail]>, [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt
References: <Your message of "Mon, 21 Oct 2002 13:57:51 -0400." <[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>

Russ,

> I agree that jingles are somewhat different than Logos.  

OK. Since you agree it is different, let us make two documents (and hence 
let us define two extensions), one for visual logos, and another one jingles.

For the second one, it would make sense to query some blind people to make 
sure that this would be really useful for them. We should hold on the 
progression of the second document until we have verified this.

Denis

> However, the 
> audio file could simple be "the right voice" saying the company name.  
> Several companies have famous people with easily distinguished voices do 
> soundtracks for their commercials, little blurbs on the phone, and such.
> 
> Again, the point is accessability and helping the user make the most 
> appropriate selection.
> 
> Russ
> 
> At 03:02 PM 10/23/2002 +1000, Dean Povey wrote:
> 
>> <meta>I have been sitting on the sidelines in this debate for a bit,
>> because I thought it would all go away.  Since it appears not to have, I
>> feel obliged to vent :-) </meta>
>>
>> >>If a user using a client is blind, do we think he will be more 
>> confident by
>> >>hearing the gingle ? How does he make sure that the gingle really 
>> originates
>> >>from the logoype extension ?
>> >
>> >The jingle associated with a brand may well help a blind person 
>> select the
>> >most appropriate certificate.  Remember that this is one of the primary
>> >motives for the specification.
>>
>> I don't buy this.  Logos/trademarks are a piece of IP that most companies
>> invest a considerable amount of time and effort associating with their
>> brand.  Jingles are produced by advertising companies and generally 
>> have a
>> much shorter life time.  Sometimes companies license some existing music
>> for their jingle (as in Microsoft's Start Me Up campaign).  Besides which
>> many of companies which matter most for this spec don't have recognisable
>> jingles.  Can you hum the RSA jingle Russ :-).  Does anyone know the
>> Verisign one.
>>
>> Adding a jingle to a certificate means revoking it every time a company
>> changes its advertising.  This is clearly silly.  Whilst logos do change,
>> the cost of changing them is so high in most organisations that it 
>> seems to
>> be a rarer event (they last years rather than weeks). The whole point of
>> logotypes is to provide a mechanism to increase trust recognition in
>> certificates. Clearly, displaying a logo is not useful in improving trust
>> to a blind person, however there are other means available (e.g. the
>> browser software can read out the subject and issuer names to them).
>>
>> Notwithstanding the good intentions of the draft editors who have in many
>> ways produced an excellent document, I STRONGLY RECOMMEND that the whole
>> audio bit of the logotypes draft be deleted as a bad joke.
>>
>> -- 
>> Dean Povey,             |em: [e-mail]|JCSI: Java security 
>> toolkit
>> Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C PKI 
>> toolkit
>> Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C SSL 
>> toolkit
>> Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML 
>> Signatures
> 
> 





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9Q765H08189 for ietf-pkix-bks; Sat, 26 Oct 2002 00:06:05 -0700 (PDT)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9Q764W08179 for <[e-mail]>; Sat, 26 Oct 2002 00:06:04 -0700 (PDT)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailb.telia.com (8.12.5/8.12.5) with SMTP id g9Q75tL7020144; Sat, 26 Oct 2002 09:05:55 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <009b01c27cbd$258547b0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "pkix" <[e-mail]>
References: <[e-mail]>
Subject: Re: Attribute Certificate Policies Extension
Date: Sat, 26 Oct 2002 08:58:48 +0200
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>

Denis, 
I have a long time questioned the value of X.509 ACs. 
What systems and SW do you know that today supports such? 

If explicit authorizations is ever going to be a major inter-organization 
issue, it seems that authorizations will rather be transferred in various 
types of XML-formatted messages (like SAML), and that for a number 
of good reasons such as: 

- XML Schemas allow exact and easy-to-differentiate authorization
  profiles to be developed

- XML is an almost human-readable format

- XML is supported by free (or built-in) software and an abundance
   of people who knows how to use it

- Practically all vendors of the required authorization management
  SW are working with XML-based systems

This limits X.509 ACs to a few local systems of little general interest,
which makes me believe that the draft is redundant.  As policies for
internal use is implicit, and typically only can be interpreted by
humans, it does not fill a need for local enterprise systems either.

As a more constructive input, I advice you to join some of the AC-
related OASIS-groups, who at least have a chance (albeit slim), to
get their work accepted by the industry.

As indicated by others, it is maybe a good idea, to from time to time,
perform polls concerning new and existing PKIX-drafts' commercial
potential, instead of wasting energy on resurrecting a dead horse.

Just my 0.002 EUR

Anders

----- Original Message ----- 
From: "Denis Pinkas" <[e-mail]>
To: "pkix" <[e-mail]>
Sent: Friday, October 25, 2002 15:23
Subject: Attribute Certificate Policies Extension



A new version of the draft on Attribute Certificate Policies Extension has 
been posted. It is available at :

http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-01.txt

Whereas the previous draft was defining different extensions, the new draft 
only covers a single extension allowing to designate the policy under which 
an Atribute Certificate has been issued.

This extension is not applicable to Public Key Certificates.

Denis



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PK1Uw23165 for ietf-pkix-bks; Fri, 25 Oct 2002 13:01:30 -0700 (PDT)
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 g9PK1TW23160 for <[e-mail]>; Fri, 25 Oct 2002 13:01:29 -0700 (PDT)
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 185Ae7-0003tw-00 for [e-mail]; Fri, 25 Oct 2002 16:01:27 -0400
Message-ID: <[e-mail]>
Date: Fri, 25 Oct 2002 16:01:04 -0400
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: Fwd: PKI Forum
References: <[e-mail] .com> <[e-mail]>
Content-Type: multipart/alternative; boundary="------------060707020103080802010606"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------060707020103080802010606
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

 From the looks of their web site, http://www.pkiforum.com,  they
seem to be doing their intended job:
 
"PKIForum.com is an independent news, information and education
organization focused on public key infrastructure (PKI)."

Phil

Housley, Russ wrote:

>
> Christine:
>
> I think that they are struggling.  They are not supposed to develop 
> technical standards; there are plenty of other organizations for 
> that.  They are supposed to help with PKI adoption.  So far, I have 
> not seen anything useful.
>
> The work that they did in CMP interoperability was useful, but it was 
> too little too late.
>
> Russ
>
>
>
>> At 07:19 PM 10/22/2002, Housley, Russ wrote:
>>
>>> I thought that the members of the PKIX WG would find this 
>>> interesting....
>>>
>>> Russ
>>>
>>> > OASIS is pleased to announce that on 1 November, PKI Forum will
>>> > become the newest OASIS Member Section.
>>
>>
>> What's your opinion about PKI forum? I've visited their Amsterdam 
>> meeting earlier this year, but I was not impressed.
>>
>> dagdag
>> Christine
>
>


--------------060707020103080802010606
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>
>From the looks of their web site, <a class="moz-txt-link-freetext" href="http://www.pkiforum.com">http://www.pkiforum.com</a>, &nbsp;they<br>
seem to be doing their intended job:<br>
&nbsp;<br>
"<font face="Trebuchet MS, Verdana, Arial, Helvetica, sans-serif"
 size="2">PKIForum.com is an independent news, information and education
<br>
organization focused on public key infrastructure (PKI)."</font><br>
<br>
Phil<br>
<br>
Housley, Russ wrote:<br>
<blockquote type="cite"
 cite="[e-mail]"> 
  <br>
Christine: <br>
 <br>
I think that they are struggling.&nbsp; They are not supposed to develop  technical
standards; there are plenty of other organizations for  that.&nbsp; They are supposed
to help with PKI adoption.&nbsp; So far, I have not  seen anything useful. <br>
 <br>
The work that they did in CMP interoperability was useful, but it was too
 little too late. <br>
 <br>
Russ <br>
 <br>
 <br>
 <br>
  <blockquote type="cite">At 07:19 PM 10/22/2002, Housley, Russ wrote: <br>
 <br>
    <blockquote type="cite">I thought that the members of the PKIX WG would
find this interesting.... <br>
 <br>
Russ <br>
 <br>
&gt; OASIS is pleased to announce that on 1 November, PKI Forum will <br>
&gt; become the newest OASIS Member Section. <br>
    </blockquote>
 <br>
What's your opinion about PKI forum? I've visited their Amsterdam meeting
 earlier this year, but I was not impressed. <br>
 <br>
dagdag <br>
Christine <br>
  </blockquote>
 <br>
</blockquote>
<br>
</body>
</html>

--------------060707020103080802010606--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PIVgP18352 for ietf-pkix-bks; Fri, 25 Oct 2002 11:31:42 -0700 (PDT)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PIVaW18334 for <[e-mail]>; Fri, 25 Oct 2002 11:31:36 -0700 (PDT)
Received: from Santesson ([213.64.1.46]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 25 Oct 2002 20:31:33 +0200
From: "Stefan Santesson" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: draft-ietf-pkix-logotypes-06.txt
Date: Fri, 25 Oct 2002 20:31:31 +0200
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: 25 Oct 2002 18:31:33.0578 (UTC) FILETIME=[BE8CA2A0:01C27C54]
Sender: [e-mail]
Precedence: 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,

I agree to everything you suggest here.

Speaking about different image formats options, I still wonder, and would
like input from implementers, if it would be worth the effort to
define/recommend some standard sizes. Some part of me believe this would
increase interoperability and as Issuer of certificates it would make life
easier for me If I have some hints about what clients may expect for optimal
performance.

But maybe this is a post-standard task for another fora?

/Stefan

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Housley, Russ
> Sent: Friday, October 25, 2002 5:45 PM
> To: Denis Pinkas
> Cc: [e-mail]
> Subject: Re: draft-ietf-pkix-logotypes-06.txt
>
>
>
> Denis:
>
> I have deleted portions of the growing message thread where we appear to
> have reached agreement.  Hopefully, this will allow us to focus on the
> remaining areas of disagreement.
>
> >>>Since we are still in Working Group Last Call, here are my 12
> comments on
> >>>that document.
> >>>
> >>>1. Page 6. Section 3. Logotype data
> >>>
> >>>"Implementations MUST support image data; however, support for
> audio data is
> >>>OPTIONAL." Audio is a good joke, in the same way, as pheromones. We are
> >>>supposed to deal with serious documents. Please delete.
> >>
> >>I belive that the response from Tom Gindin shows that there is support
> >>for audio in support if disabled users.  I believe that the document is
> >>clear that the support is OPTIONAL.
> >
> >The document was not clear that the support is OPTIONAL. There is still
> >much controversy about the need for it. No convincing arguments
> have been
> >provided. Please delete or make a strawpoll.
>
> The first paragraph in section 3 says:
>
>     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.
>
> What is unclear?
>
>
> >>>5. Page 7. Section 4.1.
> >>>
> >>>We have:
> >>>
> >>>       communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
> >>>
> >>>       LogotypeInfo ::= CHOICE {
> >>>          direct          [0] LogotypeData,
> >>>          indirect        [1] LogotypeReference }
> >>>
> >>>       LogotypeData ::= SEQUENCE {
> >>>          image           SEQUENCE OF LogotypeImage OPTIONAL,
> >>>
> >>>No explanations are given on the text about what to do for a
> client when
> >>>there is more than one LogotypeImage present in a communityLogo.
> >>>
> >>>First of all, a communityLogo may contain more than one logo
> which belongs
> >>>to one or more communities. However the client has no way to
> know whether
> >>>the LogotypeData includes different versions from the same
> logo (e.g. in
> >>>black and white or in color) or different logos.
> >>
> >>This is not supported.  The certificate may only include one image.
> >>That image could be a composite of many different logos, if
> >>appropriate.  We discussed this face-to-face in Yokohama.  Discussion
> >>with people what develop graphical interfaces do not think it is a good
> >>idea to allow this complexity.  Too many images will confuse the user.
> >
> >>When it is appropriate to include several community logos, they must be
> >>combined into one image to ensure that they are consistently displayed.
> >>If this is not done, each client will render the images differently...
> >
> >We still have different views on that topic, which is far more important
> >than audio. To give a parallel: some banks are members of both VISA and
> >EuroCard. Transposed into certificates, this may mean two logos. In the
> >same way, a CA may be certifed by two laboratories. The logo of
> these two
> >laboratories may be displayed.
> >
> >So for community certificates, I am requesting the possibility to have
> >more than one logo. The use of combined logos is not appropraite
> to solve
> >this issue.
>
> I do not believe that we can support this without creating significant
> confusion.  However, it is simple and straightforward for a CA to
> generate
> an image file that contains a combination of logos.  This is the only way
> that I can see where the combined logo is consistently displayed.
>  If it is
> not consistent, then we have not helped the use make a selection from a
> group of certificates without investigating details.
>
>
> >>>6. Page 9. Section 4.1.
> >>>
> >>>       LogotypeImageInfo ::= SEQUENCE {
> >>>          fileSize        INTEGER,  -- In octets
> >>>          xSize           INTEGER,  -- In pixels
> >>>          ySize           INTEGER,  -- In pixels
> >>>          numColors       INTEGER } -- In bits
> >>>
> >>>Text is missing to explain this structure. How is a grey scale
> indicated for
> >>>jpeg and for gif ???
> >>
> >>Do you have a recommendation?
> >
> >No. But I wonder whether the structure is correct. Has it been
> verifed by
> >an image expert ? Many PDAs have B&N screens only because they
> are cheaper.
>
> It was generated from documents that describe image formats.  You may be
> correct that a CHOICE is needed with one branch for color images and
> another branch for grey scale.  I will do some further investigation.
>
>
> >>>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."
> >>
> >>We have tried to avoid such a statement.  Instead we allow the
> inclusion
> >>of the same image at many different resolutions so that the client can
> >>select the best fit.  This is also the reason that we use MIME types to
> >>name the format.  It allows the greatest flexibility.
> >
> >  ... but is does not provide any conformance clause.
> >
> >Can we say that a client is logo-enabled if it only supports 10 x 10
> >pixels ? Unless the minimumm size (whatever it is) is always present in
> >the logo, then it is not possible to say that the client is logo-enabled.
>
> I would like to hear from developers on this one.
>
>
> >>>8. Page 9. Section 4.1.
> >>>
> >>>       LogotypeImageInfo ::= SEQUENCE {
> >>>          fileSize        INTEGER,  -- In octets
> >>>          xSize           INTEGER,  -- In pixels
> >>>          ySize           INTEGER,  -- In pixels
> >>>          numColors       INTEGER } -- In bits
> >>>
> >>>It would also be appropriate to say what to do when the image
> is in color
> >>>and that the client has no color display available. No display at all ?
> >>>Conversion into grey scale using which kind of transposition ?
> >>
> >>The client is always allowed to ignore the logotype altogether.  The
> >>stronger language added in response to your third comment makes
> this clear.
> >
> >Do you mean that if the logo is defined in color and the
> terminal is only
> >B&N then the logo shall not be displayed ? If so, this should be
> clearly said.
>
> To make such a statement, we need to implement the color vs. grey scale
> CHOICE that I described earlier.  I will do further investigation.
>
>
> >>>12. Page 11. Section 5. Type of certificates
> >>>
> >>>    Logotypes MAY be present in three types of certificates:
> >>>
> >>>      - CA certificates
> >>>      - End-entity certificates
> >>>      - Attribute certificates
> >>>
> >>>Why is there such a limitation ? CRL Issuers, OCSP responders
> or TSUs may
> >>>have logotypes present in their certificates.
> >>>
> >>>Replace with : "Logotypes MAY be present in any type of certificate".
> >>
> >>David Cross spoke against this suggestion.
> >
> >No. David Croos spoke about the *display* of the logo, not the
> *presence*
> >of the logo. Please make the change or provide new arguments.
>
> I propose a complete rewrite of section 5:
>
> 5. Type of certificates
>
>     Logotypes MAY included in public key certificates and attribute
>     certificates at the discretion of the certificate issuer; however;
>     logotypes MUST NOT be part of certification path validation or any
>     type of automated processing. The sole purpose of logotypes is to
>     enhance display of a particular certificate, regardless of its
>     position in a certification path.
>
> Russ
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PHocm16476 for ietf-pkix-bks; Fri, 25 Oct 2002 10:50:38 -0700 (PDT)
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 g9PHoaW16468 for <[e-mail]>; Fri, 25 Oct 2002 10:50:36 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05200e03b9df33433fbe@[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, 25 Oct 2002 10:50:34 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: draft-ietf-pkix-logotypes-06.txt
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 10:12 AM -0700 10/25/02, Freeman Nancy-P26924 wrote:
><long debate on audio logotypes deleted>
>
>Excuse me for jumping in on the middle of the discussion, but have 
>any blind or otherwise visually-impaired users been consulted on 
>this issue, or weighed-in on the discussion in this forum?  If so, 
>what has their general opinion been?

You mean asking the people who would be affected by our choices? Odd 
concept, that. :-)

It is clear that the two types of logos in this draft have very 
different purposes. The graphics are for ease-of-identification; the 
audio is for visually-impared users for whom the graphics are of no 
use.

For those of you new to this topic, the visually-impared community 
has a lot of very technically-savvy folks who know both how to 
specify what they need if the techncial community would just listen 
to them. Unless I missed it, we haven't listened to them, but have 
done what is typical, which is to assume that we know what is best 
for them (and my sincere apologies if I got that wrong).

We could easily come out with a graphics-only protocol document that 
says "we know that this excludes vision-impared users, and this can 
be rectified later when we are sure that our solution meets their 
needs". Otherwise, we risk saying "look, we fixed it for the 
visually-impared" but giving them something that is only partially 
useful or underspecified.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PHAlV13024 for ietf-pkix-bks; Fri, 25 Oct 2002 10:10:47 -0700 (PDT)
Received: from az25ege02.gd-decisionsystems.com (az25ege02.gd-decisionsystems.com [65.121.28.21]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9PHAjW13016 for <[e-mail]>; Fri, 25 Oct 2002 10:10:45 -0700 (PDT)
Received: from az25egi01.gddsi.com ([10.240.12.60]) by az25ege02 with InterScan Messaging Security Suite for SMTP; Fri, 25 Oct 2002 10:14:50 -0700
Received: from az25exf01.gddsi.com ([10.240.12.50]) by az25egi01.gddsi.com with InterScan Messaging Security Suite for SMTP; Fri, 25 Oct 2002 10:09:38 -0700
Received: from AZ25EXM01N2.gddsi.com ([10.240.12.42]) by az25exf01.gddsi.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 25 Oct 2002 10:09:38 -0700
x-mimeole: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: draft-ietf-pkix-logotypes-06.txt
Date: Fri, 25 Oct 2002 10:12:28 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-logotypes-06.txt
Thread-Index: AcJ7y6cu2S9ACxGiS/mUZBLBENrX2AAfNp2g
From: "Freeman Nancy-P26924" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 25 Oct 2002 17:09:38.0377 (UTC) FILETIME=[4CDC7B90:01C27C49]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9PHAjW13017
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<long debate on audio logotypes deleted>

Excuse me for jumping in on the middle of the discussion, but have any blind or otherwise visually-impaired users been consulted on this issue, or weighed-in on the discussion in this forum?  If so, what has their general opinion been?

Nancy L. Freeman
Systems Engineer
General Dynamics Decision Systems



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PGBlh08735 for ietf-pkix-bks; Fri, 25 Oct 2002 09:11:47 -0700 (PDT)
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 g9PGBjW08731 for <[e-mail]>; Fri, 25 Oct 2002 09:11:45 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 25 Oct 2002 16:11:47 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 MAA19556 for <[e-mail]>; Fri, 25 Oct 2002 12:11:46 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g9PG98P28534 for <[e-mail]>; Fri, 25 Oct 2002 12:09:08 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWF1JP>; Fri, 25 Oct 2002 12:11:44 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.10]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWF1JL; Fri, 25 Oct 2002 12:11:39 -0400
From: "Housley, Russ" <[e-mail]>
To: Dean Povey <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 25 Oct 2002 11:52:00 -0400
Subject: Re: draft-ietf-pkix-logotypes-06.txt 
In-Reply-To: <[e-mail]>
References: <Your message of "Wed, 23 Oct 2002 19:33:04 MST." <[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>

Dean:

Reading the content of the certificate is what we are trying to avoid.  For 
the people without disabilities, the image is intended to provide a quickly 
identifiable affiliation.  We want a similar aid to the visually disabled.

Russ

  At 08:51 AM 10/25/2002 +1000, Dean Povey wrote:
>On Wed, 23 Oct 2002 19:33:04 MST, "Trevor Freeman" wrote:
> >Dean,
> >The approach you suggest would put the onus on the application having
> >text to audio technology to support this case as apposed to simply
> >playing an audio file. And that text to audio technology must work for
> >all languages and cope with translation. That is a pretty high bar.
>
>How else do you think visually impaired people read web pages?  I don't
>know a huge amount about this, but there is a variety of software (e.g.
>JAWS see http://www.freedomscientific.com/fs_products/software_jaws.asp)
>that does text to speech translation, and when you develop web sites for
>accessibility you consider how such software will "read" your
>site.
>
>However, the comment about languages is interesting, will
>internationalization issues be addressed in audio types?
>
>I apologise for not raising this issue earlier than last call, but it
>seems there is sufficient controversy about this feature to warrant a
>decision.  I think most of the major arguments have been covered, and I
>have seen at least one other call for a straw poll on the feature.  I have
>no wish to hold up this draft endlessly.
>
>I think the issue of accessibility is an important one, but perhaps this
>needs to be addressed in a separate draft that considers other parts of
>PKIX as well.
>
>If we are to hold a straw poll, might I suggest rather than a simple
>plebiscite on whether audio is in or out that the options proposed be:
>
>1. To exclude the audio type from the draft, and either provide text
>    addressing accessibility concerns (for example using the suggestion that
>    software read out the issuer and/or subject names), or make a work item
>    to write a separate draft which deals with accessibility issues related
>    to PKIX in general.
>
>2. To leave the audio type in, and add text to security considerations to
>    deal with the problem of distinguishing audio for trust purposes from
>    any other audio that an application might present, as well as address
>    the internationalisation issue.
>
>Thoughts?
>--
>Dean Povey,             |em: [e-mail]|JCSI: Java security toolkit
>Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C PKI toolkit
>Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C SSL toolkit
>Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML Signatures


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PGBhJ08728 for ietf-pkix-bks; Fri, 25 Oct 2002 09:11:43 -0700 (PDT)
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 g9PGBeW08720 for <[e-mail]>; Fri, 25 Oct 2002 09:11:40 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 25 Oct 2002 16:11:42 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 MAA19536; Fri, 25 Oct 2002 12:11:41 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g9PG93h28514; Fri, 25 Oct 2002 12:09:03 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWF1JJ>; Fri, 25 Oct 2002 12:11:39 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.10]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWF1J1; Fri, 25 Oct 2002 12:11:34 -0400
From: "Housley, Russ" <[e-mail]>
To: Dean Povey <[e-mail]>
Cc: Denis Pinkas <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 25 Oct 2002 11:07:45 -0400
Subject: Re: draft-ietf-pkix-logotypes-06.txt 
In-Reply-To: <[e-mail]>
References: <Your message of "Mon, 21 Oct 2002 13:57:51 -0400." <[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>

Dean:

I agree that jingles are somewhat different than Logos.  However, the audio 
file could simple be "the right voice" saying the company name.  Several 
companies have famous people with easily distinguished voices do 
soundtracks for their commercials, little blurbs on the phone, and such.

Again, the point is accessability and helping the user make the most 
appropriate selection.

Russ

At 03:02 PM 10/23/2002 +1000, Dean Povey wrote:
><meta>I have been sitting on the sidelines in this debate for a bit,
>because I thought it would all go away.  Since it appears not to have, I
>feel obliged to vent :-) </meta>
>
> >>If a user using a client is blind, do we think he will be more confident by
> >>hearing the gingle ? How does he make sure that the gingle really 
> originates
> >>from the logoype extension ?
> >
> >The jingle associated with a brand may well help a blind person select the
> >most appropriate certificate.  Remember that this is one of the primary
> >motives for the specification.
>
>I don't buy this.  Logos/trademarks are a piece of IP that most companies
>invest a considerable amount of time and effort associating with their
>brand.  Jingles are produced by advertising companies and generally have a
>much shorter life time.  Sometimes companies license some existing music
>for their jingle (as in Microsoft's Start Me Up campaign).  Besides which
>many of companies which matter most for this spec don't have recognisable
>jingles.  Can you hum the RSA jingle Russ :-).  Does anyone know the
>Verisign one.
>
>Adding a jingle to a certificate means revoking it every time a company
>changes its advertising.  This is clearly silly.  Whilst logos do change,
>the cost of changing them is so high in most organisations that it seems to
>be a rarer event (they last years rather than weeks). The whole point of
>logotypes is to provide a mechanism to increase trust recognition in
>certificates. Clearly, displaying a logo is not useful in improving trust
>to a blind person, however there are other means available (e.g. the
>browser software can read out the subject and issuer names to them).
>
>Notwithstanding the good intentions of the draft editors who have in many
>ways produced an excellent document, I STRONGLY RECOMMEND that the whole
>audio bit of the logotypes draft be deleted as a bad joke.
>
>--
>Dean Povey,             |em: [e-mail]|JCSI: Java security toolkit
>Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C PKI toolkit
>Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C SSL toolkit
>Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML Signatures


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PGBga08727 for ietf-pkix-bks; Fri, 25 Oct 2002 09:11:42 -0700 (PDT)
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 g9PGBeW08719 for <[e-mail]>; Fri, 25 Oct 2002 09:11:40 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 25 Oct 2002 16:11:42 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 MAA19538 for <[e-mail]>; Fri, 25 Oct 2002 12:11:41 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g9PG93Z28513 for <[e-mail]>; Fri, 25 Oct 2002 12:09:03 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWF1JK>; Fri, 25 Oct 2002 12:11:39 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.10]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWF1JF; Fri, 25 Oct 2002 12:11:35 -0400
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: Fri, 25 Oct 2002 11:45:22 -0400
Subject: Re: draft-ietf-pkix-logotypes-06.txt
In-Reply-To: <[e-mail]>
References: <[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>

Denis:

I have deleted portions of the growing message thread where we appear to 
have reached agreement.  Hopefully, this will allow us to focus on the 
remaining areas of disagreement.

>>>Since we are still in Working Group Last Call, here are my 12 comments on
>>>that document.
>>>
>>>1. Page 6. Section 3. Logotype data
>>>
>>>"Implementations MUST support image data; however, support for audio data is
>>>OPTIONAL." Audio is a good joke, in the same way, as pheromones. We are
>>>supposed to deal with serious documents. Please delete.
>>
>>I belive that the response from Tom Gindin shows that there is support 
>>for audio in support if disabled users.  I believe that the document is 
>>clear that the support is OPTIONAL.
>
>The document was not clear that the support is OPTIONAL. There is still 
>much controversy about the need for it. No convincing arguments have been 
>provided. Please delete or make a strawpoll.

The first paragraph in section 3 says:

    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.

What is unclear?


>>>5. Page 7. Section 4.1.
>>>
>>>We have:
>>>
>>>       communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
>>>
>>>       LogotypeInfo ::= CHOICE {
>>>          direct          [0] LogotypeData,
>>>          indirect        [1] LogotypeReference }
>>>
>>>       LogotypeData ::= SEQUENCE {
>>>          image           SEQUENCE OF LogotypeImage OPTIONAL,
>>>
>>>No explanations are given on the text about what to do for a client when
>>>there is more than one LogotypeImage present in a communityLogo.
>>>
>>>First of all, a communityLogo may contain more than one logo which belongs
>>>to one or more communities. However the client has no way to know whether
>>>the LogotypeData includes different versions from the same logo (e.g. in
>>>black and white or in color) or different logos.
>>
>>This is not supported.  The certificate may only include one image.
>>That image could be a composite of many different logos, if 
>>appropriate.  We discussed this face-to-face in Yokohama.  Discussion 
>>with people what develop graphical interfaces do not think it is a good 
>>idea to allow this complexity.  Too many images will confuse the user.
>
>>When it is appropriate to include several community logos, they must be 
>>combined into one image to ensure that they are consistently displayed.
>>If this is not done, each client will render the images differently...
>
>We still have different views on that topic, which is far more important 
>than audio. To give a parallel: some banks are members of both VISA and 
>EuroCard. Transposed into certificates, this may mean two logos. In the 
>same way, a CA may be certifed by two laboratories. The logo of these two 
>laboratories may be displayed.
>
>So for community certificates, I am requesting the possibility to have 
>more than one logo. The use of combined logos is not appropraite to solve 
>this issue.

I do not believe that we can support this without creating significant 
confusion.  However, it is simple and straightforward for a CA to generate 
an image file that contains a combination of logos.  This is the only way 
that I can see where the combined logo is consistently displayed.  If it is 
not consistent, then we have not helped the use make a selection from a 
group of certificates without investigating details.


>>>6. Page 9. Section 4.1.
>>>
>>>       LogotypeImageInfo ::= SEQUENCE {
>>>          fileSize        INTEGER,  -- In octets
>>>          xSize           INTEGER,  -- In pixels
>>>          ySize           INTEGER,  -- In pixels
>>>          numColors       INTEGER } -- In bits
>>>
>>>Text is missing to explain this structure. How is a grey scale indicated for
>>>jpeg and for gif ???
>>
>>Do you have a recommendation?
>
>No. But I wonder whether the structure is correct. Has it been verifed by 
>an image expert ? Many PDAs have B&N screens only because they are cheaper.

It was generated from documents that describe image formats.  You may be 
correct that a CHOICE is needed with one branch for color images and 
another branch for grey scale.  I will do some further investigation.


>>>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."
>>
>>We have tried to avoid such a statement.  Instead we allow the inclusion 
>>of the same image at many different resolutions so that the client can 
>>select the best fit.  This is also the reason that we use MIME types to 
>>name the format.  It allows the greatest flexibility.
>
>  ... but is does not provide any conformance clause.
>
>Can we say that a client is logo-enabled if it only supports 10 x 10
>pixels ? Unless the minimumm size (whatever it is) is always present in
>the logo, then it is not possible to say that the client is logo-enabled.

I would like to hear from developers on this one.


>>>8. Page 9. Section 4.1.
>>>
>>>       LogotypeImageInfo ::= SEQUENCE {
>>>          fileSize        INTEGER,  -- In octets
>>>          xSize           INTEGER,  -- In pixels
>>>          ySize           INTEGER,  -- In pixels
>>>          numColors       INTEGER } -- In bits
>>>
>>>It would also be appropriate to say what to do when the image is in color
>>>and that the client has no color display available. No display at all ?
>>>Conversion into grey scale using which kind of transposition ?
>>
>>The client is always allowed to ignore the logotype altogether.  The 
>>stronger language added in response to your third comment makes this clear.
>
>Do you mean that if the logo is defined in color and the terminal is only 
>B&N then the logo shall not be displayed ? If so, this should be clearly said.

To make such a statement, we need to implement the color vs. grey scale 
CHOICE that I described earlier.  I will do further investigation.


>>>12. Page 11. Section 5. Type of certificates
>>>
>>>    Logotypes MAY be present in three types of certificates:
>>>
>>>      - CA certificates
>>>      - End-entity certificates
>>>      - Attribute certificates
>>>
>>>Why is there such a limitation ? CRL Issuers, OCSP responders or TSUs may
>>>have logotypes present in their certificates.
>>>
>>>Replace with : "Logotypes MAY be present in any type of certificate".
>>
>>David Cross spoke against this suggestion.
>
>No. David Croos spoke about the *display* of the logo, not the *presence* 
>of the logo. Please make the change or provide new arguments.

I propose a complete rewrite of section 5:

5. Type of certificates

    Logotypes MAY included in public key certificates and attribute
    certificates at the discretion of the certificate issuer; however;
    logotypes MUST NOT be part of certification path validation or any
    type of automated processing. The sole purpose of logotypes is to
    enhance display of a particular certificate, regardless of its
    position in a certification path.

Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PFRnt05350 for ietf-pkix-bks; Fri, 25 Oct 2002 08:27:49 -0700 (PDT)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PFRkW05346 for <[e-mail]>; Fri, 25 Oct 2002 08:27:47 -0700 (PDT)
Received: from Santesson ([213.64.1.46]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 25 Oct 2002 17:27:39 +0200
From: "Stefan Santesson" <[e-mail]>
To: "Dean Povey" <[e-mail]>, "Trevor Freeman" <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, <[e-mail]>
Subject: RE: draft-ietf-pkix-logotypes-06.txt 
Date: Fri, 25 Oct 2002 17:27:38 +0200
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: 25 Oct 2002 15:27:40.0218 (UTC) FILETIME=[0E2781A0:01C27C3B]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dean,

I'm not opposed to let people say what they think, but I don't think this is
a straw poll issue. At least not in a sense where you can count votes pro an
against to find a winner.

That is more appropriate for selecting 1 out of n solutions to a given
problem.

This case is different. This is about figuring out if there is enough
interest or not to support audio aspects of logotypes. If there is enough
interest, then we are home. No matter how many who won't use it.

I know that we all are here as individuals, but given the persons expressing
support for this, and given who they work for, I would say we have enough
support to go ahead without any straw poll (I bet Steve Kent will correct me
on this one :-), but for me this is still a valid aspect of reality).

/Stefan


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Dean Povey
> Sent: Friday, October 25, 2002 12:51 AM
> To: Trevor Freeman
> Cc: Stefan Santesson; Housley, Russ; [e-mail]
> Subject: Re: draft-ietf-pkix-logotypes-06.txt
>
>
>
> On Wed, 23 Oct 2002 19:33:04 MST, "Trevor Freeman" wrote:
> >Dean,
> >The approach you suggest would put the onus on the application having
> >text to audio technology to support this case as apposed to simply
> >playing an audio file. And that text to audio technology must work for
> >all languages and cope with translation. That is a pretty high bar.
>
> How else do you think visually impaired people read web pages?  I don't
> know a huge amount about this, but there is a variety of software (e.g.
> JAWS see http://www.freedomscientific.com/fs_products/software_jaws.asp)
> that does text to speech translation, and when you develop web sites for
> accessibility you consider how such software will "read" your
> site.
>
> However, the comment about languages is interesting, will
> internationalization issues be addressed in audio types?
>
> I apologise for not raising this issue earlier than last call, but it
> seems there is sufficient controversy about this feature to warrant a
> decision.  I think most of the major arguments have been covered, and I
> have seen at least one other call for a straw poll on the
> feature.  I have
> no wish to hold up this draft endlessly.
>
> I think the issue of accessibility is an important one, but perhaps this
> needs to be addressed in a separate draft that considers other parts of
> PKIX as well.
>
> If we are to hold a straw poll, might I suggest rather than a simple
> plebiscite on whether audio is in or out that the options proposed be:
>
> 1. To exclude the audio type from the draft, and either provide text
>    addressing accessibility concerns (for example using the
> suggestion that
>    software read out the issuer and/or subject names), or make a work item
>    to write a separate draft which deals with accessibility issues related
>    to PKIX in general.
>
> 2. To leave the audio type in, and add text to security considerations to
>    deal with the problem of distinguishing audio for trust purposes from
>    any other audio that an application might present, as well as address
>    the internationalisation issue.
>
> Thoughts?
> --
> Dean Povey,             |em: [e-mail]|JCSI: Java
> security toolkit
> Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C
> PKI toolkit
> Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C
> SSL toolkit
> Brisbane, Australia     |www: www.wedgetail.com |XML Security:
> XML Signatures
>
>
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PEApE29530 for ietf-pkix-bks; Fri, 25 Oct 2002 07:10:51 -0700 (PDT)
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 g9PEAnW29525; Fri, 25 Oct 2002 07:10:49 -0700 (PDT)
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 QAA12248; Fri, 25 Oct 2002 16:11:12 +0200
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 QAA23988; Fri, 25 Oct 2002 16:11:05 +0200
Message-ID: <[e-mail]>
Date: Fri, 25 Oct 2002 16:10:48 +0200
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
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], S-MIME / IETF <[e-mail]>
Subject: Re: delegation attribute within a signed message
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>

Malek,

I have presented some slides on that topic at the IETF meeting in Salt Lake
City in December 2001. The presentation is called "Signature delegation".

The main idea is to use an Attribute Certificate. Since Attribute 
Certificates may incorporated in a CMS structure (see RFC 3126),
then no addition to the signature format is necessary.

In such a case, there would be two documents to produce:

1) a profile for an Attribute Certificate usable for delegation,
    (a PKIW work item),

2) a document saying how such an Attribute Cetificate is verified when
    present in the CMS structure defined in RFC 3126, (an S-MIME work item).

Hence why I am posting this document to the S-MIME working group too.

Denis

 > I am trying to investigate the possibility to implement a delegated 
electronic signature. I mean implement the fact that a signer has the 
necessary attributes to sign on behalf of some-one else.
 >
 > My understanding is that we should address this question from 2 angles:
 > 	1. The signer should express in his signed message the fact that he is 
signing on behalf of some-one else (fopr the sake of
 >                 simplicity, let's say the superior).
 > 	2. The signer should have the necessary privleges to sign on behalf of 
the superior
 >
 > If we take into consideration CMS signatures, a possible implementation 
of the above two points can be summarized as follows:
 >
 > - Defining an additional attribute: "Detegated Signature". The fields of 
this attributes may be a reference to the document where the
 >   privilege of signing on behalf someone else are expressed. It may 
simply be teh hash of the superior signing certificate.
 > - Adding this additional attribute as a signed attribute in the SigneInfo 
of the signed data within the CMS signature.
 > - Having a reference to the signature policy added a signed attribute. 
Within the sigature policy, we should exress the fact that when a "delegated 
signature" signature is added as a signed attribute, this mens that the 
signatory is signing on behalf a "superior".
 > - The document highlighting the privileges can be expressed within an 
X509 Attribute certificate. This means that the SUPERIOR will have its own 
ATTRIBUTE AUTHORITY. And the privilege withine the X509 attribute 
certificate can be expressed as follows:
 > 	Privilege type: OID describing the privilege of signature delegation
 > 	Superior reference: Signing certificate of teh superior.
 >
 > This solution doesn't seem to be simple to express but provided that the 
necessary ASN.1 structures exist, it is intuitive to implement.
 >
 > I have in mind several solutions but can you please tell me if signature 
delegation has already been specified within some standard or RCF (up to my 
knowledge, no such functionality has already been expressed in ETSI or PKIX 
standards). And if it doen't exist, what do you think about the solution i 
summarized above.
 >
 > regards,
 >
 > ___________________________________________________________
 > Malek Bechlaghem
 > e-Security Product Development Manager
 > Strategy, Business Development and Product Management (SBP)
 > Internet Business Unit (IBU)
 > Belgacom SA/NV
 > Bd du Roi Albert II, 27, B-1030 Brussels
 >
 > Tel.: [phone]
 > Fax: [phone]
 > E-mail: [e-mail]
 >
 > We bring security to the e-world : www.e-trust.be
 >
 >
 >
 >
 > **** 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 g9PDlVw28855 for ietf-pkix-bks; Fri, 25 Oct 2002 06:47:31 -0700 (PDT)
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 g9PDlTW28851 for <[e-mail]>; Fri, 25 Oct 2002 06:47:29 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 25 Oct 2002 13:47:30 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 JAA03532 for <[e-mail]>; Fri, 25 Oct 2002 09:47:29 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g9PDipp09749 for <[e-mail]>; Fri, 25 Oct 2002 09:44:51 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWFBPB>; Fri, 25 Oct 2002 09:47:27 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.1]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWFB37; Fri, 25 Oct 2002 09:47:21 -0400
From: "Housley, Russ" <[e-mail]>
To: Christine Karman <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 25 Oct 2002 09:45:48 -0400
Subject: Re: Fwd: PKI Forum
In-Reply-To: <[e-mail]>
References: <[e-mail] .com>
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>

Christine:

I think that they are struggling.  They are not supposed to develop 
technical standards; there are plenty of other organizations for 
that.  They are supposed to help with PKI adoption.  So far, I have not 
seen anything useful.

The work that they did in CMP interoperability was useful, but it was too 
little too late.

Russ



>At 07:19 PM 10/22/2002, Housley, Russ wrote:
>
>>I thought that the members of the PKIX WG would find this interesting....
>>
>>Russ
>>
>> > OASIS is pleased to announce that on 1 November, PKI Forum will
>> > become the newest OASIS Member Section.
>
>What's your opinion about PKI forum? I've visited their Amsterdam meeting 
>earlier this year, but I was not impressed.
>
>dagdag
>Christine


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PDVaM27640 for ietf-pkix-bks; Fri, 25 Oct 2002 06:31:36 -0700 (PDT)
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 g9PDVYW27631 for <[e-mail]>; Fri, 25 Oct 2002 06:31:34 -0700 (PDT)
Received: from exhub01.bc (exchange.bc [45.34.4.231]) by mail1.belgacom.be  with SMTP id NAA00349 for <[e-mail]>; Fri, 25 Oct 2002 13:31:33 GMT
From: [e-mail]
Received: from 127.0.0.1 by exhub01.bc (InterScan E-Mail VirusWall NT); Fri, 25 Oct 2002 15:31:16 +0200
Received: by exhub01.bc with Internet Mail Service (5.5.2653.19) id <VKALRCCV>; Fri, 25 Oct 2002 15:31:16 +0200
Message-ID: <[e-mail]>
To: [e-mail]
Subject: delegation attribute within a signed message
Date: Fri, 25 Oct 2002 15:31:05 +0200
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>

I am trying to investigate the possibility to implement a delegated electronic signature. I mean implement the fact that a signer has the necessary attributes to sign on behalf of some-one else. 

My understanding is that we should address this question from 2 angles:
	1. The signer should express in his signed message the fact that he is signing on behalf of some-one else (fopr the sake of 
                simplicity, let's say the superior).
	2. The signer should have the necessary privleges to sign on behalf of the superior

If we take into consideration CMS signatures, a possible implementation of the above two points can be summarized as follows:

- Defining an additional attribute: "Detegated Signature". The fields of this attributes may be a reference to the document where the  
  privilege of signing on behalf someone else are expressed. It may simply be teh hash of the superior signing certificate.
- Adding this additional attribute as a signed attribute in the SigneInfo of the signed data within the CMS signature.
- Having a reference to the signature policy added a signed attribute. Within the sigature policy, we should exress the fact that when a "delegated signature" signature is added as a signed attribute, this mens that the signatory is signing on behalf a "superior".
- The document highlighting the privileges can be expressed within an X509 Attribute certificate. This means that the SUPERIOR will have its own ATTRIBUTE AUTHORITY. And the privilege withine the X509 attribute certificate can be expressed as follows:
	Privilege type: OID describing the privilege of signature delegation
	Superior reference: Signing certificate of teh superior.

This solution doesn't seem to be simple to express but provided that the necessary ASN.1 structures exist, it is intuitive to implement.

I have in mind several solutions but can you please tell me if signature delegation has already been specified within some standard or RCF (up to my knowledge, no such functionality has already been expressed in ETSI or PKIX standards). And if it doen't exist, what do you think about the solution i summarized above.

regards,

___________________________________________________________
Malek Bechlaghem
e-Security Product Development Manager
Strategy, Business Development and Product Management (SBP)
Internet Business Unit (IBU)
Belgacom SA/NV
Bd du Roi Albert II, 27, B-1030 Brussels

Tel.: [phone]
Fax: [phone]
E-mail: [e-mail]

We bring security to the e-world : www.e-trust.be




**** 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 g9PDNGq26489 for ietf-pkix-bks; Fri, 25 Oct 2002 06:23:16 -0700 (PDT)
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 g9PDNEW26483 for <[e-mail]>; Fri, 25 Oct 2002 06:23:14 -0700 (PDT)
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 PAA22576 for <[e-mail]>; Fri, 25 Oct 2002 15:23:33 +0200
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 PAA19068 for <[e-mail]>; Fri, 25 Oct 2002 15:23:25 +0200
Message-ID: <[e-mail]>
Date: Fri, 25 Oct 2002 15:23:09 +0200
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
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Attribute Certificate Policies Extension
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>

A new version of the draft on Attribute Certificate Policies Extension has 
been posted. It is available at :

http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-01.txt

Whereas the previous draft was defining different extensions, the new draft 
only covers a single extension allowing to designate the policy under which 
an Atribute Certificate has been issued.

This extension is not applicable to Public Key Certificates.

Denis



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PBVnv18109 for ietf-pkix-bks; Fri, 25 Oct 2002 04:31:49 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PBVmW18102 for <[e-mail]>; Fri, 25 Oct 2002 04:31:48 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20369; Fri, 25 Oct 2002 07:29:29 -0400 (EDT)
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-acpolicies-extn-01.txt
Date: Fri, 25 Oct 2002 07:29:28 -0400
Sender: [e-mail]
Precedence: 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		: Attribute Certificate Policies Extension
	Author(s)	: C. Francis, D. Pinkas
	Filename	: draft-ietf-pkix-acpolicies-extn-01.txt
	Pages		: 8
	Date		: 2002-10-24
	
This document describes one certificate extension to explicitly 
state the Attribute Certificate (AC) policies that apply to a given 
Attribute Certificate.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-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-acpolicies-extn-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-acpolicies-extn-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-acpolicies-extn-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-acpolicies-extn-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 g9P8u4505525 for ietf-pkix-bks; Fri, 25 Oct 2002 01:56:04 -0700 (PDT)
Received: from email.certplus.com ([195.101.88.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9P8u2W05515 for <[e-mail]>; Fri, 25 Oct 2002 01:56:02 -0700 (PDT)
Received: from carbone.certplus.com (facteur.certplus.com [172.16.1.81]) by email.certplus.com (8.12.2+Sun/8.12.2) with ESMTP id g9P8u0ft002502; Fri, 25 Oct 2002 10:56:01 +0200 (CEST)
Received: from certplus.com ([192.168.212.166]) by carbone.certplus.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 25 Oct 2002 10:56:01 +0200
Message-ID: <[e-mail]>
Date: Fri, 25 Oct 2002 10:55:57 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021021
X-Accept-Language: ja, fr, en, en-us
MIME-Version: 1.0
To: SPKI Mailing List <[e-mail]>, [e-mail]
Subject: Re: 2003 PKI Research Workshop CFP
References: <3.0.5.32.20021019094654.01b6f430@localhost> <3.0.5.32.20021024231129.01d9f688@localhost>
In-Reply-To: <3.0.5.32.20021024231129.01d9f688@localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Oct 2002 08:56:01.0203 (UTC) FILETIME=[57A66030:01C27C04]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Carl Ellison a dit :

>At 08:20 PM 10/24/2002 +0100, David Chadwick wrote:
>  
>
>>Correction. The URL does not work with Netscape 4.7 browser, which
>>is the one I am using. It does work with IE though.
>>    
>>
>Thank you for doing the experiment.  That is extremely disturbing and
>I will pass the word back to Internet2.  It bugs me no end when stuff
>works with only one browser.
>  
>
The problem is a broken CSS link, not incompatibility in the code.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9P6DRR04824 for ietf-pkix-bks; Thu, 24 Oct 2002 23:13:27 -0700 (PDT)
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 g9P6DQW04820 for <[e-mail]>; Thu, 24 Oct 2002 23:13:26 -0700 (PDT)
Received: from p4 ([12.224.63.6]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20021025061326.YMMA4063.rwcrmhc53.attbi.com@p4>; Fri, 25 Oct 2002 06:13:26 +0000
Message-Id: <3.0.5.32.20021024231129.01d9f688@localhost>
X-Sender: cme@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 24 Oct 2002 23:11:29 -0700
To: David Chadwick <[e-mail]>
From: Carl Ellison <[e-mail]>
Subject: Re: 2003 PKI Research Workshop CFP
Cc: Carl Ellison <[e-mail]>, SPKI Mailing List <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <3.0.5.32.20021019094654.01b6f430@localhost>
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 08:20 PM 10/24/2002 +0100, David Chadwick wrote:
>Carl
>
>Correction. The URL does not work with Netscape 4.7 browser, which
>is the one I am using. It does work with IE though.

Thank you for doing the experiment.  That is extremely disturbing and
I will pass the word back to Internet2.  It bugs me no end when stuff
works with only one browser.

 - Carl

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBPbjgkXPxfjyW5ytxEQLE0wCdE7zJ4AtJimpzeuEDxKHkCVSbbjsAoJrL
jXboCTQ/n+9NiiYSUJZxiDNX
=A4hj
-----END PGP SIGNATURE-----


+------------------------------------------------------------------+
|Carl M. Ellison         [e-mail]     http://world.std.com/~cme |
|    PGP: 75C5 1814 C3E3 AAA7 3F31  47B9 73F1 7E3C 96E7 2B71       |
+---Officer, arrest that man. He's whistling a copyrighted song.---+


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9ONT6408014 for ietf-pkix-bks; Thu, 24 Oct 2002 16:29:06 -0700 (PDT)
Received: from stargazer-o.stars-smi.com (stargazer-o.stars-smi.com [151.200.173.2]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9ONT5W08010 for <[e-mail]>; Thu, 24 Oct 2002 16:29:05 -0700 (PDT)
Received: from excelsior.stars-smi.com by stargazer-o.stars-smi.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Oct 2002 23:26:24 UT
Received: by excelsior.stars-smi.com with Internet Mail Service (5.5.2655.55) id <RDBXTARH>; Thu, 24 Oct 2002 19:37:22 -0400
Message-ID: <DCE76463749C64499892A0DB3AF05AC602457564@CHALLENGER>
From: "Hamrick, Matt" <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: draft-ietf-pkix-logotypes-06.txt
Date: Thu, 24 Oct 2002 19:24:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
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 suspect that the issue is that commercial entities with a vested interest
in protecting and promoting brand awareness wish to require certain
presentations when certificates are presented. And who can blame them? If
they ran the world, all compatible products that displayed certificate
information would be REQUIRED to play the contents of certain audio
extensions.

However, they do not run the world, and it is unlikely (in my opinion) that
there will ever be a component that plays an audio clip when a certificate
is "viewed." Look at the quality of existing tools in popular software to
view certificates: Netscape, Outlook, IE, etc. It is only recently that we
have IE components that can figure out how to display even the most basic
extensions. I find it hard to believe that Microsoft, with all it's
resources, could be convinced to add such a feature (the playing of audio
clips referenced in certificate extensions.) MS and other vendors of
consumer software have been trying their best to push the interface that
describes certificate details as far away from the user as possible. Where
it is seen, it is generally considered an "advanced" feature for a few
power-users, and I just don't think there's any great benefit to spending
money to support a feature to "market" to such a small audience.

Remember, the logotype is not a replacement for identity information, and it
is to be displayed/played, "given that it [the RP's cert viewing software]
is configured to do so."

In that certain members of this list affiliated with certain very large
software marketing organizations have indicated they are interested in
standardizing the representation of a URI and mime type representing a sound
representative of their corporate identity, I can hardly see the harm in
allowing them to pursue their folly. (Well... maybe it's not folly, they did
actually spend time working on the draft...)

-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]]
Sent: Thursday, October 24, 2002 1:46 PM
To: Denis Pinkas; Stefan Santesson
Cc: pkix
Subject: RE: draft-ietf-pkix-logotypes-06.txt




Hi Denis,
Can you please elaborate on you comment of "... adding audio to the
interface design does not mean adding audio for everything" I don't
understand the point you are making. 

The decision on if or when to display the logotype / play the audio is
down to the interface designer. There are plenty of UI designs shipped
in products for X.509 certificates just displaying text names which are
unusable - but I don't hold that to be the problem RFC3280.

Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Thursday, October 24, 2002 2:37 AM
To: Stefan Santesson
Cc: pkix
Subject: Re: draft-ietf-pkix-logotypes-06.txt


Stefan,

> I mostly agree with you.
> 
> What I mean is that there is some line, beyond which you just need to
accept
> the whish to do something and say - OK if some implementers want to do
this
> type of thing, what is the best way to do it?
> 
> I think the most cases where a firm requirement is badly needed is
where
> someone what to do something in a different way, where current
standard
> gives another way of doing almost the same thing, and where doing the
> proposed changes/amendments would produce alternative solutions to
closely
> related problem (Like the PI versus serialNumber Attributes, OCSPv2
versus
> SCVP, CMP versus CMC .....)
> 
> I think Trevor has demonstrated a reasonable need to use audio with
> Logotypes.

The argument from Trevor is not convincing: adding audio to the
interface 
design does not mean adding audio for everything.

  ... but this demonstrates that it was *not* a joke (either god or
bad), 
from at least two of the co-editors of the document. :-(

Denis

> /Stefan
> 
> 
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]]On Behalf Of Dean Povey
>>Sent: Thursday, October 24, 2002 1:04 AM
>>To: Stefan Santesson
>>Cc: [e-mail]
>>Subject: Re: draft-ietf-pkix-logotypes-06.txt
>>
>>
>>
>>
>>>If audio is supported in the protocol in a well structured manner,
and
>>>nobody deploys it, then it's just dropped before it becomes standard.
>>>
>>>I do believe though that the deployment industry is likely to
>>
>>find some use
>>
>>>for it.
>>>
>>
>>Err, I think the rule is that we start with a firm requirement and
>>implement something.  I think there has been a failure to demonstrate
a
>>firm requirement. If someone can come up with a plausible
>>meaningful reason
>>to put audio in certificates then we can consider it.  Until then, we
>>should concentrate on solving actual problems, not dreaming up
>>hypothetical
>>ones.  Why isn't there support for MPEG movies in the draft for
>>example? (I hope this doesn't give anyone ideas :-).
>>
>>As someone who has to implement this stuff, let me just say that
>>there is a
>>cost to specifying something that won't (or shouldn't) be used.  You
still
>>end up having to implement and test it to give the perception that
your
>>products are complying with standards.  It is precisely this
>>overspecification in the ITU-T standards that has led to so much
garbage
>>which has to be supported already.  The certificate path processing
>>algorithm is a case in point.  Its complexity is created by a large
number
>>of rarely used extensions whose usefulness is dubious at best.
>>
>>So, come up with a plausible use case for audio that cannot be met by
>>existing mechanisms, and it can be considered, otherwise drop it, and
make
>>implementers lives a little easier.
>>
>>--
>>Dean Povey,             |em: [e-mail]|JCSI: Java
>>security toolkit
>>Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C
>>PKI toolkit
>>Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C
>>SSL toolkit
>>Brisbane, Australia     |www: www.wedgetail.com |XML Security:
>>XML Signatures
>>
>>
>>
> 
> 
> 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9OMqse05948 for ietf-pkix-bks; Thu, 24 Oct 2002 15:52:54 -0700 (PDT)
Received: from osprey.wedgetail.com (starling.wedgetail.com [202.83.95.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9OMqqW05940 for <[e-mail]>; Thu, 24 Oct 2002 15:52:52 -0700 (PDT)
Received: from coot.wedgetail.com (coot.wedgetail.com [10.10.10.4]) by osprey.wedgetail.com (8.12.5/8.12.5) with ESMTP id g9OMpBNU028147; Fri, 25 Oct 2002 08:51:11 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh exmh 2.5 (2001-07-13) with nmh-1.0.4
From: Dean Povey <[e-mail]>
To: "Trevor Freeman" <[e-mail]>
cc: "Stefan Santesson" <[e-mail]>, "Housley, Russ" <[e-mail]>, [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt 
In-reply-to: Your message of "Wed, 23 Oct 2002 19:33:04 MST." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 25 Oct 2002 08:51:11 +1000
X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: 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 Wed, 23 Oct 2002 19:33:04 MST, "Trevor Freeman" wrote: 
>Dean,
>The approach you suggest would put the onus on the application having
>text to audio technology to support this case as apposed to simply
>playing an audio file. And that text to audio technology must work for
>all languages and cope with translation. That is a pretty high bar.

How else do you think visually impaired people read web pages?  I don't 
know a huge amount about this, but there is a variety of software (e.g. 
JAWS see http://www.freedomscientific.com/fs_products/software_jaws.asp) 
that does text to speech translation, and when you develop web sites for 
accessibility you consider how such software will "read" your 
site.

However, the comment about languages is interesting, will
internationalization issues be addressed in audio types?

I apologise for not raising this issue earlier than last call, but it 
seems there is sufficient controversy about this feature to warrant a 
decision.  I think most of the major arguments have been covered, and I 
have seen at least one other call for a straw poll on the feature.  I have 
no wish to hold up this draft endlessly.

I think the issue of accessibility is an important one, but perhaps this 
needs to be addressed in a separate draft that considers other parts of 
PKIX as well.

If we are to hold a straw poll, might I suggest rather than a simple 
plebiscite on whether audio is in or out that the options proposed be:

1. To exclude the audio type from the draft, and either provide text
   addressing accessibility concerns (for example using the suggestion that
   software read out the issuer and/or subject names), or make a work item
   to write a separate draft which deals with accessibility issues related
   to PKIX in general.

2. To leave the audio type in, and add text to security considerations to
   deal with the problem of distinguishing audio for trust purposes from 
   any other audio that an application might present, as well as address 
   the internationalisation issue.

Thoughts?
-- 
Dean Povey,             |em: [e-mail]|JCSI: Java security toolkit
Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C PKI toolkit
Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C SSL toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML Signatures 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9OMbcC04191 for ietf-pkix-bks; Thu, 24 Oct 2002 15:37:38 -0700 (PDT)
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9OMbYW04182 for <[e-mail]>; Thu, 24 Oct 2002 15:37:34 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9OMbVET131570; Thu, 24 Oct 2002 18:37:32 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9OMbS0K092872; Thu, 24 Oct 2002 18:37:28 -0400
Importance: Normal
Sensitivity: 
Subject: RE: draft-ietf-pkix-logotypes-06.txt
To: "Hallam-Baker, Phillip" <[e-mail]>
Cc: "'Denis Pinkas'" <[e-mail]>, "Housley, Russ" <[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: Thu, 24 Oct 2002 18:37:26 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11  |July 29, 2002) at 10/24/2002 06:37:29 PM
MIME-Version: 1.0
Content-type: multipart/mixed;  Boundary="0__=0ABBE6CFDFEAD5B48f9e8a93df938690918c0ABBE6CFDFEAD5B4"
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0__=0ABBE6CFDFEAD5B48f9e8a93df938690918c0ABBE6CFDFEAD5B4
Content-type: text/plain; charset=us-ascii


      Phill:

      I have one problem with the current draft, other than the fact that
audio logotypes are weaker than visual.  The current "Use" and "Security
Considerations" sections do not even suggest to RP implementors that the
display or announcement of a logotype should enable the RP to distinguish
between Issuer Organization logotypes, Subject Organization logotypes, and
Community Logotypes, nor between the latter two types occurring in an EE
certificate and those occurring in an issuer certificate.  If this is not
done, IMHO any logotypes which can be used in more than one of these roles
will be counterproductive.  An RP who sees a commercial CA's logo will not
be helped by it if he can't tell if the use means that the subject is an
employee of that CA or if it means that the certificate was issued by the
CA.  The same applies to Community vs. Subject Organization.
      I am not trying to remove audio logotypes from the proposal, since
they may be of some use if their type is announced, but are you sure that
they would be used if not for American accessibility legislation (the
Americans with Disabilities Act and Section 508 of the Rehabilitation Act)?
This applies especially to audio background logotypes, which strike me as a
security weakness rather than a strength.

            Tom Gindin


"Hallam-Baker, Phillip" <[e-mail]>@mail.imc.org on 10/24/2002
01:22:38 PM

Sent by:    [e-mail]


To:    "'Denis Pinkas'" <[e-mail]>, "Housley, Russ"
       <[e-mail]>
cc:    [e-mail]
Subject:    RE: draft-ietf-pkix-logotypes-06.txt



I find it somewhat bizare that we have this level of opposition to a
feature that there is significant commercial demand for while the group
continues to spend time on whole document sets that there is no
commercial demand for.

If it is ok for a working group to do stuff like SCVP even though the
industry has declined to give support then surely it is OK for the group
to do audio logotypes.


            Phill


> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, October 24, 2002 6:47 AM
> To: Housley, Russ
> Cc: [e-mail]
> Subject: Re: draft-ietf-pkix-logotypes-06.txt
>
>
>
> Russ,
>
> > Denis:
> >
> >> Since we are still in Working Group Last Call, here are my
> 12 comments on
> >> that document.
> >>
> >> 1. Page 6. Section 3. Logotype data
> >>
> >> "Implementations MUST support image data; however, support
> for audio
> >> data is
> >> OPTIONAL." Audio is a good joke, in the same way, as
> pheromones. We are
> >> supposed to deal with serious documents. Please delete.
> >
> >
> > I belive that the response from Tom Gindin shows that there
> is support
> > for audio in support if disabled users.  I believe that the
> document is
> > clear that the support is OPTIONAL.
>
> The document was not clear that the support is OPTIONAL.
> There is still much
> controversy about the need for it. No convincing arguments have been
> provided. Please delete or make a strawpol.
>
> >> 2. Page 7. Section 4.1 Extension format
> >>
> >> "Clients MUST support both direct and indirect addressing."
> >>
> >> I disagree. If an end-user certificate is included in a
> signature, it
> >> may be
> >> interesting to display the logotype even if the terminal
> is off-line.
> >> Indirect addressing would mandate an on-line connection.
> >>
> >> Replace with:
> >>
> >> "Clients claiming to conform with this document SHALL
> support direct
> >> addressing. Clients MAY also support indirect addressing."
> >
> >
> > We have already had a dialogue on this point.  I hope it is
> resolved.
>
> Indeed.
>
> >> 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".
> >
> >
> > I will add a similar sentence to the second paragraph of
> section 6.  The
> > paragraph now says:
> >
> >    After a certification path is successfully validated,
> the replying
> >    party trusts the information that the CA includes in the
> certificate,
> >    including any certificate extensions. The client
> software can choose
> >    to make use of such information, or the client software
> can ignore
> >    it. 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.
> Current standards
> >    do not provide any mechanism for cross-certifying CAs to
> constrain
> >    subordinate CAs from including private extensions (see
> the security
> >    considerations section).
>
> This is fine.
>
> >> 4. Page 8. Section 4.1.
> >>
> >>       LogotypeData ::= SEQUENCE {
> >>          image           SEQUENCE OF LogotypeImage     OPTIONAL,
> >>          audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }
> >>
> >> Since audio support should be suppressed, replace with:
> >>
> >>       LogotypeData ::= SEQUENCE OF LogotypeImage
> >
> >
> > This is related to comment 1.  No change will be made.
>
> See above.
>
> >> 5. Page 7. Section 4.1.
> >>
> >> We have:
> >>
> >>       communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
> >>
> >>       LogotypeInfo ::= CHOICE {
> >>          direct          [0] LogotypeData,
> >>          indirect        [1] LogotypeReference }
> >>
> >>       LogotypeData ::= SEQUENCE {
> >>          image           SEQUENCE OF LogotypeImage OPTIONAL,
> >>
> >> No explanations are given on the text about what to do for
> a client when
> >> there is more than one LogotypeImage present in a communityLogo.
> >>
> >> First of all, a communityLogo may contain more than one logo which
> >> belongs
> >> to one or more communities. However the client has no way
> to know whether
> >> the LogotypeData includes different versions from the same
> logo (e.g. in
> >> black and white or in color) or different logos.
> >
> >
> > This is not supported.  The certificate may only include
> one image.
> > That image could be a composite of many different logos, if
> > appropriate.  We discussed this face-to-face in Yokohama.
> Discussion
> > with people what develop graphical interfaces do not think
> it is a good
> > idea to allow this complexity.  Too many images will
> confuse the user.
>
>
> > When it is appropriate to include several community logos,
> they must be
> > combined into one image to ensure that they are
> consistently displayed.
> > If this is not done, each client will render the images
> differently...
>
> We still have different views on that topic, which is far
> more important
> than audio. To give a parallel: some banks are members of
> both VISA and
> EuroCard. Transposed into certificates, this may mean two
> logos. In the same
> way, a CA may be certifed by two laboratories. The logo of these two
> laboratories may be displayed.
>
> So for community certificates, I am requesting the
> possibility to have more
> than one logo. The use of combined logos is not appropraite
> to solve this issue.
>
> >> 6. Page 9. Section 4.1.
> >>
> >>       LogotypeImageInfo ::= SEQUENCE {
> >>          fileSize        INTEGER,  -- In octets
> >>          xSize           INTEGER,  -- In pixels
> >>          ySize           INTEGER,  -- In pixels
> >>          numColors       INTEGER } -- In bits
> >>
> >> Text is missing to explain this structure. How is a grey scale
> >> indicated for
> >> jpeg and for gif ???
> >
> >
> > Do you have a recommendation?
>
> No. But I wonder whether the structure is correct. Has it
> been verifed by an
> image expert ? Many PDAs have B&N screens only because they
> are cheaper.
>
> >> 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."
> >
> >
> > We have tried to avoid such a statement.  Instead we allow
> the inclusion
> > of the same image at many different resolutions so that the
> client can
> > select the best fit.  This is also the reason that we use
> MIME types to
> > name the format.  It allows the greatest flexibility.
>
>   ... but is does not provide any conformance clause.
>
> Can we say that a client is logo-enabled if it only supports 10 x 10
> pixels ? Unless the minimumm size (whatever it is) is always
> present in
> the logo, then it is not possible to say that the client is
> logo-enabled.
>
> >> 8. Page 9. Section 4.1.
> >>
> >>       LogotypeImageInfo ::= SEQUENCE {
> >>          fileSize        INTEGER,  -- In octets
> >>          xSize           INTEGER,  -- In pixels
> >>          ySize           INTEGER,  -- In pixels
> >>          numColors       INTEGER } -- In bits
> >>
> >> It would also be appropriate to say what to do when the
> image is in color
> >> and that the client has no color display available. No
> display at all ?
> >> Conversion into grey scale using which kind of transposition ?
> >
> >
> > The client is always allowed to ignore the logotype
> altogether.  The
> > stronger language added in response to your third comment
> makes this clear.
>
> Do you mean that if the logo is defined in color and the
> terminal is only
> B&N then the logo shall not be displayed ? If so, this should
> be clearly said.
>
>
> >> 9. Page 9. Section 4.1. Since audio is a joke, text and
> ASN.1 about audio
> >> should be deleted.
> >
> >
> > Again, related to your first comment. No change.
>
> See above.
>
> >> 10. Page 9. Section 4.1. The text states:
> >>
> >> "Implementations MUST support both the JPEG and GIF image formats
> >> (with MIME
> >> types of "image/jpeg" and "image/gif", respectively)"
> >>
> >> I would guess that Animated GIF should not be supported.
> Could we say
> >> it ?
> >
> >
> > Okay.  That paragraph now reads:
> >
> >    A MIME type is used to specify the format of the file
> containing the
> >    logotype data. Implementations MUST support both the JPEG and GIF
> >    image formats (with MIME types of "image/jpeg" and "image/gif",
> >    respectively). Animated images SHOULD NOT be used.
> Implementations
> >    that support audio MUST support the MP3 audio format (with a MIME
> >    type of "audio/mpeg").
>
> The additional sentence for animated images is fine. No
> comment on the
> additional sentence for audio. See above.
>
> >> 11. Page 10. Section 4.1.
> >>
> >>       Community Logotype. If communityLogo is present, the
> logotype MUST
> >>       represent the community to which the certificate issuer is
> >>       affiliated. The communityLogo MAY be present in an end entity
> >>       certificate, a CA certificate or an attribute certificate.
> >>
> >> A certificate issuer may belong to more than one
> community. Replace: "the
> >> community " by :"the community or the communities".
> >
> >
> > This is already discussed in response to comment 5.  No change.
>
> I maintain the request for it. See above.
>
> >> 12. Page 11. Section 5. Type of certificates
> >>
> >>    Logotypes MAY be present in three types of certificates:
> >>
> >>      - CA certificates
> >>      - End-entity certificates
> >>      - Attribute certificates
> >>
> >> Why is there such a limitation ? CRL Issuers, OCSP
> responders or TSUs may
> >> have logotypes present in their certificates.
> >>
> >> Replace with : "Logotypes MAY be present in any type of
> certificate".
> >
> >
> > David Cross spoke against this suggestion.
>
> No. David Croos spoke about the *display* of the logo, not
> the *presence* of
> the logo. Please make the change or provide new arguments.
>
>
> Denis
>
> > Russ
>
>
>





--0__=0ABBE6CFDFEAD5B48f9e8a93df938690918c0ABBE6CFDFEAD5B4
Content-type: application/octet-stream; 
	name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-transfer-encoding: base64

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
BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyNDE3
MjIzOFowIwYJKoZIhvcNAQkEMRYEFNZWWZme91MLtE7e0NvgfC2iVNMtMFgGCSqGSIb3DQEJDzFL
MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG
BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug
aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj
KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO
rwvJMA0GCSqGSIb3DQEBAQUABIGAfqyUvz5eqH36Et8mIvuV0yHuB+9MjsvTf/qelB+fTy5I9WKW
Qk2deTTk39bPnz2K8cn8C3Cjwl+embJKRayZa32Nqix/9sx6o43wAWyujnlihjF4+N+emEwSv2pj
ToPZ2+3LOzqrU/IbBEX4c2o/fjmCtBkCBWzd7tP7nRmYtfMAAAAAAAAA

--0__=0ABBE6CFDFEAD5B48f9e8a93df938690918c0ABBE6CFDFEAD5B4--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9OJGEh22453 for ietf-pkix-bks; Thu, 24 Oct 2002 12:16:14 -0700 (PDT)
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 g9OJGDW22449 for <[e-mail]>; Thu, 24 Oct 2002 12:16:13 -0700 (PDT)
Received: (qmail 99414 invoked by alias); 24 Oct 2002 19:16:14 -0000
Received: (qmail 99396 invoked from network); 24 Oct 2002 19:16:14 -0000
Received: from unknown (HELO salford.ac.uk) (146.87.80.124) by pan.salford.ac.uk with SMTP; 24 Oct 2002 19:16:14 -0000
Message-ID: <[e-mail]>
Date: Thu, 24 Oct 2002 20:20:20 +0100
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: Carl Ellison <[e-mail]>
CC: SPKI Mailing List <[e-mail]>, [e-mail]
Subject: Re: 2003 PKI Research Workshop CFP
References: <3.0.5.32.20021019094654.01b6f430@localhost>
Content-Type: multipart/mixed; boundary="------------21CA51741C81841038788DEE"
Sender: [e-mail]
Precedence: 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.
--------------21CA51741C81841038788DEE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Carl

Correction. The URL does not work with Netscape 4.7 browser, which is
the one I am using. It does work with IE though.

David

Carl Ellison wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> The Internet2 PKI Research activity is based on the premise that a
> great deal of research is needed in PK-authenticated authorization
> and control systems and that research is not going to come out of
> current efforts among PKI vendors and standards bodies, active though
> they may be.
> 
> The PKI Research Workshop is a place for serious researchers in this
> field to present and publish their work.
> 
> The 2003 workshop CFP is online at
> 
> http://middleware.internet2.edu/pki03/
> 
> Last year's workshop program, papers and presentations are available
> at
> 
> http://www.cs.dartmouth.edu/~pki02/
> 
> if you want to see the kind of papers we are looking for.
> 
>  - Carl
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 6.5.8
> 
> iQA/AwUBPbGLTnPxfjyW5ytxEQJhLACffJtKODaNciVZanFo8X8X0DMpawEAoKHQ
> oD+KEn0fGIdwD0X+yRFD73jN
> =d/uS
> -----END PGP SIGNATURE-----
> 
> +------------------------------------------------------------------+
> |Carl M. Ellison         [e-mail]     http://world.std.com/~cme |
> |    PGP: 75C5 1814 C3E3 AAA7 3F31  47B9 73F1 7E3C 96E7 2B71       |
> +---Officer, arrest that man. He's whistling a copyrighted song.---+

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

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

*****************************************************************
--------------21CA51741C81841038788DEE
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

--------------21CA51741C81841038788DEE--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9OJ9kA22101 for ietf-pkix-bks; Thu, 24 Oct 2002 12:09:46 -0700 (PDT)
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 g9OJ9jW22097 for <[e-mail]>; Thu, 24 Oct 2002 12:09:45 -0700 (PDT)
Received: (qmail 96789 invoked by alias); 24 Oct 2002 19:09:46 -0000
Received: (qmail 96771 invoked from network); 24 Oct 2002 19:09:46 -0000
Received: from unknown (HELO salford.ac.uk) (146.87.80.124) by pan.salford.ac.uk with SMTP; 24 Oct 2002 19:09:46 -0000
Message-ID: <[e-mail]>
Date: Thu, 24 Oct 2002 20:13:52 +0100
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: Carl Ellison <[e-mail]>
CC: SPKI Mailing List <[e-mail]>, [e-mail]
Subject: Re: 2003 PKI Research Workshop CFP
References: <3.0.5.32.20021019094654.01b6f430@localhost>
Content-Type: multipart/mixed; boundary="------------CA12D69A80AA30CC73F93862"
Sender: [e-mail]
Precedence: 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.
--------------CA12D69A80AA30CC73F93862
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Carl

the url to pki03 does not seem to work for me. Rather I found the
correct one was

http://middleware.internet2.edu/pki03/pki03announce.shtml

David

Carl Ellison wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> The Internet2 PKI Research activity is based on the premise that a
> great deal of research is needed in PK-authenticated authorization
> and control systems and that research is not going to come out of
> current efforts among PKI vendors and standards bodies, active though
> they may be.
> 
> The PKI Research Workshop is a place for serious researchers in this
> field to present and publish their work.
> 
> The 2003 workshop CFP is online at
> 
> http://middleware.internet2.edu/pki03/
> 
> Last year's workshop program, papers and presentations are available
> at
> 
> http://www.cs.dartmouth.edu/~pki02/
> 
> if you want to see the kind of papers we are looking for.
> 
>  - Carl
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 6.5.8
> 
> iQA/AwUBPbGLTnPxfjyW5ytxEQJhLACffJtKODaNciVZanFo8X8X0DMpawEAoKHQ
> oD+KEn0fGIdwD0X+yRFD73jN
> =d/uS
> -----END PGP SIGNATURE-----
> 
> +------------------------------------------------------------------+
> |Carl M. Ellison         [e-mail]     http://world.std.com/~cme |
> |    PGP: 75C5 1814 C3E3 AAA7 3F31  47B9 73F1 7E3C 96E7 2B71       |
> +---Officer, arrest that man. He's whistling a copyrighted song.---+

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

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

*****************************************************************
--------------CA12D69A80AA30CC73F93862
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

--------------CA12D69A80AA30CC73F93862--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9OIcF021006 for ietf-pkix-bks; Thu, 24 Oct 2002 11:38:15 -0700 (PDT)
Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9OIcCW21002 for <[e-mail]>; Thu, 24 Oct 2002 11:38:12 -0700 (PDT)
Received: from VON-WIN2K-BOX (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id NAA110992; Thu, 24 Oct 2002 13:38:05 -0500
From: Von Welch <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 24 Oct 2002 13:35:42 -0500
To: [e-mail]
Subject: Requesting last call on proxy certificate draft
CC: 
X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter (Windows [3])" XEmacs Lucid
Sender: [e-mail]
Precedence: 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 and I would like to bring the Proxy Cert draft to a conclusion
in PKIX, either by agreeing to drop it or by pushing it forward to
last call. The informal straw poll on the draft indicated enough
positive feedback (I counted 6 or 7 positive votes with 1 or 2
negitive votes) with this approach that we would like to go ahead and
request that it be put it up for a last call by the working group
chairs.

In preparation for this we have resubmitted the draft:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-03.txt
(This now has corrected section numbers, btw.)

I've also listed the issues raised in previous conversation on the
email list and given our responses to them below. As we've expressed
before, we are interested in any feedback on the details of the
document and are quite willing to let this group influence them. But
at this point we feel we have addressed all of the input we have
received, so in the absence of further input we feel the draft is
ready to push forward to last call.

Steve's summary of the draft is available at:
http://www.imc.org/ietf-pkix/mail-archive/msg04466.html

Von

--
Issues raised and our responses:

* Why not just issue subordinate CA certificates with name constraints
to all users who want to issue proxy certificates?

Two reasons: First, none of the CA operators we've talked with would
do such a thing. Second, name constraints seem to be largely
unimplemented, with some implementations completely ignoring them. So
this approach would take large changes in the both CA operations to
issue such certificates and the installed code base to correctly
support name constraints.

Further, given that most current implementations do not have name
constraints support, it would be more dangerous to go this route,
because implementations that do not have name constraints could be
easily spoofed.  With our proxy cert approach, a proxy cert will be
rejected by any existing implementation because of both the CA bit
check, and the critical extension check.  (If an existing
implementation does not support at least one of these checks, then
proxy certs do not add any additional vulnerability.)

* Can we support proxy certificates by addition to path validation
instead of change to path validation?

The issue was raised if proxy certificates could be supported with
only additions to path validation instead of changes:
http://www.imc.org/ietf-pkix/mail-archive/msg04568.html
http://www.imc.org/ietf-pkix/mail-archive/msg04477.html

To recap, proxy certifications don't work with current path
validation code since we would need the keyCertSign bit asserted in
end-entity certificates that are allowed to issue proxy
certificates. Unfortunately RFC 3280, section 4.2.1.10, prohibits the
keyCertSign bit from being set in non-CA certificates. This leaves us
with the options of either issuing subordinate CA certificates
(previous issue) or setting the keyCertSign bit independant of the CA
bit and being non-compliant with 3280.

In the authors opinion that while it is possible to implement proxy
certificates with additions to path validation, it is easier to do so
by making modifications to current path validation code as described
in the draft. This has been reinforced with our experience with doing
the implementation in GSI.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9OHjxd17529 for ietf-pkix-bks; Thu, 24 Oct 2002 10:45:59 -0700 (PDT)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9OHjuW17525 for <[e-mail]>; Thu, 24 Oct 2002 10:45:56 -0700 (PDT)
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 24 Oct 2002 10:45:53 -0700
Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 24 Oct 2002 10:45:54 -0700
Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 24 Oct 2002 10:45:52 -0700
Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 24 Oct 2002 10:45:52 -0700
Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Thu, 24 Oct 2002 10:45:55 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6771.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-logotypes-06.txt
Date: Thu, 24 Oct 2002 10:45:51 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-logotypes-06.txt
Thread-Index: AcJ7QYkZsp8KDEyOQ0aHwvLqiHG+AQAQMP6A
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 24 Oct 2002 17:45:55.0607 (UTC) FILETIME=[342DAA70:01C27B85]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9OHjvW17526
Sender: [e-mail]
Precedence: 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 Denis,
Can you please elaborate on you comment of "... adding audio to the
interface design does not mean adding audio for everything" I don't
understand the point you are making. 

The decision on if or when to display the logotype / play the audio is
down to the interface designer. There are plenty of UI designs shipped
in products for X.509 certificates just displaying text names which are
unusable - but I don't hold that to be the problem RFC3280.

Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Thursday, October 24, 2002 2:37 AM
To: Stefan Santesson
Cc: pkix
Subject: Re: draft-ietf-pkix-logotypes-06.txt


Stefan,

> I mostly agree with you.
> 
> What I mean is that there is some line, beyond which you just need to
accept
> the whish to do something and say - OK if some implementers want to do
this
> type of thing, what is the best way to do it?
> 
> I think the most cases where a firm requirement is badly needed is
where
> someone what to do something in a different way, where current
standard
> gives another way of doing almost the same thing, and where doing the
> proposed changes/amendments would produce alternative solutions to
closely
> related problem (Like the PI versus serialNumber Attributes, OCSPv2
versus
> SCVP, CMP versus CMC .....)
> 
> I think Trevor has demonstrated a reasonable need to use audio with
> Logotypes.

The argument from Trevor is not convincing: adding audio to the
interface 
design does not mean adding audio for everything.

  ... but this demonstrates that it was *not* a joke (either god or
bad), 
from at least two of the co-editors of the document. :-(

Denis

> /Stefan
> 
> 
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]]On Behalf Of Dean Povey
>>Sent: Thursday, October 24, 2002 1:04 AM
>>To: Stefan Santesson
>>Cc: [e-mail]
>>Subject: Re: draft-ietf-pkix-logotypes-06.txt
>>
>>
>>
>>
>>>If audio is supported in the protocol in a well structured manner,
and
>>>nobody deploys it, then it's just dropped before it becomes standard.
>>>
>>>I do believe though that the deployment industry is likely to
>>
>>find some use
>>
>>>for it.
>>>
>>
>>Err, I think the rule is that we start with a firm requirement and
>>implement something.  I think there has been a failure to demonstrate
a
>>firm requirement. If someone can come up with a plausible
>>meaningful reason
>>to put audio in certificates then we can consider it.  Until then, we
>>should concentrate on solving actual problems, not dreaming up
>>hypothetical
>>ones.  Why isn't there support for MPEG movies in the draft for
>>example? (I hope this doesn't give anyone ideas :-).
>>
>>As someone who has to implement this stuff, let me just say that
>>there is a
>>cost to specifying something that won't (or shouldn't) be used.  You
still
>>end up having to implement and test it to give the perception that
your
>>products are complying with standards.  It is precisely this
>>overspecification in the ITU-T standards that has led to so much
garbage
>>which has to be supported already.  The certificate path processing
>>algorithm is a case in point.  Its complexity is created by a large
number
>>of rarely used extensions whose usefulness is dubious at best.
>>
>>So, come up with a plausible use case for audio that cannot be met by
>>existing mechanisms, and it can be considered, otherwise drop it, and
make
>>implementers lives a little easier.
>>
>>--
>>Dean Povey,             |em: [e-mail]|JCSI: Java
>>security toolkit
>>Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C
>>PKI toolkit
>>Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C
>>SSL toolkit
>>Brisbane, Australia     |www: www.wedgetail.com |XML Security:
>>XML Signatures
>>
>>
>>
> 
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9OHKhk16568 for ietf-pkix-bks; Thu, 24 Oct 2002 10:20:43 -0700 (PDT)
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 g9OHKgW16563 for <[e-mail]>; Thu, 24 Oct 2002 10:20:42 -0700 (PDT)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id g9OHKWkw020186; Thu, 24 Oct 2002 10:20:32 -0700 (PDT)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <VPY5LJF9>; Thu, 24 Oct 2002 10:22:41 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-logotypes-06.txt
Date: Thu, 24 Oct 2002 10:22:38 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0020_01C27B60.6C54F860"; protocol="application/x-pkcs7-signature"
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_0020_01C27B60.6C54F860
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I find it somewhat bizare that we have this level of opposition to a
feature that there is significant commercial demand for while the group
continues to spend time on whole document sets that there is no
commercial demand for.

If it is ok for a working group to do stuff like SCVP even though the
industry has declined to give support then surely it is OK for the group
to do audio logotypes.


		Phill


> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, October 24, 2002 6:47 AM
> To: Housley, Russ
> Cc: [e-mail]
> Subject: Re: draft-ietf-pkix-logotypes-06.txt
> 
> 
> 
> Russ,
> 
> > Denis:
> > 
> >> Since we are still in Working Group Last Call, here are my 
> 12 comments on
> >> that document.
> >>
> >> 1. Page 6. Section 3. Logotype data
> >>
> >> "Implementations MUST support image data; however, support 
> for audio 
> >> data is
> >> OPTIONAL." Audio is a good joke, in the same way, as 
> pheromones. We are
> >> supposed to deal with serious documents. Please delete.
> > 
> > 
> > I belive that the response from Tom Gindin shows that there 
> is support 
> > for audio in support if disabled users.  I believe that the 
> document is 
> > clear that the support is OPTIONAL.
> 
> The document was not clear that the support is OPTIONAL. 
> There is still much 
> controversy about the need for it. No convincing arguments have been 
> provided. Please delete or make a strawpol.
> 
> >> 2. Page 7. Section 4.1 Extension format
> >>
> >> "Clients MUST support both direct and indirect addressing."
> >>
> >> I disagree. If an end-user certificate is included in a 
> signature, it 
> >> may be
> >> interesting to display the logotype even if the terminal 
> is off-line.
> >> Indirect addressing would mandate an on-line connection.
> >>
> >> Replace with:
> >>
> >> "Clients claiming to conform with this document SHALL 
> support direct
> >> addressing. Clients MAY also support indirect addressing."
> > 
> > 
> > We have already had a dialogue on this point.  I hope it is 
> resolved.
> 
> Indeed.
> 
> >> 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".
> > 
> > 
> > I will add a similar sentence to the second paragraph of 
> section 6.  The 
> > paragraph now says:
> > 
> >    After a certification path is successfully validated, 
> the replying
> >    party trusts the information that the CA includes in the 
> certificate,
> >    including any certificate extensions. The client 
> software can choose
> >    to make use of such information, or the client software 
> can ignore
> >    it. 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. 
> Current standards
> >    do not provide any mechanism for cross-certifying CAs to 
> constrain
> >    subordinate CAs from including private extensions (see 
> the security
> >    considerations section).
> 
> This is fine.
> 
> >> 4. Page 8. Section 4.1.
> >>
> >>       LogotypeData ::= SEQUENCE {
> >>          image           SEQUENCE OF LogotypeImage     OPTIONAL,
> >>          audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }
> >>
> >> Since audio support should be suppressed, replace with:
> >>
> >>       LogotypeData ::= SEQUENCE OF LogotypeImage
> > 
> > 
> > This is related to comment 1.  No change will be made.
> 
> See above.
> 
> >> 5. Page 7. Section 4.1.
> >>
> >> We have:
> >>
> >>       communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
> >>
> >>       LogotypeInfo ::= CHOICE {
> >>          direct          [0] LogotypeData,
> >>          indirect        [1] LogotypeReference }
> >>
> >>       LogotypeData ::= SEQUENCE {
> >>          image           SEQUENCE OF LogotypeImage OPTIONAL,
> >>
> >> No explanations are given on the text about what to do for 
> a client when
> >> there is more than one LogotypeImage present in a communityLogo.
> >>
> >> First of all, a communityLogo may contain more than one logo which 
> >> belongs
> >> to one or more communities. However the client has no way 
> to know whether
> >> the LogotypeData includes different versions from the same 
> logo (e.g. in
> >> black and white or in color) or different logos.
> > 
> > 
> > This is not supported.  The certificate may only include 
> one image.  
> > That image could be a composite of many different logos, if 
> > appropriate.  We discussed this face-to-face in Yokohama.  
> Discussion 
> > with people what develop graphical interfaces do not think 
> it is a good 
> > idea to allow this complexity.  Too many images will 
> confuse the user.  
> 
> 
> > When it is appropriate to include several community logos, 
> they must be 
> > combined into one image to ensure that they are 
> consistently displayed.  
> > If this is not done, each client will render the images 
> differently...
> 
> We still have different views on that topic, which is far 
> more important 
> than audio. To give a parallel: some banks are members of 
> both VISA and 
> EuroCard. Transposed into certificates, this may mean two 
> logos. In the same 
> way, a CA may be certifed by two laboratories. The logo of these two 
> laboratories may be displayed.
> 
> So for community certificates, I am requesting the 
> possibility to have more 
> than one logo. The use of combined logos is not appropraite 
> to solve this issue.
> 
> >> 6. Page 9. Section 4.1.
> >>
> >>       LogotypeImageInfo ::= SEQUENCE {
> >>          fileSize        INTEGER,  -- In octets
> >>          xSize           INTEGER,  -- In pixels
> >>          ySize           INTEGER,  -- In pixels
> >>          numColors       INTEGER } -- In bits
> >>
> >> Text is missing to explain this structure. How is a grey scale 
> >> indicated for
> >> jpeg and for gif ???
> > 
> > 
> > Do you have a recommendation?
> 
> No. But I wonder whether the structure is correct. Has it 
> been verifed by an 
> image expert ? Many PDAs have B&N screens only because they 
> are cheaper.
> 
> >> 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."
> > 
> > 
> > We have tried to avoid such a statement.  Instead we allow 
> the inclusion 
> > of the same image at many different resolutions so that the 
> client can 
> > select the best fit.  This is also the reason that we use 
> MIME types to 
> > name the format.  It allows the greatest flexibility.
> 
>   ... but is does not provide any conformance clause.
> 
> Can we say that a client is logo-enabled if it only supports 10 x 10
> pixels ? Unless the minimumm size (whatever it is) is always 
> present in
> the logo, then it is not possible to say that the client is 
> logo-enabled.
> 
> >> 8. Page 9. Section 4.1.
> >>
> >>       LogotypeImageInfo ::= SEQUENCE {
> >>          fileSize        INTEGER,  -- In octets
> >>          xSize           INTEGER,  -- In pixels
> >>          ySize           INTEGER,  -- In pixels
> >>          numColors       INTEGER } -- In bits
> >>
> >> It would also be appropriate to say what to do when the 
> image is in color
> >> and that the client has no color display available. No 
> display at all ?
> >> Conversion into grey scale using which kind of transposition ?
> > 
> > 
> > The client is always allowed to ignore the logotype 
> altogether.  The 
> > stronger language added in response to your third comment 
> makes this clear.
> 
> Do you mean that if the logo is defined in color and the 
> terminal is only 
> B&N then the logo shall not be displayed ? If so, this should 
> be clearly said.
> 
> 
> >> 9. Page 9. Section 4.1. Since audio is a joke, text and 
> ASN.1 about audio
> >> should be deleted.
> > 
> > 
> > Again, related to your first comment. No change.
> 
> See above.
> 
> >> 10. Page 9. Section 4.1. The text states:
> >>
> >> "Implementations MUST support both the JPEG and GIF image formats 
> >> (with MIME
> >> types of "image/jpeg" and "image/gif", respectively)"
> >>
> >> I would guess that Animated GIF should not be supported. 
> Could we say 
> >> it ?
> > 
> > 
> > Okay.  That paragraph now reads:
> > 
> >    A MIME type is used to specify the format of the file 
> containing the
> >    logotype data. Implementations MUST support both the JPEG and GIF
> >    image formats (with MIME types of "image/jpeg" and "image/gif",
> >    respectively). Animated images SHOULD NOT be used. 
> Implementations
> >    that support audio MUST support the MP3 audio format (with a MIME
> >    type of "audio/mpeg").
> 
> The additional sentence for animated images is fine. No 
> comment on the 
> additional sentence for audio. See above.
> 
> >> 11. Page 10. Section 4.1.
> >>
> >>       Community Logotype. If communityLogo is present, the 
> logotype MUST
> >>       represent the community to which the certificate issuer is
> >>       affiliated. The communityLogo MAY be present in an end entity
> >>       certificate, a CA certificate or an attribute certificate.
> >>
> >> A certificate issuer may belong to more than one 
> community. Replace: "the
> >> community " by :"the community or the communities".
> > 
> > 
> > This is already discussed in response to comment 5.  No change.
> 
> I maintain the request for it. See above.
> 
> >> 12. Page 11. Section 5. Type of certificates
> >>
> >>    Logotypes MAY be present in three types of certificates:
> >>
> >>      - CA certificates
> >>      - End-entity certificates
> >>      - Attribute certificates
> >>
> >> Why is there such a limitation ? CRL Issuers, OCSP 
> responders or TSUs may
> >> have logotypes present in their certificates.
> >>
> >> Replace with : "Logotypes MAY be present in any type of 
> certificate".
> > 
> > 
> > David Cross spoke against this suggestion.
> 
> No. David Croos spoke about the *display* of the logo, not 
> the *presence* of 
> the logo. Please make the change or provide new arguments.
> 
> 
> Denis
> 
> > Russ
> 
> 
> 

------=_NextPart_000_0020_01C27B60.6C54F860
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
BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyNDE3
MjIzOFowIwYJKoZIhvcNAQkEMRYEFNZWWZme91MLtE7e0NvgfC2iVNMtMFgGCSqGSIb3DQEJDzFL
MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG
BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug
aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj
KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO
rwvJMA0GCSqGSIb3DQEBAQUABIGAfqyUvz5eqH36Et8mIvuV0yHuB+9MjsvTf/qelB+fTy5I9WKW
Qk2deTTk39bPnz2K8cn8C3Cjwl+embJKRayZa32Nqix/9sx6o43wAWyujnlihjF4+N+emEwSv2pj
ToPZ2+3LOzqrU/IbBEX4c2o/fjmCtBkCBWzd7tP7nRmYtfMAAAAAAAA=

------=_NextPart_000_0020_01C27B60.6C54F860--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9OFdwx08987 for ietf-pkix-bks; Thu, 24 Oct 2002 08:39:58 -0700 (PDT)
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9OFduW08983 for <[e-mail]>; Thu, 24 Oct 2002 08:39:56 -0700 (PDT)
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id g9OFdN47027831; Thu, 24 Oct 2002 08:39:23 -0700 (PDT)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id <VPF4ZA23>; Thu, 24 Oct 2002 08:41:54 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: Trevor Freeman <[e-mail]>, Dean Povey <[e-mail]>, Stefan Santesson <[e-mail]>
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-logotypes-06.txt 
Date: Thu, 24 Oct 2002 08:41:52 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_000D_01C27B52.360558D0"; micalg=SHA1
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_000D_01C27B52.360558D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Trevor makes a good point. It is really easy for folk to
ignore accessibility issues.

I have a visual disability problem, whenever I am using a
telephone I cannot see the other person.

One of the main ways the Web was screwed up was that the
carefully designed accessible formats were bowlderized by 
Netscape. Inline font specifications instead of style
sheets, tables for text formatting instead of text flow etc.

As a result HTML is now pretty incompatible with cell phones
and PDAs.

Most computerised equipment has either a visual or an audio
interface. There is a very large class of device that
only has an audio interface.


One of the bugs of IETF process is that it allows people with 
no actual responsibility to customers to pontificate as to 
whether a feature is a requirement or not. Case in point
the ability to deploy DNSSEC in .com and .net has been a 
disputed requirement for over 3 years now.

If the spec describes audio and nobody deploys there is
no harm done.

If the spec does not describe audio and Microsoft and VeriSign
deploy anyway there is a small risk of loss of interoperability
but a much larger risk that people looking for the definitive
certificate specification look on the VeriSign and Microsoft
research sites.


It is completely illogical for people to make the fuss they are
making unless there is some reason that they think that by
disputing the issue here they can somehow stop the technology.
You don't stop a technology by filibustering a working group,
you stop a technology by filling a continuation in part on a
1956 patent claiming retrospectively to have invented it.


		Phill

> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Wednesday, October 23, 2002 8:09 PM
> To: Dean Povey; Stefan Santesson
> Cc: [e-mail]
> Subject: RE: draft-ietf-pkix-logotypes-06.txt 
> 
> 
> 
> Dean,
> The case for audio is simple. People with specific types of visual
> disability will not gain any benefit from a logotype image even if you
> magnify the image. To help these people the general advice from
> Microsoft and other accessibly groups is to add audio the interface
> design. 
> 
> Trevor
> 
> -----Original Message-----
> From: Dean Povey [mailto:[e-mail]] 
> Sent: Wednesday, October 23, 2002 4:04 PM
> To: Stefan Santesson
> Cc: [e-mail]
> Subject: Re: draft-ietf-pkix-logotypes-06.txt 
> 
> 
> >
> >If audio is supported in the protocol in a well structured 
> manner, and
> >nobody deploys it, then it's just dropped before it becomes standard.
> >
> >I do believe though that the deployment industry is likely 
> to find some
> use
> >for it.
> >
> 
> Err, I think the rule is that we start with a firm requirement and
> implement something.  I think there has been a failure to 
> demonstrate a
> firm requirement. If someone can come up with a plausible meaningful
> reason
> to put audio in certificates then we can consider it.  Until then, we
> should concentrate on solving actual problems, not dreaming up
> hypothetical
> ones.  Why isn't there support for MPEG movies in the draft for 
> example? (I hope this doesn't give anyone ideas :-).
> 
> As someone who has to implement this stuff, let me just say that there
> is a
> cost to specifying something that won't (or shouldn't) be used.  You
> still
> end up having to implement and test it to give the perception 
> that your
> products are complying with standards.  It is precisely this
> overspecification in the ITU-T standards that has led to so 
> much garbage
> which has to be supported already.  The certificate path processing
> algorithm is a case in point.  Its complexity is created by a large
> number
> of rarely used extensions whose usefulness is dubious at best.
> 
> So, come up with a plausible use case for audio that cannot be met by
> existing mechanisms, and it can be considered, otherwise drop it, and
> make
> implementers lives a little easier.
> 
> -- 
> Dean Povey,             |em: [e-mail]|JCSI: Java security
> toolkit
> Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C PKI
> toolkit
> Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C SSL
> toolkit
> Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML
> Signatures 
> 
> 

------=_NextPart_000_000D_01C27B52.360558D0
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
BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyNDE1
NDA1NFowIwYJKoZIhvcNAQkEMRYEFKZoNI1tFUHdkXYTqURwWyX4TVp1MFgGCSqGSIb3DQEJDzFL
MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG
BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug
aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj
KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO
rwvJMA0GCSqGSIb3DQEBAQUABIGAMWPAoJlLFF7Tz3ZHva96ShVubERxelKMCAAjvx7IPquSe54D
kO2ARrLUZba0CbMIfJdRtw/NbCdIDM5eEV1JF9Yj4fJs7ks+s3qt/g8ABMuwr7ugRiW/KgqmiMCC
EMuBm1OEnOMk+GLUi+dkpYsxqnHaiVj+6n+x9GTggzMyHc8AAAAAAAA=

------=_NextPart_000_000D_01C27B52.360558D0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9OE0Qm02119 for ietf-pkix-bks; Thu, 24 Oct 2002 07:00:26 -0700 (PDT)
Received: from relay01.rabobank.nl (relay01.rabobank.nl [145.72.69.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9OE0OW02115 for <[e-mail]>; Thu, 24 Oct 2002 07:00:24 -0700 (PDT)
X-Server-Uuid: d32dbd14-b86d-11d3-8c8e-0008c7bba343
X-Server-Uuid: 91077152-1bde-4e67-8480-731f07dac000
From: "Jong 't, D (Dennis)" <[e-mail]>
To: "'Denis Issoupov'" <[e-mail]>
cc: [e-mail]
Subject: RE: Authority Key Identifier
Date: Thu, 24 Oct 2002 16:00:08 +0200
MIME-Version: 1.0
X-WSS-ID: 11A921B61398-09-02
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <11A921B61398-09@_rabobank.nl_>
Sender: [e-mail]
Precedence: 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 agree with you that it is possible for an AKI to be not-unique; it is just
a field in a certificate. But then a CA must be introduced into the PKI
which issues certificates with "pre-defined" AKI's. Since those certificates
are signed by a non-trusted CA, we will reject the "fraudulent" certificate
by the (web) server. By this, the false AKI is not processed at all.

Met vriendelijke groet/with kind regards,
 
Dennis 't Jong

> -----Oorspronkelijk bericht-----
> Van: Denis Issoupov [mailto:[e-mail]]
> Verzonden: donderdag 24 oktober 2002 15:05
> Aan: Jong 't, D (Dennis); [e-mail]
> Onderwerp: RE: Authority Key Identifier
> 
> 
> I think, AKI should not be used for that purpose.
> Anyone can create a certificate with a predefined AKI...
> 
> 
> Denis Issoupov
> Senior Software Developer
> ALACRIS Inc.
> * Voice: 613-230-9762 x239  * Fax: [phone]
> * Cell: 613-294-5948
> * E-mail: [e-mail] * Web: www.alacris.com
> 
> Find out more about the best OCSP Client for Windows at
> http://www.ocspclient.com
> 
>  
> 
> 
> 
> > -----Original Message-----
> > From: Jong 't, D (Dennis) [mailto:[e-mail]] 
> > Sent: Thursday, October 24, 2002 2:04 AM
> > To: '[e-mail]'
> > Subject: RE: Authority Key Identifier
> > 
> > 
> > 
> > Thank you all for the (quick) responses. I now have a better 
> > feeling of the AKI. The suggested books/artickes are taken 
> > into consideration.
> > 
> > We need the AKI to be able to select the proper RA/CA 
> > combination for a Certificate Roll-over. MS IIS will do this 
> > selection using an ISAPI filter/extension. After the proper 
> > RA/CA are selected, RSA Keon will perform a certificate update.
> > 
> > Met vriendelijke groet/with kind regards,
> >  
> > Dennis 't Jong
> > Technisch Specialist
> > Windows Server Management O&O - Beveiliging
> > 
> > Rabobank ICT           Tel:    [phone]
> > Kamer ZL-R255          Fax:    [phone]
> > Laan van Eikenstein 9  Mobiel: [phone]
> > 3705 AR Zeist          Email:  [e-mail] 
> >                        Web:    http://www.RabobankICT.nl 
> > 
> > 
> > 
> > > -----Oorspronkelijk bericht-----
> > > Van: Hamrick, Matt [mailto:[e-mail]]
> > > Verzonden: woensdag 23 oktober 2002 16:19
> > > Aan: 'Jong 't, D (Dennis)'
> > > CC: '[e-mail]'
> > > Onderwerp: RE: Authority Key Identifier
> > > 
> > > 
> > > Also... as a followup to Denis' response, you can find
> > > information about
> > > ASN.1 and BER encoding in the X.680 family of specifications. 
> > > Burt Kalliski
> > > has also authored an article titled "a layman's guide to 
> > > ASN.1" You can
> > > search google or cryptonomicon.net to find the URLs for these 
> > > articles. As a
> > > fyi, most ITU specs cost money, but they allow people to 
> > > download two or
> > > three without charge each year. If you're going to spend 
> > > money trying to
> > > figure out ASN.1 and BER (and you really should figure these 
> > > things out if
> > > you have to do serious certificate work,) there are a couple 
> > > of books on
> > > ASN.1 I saw referenced on cryptonomicon.net. I think you 
> > > could go there or
> > > amazon.com and search for "ASN.1". I think I saw the book 
> by Olivier
> > > Dubuisson and thought it was a reasonable introduction to 
> > the subject.
> > > 
> > > -----Original Message-----
> > > From: Jong 't, D (Dennis) [mailto:[e-mail]]
> > > Sent: Monday, October 21, 2002 7:29 AM
> > > To: '[e-mail]'
> > > Subject: Authority Key Identifier
> > > 
> > > 
> > > 
> > > LS,
> > > 
> > > I have a question regarding the Authority Key Identifier
> > > (AKI) in an x509
> > > certificate. When we resolve the AKI from the "CERT_CONTEXT" 
> > > (MS IIS), it
> > > returns a 24 bytes structure, like:
> > > 30 16 80 14 b2 b6 f2 cb eb d0 b2 26 79 eb 8b 99 74 77 e2 df 
> > > 2f d5 20 69
> > > 
> > > The AKI should be 20 bytes long (RFC 2459, 4.2.1.2 using 160
> > > bit SHA-1),
> > > like:
> > > b2 b6 f2 cb eb d0 b2 26 79 eb 8b 99 74 77 e2 df 2f d5 20 69
> > > 
> > > Does anyone know the purpose of those 4 trailing bytes? If
> > > Yes, is it save
> > > to cut them off to substract the original AKI?
> > > 
> > > Met vriendelijke groet/with kind regards,
> > >  
> > > Dennis 't Jong
> > > Technisch Specialist
> > > Windows Server Management O&O - Beveiliging
> > > 
> > > Rabobank ICT           Tel:    [phone]
> > > Kamer ZL-R255          Fax:    [phone]
> > > Laan van Eikenstein 9  Mobiel: [phone]
> > > 3705 AR Zeist          Email:  [e-mail] 
> > > Nederland              Web:    http://www.RabobankICT.nl 
> > > 
> > > 
> > > 
> > > 
> > > ================================================
> > > De informatie opgenomen in dit bericht kan vertrouwelijk zijn en
> > > is uitsluitend bestemd voor de geadresseerde. Indien u 
> dit bericht 
> > > onterecht ontvangt, wordt u verzocht de inhoud niet te 
> gebruiken en 
> > > de afzender direct te informeren door het bericht te retourneren. 
> > > ================================================
> > > The information contained in this message may be confidential 
> > > and is intended to be exclusively for the addressee. Should you 
> > > receive this message unintentionally, please do not use the 
> > contents 
> > > herein and notify the sender immediately by return e-mail.
> > > 
> > > 
> > > 
> > 
> > 
> > ================================================
> > De informatie opgenomen in dit bericht kan vertrouwelijk zijn en 
> > is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
> > onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en 
> > de afzender direct te informeren door het bericht te retourneren. 
> > ================================================
> > The information contained in this message may be confidential 
> > and is intended to be exclusively for the addressee. Should you 
> > receive this message unintentionally, please do not use the 
> contents 
> > herein and notify the sender immediately by return e-mail.
> > 
> > 
> > 
> 
> 


================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en 
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en 
de afzender direct te informeren door het bericht te retourneren. 
================================================
The information contained in this message may be confidential 
and is intended to be exclusively for the addressee. Should you 
receive this message unintentionally, please do not use the contents 
herein and notify the sender immediately by return e-mail.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9OD51Z28082 for ietf-pkix-bks; Thu, 24 Oct 2002 06:05:01 -0700 (PDT)
Received: from CORPSRV1.Alacris.com ([64.26.153.194]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9OD50W28078 for <[e-mail]>; Thu, 24 Oct 2002 06:05:00 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
Subject: RE: Authority Key Identifier
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 24 Oct 2002 09:04:56 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Authority Key Identifier
thread-index: AcJ7MAKEcqbQc1quQrCwy5CL/bhu8QALWcOg
From: "Denis Issoupov" <[e-mail]>
To: "Jong 't, D (Dennis)" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9OD51W28079
Sender: [e-mail]
Precedence: 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, AKI should not be used for that purpose.
Anyone can create a certificate with a predefined AKI...


Denis Issoupov
Senior Software Developer
ALACRIS Inc.
* Voice: 613-230-9762 x239  * Fax: [phone]
* Cell: 613-294-5948
* E-mail: [e-mail] * Web: www.alacris.com

Find out more about the best OCSP Client for Windows at
http://www.ocspclient.com

 



> -----Original Message-----
> From: Jong 't, D (Dennis) [mailto:[e-mail]] 
> Sent: Thursday, October 24, 2002 2:04 AM
> To: '[e-mail]'
> Subject: RE: Authority Key Identifier
> 
> 
> 
> Thank you all for the (quick) responses. I now have a better 
> feeling of the AKI. The suggested books/artickes are taken 
> into consideration.
> 
> We need the AKI to be able to select the proper RA/CA 
> combination for a Certificate Roll-over. MS IIS will do this 
> selection using an ISAPI filter/extension. After the proper 
> RA/CA are selected, RSA Keon will perform a certificate update.
> 
> Met vriendelijke groet/with kind regards,
>  
> Dennis 't Jong
> Technisch Specialist
> Windows Server Management O&O - Beveiliging
> 
> Rabobank ICT           Tel:    [phone]
> Kamer ZL-R255          Fax:    [phone]
> Laan van Eikenstein 9  Mobiel: [phone]
> 3705 AR Zeist          Email:  [e-mail] 
>                        Web:    http://www.RabobankICT.nl 
> 
> 
> 
> > -----Oorspronkelijk bericht-----
> > Van: Hamrick, Matt [mailto:[e-mail]]
> > Verzonden: woensdag 23 oktober 2002 16:19
> > Aan: 'Jong 't, D (Dennis)'
> > CC: '[e-mail]'
> > Onderwerp: RE: Authority Key Identifier
> > 
> > 
> > Also... as a followup to Denis' response, you can find
> > information about
> > ASN.1 and BER encoding in the X.680 family of specifications. 
> > Burt Kalliski
> > has also authored an article titled "a layman's guide to 
> > ASN.1" You can
> > search google or cryptonomicon.net to find the URLs for these 
> > articles. As a
> > fyi, most ITU specs cost money, but they allow people to 
> > download two or
> > three without charge each year. If you're going to spend 
> > money trying to
> > figure out ASN.1 and BER (and you really should figure these 
> > things out if
> > you have to do serious certificate work,) there are a couple 
> > of books on
> > ASN.1 I saw referenced on cryptonomicon.net. I think you 
> > could go there or
> > amazon.com and search for "ASN.1". I think I saw the book by Olivier
> > Dubuisson and thought it was a reasonable introduction to 
> the subject.
> > 
> > -----Original Message-----
> > From: Jong 't, D (Dennis) [mailto:[e-mail]]
> > Sent: Monday, October 21, 2002 7:29 AM
> > To: '[e-mail]'
> > Subject: Authority Key Identifier
> > 
> > 
> > 
> > LS,
> > 
> > I have a question regarding the Authority Key Identifier
> > (AKI) in an x509
> > certificate. When we resolve the AKI from the "CERT_CONTEXT" 
> > (MS IIS), it
> > returns a 24 bytes structure, like:
> > 30 16 80 14 b2 b6 f2 cb eb d0 b2 26 79 eb 8b 99 74 77 e2 df 
> > 2f d5 20 69
> > 
> > The AKI should be 20 bytes long (RFC 2459, 4.2.1.2 using 160
> > bit SHA-1),
> > like:
> > b2 b6 f2 cb eb d0 b2 26 79 eb 8b 99 74 77 e2 df 2f d5 20 69
> > 
> > Does anyone know the purpose of those 4 trailing bytes? If
> > Yes, is it save
> > to cut them off to substract the original AKI?
> > 
> > Met vriendelijke groet/with kind regards,
> >  
> > Dennis 't Jong
> > Technisch Specialist
> > Windows Server Management O&O - Beveiliging
> > 
> > Rabobank ICT           Tel:    [phone]
> > Kamer ZL-R255          Fax:    [phone]
> > Laan van Eikenstein 9  Mobiel: [phone]
> > 3705 AR Zeist          Email:  [e-mail] 
> > Nederland              Web:    http://www.RabobankICT.nl 
> > 
> > 
> > 
> > 
> > ================================================
> > De informatie opgenomen in dit bericht kan vertrouwelijk zijn en
> > is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
> > onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en 
> > de afzender direct te informeren door het bericht te retourneren. 
> > ================================================
> > The information contained in this message may be confidential 
> > and is intended to be exclusively for the addressee. Should you 
> > receive this message unintentionally, please do not use the 
> contents 
> > herein and notify the sender immediately by return e-mail.
> > 
> > 
> > 
> 
> 
> ================================================
> De informatie opgenomen in dit bericht kan vertrouwelijk zijn en 
> is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
> onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en 
> de afzender direct te informeren door het bericht te retourneren. 
> ================================================
> The information contained in this message may be confidential 
> and is intended to be exclusively for the addressee. Should you 
> receive this message unintentionally, please do not use the contents 
> herein and notify the sender immediately by return e-mail.
> 
> 
> 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9OAkmw18302 for ietf-pkix-bks; Thu, 24 Oct 2002 03:46:48 -0700 (PDT)
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 g9OAklW18297 for <[e-mail]>; Thu, 24 Oct 2002 03:46:47 -0700 (PDT)
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 MAA14860; Thu, 24 Oct 2002 12:47:08 +0200
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 MAA18860; Thu, 24 Oct 2002 12:46:59 +0200
Message-ID: <[e-mail]>
Date: Thu, 24 Oct 2002 12:46:45 +0200
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
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt
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>

Russ,

> Denis:
> 
>> Since we are still in Working Group Last Call, here are my 12 comments on
>> that document.
>>
>> 1. Page 6. Section 3. Logotype data
>>
>> "Implementations MUST support image data; however, support for audio 
>> data is
>> OPTIONAL." Audio is a good joke, in the same way, as pheromones. We are
>> supposed to deal with serious documents. Please delete.
> 
> 
> I belive that the response from Tom Gindin shows that there is support 
> for audio in support if disabled users.  I believe that the document is 
> clear that the support is OPTIONAL.

The document was not clear that the support is OPTIONAL. There is still much 
controversy about the need for it. No convincing arguments have been 
provided. Please delete or make a strawpol.

>> 2. Page 7. Section 4.1 Extension format
>>
>> "Clients MUST support both direct and indirect addressing."
>>
>> I disagree. If an end-user certificate is included in a signature, it 
>> may be
>> interesting to display the logotype even if the terminal is off-line.
>> Indirect addressing would mandate an on-line connection.
>>
>> Replace with:
>>
>> "Clients claiming to conform with this document SHALL support direct
>> addressing. Clients MAY also support indirect addressing."
> 
> 
> We have already had a dialogue on this point.  I hope it is resolved.

Indeed.

>> 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".
> 
> 
> I will add a similar sentence to the second paragraph of section 6.  The 
> paragraph now says:
> 
>    After a certification path is successfully validated, the replying
>    party trusts the information that the CA includes in the certificate,
>    including any certificate extensions. The client software can choose
>    to make use of such information, or the client software can ignore
>    it. 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. Current standards
>    do not provide any mechanism for cross-certifying CAs to constrain
>    subordinate CAs from including private extensions (see the security
>    considerations section).

This is fine.

>> 4. Page 8. Section 4.1.
>>
>>       LogotypeData ::= SEQUENCE {
>>          image           SEQUENCE OF LogotypeImage     OPTIONAL,
>>          audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }
>>
>> Since audio support should be suppressed, replace with:
>>
>>       LogotypeData ::= SEQUENCE OF LogotypeImage
> 
> 
> This is related to comment 1.  No change will be made.

See above.

>> 5. Page 7. Section 4.1.
>>
>> We have:
>>
>>       communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
>>
>>       LogotypeInfo ::= CHOICE {
>>          direct          [0] LogotypeData,
>>          indirect        [1] LogotypeReference }
>>
>>       LogotypeData ::= SEQUENCE {
>>          image           SEQUENCE OF LogotypeImage OPTIONAL,
>>
>> No explanations are given on the text about what to do for a client when
>> there is more than one LogotypeImage present in a communityLogo.
>>
>> First of all, a communityLogo may contain more than one logo which 
>> belongs
>> to one or more communities. However the client has no way to know whether
>> the LogotypeData includes different versions from the same logo (e.g. in
>> black and white or in color) or different logos.
> 
> 
> This is not supported.  The certificate may only include one image.  
> That image could be a composite of many different logos, if 
> appropriate.  We discussed this face-to-face in Yokohama.  Discussion 
> with people what develop graphical interfaces do not think it is a good 
> idea to allow this complexity.  Too many images will confuse the user.  


> When it is appropriate to include several community logos, they must be 
> combined into one image to ensure that they are consistently displayed.  
> If this is not done, each client will render the images differently...

We still have different views on that topic, which is far more important 
than audio. To give a parallel: some banks are members of both VISA and 
EuroCard. Transposed into certificates, this may mean two logos. In the same 
way, a CA may be certifed by two laboratories. The logo of these two 
laboratories may be displayed.

So for community certificates, I am requesting the possibility to have more 
than one logo. The use of combined logos is not appropraite to solve this issue.

>> 6. Page 9. Section 4.1.
>>
>>       LogotypeImageInfo ::= SEQUENCE {
>>          fileSize        INTEGER,  -- In octets
>>          xSize           INTEGER,  -- In pixels
>>          ySize           INTEGER,  -- In pixels
>>          numColors       INTEGER } -- In bits
>>
>> Text is missing to explain this structure. How is a grey scale 
>> indicated for
>> jpeg and for gif ???
> 
> 
> Do you have a recommendation?

No. But I wonder whether the structure is correct. Has it been verifed by an 
image expert ? Many PDAs have B&N screens only because they are cheaper.

>> 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."
> 
> 
> We have tried to avoid such a statement.  Instead we allow the inclusion 
> of the same image at many different resolutions so that the client can 
> select the best fit.  This is also the reason that we use MIME types to 
> name the format.  It allows the greatest flexibility.

  ... but is does not provide any conformance clause.

Can we say that a client is logo-enabled if it only supports 10 x 10
pixels ? Unless the minimumm size (whatever it is) is always present in
the logo, then it is not possible to say that the client is logo-enabled.

>> 8. Page 9. Section 4.1.
>>
>>       LogotypeImageInfo ::= SEQUENCE {
>>          fileSize        INTEGER,  -- In octets
>>          xSize           INTEGER,  -- In pixels
>>          ySize           INTEGER,  -- In pixels
>>          numColors       INTEGER } -- In bits
>>
>> It would also be appropriate to say what to do when the image is in color
>> and that the client has no color display available. No display at all ?
>> Conversion into grey scale using which kind of transposition ?
> 
> 
> The client is always allowed to ignore the logotype altogether.  The 
> stronger language added in response to your third comment makes this clear.

Do you mean that if the logo is defined in color and the terminal is only 
B&N then the logo shall not be displayed ? If so, this should be clearly said.


>> 9. Page 9. Section 4.1. Since audio is a joke, text and ASN.1 about audio
>> should be deleted.
> 
> 
> Again, related to your first comment. No change.

See above.

>> 10. Page 9. Section 4.1. The text states:
>>
>> "Implementations MUST support both the JPEG and GIF image formats 
>> (with MIME
>> types of "image/jpeg" and "image/gif", respectively)"
>>
>> I would guess that Animated GIF should not be supported. Could we say 
>> it ?
> 
> 
> Okay.  That paragraph now reads:
> 
>    A MIME type is used to specify the format of the file containing the
>    logotype data. Implementations MUST support both the JPEG and GIF
>    image formats (with MIME types of "image/jpeg" and "image/gif",
>    respectively). Animated images SHOULD NOT be used. Implementations
>    that support audio MUST support the MP3 audio format (with a MIME
>    type of "audio/mpeg").

The additional sentence for animated images is fine. No comment on the 
additional sentence for audio. See above.

>> 11. Page 10. Section 4.1.
>>
>>       Community Logotype. If communityLogo is present, the logotype MUST
>>       represent the community to which the certificate issuer is
>>       affiliated. The communityLogo MAY be present in an end entity
>>       certificate, a CA certificate or an attribute certificate.
>>
>> A certificate issuer may belong to more than one community. Replace: "the
>> community " by :"the community or the communities".
> 
> 
> This is already discussed in response to comment 5.  No change.

I maintain the request for it. See above.

>> 12. Page 11. Section 5. Type of certificates
>>
>>    Logotypes MAY be present in three types of certificates:
>>
>>      - CA certificates
>>      - End-entity certificates
>>      - Attribute certificates
>>
>> Why is there such a limitation ? CRL Issuers, OCSP responders or TSUs may
>> have logotypes present in their certificates.
>>
>> Replace with : "Logotypes MAY be present in any type of certificate".
> 
> 
> David Cross spoke against this suggestion.

No. David Croos spoke about the *display* of the logo, not the *presence* of 
the logo. Please make the change or provide new arguments.


Denis

> Russ





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9O9b0U13428 for ietf-pkix-bks; Thu, 24 Oct 2002 02:37:00 -0700 (PDT)
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 g9O9axW13423 for <[e-mail]>; Thu, 24 Oct 2002 02:36:59 -0700 (PDT)
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 LAA22648; Thu, 24 Oct 2002 11:37:19 +0200
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 LAA16338; Thu, 24 Oct 2002 11:37:01 +0200
Message-ID: <[e-mail]>
Date: Thu, 24 Oct 2002 11:36:48 +0200
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
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: draft-ietf-pkix-logotypes-06.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,

> I mostly agree with you.
> 
> What I mean is that there is some line, beyond which you just need to accept
> the whish to do something and say - OK if some implementers want to do this
> type of thing, what is the best way to do it?
> 
> I think the most cases where a firm requirement is badly needed is where
> someone what to do something in a different way, where current standard
> gives another way of doing almost the same thing, and where doing the
> proposed changes/amendments would produce alternative solutions to closely
> related problem (Like the PI versus serialNumber Attributes, OCSPv2 versus
> SCVP, CMP versus CMC .....)
> 
> I think Trevor has demonstrated a reasonable need to use audio with
> Logotypes.

The argument from Trevor is not convincing: adding audio to the interface 
design does not mean adding audio for everything.

  ... but this demonstrates that it was *not* a joke (either god or bad), 
from at least two of the co-editors of the document. :-(

Denis

> /Stefan
> 
> 
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]]On Behalf Of Dean Povey
>>Sent: Thursday, October 24, 2002 1:04 AM
>>To: Stefan Santesson
>>Cc: [e-mail]
>>Subject: Re: draft-ietf-pkix-logotypes-06.txt
>>
>>
>>
>>
>>>If audio is supported in the protocol in a well structured manner, and
>>>nobody deploys it, then it's just dropped before it becomes standard.
>>>
>>>I do believe though that the deployment industry is likely to
>>
>>find some use
>>
>>>for it.
>>>
>>
>>Err, I think the rule is that we start with a firm requirement and
>>implement something.  I think there has been a failure to demonstrate a
>>firm requirement. If someone can come up with a plausible
>>meaningful reason
>>to put audio in certificates then we can consider it.  Until then, we
>>should concentrate on solving actual problems, not dreaming up
>>hypothetical
>>ones.  Why isn't there support for MPEG movies in the draft for
>>example? (I hope this doesn't give anyone ideas :-).
>>
>>As someone who has to implement this stuff, let me just say that
>>there is a
>>cost to specifying something that won't (or shouldn't) be used.  You still
>>end up having to implement and test it to give the perception that your
>>products are complying with standards.  It is precisely this
>>overspecification in the ITU-T standards that has led to so much garbage
>>which has to be supported already.  The certificate path processing
>>algorithm is a case in point.  Its complexity is created by a large number
>>of rarely used extensions whose usefulness is dubious at best.
>>
>>So, come up with a plausible use case for audio that cannot be met by
>>existing mechanisms, and it can be considered, otherwise drop it, and make
>>implementers lives a little easier.
>>
>>--
>>Dean Povey,             |em: [e-mail]|JCSI: Java
>>security toolkit
>>Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C
>>PKI toolkit
>>Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C
>>SSL toolkit
>>Brisbane, Australia     |www: www.wedgetail.com |XML Security:
>>XML Signatures
>>
>>
>>
> 
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9O8uxf08526 for ietf-pkix-bks; Thu, 24 Oct 2002 01:56:59 -0700 (PDT)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9O8uvW08521 for <[e-mail]>; Thu, 24 Oct 2002 01:56:57 -0700 (PDT)
Received: from Santesson ([213.64.1.112]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 24 Oct 2002 10:56:52 +0200
From: "Stefan Santesson" <[e-mail]>
To: "Dean Povey" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: draft-ietf-pkix-logotypes-06.txt 
Date: Thu, 24 Oct 2002 10:56:51 +0200
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: 24 Oct 2002 08:56:52.0609 (UTC) FILETIME=[4BE08F10:01C27B3B]
Sender: [e-mail]
Precedence: 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 mostly agree with you.

What I mean is that there is some line, beyond which you just need to accept
the whish to do something and say - OK if some implementers want to do this
type of thing, what is the best way to do it?

I think the most cases where a firm requirement is badly needed is where
someone what to do something in a different way, where current standard
gives another way of doing almost the same thing, and where doing the
proposed changes/amendments would produce alternative solutions to closely
related problem (Like the PI versus serialNumber Attributes, OCSPv2 versus
SCVP, CMP versus CMC .....)

I think Trevor has demonstrated a reasonable need to use audio with
Logotypes.

/Stefan

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Dean Povey
> Sent: Thursday, October 24, 2002 1:04 AM
> To: Stefan Santesson
> Cc: [e-mail]
> Subject: Re: draft-ietf-pkix-logotypes-06.txt
>
>
>
> >
> >If audio is supported in the protocol in a well structured manner, and
> >nobody deploys it, then it's just dropped before it becomes standard.
> >
> >I do believe though that the deployment industry is likely to
> find some use
> >for it.
> >
>
> Err, I think the rule is that we start with a firm requirement and
> implement something.  I think there has been a failure to demonstrate a
> firm requirement. If someone can come up with a plausible
> meaningful reason
> to put audio in certificates then we can consider it.  Until then, we
> should concentrate on solving actual problems, not dreaming up
> hypothetical
> ones.  Why isn't there support for MPEG movies in the draft for
> example? (I hope this doesn't give anyone ideas :-).
>
> As someone who has to implement this stuff, let me just say that
> there is a
> cost to specifying something that won't (or shouldn't) be used.  You still
> end up having to implement and test it to give the perception that your
> products are complying with standards.  It is precisely this
> overspecification in the ITU-T standards that has led to so much garbage
> which has to be supported already.  The certificate path processing
> algorithm is a case in point.  Its complexity is created by a large number
> of rarely used extensions whose usefulness is dubious at best.
>
> So, come up with a plausible use case for audio that cannot be met by
> existing mechanisms, and it can be considered, otherwise drop it, and make
> implementers lives a little easier.
>
> --
> Dean Povey,             |em: [e-mail]|JCSI: Java
> security toolkit
> Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C
> PKI toolkit
> Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C
> SSL toolkit
> Brisbane, Australia     |www: www.wedgetail.com |XML Security:
> XML Signatures
>
>
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9O8VY306575 for ietf-pkix-bks; Thu, 24 Oct 2002 01:31:34 -0700 (PDT)
Received: from izecom.com (cust.6.115.adsl.cistron.nl [62.216.6.115]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9O8VWW06561 for <[e-mail]>; Thu, 24 Oct 2002 01:31:33 -0700 (PDT)
Received: from Pengo.christine.nl ([192.168.0.16]) by izecom.com (8.11.6/8.11.6) with ESMTP id g9O8X9A08252 for <[e-mail]>; Thu, 24 Oct 2002 10:33:09 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 24 Oct 2002 10:28:43 +0200
To: [e-mail]
From: Christine Karman <[e-mail]>
Subject: Re: Fwd: PKI Forum
In-Reply-To: <[e-mail] .com>
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 07:19 PM 10/22/2002, Housley, Russ wrote:

>I thought that the members of the PKIX WG would find this interesting....
>
>Russ
>
> > OASIS is pleased to announce that on 1 November, PKI Forum will
> > become the newest OASIS Member Section.

What's your opinion about PKI forum? I've visited their Amsterdam meeting 
earlier this year, but I was not impressed.

dagdag
Christine



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9O682C09862 for ietf-pkix-bks; Wed, 23 Oct 2002 23:08:02 -0700 (PDT)
Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9O680W09852 for <[e-mail]>; Wed, 23 Oct 2002 23:08:00 -0700 (PDT)
Received: from francetelecom.com ([10.193.13.56]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Oct 2002 08:08:04 +0200
Message-ID: <[e-mail]>
Date: Thu, 24 Oct 2002 08:08:00 +0200
From: DUBUISSON Olivier <[e-mail]>
Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hamrick, Matt" <[e-mail]>
CC: "'Jong 't, D (Dennis)'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Authority Key Identifier
References: <DCE76463749C64499892A0DB3AF05AC602457557@CHALLENGER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Oct 2002 06:08:04.0203 (UTC) FILETIME=[B6E073B0:01C27B23]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Hamrick, Matt" wrote:
> 
> Also... as a followup to Denis' response, you can find information about
> ASN.1 and BER encoding in the X.680 family of specifications. Burt Kalliski
> has also authored an article titled "a layman's guide to ASN.1" You can
> search google or cryptonomicon.net to find the URLs for these articles. As a
> fyi, most ITU specs cost money, but they allow people to download two or
> three 

3

> without charge each year. 

The X.680 and X.690 have been totally free for 2 years:

http://www.itu.int/ITU-T/studygroups/com17/languages/

> If you're going to spend money trying to
> figure out ASN.1 and BER (and you really should figure these things out if
> you have to do serious certificate work,) there are a couple of books on
> ASN.1 I saw referenced on cryptonomicon.net. I think you could go there or
> amazon.com and search for "ASN.1". I think I saw the book by Olivier
> Dubuisson and thought it was a reasonable introduction to the subject.

It can be downloaded for free from OSS Nokalva's website:
http://www.oss.com/asn1/dubuisson.html
-- 
Olivier DUBUISSON
france telecom R&D

DTL/TAL - 22307 Lannion Cedex - France
t: [phone] - f: [phone] - http://asn1.elibel.tm.fr/


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9O64xd08493 for ietf-pkix-bks; Wed, 23 Oct 2002 23:04:59 -0700 (PDT)
Received: from relay02.rabobank.nl (relay02.rabobank.nl [145.72.69.21]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9O64uW08458 for <[e-mail]>; Wed, 23 Oct 2002 23:04:56 -0700 (PDT)
X-Server-Uuid: d32dbd14-b86d-11d3-8c8e-0008c7bba343
X-Server-Uuid: 91077152-1bde-4e67-8480-731f07dac000
From: "Jong 't, D (Dennis)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Authority Key Identifier
Date: Thu, 24 Oct 2002 08:03:50 +0200
MIME-Version: 1.0
X-WSS-ID: 11A95B454990614-32-02
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <11A95B454990614-32@_rabobank.nl_>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thank you all for the (quick) responses. I now have a better feeling of the
AKI. The suggested books/artickes are taken into consideration.

We need the AKI to be able to select the proper RA/CA combination for a
Certificate Roll-over. MS IIS will do this selection using an ISAPI
filter/extension. After the proper RA/CA are selected, RSA Keon will perform
a certificate update.

Met vriendelijke groet/with kind regards,
 
Dennis 't Jong
Technisch Specialist
Windows Server Management O&O - Beveiliging

Rabobank ICT           Tel:    [phone]
Kamer ZL-R255          Fax:    [phone]
Laan van Eikenstein 9  Mobiel: [phone]
3705 AR Zeist          Email:  [e-mail] 
                       Web:    http://www.RabobankICT.nl 



> -----Oorspronkelijk bericht-----
> Van: Hamrick, Matt [mailto:[e-mail]]
> Verzonden: woensdag 23 oktober 2002 16:19
> Aan: 'Jong 't, D (Dennis)'
> CC: '[e-mail]'
> Onderwerp: RE: Authority Key Identifier
> 
> 
> Also... as a followup to Denis' response, you can find 
> information about
> ASN.1 and BER encoding in the X.680 family of specifications. 
> Burt Kalliski
> has also authored an article titled "a layman's guide to 
> ASN.1" You can
> search google or cryptonomicon.net to find the URLs for these 
> articles. As a
> fyi, most ITU specs cost money, but they allow people to 
> download two or
> three without charge each year. If you're going to spend 
> money trying to
> figure out ASN.1 and BER (and you really should figure these 
> things out if
> you have to do serious certificate work,) there are a couple 
> of books on
> ASN.1 I saw referenced on cryptonomicon.net. I think you 
> could go there or
> amazon.com and search for "ASN.1". I think I saw the book by Olivier
> Dubuisson and thought it was a reasonable introduction to the subject.
> 
> -----Original Message-----
> From: Jong 't, D (Dennis) [mailto:[e-mail]]
> Sent: Monday, October 21, 2002 7:29 AM
> To: '[e-mail]'
> Subject: Authority Key Identifier
> 
> 
> 
> LS,
> 
> I have a question regarding the Authority Key Identifier 
> (AKI) in an x509
> certificate. When we resolve the AKI from the "CERT_CONTEXT" 
> (MS IIS), it
> returns a 24 bytes structure, like:
> 30 16 80 14 b2 b6 f2 cb eb d0 b2 26 79 eb 8b 99 74 77 e2 df 
> 2f d5 20 69
> 
> The AKI should be 20 bytes long (RFC 2459, 4.2.1.2 using 160 
> bit SHA-1),
> like:
> b2 b6 f2 cb eb d0 b2 26 79 eb 8b 99 74 77 e2 df 2f d5 20 69
> 
> Does anyone know the purpose of those 4 trailing bytes? If 
> Yes, is it save
> to cut them off to substract the original AKI?
> 
> Met vriendelijke groet/with kind regards,
>  
> Dennis 't Jong
> Technisch Specialist
> Windows Server Management O&O - Beveiliging 
> 
> Rabobank ICT           Tel:    [phone]
> Kamer ZL-R255          Fax:    [phone]
> Laan van Eikenstein 9  Mobiel: [phone]
> 3705 AR Zeist          Email:  [e-mail] 
> Nederland              Web:    http://www.RabobankICT.nl 
> 
> 
> 
> 
> ================================================
> De informatie opgenomen in dit bericht kan vertrouwelijk zijn en 
> is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
> onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en 
> de afzender direct te informeren door het bericht te retourneren. 
> ================================================
> The information contained in this message may be confidential 
> and is intended to be exclusively for the addressee. Should you 
> receive this message unintentionally, please do not use the contents 
> herein and notify the sender immediately by return e-mail.
> 
> 
> 


================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en 
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en 
de afzender direct te informeren door het bericht te retourneren. 
================================================
The information contained in this message may be confidential 
and is intended to be exclusively for the addressee. Should you 
receive this message unintentionally, please do not use the contents 
herein and notify the sender immediately by return e-mail.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9O2XKt25691 for ietf-pkix-bks; Wed, 23 Oct 2002 19:33:20 -0700 (PDT)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9O2XIW25685 for <[e-mail]>; Wed, 23 Oct 2002 19:33:18 -0700 (PDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 23 Oct 2002 19:33:20 -0700
Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 23 Oct 2002 19:33:17 -0700
Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 23 Oct 2002 19:33:18 -0700
Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 23 Oct 2002 19:33:14 -0700
Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Wed, 23 Oct 2002 19:33:23 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6771.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-logotypes-06.txt 
Date: Wed, 23 Oct 2002 19:33:04 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-logotypes-06.txt 
Thread-Index: AcJ69XLt/fzOMCkXQOqHh7Euf4YcMgADTe2w
From: "Trevor Freeman" <[e-mail]>
To: "Dean Povey" <[e-mail]>
Cc: "Stefan Santesson" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 24 Oct 2002 02:33:23.0118 (UTC) FILETIME=[B926DCE0:01C27B05]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9O2XJW25687
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dean,
The approach you suggest would put the onus on the application having
text to audio technology to support this case as apposed to simply
playing an audio file. And that text to audio technology must work for
all languages and cope with translation. That is a pretty high bar.
Playing an audio file is as you point out a well understood mechanism
which can be widely implemented and addresses the issue of language
because the client can pick the audio file appropriate for them. Your
suggestion also does not provide for the classes of image which the
draft supports. Equality if you are truly interested in implementation
simplicity your suggestion forces me into two radically different code
paths for audio and images which the current draft does not. 
We can certainly point out in the security section the need to ensure
that there is no ambiguity with other audio stream that many be being
played.

Trevor

-----Original Message-----
From: Dean Povey [mailto:[e-mail]] 
Sent: Wednesday, October 23, 2002 5:36 PM
To: Trevor Freeman
Cc: Stefan Santesson; [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt 

On Wed, 23 Oct 2002 17:09:28 MST, "Trevor Freeman" wrote: 
>Dean,
>The case for audio is simple. People with specific types of visual
>disability will not gain any benefit from a logotype image even if you
>magnify the image. To help these people the general advice from
>Microsoft and other accessibly groups is to add audio the interface
>design. 

Hi Trevor,

As I stated in an earlier mail, it would be more appropriate for the
browser software to read the issuer/subject name of the cert and more in
keeping with the way that web accessibility is usually done.  This does
not
require any additional support.  The fact that logotypes are not useful
to 
people with visual impairment is irrelevant to the standard, as the
image 
simply acts as an aid to the trust process are not mandatory for it.  It

can be argued that accesibility software reading a message similar to:

"The following web page is authenticated by a certificate issued to X by
Y"

is as (more?) effective than a logotype in achieving the end goal of 
increasing the visibility (in the abstract sense) of the binding between

the content and the certificate.

However, I have just thought of another objection on security grounds.
Most web browsers support the playing of audio when a web page loads.
How
will you distinguish between the audio in the cert and something a
person
puts on a web page?  This problem does not exist for logotypes, as the
browser can reserve a part of its user interface for displaying the
logos
in a way that cannot be overridden by the page itself. AFAIK, this issue
is
not addressed in the current draft.  If concensus indicates that audio 
goes ahead, this will need to be addressed in the "Client Use" and/or 
"Security Considerations" sections.

Cheers.
-- 
Dean Povey,             |em: [e-mail]|JCSI: Java security
toolkit
Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C PKI
toolkit
Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C SSL
toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML
Signatures 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9O0aVA19191 for ietf-pkix-bks; Wed, 23 Oct 2002 17:36:31 -0700 (PDT)
Received: from osprey.wedgetail.com (starling.wedgetail.com [202.83.95.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9O0aTW19186 for <[e-mail]>; Wed, 23 Oct 2002 17:36:29 -0700 (PDT)
Received: from coot.wedgetail.com (coot.wedgetail.com [10.10.10.4]) by osprey.wedgetail.com (8.12.5/8.12.5) with ESMTP id g9O0ZfNU017999; Thu, 24 Oct 2002 10:35:41 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh exmh 2.5 (2001-07-13) with nmh-1.0.4
From: Dean Povey <[e-mail]>
To: "Trevor Freeman" <[e-mail]>
cc: "Stefan Santesson" <[e-mail]>, [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt 
In-reply-to: Your message of "Wed, 23 Oct 2002 17:09:28 MST." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 24 Oct 2002 10:35:41 +1000
X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: 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 Wed, 23 Oct 2002 17:09:28 MST, "Trevor Freeman" wrote: 
>Dean,
>The case for audio is simple. People with specific types of visual
>disability will not gain any benefit from a logotype image even if you
>magnify the image. To help these people the general advice from
>Microsoft and other accessibly groups is to add audio the interface
>design. 

Hi Trevor,

As I stated in an earlier mail, it would be more appropriate for the
browser software to read the issuer/subject name of the cert and more in
keeping with the way that web accessibility is usually done.  This does not
require any additional support.  The fact that logotypes are not useful to 
people with visual impairment is irrelevant to the standard, as the image 
simply acts as an aid to the trust process are not mandatory for it.  It 
can be argued that accesibility software reading a message similar to:

"The following web page is authenticated by a certificate issued to X by Y"

is as (more?) effective than a logotype in achieving the end goal of 
increasing the visibility (in the abstract sense) of the binding between 
the content and the certificate.

However, I have just thought of another objection on security grounds.
Most web browsers support the playing of audio when a web page loads.  How
will you distinguish between the audio in the cert and something a person
puts on a web page?  This problem does not exist for logotypes, as the
browser can reserve a part of its user interface for displaying the logos
in a way that cannot be overridden by the page itself. AFAIK, this issue is
not addressed in the current draft.  If concensus indicates that audio 
goes ahead, this will need to be addressed in the "Client Use" and/or 
"Security Considerations" sections.

Cheers.
-- 
Dean Povey,             |em: [e-mail]|JCSI: Java security toolkit
Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C PKI toolkit
Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C SSL toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML Signatures 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9O09Y318084 for ietf-pkix-bks; Wed, 23 Oct 2002 17:09:34 -0700 (PDT)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9O09WW18080 for <[e-mail]>; Wed, 23 Oct 2002 17:09:32 -0700 (PDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 23 Oct 2002 17:09:28 -0700
Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 23 Oct 2002 17:09:30 -0700
Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 23 Oct 2002 17:09:29 -0700
Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 23 Oct 2002 17:09:29 -0700
Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Wed, 23 Oct 2002 17:09:28 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6771.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-logotypes-06.txt 
Date: Wed, 23 Oct 2002 17:09:28 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-logotypes-06.txt 
Thread-Index: AcJ66lRrLLW+lnFMQuSGPgRJxVgh3AAAqZYw
From: "Trevor Freeman" <[e-mail]>
To: "Dean Povey" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 24 Oct 2002 00:09:28.0302 (UTC) FILETIME=[9E6680E0:01C27AF1]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9O09WW18081
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dean,
The case for audio is simple. People with specific types of visual
disability will not gain any benefit from a logotype image even if you
magnify the image. To help these people the general advice from
Microsoft and other accessibly groups is to add audio the interface
design. 

Trevor

-----Original Message-----
From: Dean Povey [mailto:[e-mail]] 
Sent: Wednesday, October 23, 2002 4:04 PM
To: Stefan Santesson
Cc: [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt 


>
>If audio is supported in the protocol in a well structured manner, and
>nobody deploys it, then it's just dropped before it becomes standard.
>
>I do believe though that the deployment industry is likely to find some
use
>for it.
>

Err, I think the rule is that we start with a firm requirement and
implement something.  I think there has been a failure to demonstrate a
firm requirement. If someone can come up with a plausible meaningful
reason
to put audio in certificates then we can consider it.  Until then, we
should concentrate on solving actual problems, not dreaming up
hypothetical
ones.  Why isn't there support for MPEG movies in the draft for 
example? (I hope this doesn't give anyone ideas :-).

As someone who has to implement this stuff, let me just say that there
is a
cost to specifying something that won't (or shouldn't) be used.  You
still
end up having to implement and test it to give the perception that your
products are complying with standards.  It is precisely this
overspecification in the ITU-T standards that has led to so much garbage
which has to be supported already.  The certificate path processing
algorithm is a case in point.  Its complexity is created by a large
number
of rarely used extensions whose usefulness is dubious at best.

So, come up with a plausible use case for audio that cannot be met by
existing mechanisms, and it can be considered, otherwise drop it, and
make
implementers lives a little easier.

-- 
Dean Povey,             |em: [e-mail]|JCSI: Java security
toolkit
Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C PKI
toolkit
Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C SSL
toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML
Signatures 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NN5V916864 for ietf-pkix-bks; Wed, 23 Oct 2002 16:05:31 -0700 (PDT)
Received: from osprey.wedgetail.com (starling.wedgetail.com [202.83.95.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NN5TW16860 for <[e-mail]>; Wed, 23 Oct 2002 16:05:29 -0700 (PDT)
Received: from coot.wedgetail.com (coot.wedgetail.com [10.10.10.4]) by osprey.wedgetail.com (8.12.5/8.12.5) with ESMTP id g9NN4NNU016815; Thu, 24 Oct 2002 09:04:24 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh exmh 2.5 (2001-07-13) with nmh-1.0.4
From: Dean Povey <[e-mail]>
To: "Stefan Santesson" <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt 
In-reply-to: Your message of "Wed, 23 Oct 2002 14:54:03 +0200." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 24 Oct 2002 09:04:23 +1000
X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: 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 audio is supported in the protocol in a well structured manner, and
>nobody deploys it, then it's just dropped before it becomes standard.
>
>I do believe though that the deployment industry is likely to find some use
>for it.
>

Err, I think the rule is that we start with a firm requirement and
implement something.  I think there has been a failure to demonstrate a
firm requirement. If someone can come up with a plausible meaningful reason
to put audio in certificates then we can consider it.  Until then, we
should concentrate on solving actual problems, not dreaming up hypothetical
ones.  Why isn't there support for MPEG movies in the draft for 
example? (I hope this doesn't give anyone ideas :-).

As someone who has to implement this stuff, let me just say that there is a
cost to specifying something that won't (or shouldn't) be used.  You still
end up having to implement and test it to give the perception that your
products are complying with standards.  It is precisely this
overspecification in the ITU-T standards that has led to so much garbage
which has to be supported already.  The certificate path processing
algorithm is a case in point.  Its complexity is created by a large number
of rarely used extensions whose usefulness is dubious at best.

So, come up with a plausible use case for audio that cannot be met by
existing mechanisms, and it can be considered, otherwise drop it, and make
implementers lives a little easier.

-- 
Dean Povey,             |em: [e-mail]|JCSI: Java security toolkit
Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C PKI toolkit
Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C SSL toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML Signatures 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NEPsN17746 for ietf-pkix-bks; Wed, 23 Oct 2002 07:25:54 -0700 (PDT)
Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9NEPrW17741 for <[e-mail]>; Wed, 23 Oct 2002 07:25:53 -0700 (PDT)
Message-Id: <[e-mail]>
Received: from unknown (HELO IBM-9011) (forward?li@218.244.240.132 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 23 Oct 2002 14:25:53 -0000
From: "forward_li" <[e-mail]>
To: "Jong 't, D (Dennis)" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Authority Key Identifier
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Date: Wed, 23 Oct 2002 22:25:35 +0800
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9NEPrW17742
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jong 't, D (Dennis),ÄúºÃ£¡

In fact, the certificate is be encoded as asn.1 strings just like dennis Issoupov email said. 

======= 2002-10-21 13:28:00 ÄúÔÚÀ´ÐÅÖÐдµÀ£º=======

>LS,
>
>I have a question regarding the Authority Key Identifier (AKI) in an x509
>certificate. When we resolve the AKI from the "CERT_CONTEXT" (MS IIS), it
>returns a 24 bytes structure, like:
>30 16 80 14 b2 b6 f2 cb eb d0 b2 26 79 eb 8b 99 74 77 e2 df 2f d5 20 69
>
>The AKI should be 20 bytes long (RFC 2459, 4.2.1.2 using 160 bit SHA-1),
>like:
>b2 b6 f2 cb eb d0 b2 26 79 eb 8b 99 74 77 e2 df 2f d5 20 69
>
>Does anyone know the purpose of those 4 trailing bytes? If Yes, is it save
>to cut them off to substract the original AKI?
>
>Met vriendelijke groet/with kind regards,
> 
>Dennis 't Jong
>Technisch Specialist
>Windows Server Management O&O - Beveiliging 
>
>Rabobank ICT           Tel:    [phone]
>Kamer ZL-R255          Fax:    [phone]
>Laan van Eikenstein 9  Mobiel: [phone]
>3705 AR Zeist          Email:  [e-mail] 
>Nederland              Web:    http://www.RabobankICT.nl 
>
>
>
>
>================================================
>De informatie opgenomen in dit bericht kan vertrouwelijk zijn en 
>is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
>onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en 
>de afzender direct te informeren door het bericht te retourneren. 
>================================================
>The information contained in this message may be confidential 
>and is intended to be exclusively for the addressee. Should you 
>receive this message unintentionally, please do not use the contents 
>herein and notify the sender immediately by return e-mail.

= = = = = = = = = = = = = = = = = = = =
			

¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ÖÂ
Àñ£¡
 
				 
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡forward_li
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡[e-mail]
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-10-23



_________________________________________________________
Do You Yahoo!? 
"Ô¸Ò⻨¼¸·ÖÖÓÀ´¸ÄÉÆÄúµÄÑÅ»¢µçÓÊ·þÎñÂð£¿"
http://sweepstakes.yahoo.com/email_usage


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NENsx17700 for ietf-pkix-bks; Wed, 23 Oct 2002 07:23:54 -0700 (PDT)
Received: from stargazer-o.stars-smi.com (stargazer-o.stars-smi.com [151.200.173.2]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9NENrW17696 for <[e-mail]>; Wed, 23 Oct 2002 07:23:53 -0700 (PDT)
Received: from excelsior.stars-smi.com by stargazer-o.stars-smi.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 23 Oct 2002 14:21:11 UT
Received: by excelsior.stars-smi.com with Internet Mail Service (5.5.2655.55) id <RDBXS5JC>; Wed, 23 Oct 2002 10:31:57 -0400
Message-ID: <DCE76463749C64499892A0DB3AF05AC602457557@CHALLENGER>
From: "Hamrick, Matt" <[e-mail]>
To: "'Jong 't, D (Dennis)'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Authority Key Identifier
Date: Wed, 23 Oct 2002 10:18:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
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>

Also... as a followup to Denis' response, you can find information about
ASN.1 and BER encoding in the X.680 family of specifications. Burt Kalliski
has also authored an article titled "a layman's guide to ASN.1" You can
search google or cryptonomicon.net to find the URLs for these articles. As a
fyi, most ITU specs cost money, but they allow people to download two or
three without charge each year. If you're going to spend money trying to
figure out ASN.1 and BER (and you really should figure these things out if
you have to do serious certificate work,) there are a couple of books on
ASN.1 I saw referenced on cryptonomicon.net. I think you could go there or
amazon.com and search for "ASN.1". I think I saw the book by Olivier
Dubuisson and thought it was a reasonable introduction to the subject.

-----Original Message-----
From: Jong 't, D (Dennis) [mailto:[e-mail]]
Sent: Monday, October 21, 2002 7:29 AM
To: '[e-mail]'
Subject: Authority Key Identifier



LS,

I have a question regarding the Authority Key Identifier (AKI) in an x509
certificate. When we resolve the AKI from the "CERT_CONTEXT" (MS IIS), it
returns a 24 bytes structure, like:
30 16 80 14 b2 b6 f2 cb eb d0 b2 26 79 eb 8b 99 74 77 e2 df 2f d5 20 69

The AKI should be 20 bytes long (RFC 2459, 4.2.1.2 using 160 bit SHA-1),
like:
b2 b6 f2 cb eb d0 b2 26 79 eb 8b 99 74 77 e2 df 2f d5 20 69

Does anyone know the purpose of those 4 trailing bytes? If Yes, is it save
to cut them off to substract the original AKI?

Met vriendelijke groet/with kind regards,
 
Dennis 't Jong
Technisch Specialist
Windows Server Management O&O - Beveiliging 

Rabobank ICT           Tel:    [phone]
Kamer ZL-R255          Fax:    [phone]
Laan van Eikenstein 9  Mobiel: [phone]
3705 AR Zeist          Email:  [e-mail] 
Nederland              Web:    http://www.RabobankICT.nl 




================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en 
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en 
de afzender direct te informeren door het bericht te retourneren. 
================================================
The information contained in this message may be confidential 
and is intended to be exclusively for the addressee. Should you 
receive this message unintentionally, please do not use the contents 
herein and notify the sender immediately by return e-mail.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NCsSe11804 for ietf-pkix-bks; Wed, 23 Oct 2002 05:54:28 -0700 (PDT)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NCsPW11798 for <[e-mail]>; Wed, 23 Oct 2002 05:54:26 -0700 (PDT)
Received: from Santesson ([192.168.101.118]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 23 Oct 2002 14:54:03 +0200
From: "Stefan Santesson" <[e-mail]>
To: "Aram Perez" <[e-mail]>, "PKIX" <[e-mail]>
Subject: RE: draft-ietf-pkix-logotypes-06.txt 
Date: Wed, 23 Oct 2002 14:54:03 +0200
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 V6.00.2600.0000
X-OriginalArrivalTime: 23 Oct 2002 12:54:03.0445 (UTC) FILETIME=[43B40E50:01C27A93]
Sender: [e-mail]
Precedence: 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 feel like having seen this before...

We have some peoples from the "industry" wanting to do something, and they
need support from a protocol.
The protocol standards group (PKIX) sometimes gets hooked up in a debate
whether this is a good thing to do or not, rather than trying to solve the
actual protocol issues.

Those saying that audio should go away now, need to be really sure that
there are absolutely no use for this in any sensible way. I wander if you
are?, or if you just can't see it from where you stand right now.

There is much less harm in supporting something that doesn't get deployed.

If audio is supported in the protocol in a well structured manner, and
nobody deploys it, then it's just dropped before it becomes standard.

I do believe though that the deployment industry is likely to find some use
for it.

/Stefan



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Aram Perez
> Sent: Wednesday, October 23, 2002 8:16 AM
> To: PKIX
> Subject: Re: draft-ietf-pkix-logotypes-06.txt
>
>
>
> Dean Povey wrote:
>
> >
> > <meta>I have been sitting on the sidelines in this debate for a bit,
> > because I thought it would all go away.  Since it appears not to have, I
> > feel obliged to vent :-) </meta>
> >
> >>> If a user using a client is blind, do we think he will be
> more confident by
> >>> hearing the gingle ? How does he make sure that the gingle
> really originates
> >>> from the logoype extension ?
> >>
> >> The jingle associated with a brand may well help a blind
> person select the
> >> most appropriate certificate.  Remember that this is one of the primary
> >> motives for the specification.
> >
> > I don't buy this.  Logos/trademarks are a piece of IP that most
> companies
> > invest a considerable amount of time and effort associating with their
> > brand.  Jingles are produced by advertising companies and
> generally have a
> > much shorter life time.  Sometimes companies license some existing music
> > for their jingle (as in Microsoft's Start Me Up campaign).
> Besides which
> > many of companies which matter most for this spec don't have
> recognisable
> > jingles.  Can you hum the RSA jingle Russ :-).  Does anyone know the
> > Verisign one.
>
> No I don't know those but I do know the Intel Inside one. I'm pretty sure
> that if you try using the Intel Inside jingle, you'll probably
> hear from one
> of their lawyers.
>
> >
> > Adding a jingle to a certificate means revoking it every time a company
> > changes its advertising.  This is clearly silly.  Whilst logos
> do change,
> > the cost of changing them is so high in most organisations that
> it seems to
> > be a rarer event (they last years rather than weeks). The whole point of
> > logotypes is to provide a mechanism to increase trust recognition in
> > certificates. Clearly, displaying a logo is not useful in
> improving trust
> > to a blind person, however there are other means available (e.g. the
> > browser software can read out the subject and issuer names to them).
> >
> > Notwithstanding the good intentions of the draft editors who
> have in many
> > ways produced an excellent document, I STRONGLY RECOMMEND that the whole
> > audio bit of the logotypes draft be deleted as a bad joke.
>
> And I thought it was a pretty good joke ;-)
>
> Regards,
> Aram Perez
>
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9N6GIb25471 for ietf-pkix-bks; Tue, 22 Oct 2002 23:16:18 -0700 (PDT)
Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9N6GHW25464 for <[e-mail]>; Tue, 22 Oct 2002 23:16:17 -0700 (PDT)
Received: from user-1121fjj.dsl.mindspring.com ([66.32.190.115] helo=[192.168.0.3]) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 184EoY-00047G-00 for [e-mail]; Tue, 22 Oct 2002 23:16:22 -0700
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Tue, 22 Oct 2002 23:16:20 -0700
Subject: Re: draft-ietf-pkix-logotypes-06.txt 
From: Aram Perez <[e-mail]>
To: PKIX <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
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>

Dean Povey wrote:

> 
> <meta>I have been sitting on the sidelines in this debate for a bit,
> because I thought it would all go away.  Since it appears not to have, I
> feel obliged to vent :-) </meta>
> 
>>> If a user using a client is blind, do we think he will be more confident by
>>> hearing the gingle ? How does he make sure that the gingle really originates
>>> from the logoype extension ?
>> 
>> The jingle associated with a brand may well help a blind person select the
>> most appropriate certificate.  Remember that this is one of the primary
>> motives for the specification.
> 
> I don't buy this.  Logos/trademarks are a piece of IP that most companies
> invest a considerable amount of time and effort associating with their
> brand.  Jingles are produced by advertising companies and generally have a
> much shorter life time.  Sometimes companies license some existing music
> for their jingle (as in Microsoft's Start Me Up campaign).  Besides which
> many of companies which matter most for this spec don't have recognisable
> jingles.  Can you hum the RSA jingle Russ :-).  Does anyone know the
> Verisign one.

No I don't know those but I do know the Intel Inside one. I'm pretty sure
that if you try using the Intel Inside jingle, you'll probably hear from one
of their lawyers.

> 
> Adding a jingle to a certificate means revoking it every time a company
> changes its advertising.  This is clearly silly.  Whilst logos do change,
> the cost of changing them is so high in most organisations that it seems to
> be a rarer event (they last years rather than weeks). The whole point of
> logotypes is to provide a mechanism to increase trust recognition in
> certificates. Clearly, displaying a logo is not useful in improving trust
> to a blind person, however there are other means available (e.g. the
> browser software can read out the subject and issuer names to them).
> 
> Notwithstanding the good intentions of the draft editors who have in many
> ways produced an excellent document, I STRONGLY RECOMMEND that the whole
> audio bit of the logotypes draft be deleted as a bad joke.

And I thought it was a pretty good joke ;-)

Regards,
Aram Perez



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9N5veX19464 for ietf-pkix-bks; Tue, 22 Oct 2002 22:57:40 -0700 (PDT)
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 g9N5vcW19459 for <[e-mail]>; Tue, 22 Oct 2002 22:57:38 -0700 (PDT)
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 g9N5v1Vw030141; Wed, 23 Oct 2002 18:57:01 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA180469; Wed, 23 Oct 2002 18:56:57 +1300 (NZDT) (sender [e-mail])
Date: Wed, 23 Oct 2002 18:56:57 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt
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>

Dean Povey <[e-mail]> writes:

>Besides which many of companies which matter most for this spec don't have
>recognisable jingles.  Can you hum the RSA jingle Russ :-).  Does anyone know
>the Verisign one.

Well, some companies have this sorted out.  I'm just waiting to hear
http://matt.gordon.smith.net/IBMSong/ibm.wav every time I read a cert with
Jonah...

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9N53Iq17595 for ietf-pkix-bks; Tue, 22 Oct 2002 22:03:18 -0700 (PDT)
Received: from osprey.wedgetail.com (starling.wedgetail.com [202.83.95.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9N53FW17590 for <[e-mail]>; Tue, 22 Oct 2002 22:03:16 -0700 (PDT)
Received: from coot.wedgetail.com (coot.wedgetail.com [10.10.10.4]) by osprey.wedgetail.com (8.12.5/8.12.5) with ESMTP id g9N52XNU010158; Wed, 23 Oct 2002 15:02:34 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh exmh 2.5 (2001-07-13) with nmh-1.0.4
From: Dean Povey <[e-mail]>
To: "Housley, Russ" <[e-mail]>
cc: Denis Pinkas <[e-mail]>, [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt 
In-reply-to: Your message of "Mon, 21 Oct 2002 13:57:51 -0400." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 23 Oct 2002 15:02:33 +1000
X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<meta>I have been sitting on the sidelines in this debate for a bit, 
because I thought it would all go away.  Since it appears not to have, I 
feel obliged to vent :-) </meta>

>>If a user using a client is blind, do we think he will be more confident by
>>hearing the gingle ? How does he make sure that the gingle really originates
>>from the logoype extension ?
>
>The jingle associated with a brand may well help a blind person select the 
>most appropriate certificate.  Remember that this is one of the primary 
>motives for the specification.

I don't buy this.  Logos/trademarks are a piece of IP that most companies
invest a considerable amount of time and effort associating with their
brand.  Jingles are produced by advertising companies and generally have a
much shorter life time.  Sometimes companies license some existing music
for their jingle (as in Microsoft's Start Me Up campaign).  Besides which
many of companies which matter most for this spec don't have recognisable
jingles.  Can you hum the RSA jingle Russ :-).  Does anyone know the
Verisign one.

Adding a jingle to a certificate means revoking it every time a company
changes its advertising.  This is clearly silly.  Whilst logos do change,
the cost of changing them is so high in most organisations that it seems to
be a rarer event (they last years rather than weeks). The whole point of
logotypes is to provide a mechanism to increase trust recognition in
certificates. Clearly, displaying a logo is not useful in improving trust
to a blind person, however there are other means available (e.g. the
browser software can read out the subject and issuer names to them).

Notwithstanding the good intentions of the draft editors who have in many
ways produced an excellent document, I STRONGLY RECOMMEND that the whole
audio bit of the logotypes draft be deleted as a bad joke.

-- 
Dean Povey,             |em: [e-mail]|JCSI: Java security toolkit
Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C PKI toolkit
Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C SSL toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML Signatures 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9N0LeY00725 for ietf-pkix-bks; Tue, 22 Oct 2002 17:21:40 -0700 (PDT)
Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9N0LdW00716 for <[e-mail]>; Tue, 22 Oct 2002 17:21:39 -0700 (PDT)
Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id g9N0Jkp02483; Wed, 23 Oct 2002 00:19:46 GMT
Received: from nwssmail01.jf.intel.com (nwssmail01.jf.intel.com [10.7.171.40]) by talaria.jf.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with ESMTP id g9N0AgY26503; Wed, 23 Oct 2002 00:10:42 GMT
Received: from cellison-mobl (cellison-mobl.jf.intel.com [134.134.12.97]) by nwssmail01.jf.intel.com (8.11.6/8.11.4) with SMTP id g9N0NX312407; Tue, 22 Oct 2002 17:23:33 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 22 Oct 2002 17:21:34 -0700
To: <[e-mail]>, "Carl Ellison" <[e-mail]>
From: Carl Ellison <[e-mail]>
Subject: Re: 2003 PKI Research Workshop CFP
Cc: "Carl Ellison" <[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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 11:13 AM 10/22/2002 +0200, Anders Rundgren wrote:
>Thanx Carl,
>
>I assume that you refer to the TAXI paper?
>http://www.cs.dartmouth.edu/~pki02/Hallam-Baker/paper.pdf

That was one, but I was referring to the whole program.


 - Carl

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1

iQA/AwUBPbWC3cxqBGb+WvJAEQIiXwCeKNeHQ4qQW5oV4dZ4Mebkbt+PESYAnjBn
t01H3Mx8egBu8eJ1KA058qK5
=6DxS
-----END PGP SIGNATURE-----


+--------------------------------------------------------+
|Carl Ellison      Intel Labs        E: [e-mail] |
|2111 NE 25th Ave                    T: [phone]  |
|Hillsboro OR 97124                  F: [phone]  |
|PGP Key ID: 0xFE5AF240                                  |
|  1FDB 2770 08D7 8540 E157  AAB4 CC6A 0466 FE5A F240    |
+--------------------------------------------------------+


+--------------------------------------------------------+
|Carl Ellison      Intel Labs        E: [e-mail] |
|2111 NE 25th Ave                    T: [phone]  |
|Hillsboro OR 97124                  F: [phone]  |
|PGP Key ID: 0xFE5AF240                                  |
|  1FDB 2770 08D7 8540 E157  AAB4 CC6A 0466 FE5A F240    |
+--------------------------------------------------------+


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9MJx8m19328 for ietf-pkix-bks; Tue, 22 Oct 2002 12:59:08 -0700 (PDT)
Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9MJx3W19322 for <[e-mail]>; Tue, 22 Oct 2002 12:59:03 -0700 (PDT)
Received: from VON-WIN2K-BOX (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id OAA48548; Tue, 22 Oct 2002 14:58:55 -0500
From: Von Welch <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 22 Oct 2002 14:56:36 -0500
To: Kefeng Chen <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-proxy-03.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter (Windows [3])" XEmacs Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kefeng Chen writes (13:54 October 22, 2002):
 > 
 > How come this draft does not have section 4?
 > It goes from section 3 to section 5.

The section numbers >3 got shifted by 1. All the text is correct but
section 5 should be section 4, 6 should be 5, etc. I'm getting a
corrected copy posted.

Sorry for the confusion,

Von

 > 
 > -----Original Message-----
 > From: [e-mail] [mailto:[e-mail]]
 > Sent: Tuesday, October 22, 2002 7:41 AM
 > Cc: [e-mail]
 > Subject: I-D ACTION:draft-ietf-pkix-proxy-03.txt
 > 
 > 
 > 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 Proxy 
 >                           Certificate Profile
 > 	Author(s)	: S. Tuecke et al.
 > 	Filename	: draft-ietf-pkix-proxy-03.txt
 > 	Pages		: 44
 > 	Date		: 2002-10-21
 > 	
 > This document forms a certificate profile for Proxy 
 > Certificates, based on X.509 PKI certificates as defined 
 > in RFC 3280, for use in the Internet.  The term Proxy 
 > Certificate is used to describe a certificate that is 
 > derived from, and signed by, a normal X.509 Public Key End 
 > Entity Certificate or by another Proxy Certificate for the 
 > purpose of providing restricted impersonation within a PKI 
 > based authentication system.
 > 
 > A URL for this Internet-Draft is:
 > http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-03.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-proxy-03.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-proxy-03.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 g9MHw6w12523 for ietf-pkix-bks; Tue, 22 Oct 2002 10:58:06 -0700 (PDT)
Received: from atlgeo3.geotrust.com (atlgeo3.geotrust.com [66.21.21.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9MHw5W12519 for <[e-mail]>; Tue, 22 Oct 2002 10:58:05 -0700 (PDT)
Received: by atlgeo3.atlanta.geotrust.com with Internet Mail Service (5.5.2653.19) id <K49J059X>; Tue, 22 Oct 2002 13:54:56 -0400
Message-ID: <[e-mail]>
From: Kefeng Chen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-proxy-03.txt
Date: Tue, 22 Oct 2002 13:54:56 -0400
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>

How come this draft does not have section 4?
It goes from section 3 to section 5.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Tuesday, October 22, 2002 7:41 AM
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-proxy-03.txt


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 Proxy 
                          Certificate Profile
	Author(s)	: S. Tuecke et al.
	Filename	: draft-ietf-pkix-proxy-03.txt
	Pages		: 44
	Date		: 2002-10-21
	
This document forms a certificate profile for Proxy 
Certificates, based on X.509 PKI certificates as defined 
in RFC 3280, for use in the Internet.  The term Proxy 
Certificate is used to describe a certificate that is 
derived from, and signed by, a normal X.509 Public Key End 
Entity Certificate or by another Proxy Certificate for the 
purpose of providing restricted impersonation within a PKI 
based authentication system.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-03.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-proxy-03.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-proxy-03.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 g9MHRG609786 for ietf-pkix-bks; Tue, 22 Oct 2002 10:27:16 -0700 (PDT)
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 g9MHREW09781 for <[e-mail]>; Tue, 22 Oct 2002 10:27:14 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 22 Oct 2002 17:27:16 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 NAA12509 for <[e-mail]>; Tue, 22 Oct 2002 13:27:15 -0400 (EDT)
Received: from exeu00.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g9MHOcD19490 for <[e-mail]>; Tue, 22 Oct 2002 13:24:39 -0400 (EDT)
Received: by exeu00.eu.rsa.net with Internet Mail Service (5.5.2653.19) id <VA2P2TMK>; Tue, 22 Oct 2002 18:31:10 +0100
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.37]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWDRRL; Tue, 22 Oct 2002 13:26:53 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 22 Oct 2002 13:19:04 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Fwd: PKI Forum
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 thought that the members of the PKIX WG would find this interesting....

Russ

 > OASIS is pleased to announce that on 1 November, PKI Forum will
 > become the newest OASIS Member Section.
 >
 > PKI Forum (http://www.pkiforum.org/) was established in 1999 to foster
 > support for standards-based, interoperable public-key infrastructure
 > (PKI) as a foundation for secure transactions in e-business
 > applications. PKI Forum brings organizations together in a neutral
 > setting to increase knowledge about PKI and to initiate studies and
 > demonstration projects to show the value of interoperable PKI and
 > PKI-based solutions. The group collaborates and cooperates with
 > appropriate standards and testing bodies to promote the adoption of
 > open industry standards.
 >
 > OASIS advances the adoption of a growing list of security
 > specifications, including WS-Security, SAML, XACML, Rights Language,
 > SPML, XCBF--and now, PKI.
 >
 > On 5-7 November, the PKI Forum will hold their quarterly conference in
 > Dallas. See http://www.pkiforum.org/meetings/20021105/ for
 > details and registration.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9MGjkI07531 for ietf-pkix-bks; Tue, 22 Oct 2002 09:45:46 -0700 (PDT)
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 g9MGjiW07523 for <[e-mail]>; Tue, 22 Oct 2002 09:45:44 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 22 Oct 2002 16:45:46 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 MAA08089 for <[e-mail]>; Tue, 22 Oct 2002 12:45:45 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g9MGh9B14419 for <[e-mail]>; Tue, 22 Oct 2002 12:43:09 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWDQYX>; Tue, 22 Oct 2002 12:45:43 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.37]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWDQY4; Tue, 22 Oct 2002 12:45:36 -0400
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: Tue, 22 Oct 2002 12:45:27 -0400
Subject: Re: draft-ietf-pkix-logotypes-06.txt
In-Reply-To: <[e-mail]>
References: <[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>

Denis:

As you said in your last note to the list, PKIX is not doing standards for 
the MMI.

Russ

At 09:47 AM 10/22/2002 +0200, Denis Pinkas wrote:
>Russ,
>
>(...)
>
> > The jingle associated with a brand may well help a blind person select the
> > most appropriate certificate.  Remember that this is one of the primary
> > motives for the specification.
>
>  ... and for this, the blind person will certainly blindely click somewhere
>on the screen ...
>
>Denis
>
> > Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9MGdfP06687 for ietf-pkix-bks; Tue, 22 Oct 2002 09:39:41 -0700 (PDT)
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 g9MGdeW06680 for <[e-mail]>; Tue, 22 Oct 2002 09:39:40 -0700 (PDT)
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 JAA08569; Tue, 22 Oct 2002 09:39:02 -0700 (PDT)
Received: from [128.115.222.68] (HELO catalyst2b.llnl.gov) by poptop.llnl.gov (CommuniGate Pro SMTP 3.5.9) with ESMTP id 4203173; Tue, 22 Oct 2002 09:39:02 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 22 Oct 2002 09:42:37 -0700
To: Denis Pinkas <[e-mail]>, "Housley, Russ" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: draft-ietf-pkix-logotypes-06.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[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 09:47 AM 10/22/2002 +0200, Denis Pinkas wrote:

>Russ,
>
>(...)
>
> > The jingle associated with a brand may well help a blind person select the
> > most appropriate certificate.  Remember that this is one of the primary
> > motives for the specification.
>
>  ... and for this, the blind person will certainly blindely click somewhere
>on the screen ...
>
>Denis


Voice recognition?


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 g9MBhAW16172 for ietf-pkix-bks; Tue, 22 Oct 2002 04:43:10 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9MBh9W16168 for <[e-mail]>; Tue, 22 Oct 2002 04:43:09 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12281; Tue, 22 Oct 2002 07:40:54 -0400 (EDT)
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-proxy-03.txt
Date: Tue, 22 Oct 2002 07:40:53 -0400
Sender: [e-mail]
Precedence: 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 Proxy 
                          Certificate Profile
	Author(s)	: S. Tuecke et al.
	Filename	: draft-ietf-pkix-proxy-03.txt
	Pages		: 44
	Date		: 2002-10-21
	
This document forms a certificate profile for Proxy 
Certificates, based on X.509 PKI certificates as defined 
in RFC 3280, for use in the Internet.  The term Proxy 
Certificate is used to describe a certificate that is 
derived from, and signed by, a normal X.509 Public Key End 
Entity Certificate or by another Proxy Certificate for the 
purpose of providing restricted impersonation within a PKI 
based authentication system.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-03.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-proxy-03.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-proxy-03.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-proxy-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-proxy-03.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 g9M9Lsp07414 for ietf-pkix-bks; Tue, 22 Oct 2002 02:21:54 -0700 (PDT)
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 g9M9LqW07410 for <[e-mail]>; Tue, 22 Oct 2002 02:21:52 -0700 (PDT)
Received: from arport ([62.119.75.13]) by blooper.utfors.se (8.12.6/8.12.6) with SMTP id g9M9Le4d018135; Tue, 22 Oct 2002 11:21:40 +0200 (MEST)
Message-ID: <018f01c279ab$6f5364e0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Carl Ellison" <[e-mail]>
Cc: <[e-mail]>, "Carl Ellison" <[e-mail]>, "Carl Ellison" <[e-mail]>
References: <3.0.5.32.20021019094654.01b6f430@localhost> <3.0.5.32.20021022012359.01e46308@localhost>
Subject: Re: 2003 PKI Research Workshop CFP
Date: Tue, 22 Oct 2002 11:13:03 +0200
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 Carl,

I assume that you refer to the TAXI paper?
http://www.cs.dartmouth.edu/~pki02/Hallam-Baker/paper.pdf

I have two items to submit to this mess if you want.

1. The "Bank model" PKI
2. Plug-and-Play Certificates

Both are "innovative" in the sense that they formalize the
de-facto [implicit] standard that many PKI practitioners use
but are too afraid to talk about.  Or are not allowed to,
here referring to banks...

cheers,
Anders R


----- Original Message ----- 
From: "Carl Ellison" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>; "Carl Ellison" <[e-mail]>; "Carl Ellison" <[e-mail]>
Sent: Tuesday, October 22, 2002 10:23
Subject: Re: 2003 PKI Research Workshop CFP


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anders,

thank you for your comments.  They were both refreshing and
informative.

Have you read the papers from this year's (2002) PKI Workshop (link
in my original e-mail)?  You might take a look.  We had a fair amount
of good work reported and that might take the edge off your
frustration.  I am not trying to diminish the problems with current
PKI deployments or even the path that some developers are taking. 
Rather, I see signs of hope for the phoenix that will arise from the
inevitable ashes of those developments currently spinning out of
control. :)

 - Carl


At 12:16 PM 10/20/2002 +0200, Anders Rundgren wrote:
>>The Internet2 PKI Research activity is based on the premise that a
>>great deal of research is needed in PK-authenticated authorization
>>and control systems and that research is not going to come out of
>>current efforts among PKI vendors and standards bodies, active
>>though they may be.
>
>Carl,
>I could not agree more.   Although my perception is that many of
>the problems can be concluded as follows.

[snip]


-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBPbULH3PxfjyW5ytxEQJuHwCdF3Ln0Ge0wAA4G8YyphEED7X0TbQAoIFl
9vuZPbWpeor8OHO5wLquy9Hz
=RHq5
-----END PGP SIGNATURE-----


+------------------------------------------------------------------+
|Carl M. Ellison         [e-mail]     http://world.std.com/~cme |
|    PGP: 75C5 1814 C3E3 AAA7 3F31  47B9 73F1 7E3C 96E7 2B71       |
+---Officer, arrest that man. He's whistling a copyrighted song.---+



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9M8Nvn27336 for ietf-pkix-bks; Tue, 22 Oct 2002 01:23:57 -0700 (PDT)
Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9M8NuW27329 for <[e-mail]>; Tue, 22 Oct 2002 01:23:56 -0700 (PDT)
Received: from p4 ([12.224.63.6]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20021022082351.PHVL18217.rwcrmhc51.attbi.com@p4>; Tue, 22 Oct 2002 08:23:51 +0000
Message-Id: <3.0.5.32.20021022012359.01e46308@localhost>
X-Sender: cme@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 22 Oct 2002 01:23:59 -0700
To: "Anders Rundgren" <[e-mail]>
From: Carl Ellison <[e-mail]>
Subject: Re: 2003 PKI Research Workshop CFP
Cc: <[e-mail]>, "Carl Ellison" <[e-mail]>, Carl Ellison <[e-mail]>
In-Reply-To: <002601c27821$cced8fd0$0500a8c0@arport>
References: <3.0.5.32.20021019094654.01b6f430@localhost>
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anders,

	thank you for your comments.  They were both refreshing and
informative.

	Have you read the papers from this year's (2002) PKI Workshop (link
in my original e-mail)?  You might take a look.  We had a fair amount
of good work reported and that might take the edge off your
frustration.  I am not trying to diminish the problems with current
PKI deployments or even the path that some developers are taking. 
Rather, I see signs of hope for the phoenix that will arise from the
inevitable ashes of those developments currently spinning out of
control. :)

 - Carl


At 12:16 PM 10/20/2002 +0200, Anders Rundgren wrote:
>>The Internet2 PKI Research activity is based on the premise that a
>>great deal of research is needed in PK-authenticated authorization
>>and control systems and that research is not going to come out of
>>current efforts among PKI vendors and standards bodies, active
>>though they may be.
>
>Carl,
>I could not agree more.   Although my perception is that many of
>the problems can be concluded as follows.

[snip]


-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBPbULH3PxfjyW5ytxEQJuHwCdF3Ln0Ge0wAA4G8YyphEED7X0TbQAoIFl
9vuZPbWpeor8OHO5wLquy9Hz
=RHq5
-----END PGP SIGNATURE-----


+------------------------------------------------------------------+
|Carl M. Ellison         [e-mail]     http://world.std.com/~cme |
|    PGP: 75C5 1814 C3E3 AAA7 3F31  47B9 73F1 7E3C 96E7 2B71       |
+---Officer, arrest that man. He's whistling a copyrighted song.---+


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9M7lNJ19589 for ietf-pkix-bks; Tue, 22 Oct 2002 00:47:23 -0700 (PDT)
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 g9M7lLW19578 for <[e-mail]>; Tue, 22 Oct 2002 00:47:21 -0700 (PDT)
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 JAA11418; Tue, 22 Oct 2002 09:47:39 +0200
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 JAA18906; Tue, 22 Oct 2002 09:47:24 +0200
Message-ID: <[e-mail]>
Date: Tue, 22 Oct 2002 09:47:18 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt
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>

Russ,

(...)

> The jingle associated with a brand may well help a blind person select the
> most appropriate certificate.  Remember that this is one of the primary
> motives for the specification.

 ... and for this, the blind person will certainly blindely click somewhere
on the screen ...

Denis

> Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9M7kEQ19274 for ietf-pkix-bks; Tue, 22 Oct 2002 00:46:14 -0700 (PDT)
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 g9M7kDW19267 for <[e-mail]>; Tue, 22 Oct 2002 00:46:13 -0700 (PDT)
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 JAA05556; Tue, 22 Oct 2002 09:46:30 +0200
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 JAA24076; Tue, 22 Oct 2002 09:46:16 +0200
Message-ID: <[e-mail]>
Date: Tue, 22 Oct 2002 09:46:10 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: David Cross <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt
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>

David,

The issue is about the *presence* of the extension in the certificate, 
not about the *display* of the extension.

The proposed sentence is: 
"Logotypes MAY be present in any type of certificate".

Your argumentation is whether or not a logotype, if present in a
certificate, shall be displayed.

Since it is a MMI problem and not a protocol issue, it is quite hard to
place requirements on MMIs.

I believe that logotypes MAY be present in any type of certificate. 
Then, it is not because an extension is present that it should always 
be displayed.

I would have no problem to add text to state recommendations for display.

Denis


> Denis:
> 
> I my opinion, I am afraid that the presence of logotypes in additonal
> types of certificates will imply that clients should display such logos
> when path validation or revocation check is performed.  For example,
> every time a mail message is processed and signature check performed,
> should the mail client display the logo for the OCSP responder to the
> end user?  In that example, I would argue strongly that we have extended
> from the useful scenario of enabling simpler certificate selection for
> end users to an intolerable user experience.
> 
> I don't have any strong technical argument for the limitation, just a
> practical argument for implementors.
> 
> Regards,
> 
> David B. Cross
> 
> David,
> 
> > Denis:
> >
> > In general, I agree with most of your suggestions.  Thanks for taking
> > the time to perform a thorough review - I apologize for the delay in
> > response.  I do however, disagree with suggestion #12.  I disagree on
> > the basis that a relying party would want oir need to view logos for
> > certificates used in path and revocation processing.
> 
> My proposed phrasing is not in contradiction with your above statement.
> So I still do not understand why there should be any limitation. Could
> you argue and/or provide examples ?
> 
> Denis
> 
> 
> > 12. Page 11. Section 5. Type of certificates
> >
> >    Logotypes MAY be present in three types of certificates:
> >
> >      - CA certificates
> >      - End-entity certificates
> >      - Attribute certificates
> >
> > Why is there such a limitation ? CRL Issuers, OCSP responders or TSUs
> > may have logotypes present in their certificates.
> >
> > Replace with : "Logotypes MAY be present in any type of certificate".
> >
> > Regards,
> >
> > David B. Cross
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Tuesday, October 15, 2002 12:47 AM
> > To: Housley, Russ
> > Cc: [e-mail]
> > Subject: Re: draft-ietf-pkix-logotypes-06.txt
> >
> > Russ,
> >
> > > We just posted an update to the logotypes draft.  There are two
> > > primary changes from the previous version.  First, we tried to be
> > > more
> >
> > > clear about what is mandatory to implement and what is not.
> >
> > This is not yet clear enough. See below.
> >
> > > Second, we added support for more than one hash function without
> > > having to repeat a lot of data.
> > >
> > > The loudest objections (as opposed to jokes) came from Microsoft.
> > > Based on discussions with Trevor Freeman, I believe that Microsoft
> > > can
> >
> > > accept this version.
> > >
> > > We are still in Working Group Last Call.....
> >
> > Since we are still in Working Group Last Call, here are my 12 comments
> 
> > on that document.
> >
> > 1. Page 6. Section 3. Logotype data
> >
> > "Implementations MUST support image data; however, support for audio
> > data is OPTIONAL." Audio is a good joke, in the same way, as
> > pheromones. We are supposed to deal with serious documents. Please
> > delete.
> >
> > 2. Page 7. Section 4.1 Extension format
> >
> > "Clients MUST support both direct and indirect addressing."
> >
> > I disagree. If an end-user certificate is included in a signature, it
> > may be interesting to display the logotype even if the terminal is
> > off-line. Indirect addressing would mandate an on-line connection.
> >
> > Replace with:
> >
> > "Clients claiming to conform with this document SHALL support direct
> > addressing. Clients MAY also support indirect addressing."
> >
> > 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".
> >
> > 4. Page 8. Section 4.1.
> >
> >       LogotypeData ::= SEQUENCE {
> >          image           SEQUENCE OF LogotypeImage     OPTIONAL,
> >          audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }
> >
> > Since audio support should be suppressed, replace with:
> >
> >       LogotypeData ::= SEQUENCE OF LogotypeImage
> >
> > 5. Page 7. Section 4.1.
> >
> > We have:
> >
> >       communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
> >
> >       LogotypeInfo ::= CHOICE {
> >          direct          [0] LogotypeData,
> >          indirect        [1] LogotypeReference }
> >
> >       LogotypeData ::= SEQUENCE {
> >          image           SEQUENCE OF LogotypeImage OPTIONAL,
> >
> > No explanations are given on the text about what to do for a client
> > when there is more than one LogotypeImage present in a communityLogo.
> >
> > First of all, a communityLogo may contain more than one logo which
> > belongs to one or more communities. However the client has no way to
> > know whether the LogotypeData includes different versions from the
> > same logo (e.g. in black and white or in color) or different logos.
> >
> > The ASN.1 structure is not adapted to make that difference. Therefore
> > it is proposed to modify the ASN.1 syntax along the following way:
> >
> >          communityLogos   [0] EXPLICIT CommunityLogos OPTIONAL,
> >
> > CommunityLogos ::= SEQUENCE OF CommunityLogo
> >
> > CommunityLogo ::= LogotypeInfo
> >
> > In this way, clients can make their best efforts to support only one
> > instance of version for each CommunityLogo.
> >
> > 6. Page 9. Section 4.1.
> >
> >       LogotypeImageInfo ::= SEQUENCE {
> >          fileSize        INTEGER,  -- In octets
> >          xSize           INTEGER,  -- In pixels
> >          ySize           INTEGER,  -- In pixels
> >          numColors       INTEGER } -- In bits
> >
> > Text is missing to explain this structure. How is a grey scale
> > indicated for jpeg and for gif ???
> >
> > 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."
> >
> > 8. Page 9. Section 4.1.
> >
> >       LogotypeImageInfo ::= SEQUENCE {
> >          fileSize        INTEGER,  -- In octets
> >          xSize           INTEGER,  -- In pixels
> >          ySize           INTEGER,  -- In pixels
> >          numColors       INTEGER } -- In bits
> >
> > It would also be appropriate to say what to do when the image is in
> > color and that the client has no color display available. No display
> > at all ? Conversion into grey scale using which kind of transposition
> > ?
> >
> > 9. Page 9. Section 4.1. Since audio is a joke, text and ASN.1 about
> > audio should be deleted.
> >
> > 10. Page 9. Section 4.1. The text states:
> >
> > "Implementations MUST support both the JPEG and GIF image formats
> > (with MIME types of "image/jpeg" and "image/gif", respectively)"
> >
> > I would guess that Animated GIF should not be supported. Could we say
> > it ?
> >
> > 11. Page 10. Section 4.1.
> >
> >       Community Logotype. If communityLogo is present, the logotype
> MUST
> >       represent the community to which the certificate issuer is
> >       affiliated. The communityLogo MAY be present in an end entity
> >       certificate, a CA certificate or an attribute certificate.
> >
> > A certificate issuer may belong to more than one community. Replace:
> > "the community " by :"the community or the communities".
> >
> > 12. Page 11. Section 5. Type of certificates
> >
> >    Logotypes MAY be present in three types of certificates:
> >
> >      - CA certificates
> >      - End-entity certificates
> >      - Attribute certificates
> >
> > Why is there such a limitation ? CRL Issuers, OCSP responders or TSUs
> > may have logotypes present in their certificates.
> >
> > Replace with : "Logotypes MAY be present in any type of certificate".
> >
> > Denis
> >
> > >
> > > Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LL96h17197 for ietf-pkix-bks; Mon, 21 Oct 2002 14:09:06 -0700 (PDT)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9LL93W17187 for <[e-mail]>; Mon, 21 Oct 2002 14:09:03 -0700 (PDT)
Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 21 Oct 2002 14:09:00 -0700
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 21 Oct 2002 14:08:48 -0700
Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 21 Oct 2002 14:09:02 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 21 Oct 2002 14:08:48 -0700
Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 21 Oct 2002 14:08:48 -0700
Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Mon, 21 Oct 2002 14:08:47 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6771.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-logotypes-06.txt
Date: Mon, 21 Oct 2002 14:08:47 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-logotypes-06.txt
Thread-Index: AcJ5GK6c4Pp/xzlgTL29CNhJEiZAYAAK1dxg
From: "Trevor Freeman" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, "David Cross" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 21 Oct 2002 21:08:47.0876 (UTC) FILETIME=[0C2D4440:01C27946]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9LL95W17192
Sender: [e-mail]
Precedence: 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 presence of the logotype extension sets no more a precedence that
having a subject alternate name extension. When given multiple name
forms in a certificate PK clients make a choice on which names to
display (if any) given the context of the applications using the
certificate. Email clients tend to use the RFC822 name, browsers the DNS
name. RFC3039 is another example where additional information is
available in an extension and I don't see any great problem with clients
feeling compelled to display that information if they don't want to.
Where a developer feeds this information makes sense for their
application - I am sure this will get adopted. Developers will not spend
time on things they don't consider important.

-----Original Message-----
From: Peter Gutmann [mailto:[e-mail]] 
Sent: Monday, October 21, 2002 8:39 AM
To: [e-mail]; David Cross
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-logotypes-06.txt


"David Cross" <[e-mail]> writes:

>I my opinion, I am afraid that the presence of logotypes in additonal
types
>of certificates will imply that clients should display such logos when
path
>validation or revocation check is performed.  For example, every time a
mail
>message is processed and signature check performed, should the mail
client
>display the logo for the OCSP responder to the end user?  In that
example, I
>would argue strongly that we have extended from the useful scenario of
>enabling simpler certificate selection for end users to an intolerable
user
>experience.

As long as implementors follow the standard tradition of adding a "Don't
show
me this again" checkbox (checked by default) to the display, we'll be
OK.

This probably doesn't make the addition of logotypes too useful though,
since
you'll only see them the first time the software is run.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LJuOB12823 for ietf-pkix-bks; Mon, 21 Oct 2002 12:56:24 -0700 (PDT)
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 g9LJuMW12819 for <[e-mail]>; Mon, 21 Oct 2002 12:56:22 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Oct 2002 19:56:25 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 PAA15129 for <[e-mail]>; Mon, 21 Oct 2002 15:56:24 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g9LJrlp03449 for <[e-mail]>; Mon, 21 Oct 2002 15:53:47 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWDDSR>; Mon, 21 Oct 2002 15:56:18 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.11]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWDDS3; Mon, 21 Oct 2002 15:56:15 -0400
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, 21 Oct 2002 15:45:45 -0400
Subject: Re: draft-ietf-pkix-logotypes-06.txt
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>

Denis:

>Since we are still in Working Group Last Call, here are my 12 comments on
>that document.
>
>1. Page 6. Section 3. Logotype data
>
>"Implementations MUST support image data; however, support for audio data is
>OPTIONAL." Audio is a good joke, in the same way, as pheromones. We are
>supposed to deal with serious documents. Please delete.

I belive that the response from Tom Gindin shows that there is support for 
audio in support if disabled users.  I believe that the document is clear 
that the support is OPTIONAL.


>2. Page 7. Section 4.1 Extension format
>
>"Clients MUST support both direct and indirect addressing."
>
>I disagree. If an end-user certificate is included in a signature, it may be
>interesting to display the logotype even if the terminal is off-line.
>Indirect addressing would mandate an on-line connection.
>
>Replace with:
>
>"Clients claiming to conform with this document SHALL support direct
>addressing. Clients MAY also support indirect addressing."

We have already had a dialogue on this point.  I hope it is resolved.


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

I will add a similar sentence to the second paragraph of section 6.  The 
paragraph now says:

    After a certification path is successfully validated, the replying
    party trusts the information that the CA includes in the certificate,
    including any certificate extensions. The client software can choose
    to make use of such information, or the client software can ignore
    it. 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. Current standards
    do not provide any mechanism for cross-certifying CAs to constrain
    subordinate CAs from including private extensions (see the security
    considerations section).


>4. Page 8. Section 4.1.
>
>       LogotypeData ::= SEQUENCE {
>          image           SEQUENCE OF LogotypeImage     OPTIONAL,
>          audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }
>
>Since audio support should be suppressed, replace with:
>
>       LogotypeData ::= SEQUENCE OF LogotypeImage

This is related to comment 1.  No change will be made.


>5. Page 7. Section 4.1.
>
>We have:
>
>       communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
>
>       LogotypeInfo ::= CHOICE {
>          direct          [0] LogotypeData,
>          indirect        [1] LogotypeReference }
>
>       LogotypeData ::= SEQUENCE {
>          image           SEQUENCE OF LogotypeImage OPTIONAL,
>
>No explanations are given on the text about what to do for a client when
>there is more than one LogotypeImage present in a communityLogo.
>
>First of all, a communityLogo may contain more than one logo which belongs
>to one or more communities. However the client has no way to know whether
>the LogotypeData includes different versions from the same logo (e.g. in
>black and white or in color) or different logos.

This is not supported.  The certificate may only include one image.  That 
image could be a composite of many different logos, if appropriate.  We 
discussed this face-to-face in Yokohama.  Discussion with people what 
develop graphical interfaces do not think it is a good idea to allow this 
complexity.  Too many images will confuse the user.  When it is appropriate 
to include several community logos, they must be combined into one image to 
ensure that they are consistently displayed.  If this is not done, each 
client will render the images differently...


>6. Page 9. Section 4.1.
>
>       LogotypeImageInfo ::= SEQUENCE {
>          fileSize        INTEGER,  -- In octets
>          xSize           INTEGER,  -- In pixels
>          ySize           INTEGER,  -- In pixels
>          numColors       INTEGER } -- In bits
>
>Text is missing to explain this structure. How is a grey scale indicated for
>jpeg and for gif ???

Do you have a recommendation?


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

We have tried to avoid such a statement.  Instead we allow the inclusion of 
the same image at many different resolutions so that the client can select 
the best fit.  This is also the reason that we use MIME types to name the 
format.  It allows the greatest flexibility.


>8. Page 9. Section 4.1.
>
>       LogotypeImageInfo ::= SEQUENCE {
>          fileSize        INTEGER,  -- In octets
>          xSize           INTEGER,  -- In pixels
>          ySize           INTEGER,  -- In pixels
>          numColors       INTEGER } -- In bits
>
>It would also be appropriate to say what to do when the image is in color
>and that the client has no color display available. No display at all ?
>Conversion into grey scale using which kind of transposition ?

The client is always allowed to ignore the logotype altogether.  The 
stronger language added in response to your third comment makes this clear.


>9. Page 9. Section 4.1. Since audio is a joke, text and ASN.1 about audio
>should be deleted.

Again, related to your first comment. No change.


>10. Page 9. Section 4.1. The text states:
>
>"Implementations MUST support both the JPEG and GIF image formats (with MIME
>types of "image/jpeg" and "image/gif", respectively)"
>
>I would guess that Animated GIF should not be supported. Could we say it ?

Okay.  That paragraph now reads:

    A MIME type is used to specify the format of the file containing the
    logotype data. Implementations MUST support both the JPEG and GIF
    image formats (with MIME types of "image/jpeg" and "image/gif",
    respectively). Animated images SHOULD NOT be used. Implementations
    that support audio MUST support the MP3 audio format (with a MIME
    type of "audio/mpeg").


>11. Page 10. Section 4.1.
>
>       Community Logotype. If communityLogo is present, the logotype MUST
>       represent the community to which the certificate issuer is
>       affiliated. The communityLogo MAY be present in an end entity
>       certificate, a CA certificate or an attribute certificate.
>
>A certificate issuer may belong to more than one community. Replace: "the
>community " by :"the community or the communities".

This is already discussed in response to comment 5.  No change.


>12. Page 11. Section 5. Type of certificates
>
>    Logotypes MAY be present in three types of certificates:
>
>      - CA certificates
>      - End-entity certificates
>      - Attribute certificates
>
>Why is there such a limitation ? CRL Issuers, OCSP responders or TSUs may
>have logotypes present in their certificates.
>
>Replace with : "Logotypes MAY be present in any type of certificate".

David Cross spoke against this suggestion.

Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LJuLN12816 for ietf-pkix-bks; Mon, 21 Oct 2002 12:56:21 -0700 (PDT)
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 g9LJuJW12809 for <[e-mail]>; Mon, 21 Oct 2002 12:56:19 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Oct 2002 19:56:22 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 PAA15109 for <[e-mail]>; Mon, 21 Oct 2002 15:56:22 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g9LJrip03430 for <[e-mail]>; Mon, 21 Oct 2002 15:53:44 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWDDST>; Mon, 21 Oct 2002 15:56:18 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.11]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWDDSN; Mon, 21 Oct 2002 15:56:15 -0400
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, 21 Oct 2002 13:57:51 -0400
Subject: Re: draft-ietf-pkix-logotypes-06.txt
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>

Denis:

>This is an answer to the first argument raised.
>
> >       One reason why audio might be desired would be to allow the nearest
> > available equivalent to logotype functionality.  This might be motivated by
> > one of several pieces of US legislation (the Americans with Disabilities
> > Act and Section 508).  If this is the case, the specification should
> > probably reflect that audio is a backup, especially for individuals who
> > cannot benefit from video.
>
>One of the key issue is to understand the properties that a client compliant
>with this specification must support. Currently we have:
>
>"Compliant applications MUST display more just one (or none) of the images
>*and* play just one (or none) of the audio sequences at the same time."
>The *AND* is not acceptable.
>
>First of all, if audio is going to be supported, then separate requirements
>should be made so that client compliant with requirements fo image
>representation, can ignore compliance requirements for audio representation.
>
>Now, do we want to promote the use of gingles for VISA, AMEX, MasterCard ?
>They would need to invent them.
>
>If a user using a client is blind, do we think he will be more confident by
>hearing the gingle ? How does he make sure that the gingle really originates
>from the logoype extension ?

The jingle associated with a brand may well help a blind person select the 
most appropriate certificate.  Remember that this is one of the primary 
motives for the specification.

Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LJuL612815 for ietf-pkix-bks; Mon, 21 Oct 2002 12:56:21 -0700 (PDT)
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 g9LJuJW12806 for <[e-mail]>; Mon, 21 Oct 2002 12:56:19 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Oct 2002 19:56: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 PAA15102 for <[e-mail]>; Mon, 21 Oct 2002 15:56:21 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g9LJria03429 for <[e-mail]>; Mon, 21 Oct 2002 15:53:44 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWDDSS>; Mon, 21 Oct 2002 15:56:18 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.11]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWDDSL; Mon, 21 Oct 2002 15:56:14 -0400
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, 21 Oct 2002 13:54:00 -0400
Subject: Re: draft-ietf-pkix-logotypes-06.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
Sender: [e-mail]
Precedence: 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 know that you are very busy, but I think that you have not given the
> > document a fair reading.  I am not saying that the document is perfect;
> > however, the information that you request is in the document.
> >
> > It says:
> >
> >     Both direct and indirect addressing accommodate alternative URIs to
> >     obtain exactly the same item. This opportunity for replication is
> >     intended to improve availability. Therefore, if a client is unable to
> >     fetch the item form one URI, the client SHOULD try another URI in the
> >     sequence.
> >
> > And, it says:
> >
> >     The LogotypeReference, LogotypeImage and LogotypeAudio structures
> >     explicitly identify one or more one-way hash functions employed.
> >     Clients MUST support the SHA-1 [SHS] one-way hash function, and
> >     clients MAY support other one-way hash functions. CAs MUST include a
> >     SHA-1 hash value in every logotypes extension, and CAs MAY include
> >     other one-way hash values. If more than one is present, clients MUST
> >     validate at least one value, and clients MAY ignore other hash
> >     values. The client's local policy determines which hash values are
> >     validated and which hash values are ignored.
>
>OK. You are right. The information is there but usually when you have an
>ASN.1 description, it is much better to describe one by one the components.
>We both recognize that the text may be improved. I would therefore recommend
>to comment one by one each component
>
>Now, let us pick up the last sentence you quoted:
>
>"The client's local policy determines which hash values are validated and
>which hash values are ignored."
>
>This is not the case. The rule is mentionned just in the previous sentence:
>" If more than one is present, clients MUST validate at least one value".
>
>This is correct and enough. The remaining of the sentence should be deleted:
>"and clients MAY ignore other hash values".

I think that the meaning is clear, but I will be pleased to make it shorter.

> > Therefore, your suggestion is inappropriate.  The two sequences need not
> > have the same number of entries.  The imageURI sequence contains a list of
> > locations where the same image file can be located.  Multiple locations are
> > provided to ensure availability.  The imageHash sequence contains a list of
> > hash values computed on the image file, and there is one entry for each
> > hash algorithm employed.
>
>I originally raised 12 concerns, you picked the second one and argued on it.
>
>Should I understand that you fully agree with the 11 remaining arguments ?

No.  At the time, I did not have time to go through them in detail.  I will 
do so this week, factoring in the discussion from others.

Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LGTYU03939 for ietf-pkix-bks; Mon, 21 Oct 2002 09:29:34 -0700 (PDT)
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 g9LGTXW03932 for <[e-mail]>; Mon, 21 Oct 2002 09:29:33 -0700 (PDT)
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 JAA23075; Mon, 21 Oct 2002 09:28:46 -0700 (PDT)
Received: from [128.115.222.68] (HELO catalyst2b.llnl.gov) by poptop.llnl.gov (CommuniGate Pro SMTP 3.5.9) with ESMTP id 4099269; Mon, 21 Oct 2002 09:28:46 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 21 Oct 2002 09:32:24 -0700
To: [e-mail] (Peter Gutmann), [e-mail], [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: RE: draft-ietf-pkix-logotypes-06.txt
Cc: [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>

At 04:38 AM 10/22/2002 +1300, Peter Gutmann wrote:

>"David Cross" <[e-mail]> writes:
>
> >I my opinion, I am afraid that the presence of logotypes in additonal types
> >of certificates will imply that clients should display such logos when path
> >validation or revocation check is performed.  For example, every time a mail
> >message is processed and signature check performed, should the mail client
> >display the logo for the OCSP responder to the end user?  In that example, I
> >would argue strongly that we have extended from the useful scenario of
> >enabling simpler certificate selection for end users to an intolerable user
> >experience.
>
>As long as implementors follow the standard tradition of adding a "Don't show
>me this again" checkbox (checked by default) to the display, we'll be OK.
>
>This probably doesn't make the addition of logotypes too useful though, since
>you'll only see them the first time the software is run.
>
>Peter.

The "solution" would be to present the "Don't show me again" checkbox on a
certificate-by-certificate (owner) basis (or perhaps, an issuer-by-issuer 
basis.)

As if ...

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 g9LFdjj01278 for ietf-pkix-bks; Mon, 21 Oct 2002 08:39:45 -0700 (PDT)
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 g9LFdhW01274 for <[e-mail]>; Mon, 21 Oct 2002 08:39:43 -0700 (PDT)
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 g9LFd0jj010891; Tue, 22 Oct 2002 04:39:00 +1300
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id EAA165232; Tue, 22 Oct 2002 04:38:57 +1300 (NZDT) (sender [e-mail])
Date: Tue, 22 Oct 2002 04:38:57 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: draft-ietf-pkix-logotypes-06.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>

"David Cross" <[e-mail]> writes:

>I my opinion, I am afraid that the presence of logotypes in additonal types
>of certificates will imply that clients should display such logos when path
>validation or revocation check is performed.  For example, every time a mail
>message is processed and signature check performed, should the mail client
>display the logo for the OCSP responder to the end user?  In that example, I
>would argue strongly that we have extended from the useful scenario of
>enabling simpler certificate selection for end users to an intolerable user
>experience.

As long as implementors follow the standard tradition of adding a "Don't show
me this again" checkbox (checked by default) to the display, we'll be OK.

This probably doesn't make the addition of logotypes too useful though, since
you'll only see them the first time the software is run.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LDbBJ22323 for ietf-pkix-bks; Mon, 21 Oct 2002 06:37:11 -0700 (PDT)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9LDb9W22317 for <[e-mail]>; Mon, 21 Oct 2002 06:37:09 -0700 (PDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 21 Oct 2002 06:37:01 -0700
Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 21 Oct 2002 06:37:05 -0700
Received: from RED-MSG-10.redmond.corp.microsoft.com ([157.54.12.47]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 21 Oct 2002 06:37:02 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-logotypes-06.txt
Date: Mon, 21 Oct 2002 06:37:01 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-logotypes-06.txt
thread-index: AcJ434FQBcSS0o+LTLC33Yn4Gv5iFAAJqFQw
From: "David Cross" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 21 Oct 2002 13:37:02.0580 (UTC) FILETIME=[F0295340:01C27906]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9LDbAW22320
Sender: [e-mail]
Precedence: 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 my opinion, I am afraid that the presence of logotypes in additonal
types of certificates will imply that clients should display such logos
when path validation or revocation check is performed.  For example,
every time a mail message is processed and signature check performed,
should the mail client display the logo for the OCSP responder to the
end user?  In that example, I would argue strongly that we have extended
from the useful scenario of enabling simpler certificate selection for
end users to an intolerable user experience.

I don't have any strong technical argument for the limitation, just a
practical argument for implementors. 

Regards,

David B. Cross




David,

> Denis:
> 
> In general, I agree with most of your suggestions.  Thanks for taking 
> the time to perform a thorough review - I apologize for the delay in 
> response.  I do however, disagree with suggestion #12.  I disagree on 
> the basis that a relying party would want oir need to view logos for 
> certificates used in path and revocation processing.

My proposed phrasing is not in contradiction with your above statement. 
So I still do not understand why there should be any limitation. Could 
you argue and/or provide examples ?

Denis

 
> 12. Page 11. Section 5. Type of certificates
> 
>    Logotypes MAY be present in three types of certificates:
> 
>      - CA certificates
>      - End-entity certificates
>      - Attribute certificates
> 
> Why is there such a limitation ? CRL Issuers, OCSP responders or TSUs 
> may have logotypes present in their certificates.
> 
> Replace with : "Logotypes MAY be present in any type of certificate".
> 
> Regards,
> 
> David B. Cross
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Tuesday, October 15, 2002 12:47 AM
> To: Housley, Russ
> Cc: [e-mail]
> Subject: Re: draft-ietf-pkix-logotypes-06.txt
> 
> Russ,
> 
> > We just posted an update to the logotypes draft.  There are two 
> > primary changes from the previous version.  First, we tried to be 
> > more
> 
> > clear about what is mandatory to implement and what is not.
> 
> This is not yet clear enough. See below.
> 
> > Second, we added support for more than one hash function without 
> > having to repeat a lot of data.
> >
> > The loudest objections (as opposed to jokes) came from Microsoft. 
> > Based on discussions with Trevor Freeman, I believe that Microsoft 
> > can
> 
> > accept this version.
> >
> > We are still in Working Group Last Call.....
> 
> Since we are still in Working Group Last Call, here are my 12 comments

> on that document.
> 
> 1. Page 6. Section 3. Logotype data
> 
> "Implementations MUST support image data; however, support for audio 
> data is OPTIONAL." Audio is a good joke, in the same way, as 
> pheromones. We are supposed to deal with serious documents. Please 
> delete.
> 
> 2. Page 7. Section 4.1 Extension format
> 
> "Clients MUST support both direct and indirect addressing."
> 
> I disagree. If an end-user certificate is included in a signature, it 
> may be interesting to display the logotype even if the terminal is 
> off-line. Indirect addressing would mandate an on-line connection.
> 
> Replace with:
> 
> "Clients claiming to conform with this document SHALL support direct 
> addressing. Clients MAY also support indirect addressing."
> 
> 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".
> 
> 4. Page 8. Section 4.1.
> 
>       LogotypeData ::= SEQUENCE {
>          image           SEQUENCE OF LogotypeImage     OPTIONAL,
>          audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }
> 
> Since audio support should be suppressed, replace with:
> 
>       LogotypeData ::= SEQUENCE OF LogotypeImage
> 
> 5. Page 7. Section 4.1.
> 
> We have:
> 
>       communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
> 
>       LogotypeInfo ::= CHOICE {
>          direct          [0] LogotypeData,
>          indirect        [1] LogotypeReference }
> 
>       LogotypeData ::= SEQUENCE {
>          image           SEQUENCE OF LogotypeImage OPTIONAL,
> 
> No explanations are given on the text about what to do for a client 
> when there is more than one LogotypeImage present in a communityLogo.
> 
> First of all, a communityLogo may contain more than one logo which 
> belongs to one or more communities. However the client has no way to 
> know whether the LogotypeData includes different versions from the 
> same logo (e.g. in black and white or in color) or different logos.
> 
> The ASN.1 structure is not adapted to make that difference. Therefore 
> it is proposed to modify the ASN.1 syntax along the following way:
> 
>          communityLogos   [0] EXPLICIT CommunityLogos OPTIONAL,
> 
> CommunityLogos ::= SEQUENCE OF CommunityLogo
> 
> CommunityLogo ::= LogotypeInfo
> 
> In this way, clients can make their best efforts to support only one 
> instance of version for each CommunityLogo.
> 
> 6. Page 9. Section 4.1.
> 
>       LogotypeImageInfo ::= SEQUENCE {
>          fileSize        INTEGER,  -- In octets
>          xSize           INTEGER,  -- In pixels
>          ySize           INTEGER,  -- In pixels
>          numColors       INTEGER } -- In bits
> 
> Text is missing to explain this structure. How is a grey scale 
> indicated for jpeg and for gif ???
> 
> 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."
> 
> 8. Page 9. Section 4.1.
> 
>       LogotypeImageInfo ::= SEQUENCE {
>          fileSize        INTEGER,  -- In octets
>          xSize           INTEGER,  -- In pixels
>          ySize           INTEGER,  -- In pixels
>          numColors       INTEGER } -- In bits
> 
> It would also be appropriate to say what to do when the image is in 
> color and that the client has no color display available. No display 
> at all ? Conversion into grey scale using which kind of transposition 
> ?
> 
> 9. Page 9. Section 4.1. Since audio is a joke, text and ASN.1 about 
> audio should be deleted.
> 
> 10. Page 9. Section 4.1. The text states:
> 
> "Implementations MUST support both the JPEG and GIF image formats 
> (with MIME types of "image/jpeg" and "image/gif", respectively)"
> 
> I would guess that Animated GIF should not be supported. Could we say 
> it ?
> 
> 11. Page 10. Section 4.1.
> 
>       Community Logotype. If communityLogo is present, the logotype
MUST
>       represent the community to which the certificate issuer is
>       affiliated. The communityLogo MAY be present in an end entity
>       certificate, a CA certificate or an attribute certificate.
> 
> A certificate issuer may belong to more than one community. Replace: 
> "the community " by :"the community or the communities".
> 
> 12. Page 11. Section 5. Type of certificates
> 
>    Logotypes MAY be present in three types of certificates:
> 
>      - CA certificates
>      - End-entity certificates
>      - Attribute certificates
> 
> Why is there such a limitation ? CRL Issuers, OCSP responders or TSUs 
> may have logotypes present in their certificates.
> 
> Replace with : "Logotypes MAY be present in any type of certificate".
> 
> Denis
> 
> >
> > Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LCpkw20504 for ietf-pkix-bks; Mon, 21 Oct 2002 05:51:46 -0700 (PDT)
Received: from CORPSRV1.Alacris.com ([64.26.153.194]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9LCpjW20498 for <[e-mail]>; Mon, 21 Oct 2002 05:51:45 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
Subject: RE: Authority Key Identifier
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 21 Oct 2002 08:51:41 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Authority Key Identifier
thread-index: AcJ4/7OV9nm/Vw+oQgyp46aBagAicQAAN1Vw
From: "Denis Issoupov" <[e-mail]>
To: "Jong 't, D (Dennis)" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9LCpjW20499
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

According to RFC 2459,

   AuthorityKeyIdentifier ::= SEQUENCE {
      keyIdentifier             [0] KeyIdentifier           OPTIONAL,
      authorityCertIssuer       [1] GeneralNames            OPTIONAL,
      authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  } 

In your case it's encoded as

      keyIdentifier             [0] KeyIdentifier

30  -- SEQUENCE 
 16 -- lenght
    80 -- [0]
	14 -- lenght
	   b2 b6 f2 cb eb d0 b2 26 79 eb 8b 99 74 77 e2 df 2f d5 20 69
-- KeyIdentifier

So, if you decode it properly, you will have AKI=b2 b6 f2 cb eb d0 b2 26
79 eb 8b 99 74 77 e2 df 2f d5 20 69.

Denis Issoupov
Senior Software Developer
ALACRIS Inc.
* Voice: 613-230-9762 x239  * Fax: [phone]
* Cell: 613-294-5948
* E-mail: [e-mail] * Web: www.alacris.com

Find out more about the best OCSP Client for Windows at
http://www.ocspclient.com
 



> -----Original Message-----
> From: Jong 't, D (Dennis) [mailto:[e-mail]] 
> Sent: Monday, October 21, 2002 7:29 AM
> To: '[e-mail]'
> Subject: Authority Key Identifier
> 
> 
> 
> LS,
> 
> I have a question regarding the Authority Key Identifier 
> (AKI) in an x509 certificate. When we resolve the AKI from 
> the "CERT_CONTEXT" (MS IIS), it returns a 24 bytes structure, 
> like: 30 16 80 14 b2 b6 f2 cb eb d0 b2 26 79 eb 8b 99 74 77 
> e2 df 2f d5 20 69
> 
> The AKI should be 20 bytes long (RFC 2459, 4.2.1.2 using 160 
> bit SHA-1),
> like:
> b2 b6 f2 cb eb d0 b2 26 79 eb 8b 99 74 77 e2 df 2f d5 20 69
> 
> Does anyone know the purpose of those 4 trailing bytes? If 
> Yes, is it save to cut them off to substract the original AKI?
> 
> Met vriendelijke groet/with kind regards,
>  
> Dennis 't Jong
> Technisch Specialist
> Windows Server Management O&O - Beveiliging 
> 
> Rabobank ICT           Tel:    [phone]
> Kamer ZL-R255          Fax:    [phone]
> Laan van Eikenstein 9  Mobiel: [phone]
> 3705 AR Zeist          Email:  [e-mail] 
> Nederland              Web:    http://www.RabobankICT.nl 
> 
> 
> 
> 
> ================================================
> De informatie opgenomen in dit bericht kan vertrouwelijk zijn en 
> is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
> onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en 
> de afzender direct te informeren door het bericht te retourneren. 
> ================================================
> The information contained in this message may be confidential 
> and is intended to be exclusively for the addressee. Should you 
> receive this message unintentionally, please do not use the contents 
> herein and notify the sender immediately by return e-mail.
> 
> 
> 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LBvVg17575 for ietf-pkix-bks; Mon, 21 Oct 2002 04:57:31 -0700 (PDT)
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 g9LBvTW17570 for <[e-mail]>; Mon, 21 Oct 2002 04:57:29 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Oct 2002 11:57:31 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 HAA26507 for <[e-mail]>; Mon, 21 Oct 2002 07:57:29 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g9LBste07301 for <[e-mail]>; Mon, 21 Oct 2002 07:54:55 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWC55Y>; Mon, 21 Oct 2002 07:57:28 -0400
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 3TPWC55X; Mon, 21 Oct 2002 07:57:25 -0400
From: "Housley, Russ" <[e-mail]>
To: "Jong 't, D (Dennis)" <[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, 21 Oct 2002 07:57:22 -0400
Subject: Re: Authority Key Identifier
In-Reply-To: <11AD762F3715454-2000@_rabobank.nl_>
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 Authority key identifier is only used to aid in certification path 
construction.  The recipient should not expect to use it in any manner 
other than exact string matching.  RFC 2459 and RFC 3780 recommend methods 
for assigning the key identifiers, but other methods are permitted.

Russ


At 01:28 PM 10/21/2002 +0200, Jong 't, D (Dennis) wrote:

>LS,
>
>I have a question regarding the Authority Key Identifier (AKI) in an x509
>certificate. When we resolve the AKI from the "CERT_CONTEXT" (MS IIS), it
>returns a 24 bytes structure, like:
>30 16 80 14 b2 b6 f2 cb eb d0 b2 26 79 eb 8b 99 74 77 e2 df 2f d5 20 69
>
>The AKI should be 20 bytes long (RFC 2459, 4.2.1.2 using 160 bit SHA-1),
>like:
>b2 b6 f2 cb eb d0 b2 26 79 eb 8b 99 74 77 e2 df 2f d5 20 69
>
>Does anyone know the purpose of those 4 trailing bytes? If Yes, is it save
>to cut them off to substract the original AKI?
>
>Met vriendelijke groet/with kind regards,
>
>Dennis 't Jong
>Technisch Specialist
>Windows Server Management O&O - Beveiliging
>
>Rabobank ICT           Tel:    [phone]
>Kamer ZL-R255          Fax:    [phone]
>Laan van Eikenstein 9  Mobiel: [phone]
>3705 AR Zeist          Email:  [e-mail]
>Nederland              Web:    http://www.RabobankICT.nl
>
>
>
>
>================================================
>De informatie opgenomen in dit bericht kan vertrouwelijk zijn en
>is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
>onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en
>de afzender direct te informeren door het bericht te retourneren.
>================================================
>The information contained in this message may be confidential
>and is intended to be exclusively for the addressee. Should you
>receive this message unintentionally, please do not use the contents
>herein and notify the sender immediately by return e-mail.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LBSiN14828 for ietf-pkix-bks; Mon, 21 Oct 2002 04:28:44 -0700 (PDT)
Received: from relay02.rabobank.nl (relay02.rabobank.nl [145.72.69.21]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9LBSgW14824 for <[e-mail]>; Mon, 21 Oct 2002 04:28:43 -0700 (PDT)
X-Server-Uuid: d32dbd14-b86d-11d3-8c8e-0008c7bba343
X-Server-Uuid: 91077152-1bde-4e67-8480-731f07dac000
From: "Jong 't, D (Dennis)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Authority Key Identifier
Date: Mon, 21 Oct 2002 13:28:31 +0200
MIME-Version: 1.0
X-WSS-ID: 11AD762F3715454-2000-02
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <11AD762F3715454-2000@_rabobank.nl_>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

LS,

I have a question regarding the Authority Key Identifier (AKI) in an x509
certificate. When we resolve the AKI from the "CERT_CONTEXT" (MS IIS), it
returns a 24 bytes structure, like:
30 16 80 14 b2 b6 f2 cb eb d0 b2 26 79 eb 8b 99 74 77 e2 df 2f d5 20 69

The AKI should be 20 bytes long (RFC 2459, 4.2.1.2 using 160 bit SHA-1),
like:
b2 b6 f2 cb eb d0 b2 26 79 eb 8b 99 74 77 e2 df 2f d5 20 69

Does anyone know the purpose of those 4 trailing bytes? If Yes, is it save
to cut them off to substract the original AKI?

Met vriendelijke groet/with kind regards,
 
Dennis 't Jong
Technisch Specialist
Windows Server Management O&O - Beveiliging 

Rabobank ICT           Tel:    [phone]
Kamer ZL-R255          Fax:    [phone]
Laan van Eikenstein 9  Mobiel: [phone]
3705 AR Zeist          Email:  [e-mail] 
Nederland              Web:    http://www.RabobankICT.nl 




================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en 
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en 
de afzender direct te informeren door het bericht te retourneren. 
================================================
The information contained in this message may be confidential 
and is intended to be exclusively for the addressee. Should you 
receive this message unintentionally, please do not use the contents 
herein and notify the sender immediately by return e-mail.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9L8x9t02514 for ietf-pkix-bks; Mon, 21 Oct 2002 01:59:09 -0700 (PDT)
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 g9L8x8W02508 for <[e-mail]>; Mon, 21 Oct 2002 01:59:08 -0700 (PDT)
Received: from arport ([62.119.75.13]) by blooper.utfors.se (8.12.6/8.12.6) with SMTP id g9L8x24d004593 for <[e-mail]>; Mon, 21 Oct 2002 10:59:02 +0200 (MEST)
Message-ID: <005701c278df$18081c20$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Banks + Legally binding signatures = A mess
Date: Mon, 21 Oct 2002 10:51:30 +0200
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>

The following is dedicated to legally binding signatures and
useful infrastructures for performing secure e-business.

A "Digital Company Paper" is my name on a certificate that
identifies an organization but does not identify an authorized
person.   It is used in conjunction with an associated private key
to sign commercial transactions "in the name of the organization".

Although banks are extremely tight-lipped about this,  _they_
were the first to introduce this concept on a grand scale.   If you
look at SET (Safe Electronic Transaction) certificates for
Merchants these contain no information related to an individual.

SET failed, but its successor 3D Secure (Verified by VISA) is now
pushed (really hard) by VISA on its member banks.   This time VISA
did not publish certificate profiles (to not get caught red-handed?),
but I'm very confident that Issuer (Bank)-certificates do not
contain references to authorized bank employees.

What's rather odd is that bank-people are those who have questioned
this idea the most.  This must be an example of tech-hypocrisy of the
highest possible magnitude :-)

=============================================
If this scheme works for banks and payments, it sure works for
most tasks in the commercial world using common sense logic.
=============================================

If this still feels a bit too easy, I propose an International conference
on how to align this powerful concept with legislation.

cheers,
Anders Rundgren




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9L8shW02395 for ietf-pkix-bks; Mon, 21 Oct 2002 01:54:43 -0700 (PDT)
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 g9L8sfW02391 for <[e-mail]>; Mon, 21 Oct 2002 01:54:41 -0700 (PDT)
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 KAA18732; Mon, 21 Oct 2002 10:54:58 +0200
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 KAA02598; Mon, 21 Oct 2002 10:54:41 +0200
Message-ID: <[e-mail]>
Date: Mon, 21 Oct 2002 10:54:39 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: David Cross <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt
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>

David,

> Denis:
> 
> In general, I agree with most of your suggestions.  Thanks for taking
> the time to perform a thorough review - I apologize for the delay in
> response.  I do however, disagree with suggestion #12.  I disagree on
> the basis that a relying party would want oir need to view logos for
> certificates used in path and revocation processing.

My proposed phrasing is not in contradiction with your above statement. 
So I still do not understand why there should be any limitation. Could 
you argue and/or provide examples ?

Denis

 
> 12. Page 11. Section 5. Type of certificates
> 
>    Logotypes MAY be present in three types of certificates:
> 
>      - CA certificates
>      - End-entity certificates
>      - Attribute certificates
> 
> Why is there such a limitation ? CRL Issuers, OCSP responders or TSUs
> may have logotypes present in their certificates.
> 
> Replace with : "Logotypes MAY be present in any type of certificate".
> 
> Regards,
> 
> David B. Cross
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Tuesday, October 15, 2002 12:47 AM
> To: Housley, Russ
> Cc: [e-mail]
> Subject: Re: draft-ietf-pkix-logotypes-06.txt
> 
> Russ,
> 
> > We just posted an update to the logotypes draft.  There are two
> > primary changes from the previous version.  First, we tried to be more
> 
> > clear about what is mandatory to implement and what is not.
> 
> This is not yet clear enough. See below.
> 
> > Second, we added support for more than one hash function without
> > having
> > to repeat a lot of data.
> >
> > The loudest objections (as opposed to jokes) came from Microsoft.
> > Based on discussions with Trevor Freeman, I believe that Microsoft can
> 
> > accept this version.
> >
> > We are still in Working Group Last Call.....
> 
> Since we are still in Working Group Last Call, here are my 12 comments
> on that document.
> 
> 1. Page 6. Section 3. Logotype data
> 
> "Implementations MUST support image data; however, support for audio
> data is OPTIONAL." Audio is a good joke, in the same way, as pheromones.
> We are supposed to deal with serious documents. Please delete.
> 
> 2. Page 7. Section 4.1 Extension format
> 
> "Clients MUST support both direct and indirect addressing."
> 
> I disagree. If an end-user certificate is included in a signature, it
> may be interesting to display the logotype even if the terminal is
> off-line. Indirect addressing would mandate an on-line connection.
> 
> Replace with:
> 
> "Clients claiming to conform with this document SHALL support direct
> addressing. Clients MAY also support indirect addressing."
> 
> 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".
> 
> 4. Page 8. Section 4.1.
> 
>       LogotypeData ::= SEQUENCE {
>          image           SEQUENCE OF LogotypeImage     OPTIONAL,
>          audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }
> 
> Since audio support should be suppressed, replace with:
> 
>       LogotypeData ::= SEQUENCE OF LogotypeImage
> 
> 5. Page 7. Section 4.1.
> 
> We have:
> 
>       communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
> 
>       LogotypeInfo ::= CHOICE {
>          direct          [0] LogotypeData,
>          indirect        [1] LogotypeReference }
> 
>       LogotypeData ::= SEQUENCE {
>          image           SEQUENCE OF LogotypeImage OPTIONAL,
> 
> No explanations are given on the text about what to do for a client when
> there is more than one LogotypeImage present in a communityLogo.
> 
> First of all, a communityLogo may contain more than one logo which
> belongs to one or more communities. However the client has no way to
> know whether the LogotypeData includes different versions from the same
> logo (e.g. in black and white or in color) or different logos.
> 
> The ASN.1 structure is not adapted to make that difference. Therefore it
> is proposed to modify the ASN.1 syntax along the following way:
> 
>          communityLogos   [0] EXPLICIT CommunityLogos OPTIONAL,
> 
> CommunityLogos ::= SEQUENCE OF CommunityLogo
> 
> CommunityLogo ::= LogotypeInfo
> 
> In this way, clients can make their best efforts to support only one
> instance of version for each CommunityLogo.
> 
> 6. Page 9. Section 4.1.
> 
>       LogotypeImageInfo ::= SEQUENCE {
>          fileSize        INTEGER,  -- In octets
>          xSize           INTEGER,  -- In pixels
>          ySize           INTEGER,  -- In pixels
>          numColors       INTEGER } -- In bits
> 
> Text is missing to explain this structure. How is a grey scale indicated
> for jpeg and for gif ???
> 
> 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."
> 
> 8. Page 9. Section 4.1.
> 
>       LogotypeImageInfo ::= SEQUENCE {
>          fileSize        INTEGER,  -- In octets
>          xSize           INTEGER,  -- In pixels
>          ySize           INTEGER,  -- In pixels
>          numColors       INTEGER } -- In bits
> 
> It would also be appropriate to say what to do when the image is in
> color and that the client has no color display available. No display at
> all ? Conversion into grey scale using which kind of transposition ?
> 
> 9. Page 9. Section 4.1. Since audio is a joke, text and ASN.1 about
> audio should be deleted.
> 
> 10. Page 9. Section 4.1. The text states:
> 
> "Implementations MUST support both the JPEG and GIF image formats (with
> MIME types of "image/jpeg" and "image/gif", respectively)"
> 
> I would guess that Animated GIF should not be supported. Could we say it
> ?
> 
> 11. Page 10. Section 4.1.
> 
>       Community Logotype. If communityLogo is present, the logotype MUST
>       represent the community to which the certificate issuer is
>       affiliated. The communityLogo MAY be present in an end entity
>       certificate, a CA certificate or an attribute certificate.
> 
> A certificate issuer may belong to more than one community. Replace:
> "the community " by :"the community or the communities".
> 
> 12. Page 11. Section 5. Type of certificates
> 
>    Logotypes MAY be present in three types of certificates:
> 
>      - CA certificates
>      - End-entity certificates
>      - Attribute certificates
> 
> Why is there such a limitation ? CRL Issuers, OCSP responders or TSUs
> may have logotypes present in their certificates.
> 
> Replace with : "Logotypes MAY be present in any type of certificate".
> 
> Denis
> 
> >
> > Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9KAOAN27216 for ietf-pkix-bks; Sun, 20 Oct 2002 03:24:10 -0700 (PDT)
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 g9KAO7W27211 for <[e-mail]>; Sun, 20 Oct 2002 03:24:07 -0700 (PDT)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailc.telia.com (8.12.5/8.12.5) with SMTP id g9KAO2Q3015106; Sun, 20 Oct 2002 12:24:02 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <002601c27821$cced8fd0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Carl Ellison" <[e-mail]>
References: <3.0.5.32.20021019094654.01b6f430@localhost>
Subject: Re: 2003 PKI Research Workshop CFP
Date: Sun, 20 Oct 2002 12:16:48 +0200
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>

>The Internet2 PKI Research activity is based on the premise that a
>great deal of research is needed in PK-authenticated authorization
>and control systems and that research is not going to come out of
>current efforts among PKI vendors and standards bodies, active though
>they may be.

Carl,
I could not agree more.   Although my perception is that many of
the problems can be concluded as follows.  At least if we are
talking e-commerce:

- The competence of implementers of e-business systems with
   respect to PKI is very low.

- The certificates issued by most CAs do not fit the needs
   of e-business[*].

- The close to religious belief that paper-signatures and
   e-signatures have to be identical in order to create a
   trustworthy PKI-enabled e-world.  As someone else
   recently noted in this list, a paper-signature is technically
   as different to a digital signature as "analog" is to "digital". 

*] So what is the #1 problem with current certificates?
Well,  business systems are "dumb" and cannot understand that
"CN=Jane Doe, O=ACME, C=US" and 
"CN=John Doe, O=ACME, C=US"
actually come from the same business party and could lead
to valid messages put in quarantine or even being rejected.

This problem does neither exist in the traditional EDI-world
(using partner IDs), nor in the paper-world (using letter-heads),
where names of individuals are just attributes (payload) that
only occasionally is of any importance to the receiver.

But some business systems manage by _tailoring_ the "receiver"
code for each CA.    I.e. in the case above by only using O and C.
If the receiver instead is deciphering a web-server certificate
the entire Subject string or just CN should be used (to get a stable
identity property string).

Some vendors, like VeriSign have introduced DUNS numbers
as a private _option_ which just makes things even worse.

Permanent identifiers added another [but standardized]
way of screwing up RP software by making DN interpretation
an option that the CA may or may not support.

Anyway, this leads to essentially zero interoperability
compared to using shared secrets, de-facto making "open"
PKI a joke as it is _technically__impossible_ to create shrink-
wrapped RP-software that will work on the level needed by
business software, that simply cannot rely on the availability
of local PKI-gurus for carrying out day-to-day operations.

Unfortunately it seems that few (any?) PKI researchers are
interested in bothering with "low-level" stuff like compatibility
with existing business systems and processes, as most PKI experts
think in terms of signed e-mail which is a trivial  problem as the
relying party is usually _human_ that can do all kinds of more or
less clever decisions regarding unknown CAs, names etc.

Computerized RPs are _several_magnitudes_ harder to support
as things in the digital world are either TRUE or FALSE.

==============================================
I hate to admit it, but as long as this problem stays un-addressed,
it is better to refrain to Lynn Wheeler's relying-party-only PKI.
Or do as I propose: Only use web-server certificates from leading
commercial CAs, for inter-organization-messages as these are the
only certificates that are globally trusted, feature globally unique
static identifiers (in the CN), and are both easy and affordable to buy.
==============================================

Anders





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9JJiTq19447 for ietf-pkix-bks; Sat, 19 Oct 2002 12:44:29 -0700 (PDT)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9JJiOW19440 for <[e-mail]>; Sat, 19 Oct 2002 12:44:28 -0700 (PDT)
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 19 Oct 2002 12:44:21 -0700
Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 19 Oct 2002 12:44:20 -0700
Received: from RED-MSG-10.redmond.corp.microsoft.com ([157.54.12.47]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 19 Oct 2002 12:44:18 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-logotypes-06.txt
Date: Sat, 19 Oct 2002 12:44:18 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-logotypes-06.txt
Thread-Index: AcJ0IEmPdeUXs0C3TmyUd2FxFCWNhwDhxicQ
From: "David Cross" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 19 Oct 2002 19:44:18.0182 (UTC) FILETIME=[E993DA60:01C277A7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9JJiTW19444
Sender: [e-mail]
Precedence: 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:

In general, I agree with most of your suggestions.  Thanks for taking
the time to perform a thorough review - I apologize for the delay in
response.  I do however, disagree with suggestion #12.  I disagree on
the basis that a relying party would want oir need to view logos for
certificates used in path and revocation processing.




12. Page 11. Section 5. Type of certificates

   Logotypes MAY be present in three types of certificates:

     - CA certificates
     - End-entity certificates
     - Attribute certificates

Why is there such a limitation ? CRL Issuers, OCSP responders or TSUs
may have logotypes present in their certificates.

Replace with : "Logotypes MAY be present in any type of certificate".





Regards,

David B. Cross




-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Tuesday, October 15, 2002 12:47 AM
To: Housley, Russ
Cc: [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt



Russ,

> We just posted an update to the logotypes draft.  There are two 
> primary changes from the previous version.  First, we tried to be more

> clear about what is mandatory to implement and what is not.

This is not yet clear enough. See below.

> Second, we added support for more than one hash function without 
> having
> to repeat a lot of data.
> 
> The loudest objections (as opposed to jokes) came from Microsoft.  
> Based on discussions with Trevor Freeman, I believe that Microsoft can

> accept this version.
> 
> We are still in Working Group Last Call.....

Since we are still in Working Group Last Call, here are my 12 comments
on that document.

1. Page 6. Section 3. Logotype data

"Implementations MUST support image data; however, support for audio
data is OPTIONAL." Audio is a good joke, in the same way, as pheromones.
We are supposed to deal with serious documents. Please delete.


2. Page 7. Section 4.1 Extension format

"Clients MUST support both direct and indirect addressing."

I disagree. If an end-user certificate is included in a signature, it
may be interesting to display the logotype even if the terminal is
off-line. Indirect addressing would mandate an on-line connection.

Replace with:

"Clients claiming to conform with this document SHALL support direct
addressing. Clients MAY also support indirect addressing."


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


4. Page 8. Section 4.1.

      LogotypeData ::= SEQUENCE {
         image           SEQUENCE OF LogotypeImage     OPTIONAL,
         audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }

Since audio support should be suppressed, replace with:

      LogotypeData ::= SEQUENCE OF LogotypeImage


5. Page 7. Section 4.1.

We have:

      communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,

      LogotypeInfo ::= CHOICE {
         direct          [0] LogotypeData,
         indirect        [1] LogotypeReference }

      LogotypeData ::= SEQUENCE {
         image           SEQUENCE OF LogotypeImage OPTIONAL,

No explanations are given on the text about what to do for a client when
there is more than one LogotypeImage present in a communityLogo.

First of all, a communityLogo may contain more than one logo which
belongs to one or more communities. However the client has no way to
know whether the LogotypeData includes different versions from the same
logo (e.g. in black and white or in color) or different logos.

The ASN.1 structure is not adapted to make that difference. Therefore it
is proposed to modify the ASN.1 syntax along the following way:

         communityLogos   [0] EXPLICIT CommunityLogos OPTIONAL,

CommunityLogos ::= SEQUENCE OF CommunityLogo

CommunityLogo ::= LogotypeInfo

In this way, clients can make their best efforts to support only one
instance of version for each CommunityLogo.


6. Page 9. Section 4.1.

      LogotypeImageInfo ::= SEQUENCE {
         fileSize        INTEGER,  -- In octets
         xSize           INTEGER,  -- In pixels
         ySize           INTEGER,  -- In pixels
         numColors       INTEGER } -- In bits

Text is missing to explain this structure. How is a grey scale indicated
for jpeg and for gif ???


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


8. Page 9. Section 4.1.

      LogotypeImageInfo ::= SEQUENCE {
         fileSize        INTEGER,  -- In octets
         xSize           INTEGER,  -- In pixels
         ySize           INTEGER,  -- In pixels
         numColors       INTEGER } -- In bits

It would also be appropriate to say what to do when the image is in
color and that the client has no color display available. No display at
all ? Conversion into grey scale using which kind of transposition ?


9. Page 9. Section 4.1. Since audio is a joke, text and ASN.1 about
audio should be deleted.


10. Page 9. Section 4.1. The text states:

"Implementations MUST support both the JPEG and GIF image formats (with
MIME types of "image/jpeg" and "image/gif", respectively)"

I would guess that Animated GIF should not be supported. Could we say it
?


11. Page 10. Section 4.1.

      Community Logotype. If communityLogo is present, the logotype MUST
      represent the community to which the certificate issuer is
      affiliated. The communityLogo MAY be present in an end entity
      certificate, a CA certificate or an attribute certificate.

A certificate issuer may belong to more than one community. Replace:
"the community " by :"the community or the communities". 


12. Page 11. Section 5. Type of certificates

   Logotypes MAY be present in three types of certificates:

     - CA certificates
     - End-entity certificates
     - Attribute certificates

Why is there such a limitation ? CRL Issuers, OCSP responders or TSUs
may have logotypes present in their certificates.

Replace with : "Logotypes MAY be present in any type of certificate".


Denis



> 
> Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9JGl7h09887 for ietf-pkix-bks; Sat, 19 Oct 2002 09:47:07 -0700 (PDT)
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 g9JGl6W09882 for <[e-mail]>; Sat, 19 Oct 2002 09:47:06 -0700 (PDT)
Received: from p4 ([12.224.63.6]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20021019164653.LUCJ26432.sccrmhc02.attbi.com@p4>; Sat, 19 Oct 2002 16:46:53 +0000
Message-Id: <3.0.5.32.20021019094654.01b6f430@localhost>
X-Sender: cme@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Sat, 19 Oct 2002 09:46:54 -0700
To: SPKI Mailing List <[e-mail]>, [e-mail]
From: Carl Ellison <[e-mail]>
Subject: 2003 PKI Research Workshop CFP
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The Internet2 PKI Research activity is based on the premise that a
great deal of research is needed in PK-authenticated authorization
and control systems and that research is not going to come out of
current efforts among PKI vendors and standards bodies, active though
they may be.

The PKI Research Workshop is a place for serious researchers in this
field to present and publish their work.

The 2003 workshop CFP is online at

http://middleware.internet2.edu/pki03/

Last year's workshop program, papers and presentations are available
at

http://www.cs.dartmouth.edu/~pki02/

if you want to see the kind of papers we are looking for.

 - Carl

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBPbGLTnPxfjyW5ytxEQJhLACffJtKODaNciVZanFo8X8X0DMpawEAoKHQ
oD+KEn0fGIdwD0X+yRFD73jN
=d/uS
-----END PGP SIGNATURE-----


+------------------------------------------------------------------+
|Carl M. Ellison         [e-mail]     http://world.std.com/~cme |
|    PGP: 75C5 1814 C3E3 AAA7 3F31  47B9 73F1 7E3C 96E7 2B71       |
+---Officer, arrest that man. He's whistling a copyrighted song.---+


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9HB3Hl24530 for ietf-pkix-bks; Thu, 17 Oct 2002 04:03:17 -0700 (PDT)
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 g9HB3FW24526 for <[e-mail]>; Thu, 17 Oct 2002 04:03:15 -0700 (PDT)
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 NAA23092; Thu, 17 Oct 2002 13:03:30 +0200
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 NAA15470; Thu, 17 Oct 2002 13:03:26 +0200
Message-ID: <[e-mail]>
Date: Thu, 17 Oct 2002 13:03:12 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt
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>

Tom,

This is an answer to the first argument raised.

>       Denis, Russ:
> 
>       One reason why audio might be desired would be to allow the nearest
> available equivalent to logotype functionality.  This might be motivated by
> one of several pieces of US legislation (the Americans with Disabilities
> Act and Section 508).  If this is the case, the specification should
> probably reflect that audio is a backup, especially for individuals who
> cannot benefit from video.  

One of the key issue is to understand the properties that a client compliant
with this specification must support. Currently we have:

"Compliant applications MUST display more just one (or none) of the images
*and* play just one (or none) of the audio sequences at the same time." 
The *AND* is not acceptable.

First of all, if audio is going to be supported, then separate requirements
should be made so that client compliant with requirements fo image
representation, can ignore compliance requirements for audio representation.

Now, do we want to promote the use of gingles for VISA, AMEX, MasterCard ?
They would need to invent them.

If a user using a client is blind, do we think he will be more confident by
hearing the gingle ? How does he make sure that the gingle really originates 
from the logoype extension ?  

> I have a couple of suggestions in that case:
>        The image component should be mandatory, while other components
> should be optional
>       Clients should be directed to use other components only when the use
> of the video component is known to be impractical or useless, or the user
> has explicitly selected the other component.

While your formulation sound reasonable, I am still questioning the need 
to support audio.

Denis

>             Tom Gindin
> 
> Denis Pinkas <[e-mail]>@mail.imc.org on 10/15/2002 03:46:34 AM
> 
> Sent by:    [e-mail]
> 
> To:    "Housley, Russ" <[e-mail]>
> cc:    [e-mail]
> Subject:    Re: draft-ietf-pkix-logotypes-06.txt
> 
> Russ,
> 
> > We just posted an update to the logotypes draft.  There are two primary
> > changes from the previous version.  First, we tried to be more clear
> about
> > what is mandatory to implement and what is not.
> 
> This is not yet clear enough. See below.
> 
> > Second, we added support for more than one hash function without having
> > to repeat a lot of data.
> >
> > The loudest objections (as opposed to jokes) came from Microsoft.  Based
> on
> > discussions with Trevor Freeman, I believe that Microsoft can accept this
> > version.
> >
> > We are still in Working Group Last Call.....
> 
> Since we are still in Working Group Last Call, here are my 12 comments on
> that document.
> 
> 1. Page 6. Section 3. Logotype data
> 
> "Implementations MUST support image data; however, support for audio data
> is
> OPTIONAL." Audio is a good joke, in the same way, as pheromones. We are
> supposed to deal with serious documents. Please delete.
> 
> 2. Page 7. Section 4.1 Extension format
> 
> "Clients MUST support both direct and indirect addressing."
> 
> I disagree. If an end-user certificate is included in a signature, it may
> be
> interesting to display the logotype even if the terminal is off-line.
> Indirect addressing would mandate an on-line connection.
> 
> Replace with:
> 
> "Clients claiming to conform with this document SHALL support direct
> addressing. Clients MAY also support indirect addressing."
> 
> 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".
> 
> 4. Page 8. Section 4.1.
> 
>       LogotypeData ::= SEQUENCE {
>          image           SEQUENCE OF LogotypeImage     OPTIONAL,
>          audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }
> 
> Since audio support should be suppressed, replace with:
> 
>       LogotypeData ::= SEQUENCE OF LogotypeImage
> 
> 5. Page 7. Section 4.1.
> 
> We have:
> 
>       communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
> 
>       LogotypeInfo ::= CHOICE {
>          direct          [0] LogotypeData,
>          indirect        [1] LogotypeReference }
> 
>       LogotypeData ::= SEQUENCE {
>          image           SEQUENCE OF LogotypeImage OPTIONAL,
> 
> No explanations are given on the text about what to do for a client when
> there is more than one LogotypeImage present in a communityLogo.
> 
> First of all, a communityLogo may contain more than one logo which belongs
> to one or more communities. However the client has no way to know whether
> the LogotypeData includes different versions from the same logo (e.g. in
> black and white or in color) or different logos.
> 
> The ASN.1 structure is not adapted to make that difference. Therefore it is
> proposed to modify the ASN.1 syntax along the following way:
> 
>          communityLogos   [0] EXPLICIT CommunityLogos OPTIONAL,
> 
> CommunityLogos ::= SEQUENCE OF CommunityLogo
> 
> CommunityLogo ::= LogotypeInfo
> 
> In this way, clients can make their best efforts to support only one
> instance of version for each CommunityLogo.
> 
> 6. Page 9. Section 4.1.
> 
>       LogotypeImageInfo ::= SEQUENCE {
>          fileSize        INTEGER,  -- In octets
>          xSize           INTEGER,  -- In pixels
>          ySize           INTEGER,  -- In pixels
>          numColors       INTEGER } -- In bits
> 
> Text is missing to explain this structure. How is a grey scale indicated
> for
> jpeg and for gif ???
> 
> 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."
> 
> 8. Page 9. Section 4.1.
> 
>       LogotypeImageInfo ::= SEQUENCE {
>          fileSize        INTEGER,  -- In octets
>          xSize           INTEGER,  -- In pixels
>          ySize           INTEGER,  -- In pixels
>          numColors       INTEGER } -- In bits
> 
> It would also be appropriate to say what to do when the image is in color
> and that the client has no color display available. No display at all ?
> Conversion into grey scale using which kind of transposition ?
> 
> 9. Page 9. Section 4.1. Since audio is a joke, text and ASN.1 about audio
> should be deleted.
> 
> 10. Page 9. Section 4.1. The text states:
> 
> "Implementations MUST support both the JPEG and GIF image formats (with
> MIME
> types of "image/jpeg" and "image/gif", respectively)"
> 
> I would guess that Animated GIF should not be supported. Could we say it ?
> 
> 11. Page 10. Section 4.1.
> 
>       Community Logotype. If communityLogo is present, the logotype MUST
>       represent the community to which the certificate issuer is
>       affiliated. The communityLogo MAY be present in an end entity
>       certificate, a CA certificate or an attribute certificate.
> 
> A certificate issuer may belong to more than one community. Replace: "the
> community " by :"the community or the communities".
> 
> 12. Page 11. Section 5. Type of certificates
> 
>    Logotypes MAY be present in three types of certificates:
> 
>      - CA certificates
>      - End-entity certificates
>      - Attribute certificates
> 
> Why is there such a limitation ? CRL Issuers, OCSP responders or TSUs may
> have logotypes present in their certificates.
> 
> Replace with : "Logotypes MAY be present in any type of certificate".
> 
> Denis
> 
> >
> > Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9HApPB24383 for ietf-pkix-bks; Thu, 17 Oct 2002 03:51:25 -0700 (PDT)
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 g9HApNW24379 for <[e-mail]>; Thu, 17 Oct 2002 03:51:24 -0700 (PDT)
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 MAA13400; Thu, 17 Oct 2002 12:51:27 +0200
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 MAA12138; Thu, 17 Oct 2002 12:51:24 +0200
Message-ID: <[e-mail]>
Date: Thu, 17 Oct 2002 12:51:10 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt
References: <[e-mail]> <[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>

Russ,

> Denis:
> 
> I know that you are very busy, but I think that you have not given the
> document a fair reading.  I am not saying that the document is perfect;
> however, the information that you request is in the document.
> 
> It says:
> 
>     Both direct and indirect addressing accommodate alternative URIs to
>     obtain exactly the same item. This opportunity for replication is
>     intended to improve availability. Therefore, if a client is unable to
>     fetch the item form one URI, the client SHOULD try another URI in the
>     sequence.
> 
> And, it says:
> 
>     The LogotypeReference, LogotypeImage and LogotypeAudio structures
>     explicitly identify one or more one-way hash functions employed.
>     Clients MUST support the SHA-1 [SHS] one-way hash function, and
>     clients MAY support other one-way hash functions. CAs MUST include a
>     SHA-1 hash value in every logotypes extension, and CAs MAY include
>     other one-way hash values. If more than one is present, clients MUST
>     validate at least one value, and clients MAY ignore other hash
>     values. The client's local policy determines which hash values are
>     validated and which hash values are ignored.

OK. You are right. The information is there but usually when you have an
ASN.1 description, it is much better to describe one by one the components.
We both recognize that the text may be improved. I would therefore recommend
to comment one by one each component 

Now, let us pick up the last sentence you quoted: 

"The client's local policy determines which hash values are validated and
which hash values are ignored."

This is not the case. The rule is mentionned just in the previous sentence:
" If more than one is present, clients MUST validate at least one value".

This is correct and enough. The remaining of the sentence should be deleted:
"and clients MAY ignore other hash values".

> Therefore, your suggestion is inappropriate.  The two sequences need not
> have the same number of entries.  The imageURI sequence contains a list of
> locations where the same image file can be located.  Multiple locations are
> provided to ensure availability.  The imageHash sequence contains a list of
> hash values computed on the image file, and there is one entry for each
> hash algorithm employed.

I originally raised 12 concerns, you picked the second one and argued on it. 

Should I understand that you fully agree with the 11 remaining arguments ?

 :-)

Denis 

> 
> Russ
> 
> At 09:18 AM 10/16/2002 +0200, Denis Pinkas wrote:
> >Russ,
> >
> > > Denis:
> > >
> > > This is not correct.  In neither direct nor indirect addressing is the
> > > logotype data included directly in the certificate.  With direct, the URI
> > > of the data is directly in the certificate.  With indirect, the URI of the
> > > data is obtained from an intermediate structure.
> > >
> > > Caching is the technique for display of this data by an off line client.
> > >
> > > Russ
> >
> >The current text is confusing and needs clarifications along the lines that
> >you have provided. Explanations along the description of the various ASN.1
> >fields would certainly help to have a better understanding. These
> >explanations are currently missing.
> >
> >As an example, we have:
> >
> >          imageHash       SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
> >          imageURI        SEQUENCE SIZE (1..MAX) OF IA5String,
> >
> >I would guess that each SEQUENCE SHALL have the same number of elements.
> >It would be nice to say it.
> >
> >Denis
> >
> > > >2. Page 7. Section 4.1 Extension format
> > > >
> > > >"Clients MUST support both direct and indirect addressing."
> > > >
> > > >I disagree. If an end-user certificate is included in a signature, it
> > may be
> > > >interesting to display the logotype even if the terminal is off-line.
> > > >Indirect addressing would mandate an on-line connection.
> > > >
> > > >Replace with:
> > > >
> > > >"Clients claiming to conform with this document SHALL support direct
> > > >addressing. Clients MAY also support indirect addressing."


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9GL6vs16306 for ietf-pkix-bks; Wed, 16 Oct 2002 14:06:57 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9GL6sW16300 for <[e-mail]>; Wed, 16 Oct 2002 14:06:54 -0700 (PDT)
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9GL6JtB334296; Wed, 16 Oct 2002 17:06:19 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9GL6DCL104532; Wed, 16 Oct 2002 17:06:14 -0400
Importance: Normal
Sensitivity: 
Subject: Re: draft-ietf-pkix-logotypes-06.txt
To: Denis Pinkas <[e-mail]>
Cc: "Housley, Russ" <[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, 16 Oct 2002 17:06:06 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11  |July 29, 2002) at 10/16/2002 05:06:14 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, Russ:

      One reason why audio might be desired would be to allow the nearest
available equivalent to logotype functionality.  This might be motivated by
one of several pieces of US legislation (the Americans with Disabilities
Act and Section 508).  If this is the case, the specification should
probably reflect that audio is a backup, especially for individuals who
cannot benefit from video.  I have a couple of suggestions in that case:
       The image component should be mandatory, while other components
should be optional
      Clients should be directed to use other components only when the use
of the video component is known to be impractical or useless, or the user
has explicitly selected the other component.

            Tom Gindin

Denis Pinkas <[e-mail]>@mail.imc.org on 10/15/2002 03:46:34 AM

Sent by:    [e-mail]


To:    "Housley, Russ" <[e-mail]>
cc:    [e-mail]
Subject:    Re: draft-ietf-pkix-logotypes-06.txt



Russ,

> We just posted an update to the logotypes draft.  There are two primary
> changes from the previous version.  First, we tried to be more clear
about
> what is mandatory to implement and what is not.

This is not yet clear enough. See below.

> Second, we added support for more than one hash function without having
> to repeat a lot of data.
>
> The loudest objections (as opposed to jokes) came from Microsoft.  Based
on
> discussions with Trevor Freeman, I believe that Microsoft can accept this
> version.
>
> We are still in Working Group Last Call.....

Since we are still in Working Group Last Call, here are my 12 comments on
that document.

1. Page 6. Section 3. Logotype data

"Implementations MUST support image data; however, support for audio data
is
OPTIONAL." Audio is a good joke, in the same way, as pheromones. We are
supposed to deal with serious documents. Please delete.


2. Page 7. Section 4.1 Extension format

"Clients MUST support both direct and indirect addressing."

I disagree. If an end-user certificate is included in a signature, it may
be
interesting to display the logotype even if the terminal is off-line.
Indirect addressing would mandate an on-line connection.

Replace with:

"Clients claiming to conform with this document SHALL support direct
addressing. Clients MAY also support indirect addressing."


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


4. Page 8. Section 4.1.

      LogotypeData ::= SEQUENCE {
         image           SEQUENCE OF LogotypeImage     OPTIONAL,
         audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }

Since audio support should be suppressed, replace with:

      LogotypeData ::= SEQUENCE OF LogotypeImage


5. Page 7. Section 4.1.

We have:

      communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,

      LogotypeInfo ::= CHOICE {
         direct          [0] LogotypeData,
         indirect        [1] LogotypeReference }

      LogotypeData ::= SEQUENCE {
         image           SEQUENCE OF LogotypeImage OPTIONAL,

No explanations are given on the text about what to do for a client when
there is more than one LogotypeImage present in a communityLogo.

First of all, a communityLogo may contain more than one logo which belongs
to one or more communities. However the client has no way to know whether
the LogotypeData includes different versions from the same logo (e.g. in
black and white or in color) or different logos.

The ASN.1 structure is not adapted to make that difference. Therefore it is
proposed to modify the ASN.1 syntax along the following way:

         communityLogos   [0] EXPLICIT CommunityLogos OPTIONAL,

CommunityLogos ::= SEQUENCE OF CommunityLogo

CommunityLogo ::= LogotypeInfo

In this way, clients can make their best efforts to support only one
instance of version for each CommunityLogo.


6. Page 9. Section 4.1.

      LogotypeImageInfo ::= SEQUENCE {
         fileSize        INTEGER,  -- In octets
         xSize           INTEGER,  -- In pixels
         ySize           INTEGER,  -- In pixels
         numColors       INTEGER } -- In bits

Text is missing to explain this structure. How is a grey scale indicated
for
jpeg and for gif ???


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


8. Page 9. Section 4.1.

      LogotypeImageInfo ::= SEQUENCE {
         fileSize        INTEGER,  -- In octets
         xSize           INTEGER,  -- In pixels
         ySize           INTEGER,  -- In pixels
         numColors       INTEGER } -- In bits

It would also be appropriate to say what to do when the image is in color
and that the client has no color display available. No display at all ?
Conversion into grey scale using which kind of transposition ?


9. Page 9. Section 4.1. Since audio is a joke, text and ASN.1 about audio
should be deleted.


10. Page 9. Section 4.1. The text states:

"Implementations MUST support both the JPEG and GIF image formats (with
MIME
types of "image/jpeg" and "image/gif", respectively)"

I would guess that Animated GIF should not be supported. Could we say it ?


11. Page 10. Section 4.1.

      Community Logotype. If communityLogo is present, the logotype MUST
      represent the community to which the certificate issuer is
      affiliated. The communityLogo MAY be present in an end entity
      certificate, a CA certificate or an attribute certificate.

A certificate issuer may belong to more than one community. Replace: "the
community " by :"the community or the communities".


12. Page 11. Section 5. Type of certificates

   Logotypes MAY be present in three types of certificates:

     - CA certificates
     - End-entity certificates
     - Attribute certificates

Why is there such a limitation ? CRL Issuers, OCSP responders or TSUs may
have logotypes present in their certificates.

Replace with : "Logotypes MAY be present in any type of certificate".


Denis



>
> Russ







Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9GIvvk08772 for ietf-pkix-bks; Wed, 16 Oct 2002 11:57:57 -0700 (PDT)
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 g9GIvuW08768 for <[e-mail]>; Wed, 16 Oct 2002 11:57:56 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 16 Oct 2002 18:57:58 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 OAA17915 for <[e-mail]>; Wed, 16 Oct 2002 14:57:57 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g9GItOU16418 for <[e-mail]>; Wed, 16 Oct 2002 14:55:24 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWBKHJ>; Wed, 16 Oct 2002 14:57:56 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.102.89]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWBKH2; Wed, 16 Oct 2002 14:57:50 -0400
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: Wed, 16 Oct 2002 14:57:46 -0400
Subject: Re: draft-ietf-pkix-logotypes-06.txt
In-Reply-To: <[e-mail]>
References: <[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>

Denis:

I know that you are very busy, but I think that you have not given the 
document a fair reading.  I am not saying that the document is perfect; 
however, the information that you request is in the document.

It says:

    Both direct and indirect addressing accommodate alternative URIs to
    obtain exactly the same item. This opportunity for replication is
    intended to improve availability. Therefore, if a client is unable to
    fetch the item form one URI, the client SHOULD try another URI in the
    sequence.

And, it says:

    The LogotypeReference, LogotypeImage and LogotypeAudio structures
    explicitly identify one or more one-way hash functions employed.
    Clients MUST support the SHA-1 [SHS] one-way hash function, and
    clients MAY support other one-way hash functions. CAs MUST include a
    SHA-1 hash value in every logotypes extension, and CAs MAY include
    other one-way hash values. If more than one is present, clients MUST
    validate at least one value, and clients MAY ignore other hash
    values. The client's local policy determines which hash values are
    validated and which hash values are ignored.

Therefore, your suggestion is inappropriate.  The two sequences need not 
have the same number of entries.  The imageURI sequence contains a list of 
locations where the same image file can be located.  Multiple locations are 
provided to ensure availability.  The imageHash sequence contains a list of 
hash values computed on the image file, and there is one entry for each 
hash algorithm employed.

Russ


At 09:18 AM 10/16/2002 +0200, Denis Pinkas wrote:
>Russ,
>
> > Denis:
> >
> > This is not correct.  In neither direct nor indirect addressing is the
> > logotype data included directly in the certificate.  With direct, the URI
> > of the data is directly in the certificate.  With indirect, the URI of the
> > data is obtained from an intermediate structure.
> >
> > Caching is the technique for display of this data by an off line client.
> >
> > Russ
>
>The current text is confusing and needs clarifications along the lines that
>you have provided. Explanations along the description of the various ASN.1
>fields would certainly help to have a better understanding. These
>explanations are currently missing.
>
>As an example, we have:
>
>          imageHash       SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
>          imageURI        SEQUENCE SIZE (1..MAX) OF IA5String,
>
>I would guess that each SEQUENCE SHALL have the same number of elements.
>It would be nice to say it.
>
>Denis
>
> > >2. Page 7. Section 4.1 Extension format
> > >
> > >"Clients MUST support both direct and indirect addressing."
> > >
> > >I disagree. If an end-user certificate is included in a signature, it 
> may be
> > >interesting to display the logotype even if the terminal is off-line.
> > >Indirect addressing would mandate an on-line connection.
> > >
> > >Replace with:
> > >
> > >"Clients claiming to conform with this document SHALL support direct
> > >addressing. Clients MAY also support indirect addressing."


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9GABqi03851 for ietf-pkix-bks; Wed, 16 Oct 2002 03:11:52 -0700 (PDT)
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 g9GABnW03845 for <[e-mail]>; Wed, 16 Oct 2002 03:11:49 -0700 (PDT)
Received: from exhub01.bc (exchange.bc [45.34.4.231]) by mail1.belgacom.be  with SMTP id KAA03562 for <[e-mail]>; Wed, 16 Oct 2002 10:11:47 GMT
From: [e-mail]
Received: from 127.0.0.1 by exhub01.bc (InterScan E-Mail VirusWall NT); Wed, 16 Oct 2002 12:11:46 +0200
Received: by exhub01.bc with Internet Mail Service (5.5.2653.19) id <46S8WQ8D>; Wed, 16 Oct 2002 12:11:46 +0200
Message-ID: <[e-mail]>
To: [e-mail]
Subject: message-digest attribute in signed data
Date: Wed, 16 Oct 2002 12:11:35 +0200
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>

In RFC 2630 "Cryptographic message syntax", a message-digest attribute is defined as being the digest of the encapContentInfo eContent OCTET STRING being signed in signed-data. For signed-data, the same RFC requires that message-digest attribute be present as a signed attribute if any attributes are added. So i understand that it is easier for a signature verification application to have the message-digest added as a signed attribute since it shouldn't hence care about the order of the signed attributes, but are there any other particular reasons to put the message-digest attribute as a signed attribute? 

Regards,

malek bechlaghem.


**** 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 g9G7JuT10690 for ietf-pkix-bks; Wed, 16 Oct 2002 00:19:56 -0700 (PDT)
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 g9G7JsW10679 for <[e-mail]>; Wed, 16 Oct 2002 00:19:54 -0700 (PDT)
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 JAA05572; Wed, 16 Oct 2002 09:20:06 +0200
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 JAA23518; Wed, 16 Oct 2002 09:18:56 +0200
Message-ID: <[e-mail]>
Date: Wed, 16 Oct 2002 09:18:44 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt
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>

Russ,

> Denis:
> 
> This is not correct.  In neither direct nor indirect addressing is the
> logotype data included directly in the certificate.  With direct, the URI
> of the data is directly in the certificate.  With indirect, the URI of the
> data is obtained from an intermediate structure.
> 
> Caching is the technique for display of this data by an off line client.
> 
> Russ

The current text is confusing and needs clarifications along the lines that
you have provided. Explanations along the description of the various ASN.1
fields would certainly help to have a better understanding. These
explanations are currently missing.

As an example, we have:

         imageHash       SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
         imageURI        SEQUENCE SIZE (1..MAX) OF IA5String,

I would guess that each SEQUENCE SHALL have the same number of elements. 
It would be nice to say it.

Denis

> >2. Page 7. Section 4.1 Extension format
> >
> >"Clients MUST support both direct and indirect addressing."
> >
> >I disagree. If an end-user certificate is included in a signature, it may be
> >interesting to display the logotype even if the terminal is off-line.
> >Indirect addressing would mandate an on-line connection.
> >
> >Replace with:
> >
> >"Clients claiming to conform with this document SHALL support direct
> >addressing. Clients MAY also support indirect addressing."


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9FHX4615901 for ietf-pkix-bks; Tue, 15 Oct 2002 10:33:04 -0700 (PDT)
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 g9FHX2W15894 for <[e-mail]>; Tue, 15 Oct 2002 10:33:02 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 15 Oct 2002 17:33:04 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 NAA26153 for <[e-mail]>; Tue, 15 Oct 2002 13:33:03 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g9FHUSB01736 for <[e-mail]>; Tue, 15 Oct 2002 13:30:28 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWAWX6>; Tue, 15 Oct 2002 13:33:01 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.14]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWAWXZ; Tue, 15 Oct 2002 13:32:58 -0400
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: Tue, 15 Oct 2002 11:57:26 -0400
Subject: Re: draft-ietf-pkix-logotypes-06.txt
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>

Denis:

This is not correct.  In neither direct nor indirect addressing is the 
logotype data included directly in the certificate.  With direct, the URI 
of the data is directly in the certificate.  With indirect, the URI of the 
data is obtained from an intermediate structure.

Caching is the technique for display of this data by an off line client.

Russ


>2. Page 7. Section 4.1 Extension format
>
>"Clients MUST support both direct and indirect addressing."
>
>I disagree. If an end-user certificate is included in a signature, it may be
>interesting to display the logotype even if the terminal is off-line.
>Indirect addressing would mandate an on-line connection.
>
>Replace with:
>
>"Clients claiming to conform with this document SHALL support direct
>addressing. Clients MAY also support indirect addressing."


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9F7kuX24531 for ietf-pkix-bks; Tue, 15 Oct 2002 00:46:56 -0700 (PDT)
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 g9F7ksW24522 for <[e-mail]>; Tue, 15 Oct 2002 00:46:54 -0700 (PDT)
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 JAA23138; Tue, 15 Oct 2002 09:46:52 +0200
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 JAA19982; Tue, 15 Oct 2002 09:46:42 +0200
Message-ID: <[e-mail]>
Date: Tue, 15 Oct 2002 09:46:34 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-logotypes-06.txt
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>

Russ,

> We just posted an update to the logotypes draft.  There are two primary
> changes from the previous version.  First, we tried to be more clear about
> what is mandatory to implement and what is not.  

This is not yet clear enough. See below.

> Second, we added support for more than one hash function without having 
> to repeat a lot of data.
> 
> The loudest objections (as opposed to jokes) came from Microsoft.  Based on
> discussions with Trevor Freeman, I believe that Microsoft can accept this
> version.
> 
> We are still in Working Group Last Call.....

Since we are still in Working Group Last Call, here are my 12 comments on
that document.

1. Page 6. Section 3. Logotype data

"Implementations MUST support image data; however, support for audio data is
OPTIONAL." Audio is a good joke, in the same way, as pheromones. We are
supposed to deal with serious documents. Please delete.


2. Page 7. Section 4.1 Extension format

"Clients MUST support both direct and indirect addressing."

I disagree. If an end-user certificate is included in a signature, it may be
interesting to display the logotype even if the terminal is off-line.
Indirect addressing would mandate an on-line connection.

Replace with:

"Clients claiming to conform with this document SHALL support direct
addressing. Clients MAY also support indirect addressing."


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


4. Page 8. Section 4.1.

      LogotypeData ::= SEQUENCE {
         image           SEQUENCE OF LogotypeImage     OPTIONAL,
         audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }

Since audio support should be suppressed, replace with:

      LogotypeData ::= SEQUENCE OF LogotypeImage


5. Page 7. Section 4.1.

We have:

      communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,

      LogotypeInfo ::= CHOICE {
         direct          [0] LogotypeData,
         indirect        [1] LogotypeReference }

      LogotypeData ::= SEQUENCE {
         image           SEQUENCE OF LogotypeImage OPTIONAL,

No explanations are given on the text about what to do for a client when
there is more than one LogotypeImage present in a communityLogo.

First of all, a communityLogo may contain more than one logo which belongs
to one or more communities. However the client has no way to know whether
the LogotypeData includes different versions from the same logo (e.g. in
black and white or in color) or different logos.

The ASN.1 structure is not adapted to make that difference. Therefore it is
proposed to modify the ASN.1 syntax along the following way:

         communityLogos   [0] EXPLICIT CommunityLogos OPTIONAL,

CommunityLogos ::= SEQUENCE OF CommunityLogo

CommunityLogo ::= LogotypeInfo

In this way, clients can make their best efforts to support only one
instance of version for each CommunityLogo.


6. Page 9. Section 4.1.

      LogotypeImageInfo ::= SEQUENCE {
         fileSize        INTEGER,  -- In octets
         xSize           INTEGER,  -- In pixels
         ySize           INTEGER,  -- In pixels
         numColors       INTEGER } -- In bits

Text is missing to explain this structure. How is a grey scale indicated for
jpeg and for gif ???


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


8. Page 9. Section 4.1.

      LogotypeImageInfo ::= SEQUENCE {
         fileSize        INTEGER,  -- In octets
         xSize           INTEGER,  -- In pixels
         ySize           INTEGER,  -- In pixels
         numColors       INTEGER } -- In bits

It would also be appropriate to say what to do when the image is in color
and that the client has no color display available. No display at all ?
Conversion into grey scale using which kind of transposition ?


9. Page 9. Section 4.1. Since audio is a joke, text and ASN.1 about audio
should be deleted.


10. Page 9. Section 4.1. The text states:

"Implementations MUST support both the JPEG and GIF image formats (with MIME
types of "image/jpeg" and "image/gif", respectively)"

I would guess that Animated GIF should not be supported. Could we say it ?


11. Page 10. Section 4.1.

      Community Logotype. If communityLogo is present, the logotype MUST
      represent the community to which the certificate issuer is
      affiliated. The communityLogo MAY be present in an end entity
      certificate, a CA certificate or an attribute certificate.

A certificate issuer may belong to more than one community. Replace: "the
community " by :"the community or the communities". 


12. Page 11. Section 5. Type of certificates

   Logotypes MAY be present in three types of certificates:

     - CA certificates
     - End-entity certificates
     - Attribute certificates

Why is there such a limitation ? CRL Issuers, OCSP responders or TSUs may
have logotypes present in their certificates.

Replace with : "Logotypes MAY be present in any type of certificate".


Denis



> 
> Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9EFCxZ07861 for ietf-pkix-bks; Mon, 14 Oct 2002 08:12:59 -0700 (PDT)
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 g9EFCvv07852 for <[e-mail]>; Mon, 14 Oct 2002 08:12:57 -0700 (PDT)
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 LAA27311; Mon, 14 Oct 2002 11:12:34 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100309b9d08c78a1fa@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 14 Oct 2002 11:09:07 -0400
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Questions on Authority/Subject Key Identifiers
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:52 PM +1200 9/29/02, Peter Gutmann wrote:
>Stephen Kent <[e-mail]> writes:
>
>>The real world issue you describe calls for re-issuance of certs; it does not
>>justify violating the standards.
>
>In *theory* it calls for the re-issuance of certs.  I can quite easily see
>that the practical approach would be to chain by sKID, and obviously enough
>people agree with this that they persuaded MS to change the behaviour of their
>code to allow it (the issue you're referring to was a bug, not a deliberate
>design decision like sKID chaining).
>
>Peter.

peter,

With much MS code, it's hard to tell the difference between bugs and 
design errors, er, I mean features :-)

The BasicConstraints "feature" in path validation is just the latest 
example. Nobody from  MS ever brought this suggestion up on PKIX or 
argued to have the PKIX docs accommodate this processing approach 
based on ANY arguments. So, I have no basis to believe that customers 
asked MS to make their software work in this fashion, vs. someone in 
MS just deciding that this was just a good idea.  Given that context, 
it is hard for me to be sympathetic to this violation of the 
standards.

Consistent with the SKID/AKID matching model, I have been told that 
the MS code also searches for certs based on the SKID, which is a 
non-scaleable approach given that there is no general way to loacte a 
cert based on this value. It is more efficient in a closed 
environment, but we prize Internet standards that work in open 
environments, not ones optimized for closed environments.

Yes, it would simplify life for a company that was rehomed under a 
new cert, but as an employee of a company that changed parent names 
twice in a 3 years period, I don't see reissuance of certs as a 
terrible burden. Employees of BBN got to change business cards and 
stationary as well as company signs, web site content etc. when we 
became part of GTE, and then GTE merged with Bell Atlantic to become 
Verizon.  Cert reissunace is just another task and not my any means 
the most expensive one under these circumstances.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9EHPbB15639 for ietf-pkix-bks; Mon, 14 Oct 2002 10:25:37 -0700 (PDT)
Received: from junker.stroeder.com (krl9-d9bb4f09.pool.mediaWays.net [217.187.79.9]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9EHPZv15635 for <[e-mail]>; Mon, 14 Oct 2002 10:25:35 -0700 (PDT)
Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id BCFF31572F4; Mon, 14 Oct 2002 19:25:33 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 14 Oct 2002 19:25:32 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
Reply-To: [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: Stephen Kent <[e-mail]>
Cc: Peter Gutmann <[e-mail]>, [e-mail]
Subject: Re: Questions on Authority/Subject Key Identifiers
References: <[e-mail]> <p05100309b9d08c78a1fa@[128.89.88.34]>
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>

Stephen Kent wrote:
> 
> With much MS code, it's hard to tell the difference between bugs and 
> design errors, er, I mean features :-)

Disclaimer: I'm not related to MS nor do I want to defend MS in general.

> The BasicConstraints "feature" in path validation is just the latest 
> example.

This is a very good example: I guess some programmer was trying "to make it 
work". I can imagine that the developer had quite a bunch of examples of 
malformed certs of well-known CAs and decided to not take care of 
BasicConstraints because some of the famous CAs designed by so-called PKI 
experts are simply flawed.

IMHO this particular discussion and other threads like "Identifying the 
right CRL for a given certificate" show that some very basic issues are not 
made clear enough.

Several times I mentioned that I suspect PKIX is getting far too complex to 
be ever implemented correctly. Folks here always forget that for a developer 
making an application "PKI-enabled" is a side-job. Still lots of new 
"features" are pushed through the IETF-PKIX without caring about how to 
implement them correctly.

Having said this I wonder why people consider cross-certification, bridge 
CAs and such. IMHO these things just open other cans of worms and give 
developers a hell of a time...

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9DJdLY14979 for ietf-pkix-bks; Sun, 13 Oct 2002 12:39:21 -0700 (PDT)
Received: from stargazer-o.stars-smi.com (stargazer-o.stars-smi.com [151.200.173.2]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9DJdKv14974 for <[e-mail]>; Sun, 13 Oct 2002 12:39:20 -0700 (PDT)
Received: from excelsior.stars-smi.com by stargazer-o.stars-smi.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 13 Oct 2002 19:36:46 UT
Received: by excelsior.stars-smi.com with Internet Mail Service (5.5.2655.55) id <RDBXSAVZ>; Sun, 13 Oct 2002 15:47:10 -0400
Message-ID: <DCE76463749C64499892A0DB3AF05AC602457544@CHALLENGER>
From: "Hamrick, Matt" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, "Hamrick, Matt" <[e-mail]>
Cc: [e-mail]
Subject: RE: The Bank-model  Was: Employee Certificates - Security Issues
Date: Sun, 13 Oct 2002 15:34:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
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>

 
-----BEGIN PGP SIGNED MESSAGE-----

Alzo Spracht Anders Rundgren:
>Matt,
>There is a short explanation and that is that a trivial thing like
>a purchase order involves at least three parties (purchaser,
>purchaser organization and supplier) while PKI only supports
>two parties (end-entity and relying party).

Okay... this is totally understandable. There were many such
discussions in the CORBASec community when talking about
client-server technologies like SSL/TLS.

>The Enterprise model does not take this in account which is
>the reason why few if any business system vendors support
>the Enterprise model.

>The Bank model addresses this by using multiple more
>or less independent PKIs.  The Bank model needs as a
>minimum one X.509 certificate and key per organization.
>Due to the Bank model's "non-personal" way of working,
>it is seldom relying on X.500/LDAP-support except for
>internal use.  UDDI registries are probably more
>conformant with future needs of the Bank model.
>The Bank model minimizes the need for publishing (or
>leaking) information concerning employees, as a key element
>of banking is, and has always been, client integrity.

UDDI registeries seem to have similar problems to X.500/DAP/LDAP
directories. The primary one being a name-space issue. When there are
more than two entities that want to interact, the semantics of naming
issues can get complicated. With DAP/LDAP, most of the naming issues
tend to be structural; some people want RDNs to be "rich" with a
highly branchified DIT, other people want a flat naming structure.
With UDDI, naming issues seem to incorporate more functional aspects,
leading to even more confusion when more than two parties
interoperate. It's my belief that the fundamental flaw with web
services is the lack of a canon for the semantics of meta-data in
UDDI. But, then again, I haven't really looked at v3 of UDDI, and
it's a little off-topic anyway.

I think I'm tracking you on the whole enterprise-model/bank-model
thign, but I'm somewhat confused still about one point. When a
digital bearer instrument (such as an electronic purchase order)
leaves an orgainization, it if is shrouded in the bank's keys in such
a way that the keys of the individual inside the bank that
origininated the transaction is unseen, why should we care what the
bank's internal DIT schema looks like? Or rather, it seems to be an
issue only if there's delegation going on, which is what you seem to
be arguing against.

>The Enterprise model is based on the defunct X.500 vision
>where we all would be a part of a giant PKI and published
>in a globally accessible directory.  This is would be OK
>if "e-business" were equivalent to sending signed and
>optionally encrypted e-mail, using Outlook etc.
>But, AFAIK, this is miles away from where the
>e-business industry in general is headed.

Aye.. 'twas a bit of a pipe dream to think that we would all "PEMify"
ourselves into a global PKI. It would be nice if it was doable, but
clearly it would officially require EVERYONE in the world who wanted
to participate to adhere to the same or similar CPs if not CPSes. I'm
not entirely certain that I would go so far as to say that the
"enterprise model" is based on X.500, but clearly the concept of the
global X.500 is dead.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQEVAwUBPanLpAYqu9rjxyWVAQHD/gf+MYl3tSjehPSQRd96Vs9H+WQTP8fdtDX6
g35wIEgrbSP/asa+y7/8PFU+/wNWuzYefhRj4OJX2NIiLEURve4ZhZ6FanAyYLHL
S5nOOIbe0ObCO4/ti2KYA92sUzDCbI49pPIZq8Otrq9bvwVeL3xh5FO09Pj/pN6k
64nrTHs2EdTeWfIEIp84dLY6ZDHd0pPkY3dXhZc4oaBb/9UjLV9voZyb+Ifdwfjw
W2teCunsUycUOCDT1pbf/zojxDtrZHvisICYnAqQM5PQ5ooMe6p9RVhsNMUo/Yq6
xX//+ls4ovMbHWC6AuD8IDguEAYYhVdy3XIWHj4xVm6YXXLOkBHZ0Q==
=/F+O
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9DFUIj29304 for ietf-pkix-bks; Sun, 13 Oct 2002 08:30:18 -0700 (PDT)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9DFU8v29297 for <[e-mail]>; Sun, 13 Oct 2002 08:30:08 -0700 (PDT)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailb.telia.com (8.12.5/8.12.5) with SMTP id g9DFU3I3028932; Sun, 13 Oct 2002 17:30:03 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <002f01c272cc$6d720900$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Hamrick, Matt" <[e-mail]>
Cc: <[e-mail]>
References: <DCE76463749C64499892A0DB3AF05AC602457542@CHALLENGER>
Subject: Re: The Bank-model  Was: Employee Certificates - Security Issues
Date: Sun, 13 Oct 2002 17:22:59 +0200
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>

Matt,
There is a short explanation and that is that a trivial thing like
a purchase order involves at least three parties (purchaser,
purchaser organization and supplier) while PKI only supports
two parties (end-entity and relying party).

The Enterprise model does not take this in account which is
the reason why few if any business system vendors support
the Enterprise model.

The Bank model addresses this by using multiple more
or less independent PKIs.  The Bank model needs as a
minimum one X.509 certificate and key per organization.
Due to the Bank model's "non-personal" way of working,
it is seldom relying on X.500/LDAP-support except for
internal use.  UDDI registries are probably more
conformant with future needs of the Bank model.
The Bank model minimizes the need for publishing (or
leaking) information concerning employees, as a key element
of banking is, and has always been, client integrity.

The Enterprise model is based on the defunct X.500 vision
where we all would be a part of a giant PKI and published
in a globally accessible directory.  This is would be OK
if "e-business" were equivalent to sending signed and
optionally encrypted e-mail, using Outlook etc.
But, AFAIK, this is miles away from where the
e-business industry in general is headed.

cheers,
Anders

----- Original Message ----- 
From: "Hamrick, Matt" <[e-mail]>
To: <[e-mail]>; "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>
Sent: Saturday, October 12, 2002 03:40
Subject: RE: The Bank-model Was: Employee Certificates - Security Issues



Sadly I am still confused as to what it is that Anders is objecting to: PKI
in general, X.509 in particular, or the fact that WAY too many people ignore
the semantics of what it means to hold a certificate.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, October 11, 2002 5:18 PM
To: Anders Rundgren
Cc: Hamrick, Matt; [e-mail]
Subject: Re: The Bank-model Was: Employee Certificates - Security Issues



semi-related posting in spki mailing list
http://www.garlic.com/~lynn/aadsm12.htm#33 two questions about spki



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9C1jK805061 for ietf-pkix-bks; Fri, 11 Oct 2002 18:45:20 -0700 (PDT)
Received: from stargazer-o.stars-smi.com (stargazer-o.stars-smi.com [151.200.173.2]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9C1jJv05055 for <[e-mail]>; Fri, 11 Oct 2002 18:45:19 -0700 (PDT)
Received: from excelsior.stars-smi.com by stargazer-o.stars-smi.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 12 Oct 2002 01:42:48 UT
Received: by excelsior.stars-smi.com with Internet Mail Service (5.5.2655.55) id <RDBXR0YY>; Fri, 11 Oct 2002 21:53:22 -0400
Message-ID: <DCE76463749C64499892A0DB3AF05AC602457542@CHALLENGER>
From: "Hamrick, Matt" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Anders Rundgren <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: The Bank-model  Was: Employee Certificates - Security Issues
Date: Fri, 11 Oct 2002 21:40:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
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>

Sadly I am still confused as to what it is that Anders is objecting to: PKI
in general, X.509 in particular, or the fact that WAY too many people ignore
the semantics of what it means to hold a certificate.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, October 11, 2002 5:18 PM
To: Anders Rundgren
Cc: Hamrick, Matt; [e-mail]
Subject: Re: The Bank-model Was: Employee Certificates - Security Issues



semi-related posting in spki mailing list
http://www.garlic.com/~lynn/aadsm12.htm#33 two questions about spki


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9BLIdn23692 for ietf-pkix-bks; Fri, 11 Oct 2002 14:18:39 -0700 (PDT)
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 g9BLIcv23685 for <[e-mail]>; Fri, 11 Oct 2002 14:18:38 -0700 (PDT)
Subject: Re: The Bank-model  Was: Employee Certificates - Security Issues
To: "Anders Rundgren" <[e-mail]>
Cc: "Hamrick, Matt" <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 11 Oct 2002 15:17:52 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 10/11/2002 05:21:33 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>

semi-related posting in spki mailing list
http://www.garlic.com/~lynn/aadsm12.htm#33 two questions about spki



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9BJJxA17287 for ietf-pkix-bks; Fri, 11 Oct 2002 12:19:59 -0700 (PDT)
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 g9BJJvv17282 for <[e-mail]>; Fri, 11 Oct 2002 12:19:57 -0700 (PDT)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailc.telia.com (8.12.5/8.12.5) with SMTP id g9BJJvvc027803; Fri, 11 Oct 2002 21:19:58 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <002e01c2715a$351d1950$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Hamrick, Matt" <[e-mail]>, <[e-mail]>
References: <DCE76463749C64499892A0DB3AF05AC602457537@CHALLENGER>
Subject: The Bank-model  Was: Employee Certificates - Security Issues
Date: Fri, 11 Oct 2002 21:12:56 +0200
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>

Matt,
This thread has many issues.  What makes this so extremely
hard to discuss in a constructive way is the fact that by
looking at one issue at a time (like transaction limits),
you don't get the whole picture.

One issue is security.
One issue is privacy.
One issue is control of users.
One issue is archiving of operations.
One issue is PKI in conjunction with existing information systems.
One issue is compatibility with existing client-standards.
One issue is authority management.
One issue is TTP CA support.
One issue is user-convenience.
One issue is legal validity.

None of the issues above except for legal validity and security
[in the cryptographic sense only], are addressed by a static,
client-centric "enterprise model" according to the lines of the
US federal PKI and HEPKI to take some real examples.

I claim that the "bank model" as sketched in another posting has
_reasonable_ answers to all these issues and also allows a higher
flexibility by _simultaneously_ supporting a wide range of options
within a single organization. 

The bank model supports full-end-to-end-security-all-privacy-lost
for really important agreements, to the very elementary (but pretty
efficient) where outgoing data just gets a "stamp" of authenticy.
By building on the bank model, you don't have to have an answer
on how to handle every possible case (we already do?) as you can
adjust things with ease (well...) at the _server_ level.

Note: The bank-model was invented around 1700 and has recently
been recast into electronics.

cheers,
Anders

----- Original Message ----- 
From: "Hamrick, Matt" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, October 10, 2002 22:50
Subject: RE: Employee Certificates - Security Issues



 
-----BEGIN PGP SIGNED MESSAGE-----

Anders,
        I've just got to chime in here... A few things to consider:

1. It is generally not the case that anyone with a credit card with a
$1000 credit limit may repeatedly charge $999 with wild abandon.
Merchants who do not use an on-line credit card verification system
are severely limited by contract as to the types of charges that may
be applied to a particular account. Merchants with online credit card
verification systems are required by contract to check the available
credit on an account before accepting it as payment. To ignore either
contract point causes the MERCHANT to be stuck with the bill as the
settling banks will be more than happy to not reimburse merchants
that do not honor their contractual obligations with respect to
checking available credit.

It seems that if you have a PKI where an identity cert is issued to
an end entity, the use of that cert is STRICTLY to bind an electronic
representation of an identity to the public key associated with the
private key used in an authentication protocol. If you're creating
PKI where anyone with a PKC can charge up to $999 on an account with
a $1000 limit, well.. that's your own problem. My recommendation is,
"don't do that." It's as ridiculous as credit card companies assuming
that anyone with a signature is allowed to charge whatever they want.

2. Now lets assume that we have a system where a PKC identifies an
end entity (for some definition of "identification".) We could quite
easily establish a credit limit in the certificate, but I do rather
agree that this leaks too much information about the end entity, but
that's a privacy issue for another thread. Let's just say we want to
put it in an AC. Maybe we keep issuing these ACs every week or every
day or something. Inside the AC there might be a limited purchasing
authority attribute. It's important to note, that in relatively few
companies are general employees allowed to sign for the company. Most
companies I've worked for, contracts may only be signed by officers
of the corporation, or by their designated representatives. Were I
putting together a PKI/PMI for B2B, I would probably include a review
or financial controls process where a buyer would perform a search,
find the thing they're looking for, click on a button that says
"generate a sales contract" that includes a quote, a delivery date,
and an expiration date, then send the digital contract to whoever is
"up the food chain." That person would then authenticate the purchase
by issuing an AC that specifically references the contract.

While I agree with you that DTDs with XML are probably better for a
lot of reasons than asn.1 and BER encoding, I can't say that I
totally agree with the implicit argument that we shouldn't use X.509
ACs ever. (Some on this list might be snickering, because they might
have heard my statement at last years ISOC conference that X.509 was
totally inappropriate for use in constrained environments.)

3. XML is wonderful. XML is great. All hail XML, the ASCII of a new
millennium. It is a representation format, just like asn.1 and
BER/CER/DER/XER, etc The largest problem with XML is that it does
nothing to address the semantics of signature production. XML by
itself does not tell you what it means to be signed. X.509 is pretty
murky on some of the issues, but by repeatedly reading the
specification and reading the graffiti on the walls at IETF meetings,
you get the idea that a X.509 PKC is an identification vehicle, and
that most extensions or attributes are there primarily to support the
identification goals. XML DSIG is coming along, but it's still not
ready for prime time (if you disagree, let's start a flame war
somewhere else...) SAML also shows great promise. The Semantic Web
efforts show great promise. Personally, I look forward to the day
that we'll be able to replace asn.1/BER with something better. I'm
just not sure that XML is there yet.





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9B1oJR21286 for ietf-pkix-bks; Thu, 10 Oct 2002 18:50:19 -0700 (PDT)
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 g9B1oHv21273 for <[e-mail]>; Thu, 10 Oct 2002 18:50:17 -0700 (PDT)
Subject: RE: Employee Certificates - Security Issues
To: "Hamrick, Matt" <[e-mail]>
Cc: "'[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: Thu, 10 Oct 2002 19:49:03 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 10/10/2002 09:53:14 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>

.... european financial institutions and various endevers ... like SET ...
went to relying-party-only certificates ... no visiable name, no visable
credit limit .... etc ... all of which are at least privacy issues ... if
not security issues ... like publishing credit limit. I wouldn't think much
of attaching a certificate to hardly any set of my messages (even financial
transactions) that might flow thru 3rd parties (like merchants) with a
credit limit (in the sense of a credit card credit limit).

the other issue is that since a certificate is stale, static information
... it can't actually approximate the function of credit limit in the
credit card sense .... i.e. credit limit minus (real time) charges to date
to give (real time) available credit.

in past discussions of this type of proposal ... the value in the
certificate was approximating the limit in the paper "check signing limits"
(aka paper checks that had per check signing limit). it doesn't do anything
for real time credit limit ... since at most. a stale, static certificate
approximates a arbritrarily large stack of paper checks each with the same
check signing limit (i.e. the stack is arbritrary large in the sense that a
stale, static certificate could be appended to an arbitrary large number of
different financial transactions). The problem with solely an offline,
static certificate .... is that it has difficulty dealing with aggregated
and/or real-time infomration.

as previously posted ... one of the reasons for migration to payment cards
was that payment cards did provide businesses with aggregation and real
time transaction controls. The issue was that individuals were
circumventing the per transaction limits of the check signing limits by
signing multiple checks (cases of person using 200 $5000 limit checks to
perform a million dollar transaction).

ref:
http://www.garlic.com/~lynn/aadsm12.htm#31 The bank-model, was: employee
certificates - security issues

there have been proposals that involve organization issuing daily
certificates .... where two organization members can trust that each other
are members in good standing as of the morning of that day ... however,
these certificates aren't involved in any sort of transactional
authentication and/or authorization mechanism ... and are proposed for
offline environments where the two participants have no online recourse for
doing real-time checking of organizational member status.

basically, the financial scenario found that starting sometime in the '70s
the cost/benefit ratio of doing online, real-time transactions paid off
(especially where aggregation and real-time information was useful) ...
compared to the old fashion offline credential/certificate (whether paper
or electronic) mode of operations.

ref relying-party-only postings
http://www.garlic.com/~lynn/subtopic.html#rpo

privacy/identification related postings
http://www.garlic.com/~lynn/subtopic.html#privacy




[e-mail] on 10/10/2002 2:50 pm wrote:
                                                                                   
                                                                                   
                                                                                   


... snip ...

2. Now lets assume that we have a system where a PKC identifies an
end entity (for some definition of "identification".) We could quite
easily establish a credit limit in the certificate, but I do rather
agree that this leaks too much information about the end entity, but
that's a privacy issue for another thread. Let's just say we want to
put it in an AC. Maybe we keep issuing these ACs every week or every
day or something. Inside the AC there might be a limited purchasing
authority attribute. It's important to note, that in relatively few
companies are general employees allowed to sign for the company. Most
companies I've worked for, contracts may only be signed by officers
of the corporation, or by their designated representatives. Were I
putting together a PKI/PMI for B2B, I would probably include a review
or financial controls process where a buyer would perform a search,
find the thing they're looking for, click on a button that says
"generate a sales contract" that includes a quote, a delivery date,
and an expiration date, then send the digital contract to whoever is
"up the food chain." That person would then authenticate the purchase
by issuing an AC that specifically references the contract.

... snip ...



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9AMrLT11648 for ietf-pkix-bks; Thu, 10 Oct 2002 15:53:21 -0700 (PDT)
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 g9AMrJv11644 for <[e-mail]>; Thu, 10 Oct 2002 15:53:19 -0700 (PDT)
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 g9AMrHc9069520; Thu, 10 Oct 2002 18:53:17 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9AMrEGE022656; Thu, 10 Oct 2002 18:53:14 -0400
Importance: Normal
Sensitivity: 
Subject: RE: Employee Certificates - Security Issues
To: "Hamrick, Matt" <[e-mail]>
Cc: "'[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: Thu, 10 Oct 2002 18:53:08 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11  |July 29, 2002) at 10/10/2002 06:53:15 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>

      XMLDSIG may well be ready for prime time now.  However, its scope is
roughly comparable to that of CMS SignedData.  It uses references instead
of in-line data, which allows for extra complexity, and it includes a
(quite valuable) canonicalization facility, but it's mainly a format for
defining the data which is signed and representing its signature.
      Unless one thinks that ASN.1/DER is the primary problem with PKI,
IMHO XMLDSIG is not going to be revolutionary.  I'm for it, and I've done
some work on it, but it isn't going to solve issues like those in this
thread.  If I've understood most of what's going on here, we've largely
been discussing what happens when an employee tries to commit his or her
employer by signing a document with an organizationally affiliated
certificate, and whether there would be a better way of handling that.  The
format of the signed document has little to do with this issue.

            Tom Gindin


"Hamrick, Matt" <[e-mail]>@mail.imc.org on 10/10/2002
04:50:19 PM

Sent by:    [e-mail]


To:    "'[e-mail]'" <[e-mail]>
cc:
Subject:    RE: Employee Certificates - Security Issues




-----BEGIN PGP SIGNED MESSAGE-----

Anders,
        I've just got to chime in here... A few things to consider:

1. It is generally not the case that anyone with a credit card with a
$1000 credit limit may repeatedly charge $999 with wild abandon.
Merchants who do not use an on-line credit card verification system
are severely limited by contract as to the types of charges that may
be applied to a particular account. Merchants with online credit card
verification systems are required by contract to check the available
credit on an account before accepting it as payment. To ignore either
contract point causes the MERCHANT to be stuck with the bill as the
settling banks will be more than happy to not reimburse merchants
that do not honor their contractual obligations with respect to
checking available credit.

It seems that if you have a PKI where an identity cert is issued to
an end entity, the use of that cert is STRICTLY to bind an electronic
representation of an identity to the public key associated with the
private key used in an authentication protocol. If you're creating
PKI where anyone with a PKC can charge up to $999 on an account with
a $1000 limit, well.. that's your own problem. My recommendation is,
"don't do that." It's as ridiculous as credit card companies assuming
that anyone with a signature is allowed to charge whatever they want.

2. Now lets assume that we have a system where a PKC identifies an
end entity (for some definition of "identification".) We could quite
easily establish a credit limit in the certificate, but I do rather
agree that this leaks too much information about the end entity, but
that's a privacy issue for another thread. Let's just say we want to
put it in an AC. Maybe we keep issuing these ACs every week or every
day or something. Inside the AC there might be a limited purchasing
authority attribute. It's important to note, that in relatively few
companies are general employees allowed to sign for the company. Most
companies I've worked for, contracts may only be signed by officers
of the corporation, or by their designated representatives. Were I
putting together a PKI/PMI for B2B, I would probably include a review
or financial controls process where a buyer would perform a search,
find the thing they're looking for, click on a button that says
"generate a sales contract" that includes a quote, a delivery date,
and an expiration date, then send the digital contract to whoever is
"up the food chain." That person would then authenticate the purchase
by issuing an AC that specifically references the contract.

While I agree with you that DTDs with XML are probably better for a
lot of reasons than asn.1 and BER encoding, I can't say that I
totally agree with the implicit argument that we shouldn't use X.509
ACs ever. (Some on this list might be snickering, because they might
have heard my statement at last years ISOC conference that X.509 was
totally inappropriate for use in constrained environments.)

3. XML is wonderful. XML is great. All hail XML, the ASCII of a new
millennium. It is a representation format, just like asn.1 and
BER/CER/DER/XER, etc The largest problem with XML is that it does
nothing to address the semantics of signature production. XML by
itself does not tell you what it means to be signed. X.509 is pretty
murky on some of the issues, but by repeatedly reading the
specification and reading the graffiti on the walls at IETF meetings,
you get the idea that a X.509 PKC is an identification vehicle, and
that most extensions or attributes are there primarily to support the
identification goals. XML DSIG is coming along, but it's still not
ready for prime time (if you disagree, let's start a flame war
somewhere else...) SAML also shows great promise. The Semantic Web
efforts show great promise. Personally, I look forward to the day
that we'll be able to replace asn.1/BER with something better. I'm
just not sure that XML is there yet.

- -----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Friday, October 04, 2002 4:58 PM
To: Roberto Opazo; [e-mail]
Subject: Re: Employee Certificates - Security Issues



Roberto,
May I challenge this a bit?

Assume that a purchaser had a PKC + AC where the AC in some
way says that the purhaser has a $1000 limt.  By doing multiple
purchases at $999 the purchaser made this information useless.

Static solutions to dynamic problems is not a "hit".

That's one reason why ACs are unlikely to become very important.

Another reason is that most sophisticated information systems today
are
built on XML which is superior for ACs as there is both a human-
readable format (almost at least), and even more important, there is
the powerful  XML "Schema" language.

cheers,
Anders

- ----- Original Message -----
From: "Roberto Opazo" <[e-mail]>
To: <[e-mail]>
Sent: Friday, October 04, 2002 22:15
Subject: RE: Employee Certificates - Security Issues



Hello everybody,

This tread is just showing some of the problems you can have when
mixing a
public key certificate (PKC) with an attribute certificate (AC), the
solution is very ease: Do not do so.

RFC 3281 states:
"Some people constantly confuse PKCs and ACs.  An analogy may make
the
   distinction clear.  A PKC can be considered to be like a passport:
it
   identifies the holder, tends to last for a long time, and should
not
   be trivial to obtain.  An AC is more like an entry visa: it is
   typically issued by a different authority and does not last for as
   long a time.  As acquiring an entry visa typically requires
   presenting a passport, getting a visa can be a simpler process.

   Authorization information may be placed in a PKC extension or
placed
   in a separate attribute certificate (AC).  The placement of
   authorization information in PKCs is usually undesirable for two
   reasons.  First, authorization information often does not have the
   same lifetime as the binding of the identity and the public key.
   When authorization information is placed in a PKC extension, the
   general result is the shortening of the PKC useful lifetime.
Second,
   the PKC issuer is not usually authoritative for the authorization
   information.  This results in additional steps for the PKC issuer
to
   obtain authorization information from the authoritative source."

Now than we have a standard to solve this problem, lets use it!

We need applications using this standard, not another discussion to
define a
new standard, to need again, applications using the new standard. We
could
repeat this circle as many times as we want.

Best regards,

Roberto Opazo

> -----Mensaje original-----
> De: [e-mail]
> [mailto:[e-mail]]En nombre de Anders Rundgren
> Enviado el: viernes, 04 de octubre de 2002 12:24
> Para: [e-mail]; Guida, Richard [JJCUS]
> Asunto: Re: Employee Certificates - Security Issues
>
>
>
> Richard,
> I think you have mostly misinterpreted my messages.
>
> Employee-PKI means (I do at least), that the employee has a
> certificate that allows him/her to act on behalf on their employer.
>  This is
> a fundamental characteristic of the US Federal PKI and commercial
> efforts like Identrus.
>
> What I'm saying is that this opens the organization to massive
> and non-controllable attacks from disloyal employees etc.  It is a
> smart as giving the entire work-force company credit-cards.
>
> Regarding the market, it is interesting to note that there is not a
> business system maker of any significance that support a model
> where the client's certificate and signature is a part of
> _outgoing_ messages.  In the same way as there is not a single bank
> in the
> world that does this either.  And this fact is completely
> independent of the availability of client-side PKI.
>
> Note: Client-side PKI is absolutely not a bad idea, it is
> the idea to hand over specific "company keys" to employees
> that is not such a terribly good idea.
>
> Anders

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQEVAwUBPaXpFwYqu9rjxyWVAQH7zgf+Ic7xANsvL+F3mh8ZbwZLumCnvQ1NqVvo
wEbclh2uScS5OONLL26tox8Xg8Ry9FW2StmKYnDApho9FAgEhk2L8VCxjcLXOGWz
/xCpLu/9A+vjvGD08RUrjr6ZieaS7AFSTR0+F73r7YSPbdViuS6uQdxRzX3dZtxE
+MRlvFuBza3ztli9UYqgAJurzBPNAMyz3umWTA+mFcE1b135ADjWcaTD+rqrKCdt
sMqioErpC/mpk7BD7AVL6pJ3/emtAvU6JgvwFqrJ6N9dD6/+a4oyeSalcQJB/7sJ
hK7IgnLrlqQFKrsI1FHU79DFhyRWDZULnq91ckm23NyWF/tSa3suXQ==
=eHct
-----END PGP SIGNATURE-----







Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9AMgiK11455 for ietf-pkix-bks; Thu, 10 Oct 2002 15:42:44 -0700 (PDT)
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 g9AMghv11451 for <[e-mail]>; Thu, 10 Oct 2002 15:42:43 -0700 (PDT)
Received: from Chokhani ([12.91.130.191]) by mtiwmhc13.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20021010224237.EQUO23792.mtiwmhc13.worldnet.att.net@Chokhani>; Thu, 10 Oct 2002 22:42:37 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Identifying the right CRL for a given certificate
Date: Thu, 10 Oct 2002 18:43:20 -0400
Message-ID: <004101c270ae$6f3d6470$2a00a8c0@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>

Sarbari: Please see the responses in-line.

-----Original Message-----
From: Sarbari Gupta [mailto:[e-mail]] 
Sent: Thursday, October 10, 2002 9:42 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Identifying the right CRL for a given certificate


Santosh,

As you indicated, the additional constraints on CRL validation should be
added to the PKI standards. Otherwise there seems to be a security hole
if the certificate and CRL are validated up to different trust anchors,
while matching the two based only upon names.

Thanks for your explanation of 6.3.3 (2)(b)(i) related to CRL
processing. While what you wrote makes sense, (assuming that all of the
prior decisions in this portion of the standard makes sense,) it is
unfortunate that the text of the standard leaves so much to
interpretation, and familiarity with the standard's evolution.

One of the problems that I have noticed with the X.509 and PKIX specs is
the tendency to overload fields to mean different things at different
times. A case at point is the overloading of the Distribution Points
(DP) field.

Within the CDP extension of a certificate,
	a) the DP field defines the "location" of the CRL regardless of
whether it is a full or partitioned CRL
	b) the Reasons field determines whether the CA issues
partitioned CRLs based upon a subset of the reasons
	c) the cRLIssuer field indicates that the CRL issuer is
different from the certificate issuer

However, in the IDP extension of a CRL
	a) the existence of the DP field signals a partitioned CRL, AS
WELL AS the location of the CRL - WHY IS THIS OVERLOADING DONE?
[SC -- The existence of DP field in the CRL means which partition the
CRL is tied to.  Once you have the CRL, you do not need the location.
The purpose is that you have piece of unique information within the
signed envelop that lets you ensure that you have the CRL for the scope
of certificate of interest.  I can not think of a better or simpler
mechanism]
	b) the onlySomeReasons field also determines whether this is a
partitioned CRL - WHY CAN'T THIS BE THE DEFINITIVE INDICATOR FOR A
PARTITIONED CRL INSTEAD OF THE DP FIELD?
[SC -- All this determines is which reasons are covered in the CRL.
This permits you to create e.g., very fast key compromise CRL]
	c) the indirectCRL boolean indicates that the CRL issuer is
different from the certificate issuer


As I indicated before, the CRL handling description of X.509 and PKIX
could definitely be improved in terms of simplicity and clarity.
[SC -- Do you have any editorial suggestions for Annex B of X.509?  If
you do, let me know]

Respectfully,

- Sarbari
==============================
Sarbari Gupta
Electrosoft Services, Inc.
Tel: [phone]
Cell:[phone]
FAX: [phone]
Email:  [e-mail]
Web: <http://www.electrosoft-inc.com> ==============================
-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, October 03, 2002 8:19 PM
To: [e-mail]; [e-mail]
Subject: RE: Identifying the right CRL for a given certificate


Sarbari:

See my comments in-line in [].

-----Original Message-----
From: Sarbari Gupta [mailto:[e-mail]]
Sent: Wednesday, October 02, 2002 11:42 PM
To: Santosh Chokhani; [e-mail]
Subject: RE: Identifying the right CRL for a given certificate


Santosh,

I like the flavor of the new constraints on CRL validation that you have
specified.

You're also right about 2a and 2b. I should probably have expressed them
as:

	a) If the same Issuer entity signs both the certificate and the
CRL, then the Issuer Names of both have to match
	b) If different Issuers sign the certificate and CRL,
then the Issuer Name of the CRL has to match the cRLIssuer in the CDP
extension of the certificate. c [I agree]

However, the point I was trying to make was that in pairing up a
certificate and CRL, 6.3.3 specifies that only the Issuer Name matches
are of relevance (ignoring delta CRLs and partitioned CRLs).

I can think of a simple case where this may be a problem in the current
RFC 3280. Assume that the certificate CERT1 asserts the CDP extension
with no cRLIssuer and a single DP field which represents the address for
LDAP retrieval of the associated CRL. There happens to be a CRL CRL2 in
the Relying Party's local cache that has the same Issuer Name as CERT1;
however, CRL2 verifies under a different trust anchor than CERT1.
According to RFC 3280, CRL2 is acceptable for CERT1. Intuitively,
though, we know this is incorrect - there needs to be something more
than a simple name match and the ability to verify CRL2 to one of the
trust roots. The bottom line is that pairing up certificates and CRLs
based on issuer names without constraining them to be verifiable under
the same trust root, makes 6.3.3 rather weak.

[I agree.  That is why I have listed the three rules above]

AN ADDITIONAL POINT:
I also think the area of CRL usage and validation (with respect to a
given
certificate) needs to be less complex and more specific.

[I am not sure it can be made less complex]

For example, Section 6.3.3 item (2)(b)(i) states:

"If the distribution point name is present in the IDP CRL extension and
the distribution point is omitted from the DP (field of the CDP
extension in the
certificate) then verify that one of the names of the IDP matches one of
the names in the cRLIssuer field of the DP."

I don't understand the reason for this complication at all. If the DP
field is not present in the CDP extension in the certificate, why does
it make sense for the CRL IDP extension to have a distribution point
name, and why does this need to match the cRLIssuer field in the
certificate?

[RFC 3280 is correct in this regard.  Here are the answers to your
questions.  If you have a CRL that asserts a DP field in the IDP
extension, the relying party does not know whether it is a full CRL.
Thus, relying party must determine whether the CRL is relevant for the
certificate.  That is where CDP comes in.  Normally, DP in IDP should be
matched with DP in CDP.  But, in order not overload the certificate, if
CDP asserts cRLIssuer, that name is the DP by default unless a full name
or name relative to cRLIssuer is asserted.  Please look at the syntax of
the CDP extension carefully.  Thus, given that the IDP had DP and the
CDP does not, DP in IDP must match the cRLIssuer]

My suggestion would be to delete this portion of (2)(b)(i) altogether.
[That would be WRONG]

A related suggestion would be to require that is the certificate asserts
the DP field in the CDP extension, then the related CRL MUST assert the
distribution point field of the IDP extension and the two must match up
in order to be acceptable as a pair.

[Again, in the area of path processing, just because the certificate
asserts a DP, does not mean you can not use a full CRL, i.e., a CRL that
does not assert DP in IDP.  You should be able to either accept a full
CRL or a CRL whose IDP has the same DP.  I think that is what 3280 is
trying to say.  Thus, rejecting full CRL and only accepting an IDP CRL
in this case will be unnecessarily limiting.  I encourage you to review
Annex B in X.509 for CRL processing.  That may be a bit easier to follow
that 3280.  That Annex also provides some background material to make
the CRL processing more understandable.]

- Sarbari
==============================
Sarbari Gupta
Electrosoft Services, Inc.
Tel: [phone]
Cell:[phone]
FAX: [phone]
Email:  [e-mail]
Web: <http://www.electrosoft-inc.com> ==============================

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Wednesday, October 02, 2002 9:18 PM
To: [e-mail]; [e-mail]
Subject: RE: Identifying the right CRL for a given certificate


Sarbari:

Section 6.3.3 of 3280 does not imply anything regarding your assertions
2a and 2b.  It is not clear to me as to how you arrived at 2a and 2b. In
Section 6.3.3 of 3280, the operative item for the CRL signing key is
bullet f which states:

(f)  Obtain and validate the certification path for the complete CRL
   issuer.  If a key usage extension is present in the CRL issuer's

I agree that the RFC is missing guidance on CRL path building.  In my
mind a CRL path must be further constrained by the following rule:

1.  The trust must emanate from the same trust anchor as the
certification path for certificate for which the CRL is being sought.

2.  The DNs for the certification path for the certificate should match
the DNs for the certification path for the CRL (ignoring self-issued
certificates).  Of course, the last DN (namely the subscriber DN) will
be missing from the CRL certification path.

3.  The CRL certification path must be good for the same policy as the
subscriber.

I am not a CA product vendor and hence can not answer your other
questions.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Sarbari Gupta
Sent: Wednesday, October 02, 2002 4:30 PM
To: [e-mail]
Subject: Identifying the right CRL for a given certificate



I have been reviewing the RFC 3280 specs to understand how to identify
the correct CRL for a given certificate, and made the following
observations:

1) It appears to be possible to validate a certificate along a path that
leads to trust anchor TA1, while validating the CRL for that certificate
along a path that leads to trust anchor TA2. Intuitively, this seems
like a bad idea, however, I have not stumbled across anything in the RFC
that restricts Relying Parties from allowing this behavior.

2) Section 6.3.3 of the RFC seems to indicate that the primary means of
pairing up a certificate with the appropriate CRL are as follows:

	a) If the same key signs both the certificate and the CRL, then
the Issuer Names of both have to match
	b) If different keys are used to sign the certificate and CRL,
then the Issuer Name of the CRL has to match the cRLIssuer in the CDP
extension of the certificate

If this observation is coupled with observation (1) above, there seems
to be a possible security problem in matching on name fields when the
certificate and CRL emanate from different trust roots. This is
especially alarming since most of us have a large number of preloaded
trust roots in our systems, and it is possible that the same DN is used
within two different trust domains, either intentionally or
unintentionally.

3) Although it is acceptable that the same or different private keys are
used to sign certificates and CRLs for a given CA, there seems to be no
definition of conforming behavior for Relying Parties that says RPs
SHOULD be able to deal with both scenarios. The result is that certain
vendor's RPs only support one scenario or the other, leading to
non-interoperable implementations although both are in compliance with
the standard.

Am I missing something? I welcome comments.

Also, it would be very interesting to find out how the different vendors
have implemented the functionality to pair up certificates with the
correct CRLs.

==============================
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 g9AKwDX06553 for ietf-pkix-bks; Thu, 10 Oct 2002 13:58:13 -0700 (PDT)
Received: from stargazer-o.stars-smi.com (stargazer-o.stars-smi.com [151.200.173.2]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9AKwBv06545 for <[e-mail]>; Thu, 10 Oct 2002 13:58:11 -0700 (PDT)
Received: from excelsior.stars-smi.com by stargazer-o.stars-smi.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 Oct 2002 20:55:40 UT
Received: by excelsior.stars-smi.com with Internet Mail Service (5.5.2655.55) id <RDBXR7GJ>; Thu, 10 Oct 2002 17:06:13 -0400
Message-ID: <DCE76463749C64499892A0DB3AF05AC602457538@CHALLENGER>
From: "Hamrick, Matt" <[e-mail]>
To: [e-mail]
Subject: RE: Cross Certification RFCs
Date: Thu, 10 Oct 2002 16:53:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
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>

 
-----BEGIN PGP SIGNED MESSAGE-----

David,
    Are you offering to share them with the list? Those of us working
on projects related to the Federal Bridge would be interested in what
MS has to say about this issue.

- -Matt H.
- -----Original Message-----
From: David Cross [mailto:[e-mail]]
Sent: Friday, October 04, 2002 6:52 PM
To: mars; [e-mail]
Cc: Ignacio Mendivil Gutierrez
Subject: RE: Cross Certification RFCs


RFC 3280 and RFC 2459

I have a draft whitepaper that will help explain this technology from
a Microsoft perspective.

Regards,


David B. Cross
Program Manager
Windows Security
- -----Original Message-----
From: mars [mailto:[e-mail]] 
Sent: Friday, October 04, 2002 9:07 AM
To: [e-mail]
Subject: Cross Certification RFCs


What are the RFCs and drafts that contain requirements and
information regarding cross certification?
 
Best regards,
 
Miguel A. Rodriguez
SeguriDATA
Mexico
 

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQEVAwUBPaXp0AYqu9rjxyWVAQE23gf8CT3ufncZE0o5AzgFCDcCFDmxm/ychbvq
+nOXgTAjh9FYfOwjaWfCr5Lj3DlzTc6rOcpmGO78AtJa1oqm9Dp1K8XD7gHnqlT3
pqwbkBiEG6JX2RfrbORNn5WeBTludbOnzjnt9ZYjk7KGHq9OVL0ODj25T19Y5J1z
JAXbWDVAKnvp7F6zvXIRZsqj4rWMUFkg4kI9vc8EsRLkVPD46DClTAm7/Am0StxX
eDT5mQ1Als7yUpf8LHMHcjHBbLzRr63+jmiQ/L5hZf46KUW3Xw52WJz0Wv0uPFru
pS6bmO/41VruKChipwbVs2FDe19lq2FK7QkascQ9FTrrvqaV+F3WYA==
=79Vu
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9AKtDh06377 for ietf-pkix-bks; Thu, 10 Oct 2002 13:55:13 -0700 (PDT)
Received: from stargazer-o.stars-smi.com (stargazer-o.stars-smi.com [151.200.173.2]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9AKtCv06371 for <[e-mail]>; Thu, 10 Oct 2002 13:55:12 -0700 (PDT)
Received: from excelsior.stars-smi.com by stargazer-o.stars-smi.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 Oct 2002 20:52:40 UT
Received: by excelsior.stars-smi.com with Internet Mail Service (5.5.2655.55) id <RDBXR7F7>; Thu, 10 Oct 2002 17:03:13 -0400
Message-ID: <DCE76463749C64499892A0DB3AF05AC602457537@CHALLENGER>
From: "Hamrick, Matt" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Employee Certificates - Security Issues
Date: Thu, 10 Oct 2002 16:50:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
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>

 
-----BEGIN PGP SIGNED MESSAGE-----

Anders,
        I've just got to chime in here... A few things to consider:

1. It is generally not the case that anyone with a credit card with a
$1000 credit limit may repeatedly charge $999 with wild abandon.
Merchants who do not use an on-line credit card verification system
are severely limited by contract as to the types of charges that may
be applied to a particular account. Merchants with online credit card
verification systems are required by contract to check the available
credit on an account before accepting it as payment. To ignore either
contract point causes the MERCHANT to be stuck with the bill as the
settling banks will be more than happy to not reimburse merchants
that do not honor their contractual obligations with respect to
checking available credit.

It seems that if you have a PKI where an identity cert is issued to
an end entity, the use of that cert is STRICTLY to bind an electronic
representation of an identity to the public key associated with the
private key used in an authentication protocol. If you're creating
PKI where anyone with a PKC can charge up to $999 on an account with
a $1000 limit, well.. that's your own problem. My recommendation is,
"don't do that." It's as ridiculous as credit card companies assuming
that anyone with a signature is allowed to charge whatever they want.

2. Now lets assume that we have a system where a PKC identifies an
end entity (for some definition of "identification".) We could quite
easily establish a credit limit in the certificate, but I do rather
agree that this leaks too much information about the end entity, but
that's a privacy issue for another thread. Let's just say we want to
put it in an AC. Maybe we keep issuing these ACs every week or every
day or something. Inside the AC there might be a limited purchasing
authority attribute. It's important to note, that in relatively few
companies are general employees allowed to sign for the company. Most
companies I've worked for, contracts may only be signed by officers
of the corporation, or by their designated representatives. Were I
putting together a PKI/PMI for B2B, I would probably include a review
or financial controls process where a buyer would perform a search,
find the thing they're looking for, click on a button that says
"generate a sales contract" that includes a quote, a delivery date,
and an expiration date, then send the digital contract to whoever is
"up the food chain." That person would then authenticate the purchase
by issuing an AC that specifically references the contract.

While I agree with you that DTDs with XML are probably better for a
lot of reasons than asn.1 and BER encoding, I can't say that I
totally agree with the implicit argument that we shouldn't use X.509
ACs ever. (Some on this list might be snickering, because they might
have heard my statement at last years ISOC conference that X.509 was
totally inappropriate for use in constrained environments.)

3. XML is wonderful. XML is great. All hail XML, the ASCII of a new
millennium. It is a representation format, just like asn.1 and
BER/CER/DER/XER, etc The largest problem with XML is that it does
nothing to address the semantics of signature production. XML by
itself does not tell you what it means to be signed. X.509 is pretty
murky on some of the issues, but by repeatedly reading the
specification and reading the graffiti on the walls at IETF meetings,
you get the idea that a X.509 PKC is an identification vehicle, and
that most extensions or attributes are there primarily to support the
identification goals. XML DSIG is coming along, but it's still not
ready for prime time (if you disagree, let's start a flame war
somewhere else...) SAML also shows great promise. The Semantic Web
efforts show great promise. Personally, I look forward to the day
that we'll be able to replace asn.1/BER with something better. I'm
just not sure that XML is there yet.

- -----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Friday, October 04, 2002 4:58 PM
To: Roberto Opazo; [e-mail]
Subject: Re: Employee Certificates - Security Issues



Roberto,
May I challenge this a bit?

Assume that a purchaser had a PKC + AC where the AC in some
way says that the purhaser has a $1000 limt.  By doing multiple
purchases at $999 the purchaser made this information useless.

Static solutions to dynamic problems is not a "hit".

That's one reason why ACs are unlikely to become very important.

Another reason is that most sophisticated information systems today
are
built on XML which is superior for ACs as there is both a human-
readable format (almost at least), and even more important, there is
the powerful  XML "Schema" language.

cheers,
Anders

- ----- Original Message -----
From: "Roberto Opazo" <[e-mail]>
To: <[e-mail]>
Sent: Friday, October 04, 2002 22:15
Subject: RE: Employee Certificates - Security Issues



Hello everybody,

This tread is just showing some of the problems you can have when
mixing a
public key certificate (PKC) with an attribute certificate (AC), the
solution is very ease: Do not do so.

RFC 3281 states:
"Some people constantly confuse PKCs and ACs.  An analogy may make
the
   distinction clear.  A PKC can be considered to be like a passport:
it
   identifies the holder, tends to last for a long time, and should
not
   be trivial to obtain.  An AC is more like an entry visa: it is
   typically issued by a different authority and does not last for as
   long a time.  As acquiring an entry visa typically requires
   presenting a passport, getting a visa can be a simpler process.

   Authorization information may be placed in a PKC extension or
placed
   in a separate attribute certificate (AC).  The placement of
   authorization information in PKCs is usually undesirable for two
   reasons.  First, authorization information often does not have the
   same lifetime as the binding of the identity and the public key.
   When authorization information is placed in a PKC extension, the
   general result is the shortening of the PKC useful lifetime. 
Second,
   the PKC issuer is not usually authoritative for the authorization
   information.  This results in additional steps for the PKC issuer
to
   obtain authorization information from the authoritative source."

Now than we have a standard to solve this problem, lets use it!

We need applications using this standard, not another discussion to
define a
new standard, to need again, applications using the new standard. We
could
repeat this circle as many times as we want.

Best regards,

Roberto Opazo

> -----Mensaje original-----
> De: [e-mail]
> [mailto:[e-mail]]En nombre de Anders Rundgren
> Enviado el: viernes, 04 de octubre de 2002 12:24
> Para: [e-mail]; Guida, Richard [JJCUS]
> Asunto: Re: Employee Certificates - Security Issues
>
>
>
> Richard,
> I think you have mostly misinterpreted my messages.
>
> Employee-PKI means (I do at least), that the employee has a
> certificate that allows him/her to act on behalf on their employer.
>  This is
> a fundamental characteristic of the US Federal PKI and commercial
> efforts like Identrus.
>
> What I'm saying is that this opens the organization to massive
> and non-controllable attacks from disloyal employees etc.  It is a
> smart as giving the entire work-force company credit-cards.
>
> Regarding the market, it is interesting to note that there is not a
> business system maker of any significance that support a model
> where the client's certificate and signature is a part of
> _outgoing_ messages.  In the same way as there is not a single bank
> in the
> world that does this either.  And this fact is completely
> independent of the availability of client-side PKI.
>
> Note: Client-side PKI is absolutely not a bad idea, it is
> the idea to hand over specific "company keys" to employees
> that is not such a terribly good idea.
>
> Anders

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQEVAwUBPaXpFwYqu9rjxyWVAQH7zgf+Ic7xANsvL+F3mh8ZbwZLumCnvQ1NqVvo
wEbclh2uScS5OONLL26tox8Xg8Ry9FW2StmKYnDApho9FAgEhk2L8VCxjcLXOGWz
/xCpLu/9A+vjvGD08RUrjr6ZieaS7AFSTR0+F73r7YSPbdViuS6uQdxRzX3dZtxE
+MRlvFuBza3ztli9UYqgAJurzBPNAMyz3umWTA+mFcE1b135ADjWcaTD+rqrKCdt
sMqioErpC/mpk7BD7AVL6pJ3/emtAvU6JgvwFqrJ6N9dD6/+a4oyeSalcQJB/7sJ
hK7IgnLrlqQFKrsI1FHU79DFhyRWDZULnq91ckm23NyWF/tSa3suXQ==
=eHct
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9AKCj104255 for ietf-pkix-bks; Thu, 10 Oct 2002 13:12:45 -0700 (PDT)
Received: from CORPSRV1.Alacris.com ([64.26.153.194]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9AKCiv04251 for <[e-mail]>; Thu, 10 Oct 2002 13:12:44 -0700 (PDT)
Content-Class: urn:content-classes:message
Subject: RE: OCSP Nonce Syntax
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27099.6118D600"
Date: Thu, 10 Oct 2002 16:12:38 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP Nonce Syntax
thread-index: AcJuOdf59GU5CfwiTM2JgkILrkKYzwCXuMrA
From: "Denis Issoupov" <[e-mail]>
To: "mars" <[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>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C27099.6118D600
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I think, it does not matter unless it's a valid ASN.1 object.
A responder should not care on the value of the nonce, but just include
it in a response.
But OCTET STRING is more preferred than INTEGER, because INTEGER
requires additional operations on encoding/decoding.
Denis Issoupov
Senior Software Developer
ALACRIS Inc.
* Voice: 613-230-9762 x239  * Fax: [phone]
* Cell: 613-294-5948
* E-mail: [e-mail] * Web: www.alacris.com
Find out more about the best OCSP Client for Windows at
<http://www.ocspclient.com/> http://www.ocspclient.com
=20
-----Original Message-----
From: mars [mailto:[e-mail]]=20
Sent: Monday, October 07, 2002 1:54 PM
To: [e-mail]
Subject: OCSP Nonce Syntax


Which RFCs or drafts contain a definition for a Nonce, besides 3161
(which uses an INTEGER)?=20
Is it a standard practice to encode the NONCE as an OCTET STRING for
OCSP?
=20
Thanks in advance,
=20
Miguel A. Rodriguez
SeguriDATA
Mexico
=20

------_=_NextPart_001_01C27099.6118D600
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 6.00.2719.2200" name=3DGENERATOR>
<META content=3D"Microsoft Word 10" name=3DOriginator><LINK=20
href=3D"cid:filelist.xml@01C26E00.98D7A580" =
rel=3DFile-List><o:SmartTagType=20
name=3D"country-region"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[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:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 90.0pt =
72.0pt 90.0pt; mso-header-margin: 35.4pt; mso-footer-margin: 35.4pt; =
mso-paper-source: 0; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: =
personal-compose; mso-style-noshow: yes; mso-ansi-font-size: 10.0pt; =
mso-bidi-font-size: 10.0pt; mso-ascii-font-family: Arial; =
mso-hansi-font-family: Arial; mso-bidi-font-family: Arial
}
SPAN.SpellE {
	mso-style-name: ""; mso-spl-e: yes
}
SPAN.GramE {
	mso-style-name: ""; mso-gram-e: yes
}
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:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	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 style=3D"tab-interval: 36.0pt" vLink=3Dpurple =
link=3Dblue>
<DIV>
<DIV><SPAN class=3D015260320-10102002><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
think, it does not matter unless it's a valid ASN.1 =
object.</FONT></SPAN></DIV>
<DIV><SPAN class=3D015260320-10102002><FONT face=3DArial color=3D#0000ff =

size=3D2>A&nbsp;responder should not care on the value of the nonce, but =

just&nbsp;include it in&nbsp;a response.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D703590720-10102002>But </SPAN>OCTET STRING<SPAN =
class=3D703590720-10102002>=20
is&nbsp;more preferred than INTEGER, because&nbsp;INTEGER&nbsp;requires=20
additional operations on =
encoding/decoding.</SPAN></FONT></FONT></FONT></DIV><!-- Converted from =
text/plain format -->
<P align=3Dleft><FONT size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial; mso-no-proof: yes">Denis=20
Issoupov</SPAN><B><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial; mso-no-proof: yes"><BR></SPAN></FONT></B><FONT=20
face=3DArial color=3Dgray size=3D1><SPAN=20
style=3D"FONT-SIZE: 8pt; COLOR: gray; FONT-FAMILY: Arial; mso-no-proof: =
yes">Senior=20
Software Developer<BR>ALACRIS Inc.<BR></SPAN></FONT><FONT =
face=3DWingdings=20
color=3Dgray size=3D3><SPAN=20
style=3D"COLOR: gray; FONT-FAMILY: Wingdings; mso-no-proof: =
yes">(</SPAN></FONT><FONT=20
face=3DArial color=3Dgray size=3D1><SPAN=20
style=3D"FONT-SIZE: 8pt; COLOR: gray; FONT-FAMILY: Arial; mso-no-proof: =
yes">=20
Voice: 613-230-9762 x239&nbsp; </SPAN></FONT><FONT face=3DWingdings =
color=3Dgray=20
size=3D3><SPAN=20
style=3D"COLOR: gray; FONT-FAMILY: Wingdings; mso-no-proof: =
yes">1</SPAN></FONT><FONT=20
face=3DArial color=3Dgray size=3D1><SPAN=20
style=3D"FONT-SIZE: 8pt; COLOR: gray; FONT-FAMILY: Arial; mso-no-proof: =
yes"> Fax:=20
613-230-9702<BR></SPAN></FONT><FONT face=3DWingdings color=3Dgray =
size=3D3><SPAN=20
style=3D"COLOR: gray; FONT-FAMILY: Wingdings; mso-no-proof: =
yes">(</SPAN></FONT><FONT=20
face=3DArial color=3Dgray size=3D1><SPAN=20
style=3D"FONT-SIZE: 8pt; COLOR: gray; FONT-FAMILY: Arial; mso-no-proof: =
yes">=20
Cell: 613-294-5948<BR></SPAN></FONT><FONT face=3DWingdings color=3Dgray =
size=3D3><SPAN=20
style=3D"COLOR: gray; FONT-FAMILY: Wingdings; mso-no-proof: =
yes">+</SPAN></FONT><FONT=20
face=3DArial color=3Dgray size=3D1><SPAN=20
style=3D"FONT-SIZE: 8pt; COLOR: gray; FONT-FAMILY: Arial; mso-no-proof: =
yes">=20
E-mail: </SPAN></FONT><U><FONT face=3DArial color=3Dblue size=3D1><SPAN=20
style=3D"FONT-SIZE: 8pt; COLOR: blue; FONT-FAMILY: Arial; mso-no-proof: =
yes"><A=20
href=3D"mailto:[e-mail]">[e-mail]</A></SPAN></FON=
T></U><FONT=20
face=3DWingdings color=3Dgray size=3D3><SPAN=20
style=3D"COLOR: gray; FONT-FAMILY: Wingdings; mso-no-proof: yes">=20
&amp;</SPAN></FONT><FONT face=3DArial color=3Dgray size=3D1><SPAN=20
style=3D"FONT-SIZE: 8pt; COLOR: gray; FONT-FAMILY: Arial; mso-no-proof: =
yes"> Web:=20
</SPAN></FONT><U><FONT face=3DArial color=3Dblue size=3D1><SPAN=20
style=3D"FONT-SIZE: 8pt; COLOR: blue; FONT-FAMILY: Arial; mso-no-proof: =
yes">www.alacris.com</SPAN></FONT></U></FONT></P>
<P align=3Dleft><SPAN=20
style=3D"FONT-SIZE: 8pt; COLOR: blue; FONT-FAMILY: Arial; mso-no-proof: =
yes"><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial; mso-no-proof: yes"><FONT=20
color=3D#0000ff>Find out more about the best OCSP Client for Windows at =
</FONT><A=20
href=3D"http://www.ocspclient.com/"><FONT=20
color=3D#0000ff>http://www.ocspclient.com</FONT></A></SPAN></SPAN></P></D=
IV>
<P align=3Dleft><SPAN=20
style=3D"FONT-SIZE: 8pt; COLOR: blue; FONT-FAMILY: Arial; mso-no-proof: =
yes"><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial; mso-no-proof: yes"></SPAN></SPAN>&nbsp;</P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> mars =

  [mailto:[e-mail]] <BR><B>Sent:</B> Monday, October 07, 2002 =
1:54=20
  PM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> OCSP Nonce=20
  Syntax<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Which <SPAN=20
  class=3DSpellE>RFCs</SPAN> or drafts contain a definition for a Nonce, =
besides=20
  3161 (which uses an INTEGER)? <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Is it a standard =
practice to=20
  encode the NONCE as an OCTET STRING for =
OCSP?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Thanks in=20
  advance,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-no-proof: =
yes">Miguel A.=20
  Rodriguez</SPAN></FONT><SPAN style=3D"mso-no-proof: =
yes"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-no-proof: =
yes">SeguriDATA</SPAN></FONT><SPAN=20
  style=3D"mso-no-proof: yes"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><st1:country-region><st1:place><FONT face=3DArial =

  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-no-proof: =
yes">Mexico</SPAN></FONT></st1:place></st1:country-region><o:p></o:p></P>=

  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML=
>

------_=_NextPart_001_01C27099.6118D600--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9ADgYo10280 for ietf-pkix-bks; Thu, 10 Oct 2002 06:42:34 -0700 (PDT)
Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9ADgTv10266 for <[e-mail]>; Thu, 10 Oct 2002 06:42:29 -0700 (PDT)
Received: from sgupta (68.100.200.151) by mail.san.yahoo.com (6.5.029) id 3DA55E620000D49A; Thu, 10 Oct 2002 06:40:29 -0700
Reply-To: <[e-mail]>
From: "Sarbari Gupta" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Identifying the right CRL for a given certificate
Date: Thu, 10 Oct 2002 09:41:53 -0400
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.4807.1700
In-Reply-To: <006101c26b3b$9c4d4f70$0a00a8c0@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,

As you indicated, the additional constraints on CRL validation should be
added to the PKI standards. Otherwise there seems to be a security hole if
the certificate and CRL are validated up to different trust anchors, while
matching the two based only upon names.

Thanks for your explanation of 6.3.3 (2)(b)(i) related to CRL processing.
While what you wrote makes sense, (assuming that all of the prior decisions
in this portion of the standard makes sense,) it is unfortunate that the
text of the standard leaves so much to interpretation, and familiarity with
the standard's evolution.

One of the problems that I have noticed with the X.509 and PKIX specs is the
tendency to overload fields to mean different things at different times. A
case at point is the overloading of the Distribution Points (DP) field.

Within the CDP extension of a certificate,
	a) the DP field defines the "location" of the CRL regardless of whether it
is a full or partitioned CRL
	b) the Reasons field determines whether the CA issues partitioned CRLs
based upon a subset of the reasons
	c) the cRLIssuer field indicates that the CRL issuer is different from the
certificate issuer

However, in the IDP extension of a CRL
	a) the existence of the DP field signals a partitioned CRL, AS WELL AS the
location of the CRL - WHY IS THIS OVERLOADING DONE?
	b) the onlySomeReasons field also determines whether this is a partitioned
CRL - WHY CAN'T THIS BE THE DEFINITIVE INDICATOR FOR A PARTITIONED CRL
INSTEAD OF THE DP FIELD?
	c) the indirectCRL boolean indicates that the CRL issuer is different from
the certificate issuer

As I indicated before, the CRL handling description of X.509 and PKIX could
definitely be improved in terms of simplicity and clarity.

Respectfully,

- Sarbari
==============================
Sarbari Gupta
Electrosoft Services, Inc.
Tel: [phone]
Cell:[phone]
FAX: [phone]
Email:  [e-mail]
Web: <http://www.electrosoft-inc.com>
==============================
-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, October 03, 2002 8:19 PM
To: [e-mail]; [e-mail]
Subject: RE: Identifying the right CRL for a given certificate


Sarbari:

See my comments in-line in [].

-----Original Message-----
From: Sarbari Gupta [mailto:[e-mail]]
Sent: Wednesday, October 02, 2002 11:42 PM
To: Santosh Chokhani; [e-mail]
Subject: RE: Identifying the right CRL for a given certificate


Santosh,

I like the flavor of the new constraints on CRL validation that you have
specified.

You're also right about 2a and 2b. I should probably have expressed them
as:

	a) If the same Issuer entity signs both the certificate and the
CRL, then the Issuer Names of both have to match
	b) If different Issuers sign the certificate and CRL,
then the Issuer Name of the CRL has to match the cRLIssuer in the CDP
extension of the certificate.
c
[I agree]

However, the point I was trying to make was that in pairing up a
certificate and CRL, 6.3.3 specifies that only the Issuer Name matches
are of relevance (ignoring delta CRLs and partitioned CRLs).

I can think of a simple case where this may be a problem in the current
RFC 3280. Assume that the certificate CERT1 asserts the CDP extension
with no cRLIssuer and a single DP field which represents the address for
LDAP retrieval of the associated CRL. There happens to be a CRL CRL2 in
the Relying Party's local cache that has the same Issuer Name as CERT1;
however, CRL2 verifies under a different trust anchor than CERT1.
According to RFC 3280, CRL2 is acceptable for CERT1. Intuitively,
though, we know this is incorrect - there needs to be something more
than a simple name match and the ability to verify CRL2 to one of the
trust roots. The bottom line is that pairing up certificates and CRLs
based on issuer names without constraining them to be verifiable under
the same trust root, makes 6.3.3 rather weak.

[I agree.  That is why I have listed the three rules above]

AN ADDITIONAL POINT:
I also think the area of CRL usage and validation (with respect to a
given
certificate) needs to be less complex and more specific.

[I am not sure it can be made less complex]

For example, Section 6.3.3 item (2)(b)(i) states:

"If the distribution point name is present in the IDP CRL extension and
the distribution point is omitted from the DP (field of the CDP
extension in the
certificate) then verify that one of the names of the IDP matches one of
the names in the cRLIssuer field of the DP."

I don't understand the reason for this complication at all. If the DP
field is not present in the CDP extension in the certificate, why does
it make sense for the CRL IDP extension to have a distribution point
name, and why does this need to match the cRLIssuer field in the
certificate?

[RFC 3280 is correct in this regard.  Here are the answers to your
questions.  If you have a CRL that asserts a DP field in the IDP
extension, the relying party does not know whether it is a full CRL.
Thus, relying party must determine whether the CRL is relevant for the
certificate.  That is where CDP comes in.  Normally, DP in IDP should be
matched with DP in CDP.  But, in order not overload the certificate, if
CDP asserts cRLIssuer, that name is the DP by default unless a full name
or name relative to cRLIssuer is asserted.  Please look at the syntax of
the CDP extension carefully.  Thus, given that the IDP had DP and the
CDP does not, DP in IDP must match the cRLIssuer]

My suggestion would be to delete this portion of (2)(b)(i) altogether.
[That would be WRONG]

A related suggestion would be to require that is the certificate asserts
the DP field in the CDP extension, then the related CRL MUST assert the
distribution point field of the IDP extension and the two must match up
in order to be acceptable as a pair.

[Again, in the area of path processing, just because the certificate
asserts a DP, does not mean you can not use a full CRL, i.e., a CRL that
does not assert DP in IDP.  You should be able to either accept a full
CRL or a CRL whose IDP has the same DP.  I think that is what 3280 is
trying to say.  Thus, rejecting full CRL and only accepting an IDP CRL
in this case will be unnecessarily limiting.  I encourage you to review
Annex B in X.509 for CRL processing.  That may be a bit easier to follow
that 3280.  That Annex also provides some background material to make
the CRL processing more understandable.]

- Sarbari
==============================
Sarbari Gupta
Electrosoft Services, Inc.
Tel: [phone]
Cell:[phone]
FAX: [phone]
Email:  [e-mail]
Web: <http://www.electrosoft-inc.com> ==============================

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Wednesday, October 02, 2002 9:18 PM
To: [e-mail]; [e-mail]
Subject: RE: Identifying the right CRL for a given certificate


Sarbari:

Section 6.3.3 of 3280 does not imply anything regarding your assertions
2a and 2b.  It is not clear to me as to how you arrived at 2a and 2b. In
Section 6.3.3 of 3280, the operative item for the CRL signing key is
bullet f which states:

(f)  Obtain and validate the certification path for the complete CRL
   issuer.  If a key usage extension is present in the CRL issuer's

I agree that the RFC is missing guidance on CRL path building.  In my
mind a CRL path must be further constrained by the following rule:

1.  The trust must emanate from the same trust anchor as the
certification path for certificate for which the CRL is being sought.

2.  The DNs for the certification path for the certificate should match
the DNs for the certification path for the CRL (ignoring self-issued
certificates).  Of course, the last DN (namely the subscriber DN) will
be missing from the CRL certification path.

3.  The CRL certification path must be good for the same policy as the
subscriber.

I am not a CA product vendor and hence can not answer your other
questions.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Sarbari Gupta
Sent: Wednesday, October 02, 2002 4:30 PM
To: [e-mail]
Subject: Identifying the right CRL for a given certificate



I have been reviewing the RFC 3280 specs to understand how to identify
the correct CRL for a given certificate, and made the following
observations:

1) It appears to be possible to validate a certificate along a path that
leads to trust anchor TA1, while validating the CRL for that certificate
along a path that leads to trust anchor TA2. Intuitively, this seems
like a bad idea, however, I have not stumbled across anything in the RFC
that restricts Relying Parties from allowing this behavior.

2) Section 6.3.3 of the RFC seems to indicate that the primary means of
pairing up a certificate with the appropriate CRL are as follows:

	a) If the same key signs both the certificate and the CRL, then
the Issuer Names of both have to match
	b) If different keys are used to sign the certificate and CRL,
then the Issuer Name of the CRL has to match the cRLIssuer in the CDP
extension of the certificate

If this observation is coupled with observation (1) above, there seems
to be a possible security problem in matching on name fields when the
certificate and CRL emanate from different trust roots. This is
especially alarming since most of us have a large number of preloaded
trust roots in our systems, and it is possible that the same DN is used
within two different trust domains, either intentionally or
unintentionally.

3) Although it is acceptable that the same or different private keys are
used to sign certificates and CRLs for a given CA, there seems to be no
definition of conforming behavior for Relying Parties that says RPs
SHOULD be able to deal with both scenarios. The result is that certain
vendor's RPs only support one scenario or the other, leading to
non-interoperable implementations although both are in compliance with
the standard.

Am I missing something? I welcome comments.

Also, it would be very interesting to find out how the different vendors
have implemented the functionality to pair up certificates with the
correct CRLs.

==============================
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 g99Ea1x18037 for ietf-pkix-bks; Wed, 9 Oct 2002 07:36:01 -0700 (PDT)
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 g99Ea0v18023 for <[e-mail]>; Wed, 9 Oct 2002 07:36:00 -0700 (PDT)
Subject: RE: The Bank-model  Was: Employee Certificates - Security  Issues
To: "=?iso-8859-1?Q?S=E4rs=2C_Camillo?=" <[e-mail]>
Cc: "=?iso-8859-1?Q?S=E4rs=2C_Camillo?=" <[e-mail]>, [e-mail], "J Adrian Pickering" <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 9 Oct 2002 08:35:06 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 10/09/2002 10:38:55 AM
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 g99Ea0v18027
Sender: [e-mail]
Precedence: 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 some extent the PKI model is patterned after offline credit cards of the
'60s ... except substituting offline electronic bits in place of plastic &
paper. Except for legacy compatibility, the infrastructure migrated to a
online, electronic model in the '70s ... while PKI in the '80s somewhat
took a step backward to an offline, electronic model. Part of the '80s PKI
issue was addressing offline email (download email, hangup need some way to
authenticated w/o having any sort of online connectivity).

In the 90s there was some activity expanding certificate information for
the business market to emulate signing limit checks .... and various pieces
of that information has migrated to some of the attribute certificate
efforts. The point of the signing limit checks was to provide some means to
distribute/allow certain employee purchasing capability while still
limiting some of the earlier fraud activities (letter head or employee ID
based, w/o incuring the overhead of purchasing department approval).

The relative benefit of the signing limit checks was that there was some
small control on the total number such checks a person might posses ...
while current attribute certificate technology bascially allows an
attribute certificate to be re-used an unlimited number of times. However,
even in the case of signing limit checks ... there was still fraud
appearing using multiple such checks to bypass total aggregate controls
(aka a person using 200 $5000 limit checks to make million dollar
purchases). In part, the migration to purchase cards was in response to the
type of fraud with (attribute certificate analogous) signing limit checks
.... using the online electronic model enables (real-time) aggregation &
velocity controls (aka X amount total per month, etc) in addition to
optional other controls available from level3 data .... merchant, merchant
location, SKU.

Straight attribute certificate could be a return to just letterhead type
fraud ... or with a little additional information, they could approximate
checks with signing limit type fraud .... although in some ways the
repeated use of an attribute certificate is simpler than fraud involving
the repeated use of signing limit checks.

At its simplest, the financial industry X9.59 standard adds the benefit of
digital signature authentication & integrity to existing payment cards
(credit, debit, purchase, stored-value) within the context of existing
online electronic business controls .... w/o having to take a
step-backwards to an electronic, offline model.

misc.
http://www.garlic.com/~lynn/subtopic.html#privacy
http://www.garlic.com/~lynn/subtopic.html#fraud
http://www.garlic.com/~lynn/subtopic.html#rpo
http://www.garlic.com/~lynn/index.html#x959


sars. camillo <[e-mail]> on 10/9/2002 1:52 am wrote:

>I can have an individual certificate 'J Adrian Pickering' that
>I obtain, perhaps issued by a government authority much like a passport.

In that case, you would only want to ever use that certificate in use cases
where an official proof of citizenship is required.  Any use beyond that
use
case violates the principle of least authority.  It also exposes you to may
privacy risks.  In my layman interpretation of EU privacy directives, it
may
also be illegal.  (Admittedly, I blatantly disregard the fact that even
some
EU efforts in the above direction exist.)

> When I work for Company X in role Y, the Company issues me with an
appropriate
> attribute certificate. The two, when used together, are applied to
Company
> transactions and are understood by the recipient to mean 'this
> individual has signed this transaction on behalf of company x in their
> role as y'.

This model unnecessarily ties two unrelated facets of your identity to each
other.  If used as such, when you sign something on behalf of company x,
you
are as a matter of fact *also* attesting to your citizenship in country z.
I
fail to see why this would be necessary or even desired.

> This is just like a traditional legal document where an
> individual signs and it is endorsed by the company seal.

This is *incredibly* unlike traditional legal documents.  It is a brilliant
example of why comparing PKI with traditional signatures proves why "analog
<-> digital" analogies are so dangerous.

In many jurisdictions, there is little formal requirements on an individual
signature.  There may be requirements on a company seal.  But I digress.

If I work for Company X in role Y, I would expect the company to issue me
with an appropriate identity certificate [possibly anonymous].  The company
might choose to initially require me to present a government issued
identity
certificate to establish my "true identity", but beyond that point my
citizenship in "z" is fairly irrelevant to the company. I would also be
granted an attribute certificate for role Y, tied to identity X.  All this
on
the assumption that the company would use X.509-type identity
certification.

In reality, in my current roles, I would probably have to have several
identity certificates.  My "identity" varies depending on whom I am talking
to.  Right now, I am writing this email as a personal message in my role as
security researcher.  I would prefer not to sign such a message with an
identity certificate that would also be used to sign official company
statements, because the deployed X.509 S/MIME infrastructure does not
support
attribute certificates.

The entire concept of trying to issue an "identity certificate" that is
useful in many contexts seems misguided to me.  Such a certificate would
quickly grow to become a dossier.  Personal dossiers are necessarily highly
confidential.

> I am still free to sign 'cheques' with my personal certificate whether
I'm in
> the employ of the company or not.

I would not sign cheques with a passport [pardon the bad analogy].
Actually,
it seems fairly evident from litterature that cheques need not be tied to
identities in any meaningful way.  Cheques are only concerned with the
matter
of credit.  If I would create a [public-key based] system which attests to
valid credit without using identities, it would serve me well.

> Apologies in advance if I'm beating an old drum,

Apologies in advance if I'm doing the same.

Regards,
Camillo Särs
--
Camillo Särs <[e-mail]>          http://www.iki.fi/ged/
Senior Security Researcher, F-Secure Corporation  http://www.F-Secure.com

          F-Secure products: Securing the Mobile Enterprise




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g997qw609362 for ietf-pkix-bks; Wed, 9 Oct 2002 00:52:58 -0700 (PDT)
Received: from dfmail.f-secure.com (dfmail.f-secure.com [194.252.6.39]) by above.proper.com (8.11.6/8.11.3) with SMTP id g997quv09354 for <[e-mail]>; Wed, 9 Oct 2002 00:52:57 -0700 (PDT)
Received: (qmail 30340 invoked by uid 0); 9 Oct 2002 07:52:37 -0000
Received: from fsav4im2.f-secure.com (HELO fsav4im2) (193.110.108.82) by dfmail.f-secure.com with SMTP; 9 Oct 2002 07:52:37 -0000
Received: from [10.128.128.81]:46216 (HELO dfintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Wed, 9 Oct 2002 07:56:04 -0000
Received: (qmail 5650 invoked from network); 9 Oct 2002 07:52:33 -0000
Received: from unknown (HELO fsfimail1.fi.f-secure.com) (10.128.128.19) by dfintra.f-secure.com with SMTP; 9 Oct 2002 07:52:33 -0000
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: The Bank-model  Was: Employee Certificates - Security  Issues
Date: Wed, 9 Oct 2002 10:52:33 +0300
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: The Bank-model  Was: Employee Certificates - Security  Issues
Thread-Index: AcJvIN0bssav8e57RMydrlJ0sMJ2AwARRDHw
From: =?iso-8859-1?Q?=22S=E4rs=2C_Camillo=22?= <[e-mail]>
To: "J Adrian Pickering" <[e-mail]>, <[e-mail]>
Cc: =?iso-8859-1?Q?=22S=E4rs=2C_Camillo=22?= <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g997qwv09358
Sender: [e-mail]
Precedence: 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 can have an individual certificate 'J Adrian Pickering' that 
>I obtain, perhaps issued by a government authority much like a passport. 

In that case, you would only want to ever use that certificate in use cases
where an official proof of citizenship is required.  Any use beyond that use
case violates the principle of least authority.  It also exposes you to may
privacy risks.  In my layman interpretation of EU privacy directives, it may
also be illegal.  (Admittedly, I blatantly disregard the fact that even some
EU efforts in the above direction exist.)

> When I work for Company X in role Y, the Company issues me with an
appropriate 
> attribute certificate. The two, when used together, are applied to Company 
> transactions and are understood by the recipient to mean 'this 
> individual has signed this transaction on behalf of company x in their 
> role as y'. 

This model unnecessarily ties two unrelated facets of your identity to each
other.  If used as such, when you sign something on behalf of company x, you
are as a matter of fact *also* attesting to your citizenship in country z.  I
fail to see why this would be necessary or even desired.

> This is just like a traditional legal document where an 
> individual signs and it is endorsed by the company seal.

This is *incredibly* unlike traditional legal documents.  It is a brilliant
example of why comparing PKI with traditional signatures proves why "analog
<-> digital" analogies are so dangerous.

In many jurisdictions, there is little formal requirements on an individual
signature.  There may be requirements on a company seal.  But I digress.

If I work for Company X in role Y, I would expect the company to issue me
with an appropriate identity certificate [possibly anonymous].  The company
might choose to initially require me to present a government issued identity
certificate to establish my "true identity", but beyond that point my
citizenship in "z" is fairly irrelevant to the company. I would also be
granted an attribute certificate for role Y, tied to identity X.  All this on
the assumption that the company would use X.509-type identity certification.

In reality, in my current roles, I would probably have to have several
identity certificates.  My "identity" varies depending on whom I am talking
to.  Right now, I am writing this email as a personal message in my role as
security researcher.  I would prefer not to sign such a message with an
identity certificate that would also be used to sign official company
statements, because the deployed X.509 S/MIME infrastructure does not support
attribute certificates.

The entire concept of trying to issue an "identity certificate" that is
useful in many contexts seems misguided to me.  Such a certificate would
quickly grow to become a dossier.  Personal dossiers are necessarily highly
confidential.

> I am still free to sign 'cheques' with my personal certificate whether I'm
in 
> the employ of the company or not.

I would not sign cheques with a passport [pardon the bad analogy].  Actually,
it seems fairly evident from litterature that cheques need not be tied to
identities in any meaningful way.  Cheques are only concerned with the matter
of credit.  If I would create a [public-key based] system which attests to
valid credit without using identities, it would serve me well.

> Apologies in advance if I'm beating an old drum,

Apologies in advance if I'm doing the same.

Regards,
Camillo Särs
-- 
Camillo Särs <[e-mail]>          http://www.iki.fi/ged/
Senior Security Researcher, F-Secure Corporation  http://www.F-Secure.com

          F-Secure products: Securing the Mobile Enterprise


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g98MToS18547 for ietf-pkix-bks; Tue, 8 Oct 2002 15:29:50 -0700 (PDT)
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 g98MTnv18540 for <[e-mail]>; Tue, 8 Oct 2002 15:29:49 -0700 (PDT)
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 05B3F160080EE for <[e-mail]>; Tue,  8 Oct 2002 23:29:43 +0100 (BST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 08 Oct 2002 23:29:09 +0100
To: <[e-mail]>
From: J Adrian Pickering <[e-mail]>
Subject: Re: The Bank-model  Was: Employee Certificates - Security Issues
In-Reply-To: <007901c26f05$62ba6ea0$0500a8c0@arport>
References: <[e-mail]> <001c01c26e30$1b70d460$0500a8c0@arport> <[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>

This discussion seems to be circling around the issue of roles. I thought 
that Attribute Certificates were invented to solve this? Someone did 
mention this but I'm not sure there was an answer.

I can have an individual certificate 'J Adrian Pickering' that I obtain, 
perhaps issued by a government authority much like a passport. When I work 
for Company X in role Y, the Company issues me with an appropriate 
attribute certificate. The two, when used together, are applied to Company 
transactions and are understood by the recipient to mean 'this individual 
has signed this transaction on behalf of company x in their role as y'. 
This is just like a traditional legal document where an individual signs 
and it is endorsed by the company seal.

When I leave the company or the company leaves me, then I retain my 
personal certificate but the 'keys of the office' (aka seal) are taken away 
from me i.e. the attribute certificate. I am still free to sign 'cheques' 
with my personal certificate whether I'm in the employ of the company or 
not. I am also free to be employed at other companies who will also issue 
appropriate ACs.

The recipient is always left to work out whether that means the transaction 
is valid or not i.e. if the signatory is authorised to make a binding 
contract. PKI provides the tools to help make this assessment.

Are we still working with unrelated certificates or do we still believe in 
ACs? Apologies in advance if I'm beating an old drum,

Adrian Pickering/
ECS, University of Southampton, UK



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g98KEJC11693 for ietf-pkix-bks; Tue, 8 Oct 2002 13:14:19 -0700 (PDT)
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 g98KEIv11686 for <[e-mail]>; Tue, 8 Oct 2002 13:14:18 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 8 Oct 2002 20:14: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 QAA04075 for <[e-mail]>; Tue, 8 Oct 2002 16:14:20 -0400 (EDT)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g98KBnQ09320 for <[e-mail]>; Tue, 8 Oct 2002 16:11:49 -0400 (EDT)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <4J1RXHNW>; Tue, 8 Oct 2002 13:14:18 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.16]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPV8917; Tue, 8 Oct 2002 16:14:08 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 08 Oct 2002 16:09:56 -0400
Subject: draft-ietf-pkix-logotypes-06.txt
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>

We just posted an update to the logotypes draft.  There are two primary 
changes from the previous version.  First, we tried to be more clear about 
what is mandatory to implement and what is not.  Second, we added support 
for more than one hash function without having to repeat a lot of data.

The loudest objections (as opposed to jokes) came from Microsoft.  Based on 
discussions with Trevor Freeman, I believe that Microsoft can accept this 
version.

We are still in Working Group Last Call.....

Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g98K7fP10811 for ietf-pkix-bks; Tue, 8 Oct 2002 13:07:41 -0700 (PDT)
Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g98K7ev10807 for <[e-mail]>; Tue, 8 Oct 2002 13:07:40 -0700 (PDT)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maila.telia.com (8.12.5/8.12.5) with SMTP id g98K7fkf004506; Tue, 8 Oct 2002 22:07:41 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <007901c26f05$62ba6ea0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "David Maurus" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <001c01c26e30$1b70d460$0500a8c0@arport> <[e-mail]>
Subject: The Bank-model  Was: Employee Certificates - Security Issues
Date: Tue, 8 Oct 2002 22:00:43 +0200
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>

David,

Nema Problema, here it is:

Using the time-proven Internet-bank model, clients (= employees)
get keys (some kind of...) to their accounts, but never ever the
"bank-keys", as the latter are exclusively used for _authorized_
inter-bank  (= inter-organization) communication.  I.e.
the latter "execute" on a secure server only.

The "bank model", which was from the earliest days (1700?)
heavily founded on accountability and security, has a long-
term _sustainability_ due to its "trust-center" foundation.

The bank-model allows arbitrary complex authorization
messages as they are created on a server that can in a
single message pack signed authority documents from
various external authorities.  This removes the need
for updating authorization data out-of-band as the
"payload" contains everything you need.  Or could at least.

As purchase orders do not require personal signatures
to be honored, a procurement system simply "stamps"
outgoing purchase orders using the organization key.
It also means that it is impossible to create a valid
purchase order except going through the procurement
system giving non-intrusive (invisible, as long as
you stick to the rules) archiving, user control, 
privacy protection and a simple stable digital identity 
to trading partners.  The latter is extremely important
particularly given the pretty crude products currently
offered by commercial CAs.

A legally binding court verdict is likely to require a bit
more.  A dual-signed message seems like a possibility.
Judge + Court where the court's authoritative
signature is at the outermost layer to be valid.  Well, there
could be an additional TSA signature as well.

I just talked to a very experienced person from the
Swedish health-sector who claimed that this model is
_exactly_ what they are thinking of.  Regarding privacy
he had noticed that even badges nowadays have been
privacy-enhanced by having no SSNs and just
"John D, M.D." as clients could harass staff.

A document is in preparation based on the feedback
gathered in many discussions including those on
this list.  Stay tuned!

cheers,
Anders

----- Original Message ----- 
From: "David Maurus" <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, October 08, 2002 19:50
Subject: Re: Employee Certificates - Security Issues



[forgot to copy the list, so here again:]
Anders,

Anders Rundgren wrote:

> Actually I would be extremely happy if someone else wrote
> how a simple thing like a purchase order should be handled
> in a classical enterprise-PKI, including possible business
> systems.  Without such a description this entire thread
> becomes both unintelligible and pretty boring.
>
As most people on this list probably have a vision of how a purchase 
order in the context of a classical enterprise-PKI would work, I think 
it would also help to increase the value of this thread if you would 
describe what you mean exactly by the term "Internet-bank model", 
especially in the context of PKI and signatures.

How would a purchase order work in your non-classical 
"Internet-bank-model"-PKI?

- David




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g98Hq5h02636 for ietf-pkix-bks; Tue, 8 Oct 2002 10:52:05 -0700 (PDT)
Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g98Hq3v02632 for <[e-mail]>; Tue, 8 Oct 2002 10:52:04 -0700 (PDT)
Received: from fwd04.sul.t-online.de  by mailout11.sul.t-online.com with smtp  id 17yyWQ-0001bt-02; Tue, 08 Oct 2002 19:51:54 +0200
Received: from mailbag.de (520021154063-0001@[217.80.41.135]) by fmrl04.sul.t-online.com with esmtp id 17yyW7-2BtjZQC; Tue, 8 Oct 2002 19:51:35 +0200
Message-ID: <[e-mail]>
Date: Tue, 08 Oct 2002 19:50:57 +0200
From: David Maurus <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Employee Certificates - Security Issues
References: <[e-mail]> <001c01c26e30$1b70d460$0500a8c0@arport>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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>

[forgot to copy the list, so here again:]
Anders,

Anders Rundgren wrote:

> Actually I would be extremely happy if someone else wrote
> how a simple thing like a purchase order should be handled
> in a classical enterprise-PKI, including possible business
> systems.  Without such a description this entire thread
> becomes both unintelligible and pretty boring.
>
As most people on this list probably have a vision of how a purchase 
order in the context of a classical enterprise-PKI would work, I think 
it would also help to increase the value of this thread if you would 
describe what you mean exactly by the term "Internet-bank model", 
especially in the context of PKI and signatures.

How would a purchase order work in your non-classical 
"Internet-bank-model"-PKI?

- David



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g98BGZB07635 for ietf-pkix-bks; Tue, 8 Oct 2002 04:16:35 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g98BGYv07630 for <[e-mail]>; Tue, 8 Oct 2002 04:16:34 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06329; Tue, 8 Oct 2002 07:14:29 -0400 (EDT)
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-06.txt
Date: Tue, 08 Oct 2002 07:14:28 -0400
Sender: [e-mail]
Precedence: 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-06.txt
	Pages		: 20
	Date		: 2002-10-7
	
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-06.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-06.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-06.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-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-logotypes-06.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 g985Wmd23470 for ietf-pkix-bks; Mon, 7 Oct 2002 22:32:48 -0700 (PDT)
Received: from mailout.zetnet.co.uk ([e-mail] [194.247.47.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g985Wlv23466 for <[e-mail]>; Mon, 7 Oct 2002 22:32:47 -0700 (PDT)
Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk) by mailout.zetnet.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 17ymzC-0005BR-00 for <[e-mail]>; Tue, 08 Oct 2002 06:32:50 +0100
Received: from zetnet.co.uk (bts-0280.dialup.zetnet.co.uk [194.247.49.24]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g985WjN14667 for <[e-mail]>; Tue, 8 Oct 2002 06:32:47 +0100
Message-ID: <[e-mail]>
Date: Tue, 08 Oct 2002 06:32:06 +0000
From: David Hopwood <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP Nonce Syntax
References: <001901c26e2a$820d0b90$[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>

-----BEGIN PGP SIGNED MESSAGE-----

"mars" <[e-mail]> wrote:
> Which RFCs or drafts contain a definition for a Nonce, besides 3161 (which
> uses an INTEGER)? 

See the earlier discussion in this group, archived at
<http://www.imc.org/ietf-pkix/mail-archive/thrd2.html#04040>, which
concluded that it should be an OCTET STRING.

<http://www.ietf.org/internet-drafts/draft-ietf-tls-extensions-05.txt>
(in the RFC queue) requires that it be an OCTET STRING for OSCP clients that
are used to implement the TLS 'status_request' extension.

- -- 
David Hopwood <[e-mail]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPaJ70TkCAxeYt5gVAQEILggAx/VDEJaT88pWUfbUqkLtnXPouTYH4ebW
YlFHXz3szLeQ4eJmesKboS/9bQVz6sFoLkhij0qk3OwJH3p5MP7CXfZ5QjwfSsNn
vWaya+RLuVoqIZ937g5nb+N98sIH+4motXD1hZTB3+hwyCMZI1K6qaKoAmyRdnfn
ALyXO0FeDqvOuuSHYDDh+1TP77tGX4Yc1nmb5EfFJxK9bHEtlGY0qONhQx/Simk5
f3ZeyO22vK3wLHREqDPnSOEjGhf10bONcaeV61+/wwSpkM+dSxxT2zi0Jutj2dlI
G8nXKtwT8RBiBmt+DO1BcRCyUkOFyDHoh7+qypM9OE399oLpONrkkA==
=6RhB
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g97MqLs29314 for ietf-pkix-bks; Mon, 7 Oct 2002 15:52:21 -0700 (PDT)
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 g97MqKv29310 for <[e-mail]>; Mon, 7 Oct 2002 15:52:20 -0700 (PDT)
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id g97MqIX1001924 for <[e-mail]>; Mon, 7 Oct 2002 15:52:18 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "IETF PKIX" <[e-mail]>
Subject: FW: OCSP Nonce Syntax
Date: Mon, 7 Oct 2002 16:02:32 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C26E1A.F18FE6A0"
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
Sender: [e-mail]
Precedence: 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_001D_01C26E1A.F18FE6A0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit


Sorry, forgot to cc the list on this response.

In addition, I would recommend that when people implement the nonce logic
on the responder side, they be prepared to accept nonces that are not
encoded as OCTET STRINGs, since there is software out there that
doesn't put them in OCTET STRINGs. Since all you need to do is
return the nonce in the response, this shouldn't be a problem.

Regards,
Ambarish
---------------------------------------------------------------------
Ambarish Malpani                                          650.759.9045
Malpani Consulting Services
[e-mail]                         http://www.malpani.biz



  -----Original Message-----
  From: Ambarish Malpani [mailto:[e-mail]]
  Sent: Monday, October 07, 2002 3:36 PM
  To: mars
  Subject: RE: OCSP Nonce Syntax



  Hi Mars,
      OCSP doesn't currently tell you how to encode the nonce. I need to
  clarify that to tell people to use an OCTET STRING - that was where the
  group concensus wanted it to go.

  Hope this helps,
  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 mars
    Sent: Monday, October 07, 2002 10:54 AM
    To: [e-mail]
    Subject: OCSP Nonce Syntax


    Which RFCs or drafts contain a definition for a Nonce, besides 3161
(which uses an INTEGER)?

    Is it a standard practice to encode the NONCE as an OCTET STRING for
OCSP?



    Thanks in advance,



    Miguel A. Rodriguez

    SeguriDATA

    Mexico



------=_NextPart_000_001D_01C26E1A.F18FE6A0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<META content=3D"Microsoft Word 10" name=3DOriginator><LINK=20
href=3D"cid:filelist.xml@01C26E00.98D7A580" =
rel=3DFile-List><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=20
name=3D"country-region"></o:SmartTagType><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=20
name=3D"place"></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:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 90.0pt =
72.0pt 90.0pt; mso-header-margin: 35.4pt; mso-footer-margin: 35.4pt; =
mso-paper-source: 0; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: =
personal-compose; mso-style-noshow: yes; mso-ansi-font-size: 10.0pt; =
mso-bidi-font-size: 10.0pt; mso-ascii-font-family: Arial; =
mso-hansi-font-family: Arial; mso-bidi-font-family: Arial
}
SPAN.SpellE {
	mso-style-name: ""; mso-spl-e: yes
}
SPAN.GramE {
	mso-style-name: ""; mso-gram-e: yes
}
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:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	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 style=3D"tab-interval: 36.0pt" vLink=3Dpurple =
link=3Dblue>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D077430023-07102002><FONT face=3DArial color=3D#0000ff =
size=3D2>Sorry,=20
forgot to cc the list on this response.</FONT></SPAN></DIV>
<DIV><SPAN class=3D077430023-07102002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D077430023-07102002><FONT face=3DArial color=3D#0000ff =
size=3D2>In=20
addition, I would recommend that when people implement the nonce=20
logic</FONT></SPAN></DIV>
<DIV><SPAN class=3D077430023-07102002><FONT face=3DArial color=3D#0000ff =
size=3D2>on the=20
responder side, they be prepared to accept nonces that are=20
not</FONT></SPAN></DIV>
<DIV><SPAN class=3D077430023-07102002><FONT face=3DArial color=3D#0000ff =

size=3D2>encoded as OCTET STRINGs, since there is software out there=20
that</FONT></SPAN></DIV>
<DIV><SPAN class=3D077430023-07102002><FONT face=3DArial color=3D#0000ff =

size=3D2>doesn't put them in OCTET STRINGs. Since all you need to do=20
is</FONT></SPAN></DIV>
<DIV><SPAN class=3D077430023-07102002><FONT face=3DArial color=3D#0000ff =
size=3D2>return=20
the nonce in the response, this shouldn't be a =
problem.</FONT></SPAN></DIV>
<DIV><SPAN class=3D077430023-07102002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D077430023-07102002><FONT face=3DArial color=3D#0000ff =

size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D077430023-07102002><FONT face=3DArial color=3D#0000ff =

size=3D2>Ambarish</FONT></SPAN></DIV>
<P><FONT=20
size=3D2>----------------------------------------------------------------=
-----<BR>Ambarish=20
Malpani&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
650.759.9045<BR>Malpani Consulting=20
Services&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[e-mail]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
<A href=3D"http://www.malpani.biz/"=20
target=3D_blank>http://www.malpani.biz</A><BR><BR></FONT></P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Ambarish Malpani=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Monday, October 07, 2002 =
3:36=20
  PM<BR><B>To:</B> mars<BR><B>Subject:</B> RE: OCSP Nonce=20
  Syntax<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <DIV><SPAN class=3D288183422-07102002><FONT face=3DArial =
color=3D#0000ff size=3D2>Hi=20
  Mars,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D288183422-07102002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp; OCSP doesn't currently tell you how to =
encode the=20
  nonce. I need to</FONT></SPAN></DIV>
  <DIV><SPAN class=3D288183422-07102002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>clarify that to tell people to use an OCTET STRING - that was =
where=20
  the</FONT></SPAN></DIV>
  <DIV><SPAN class=3D288183422-07102002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>group concensus wanted it to go.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D288183422-07102002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D288183422-07102002><FONT face=3DArial =
color=3D#0000ff size=3D2>Hope=20
  this helps,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D288183422-07102002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Ambarish</FONT></SPAN></DIV>
  <DIV>&nbsp;</DIV>
  <P><FONT=20
  =
size=3D2>----------------------------------------------------------------=
-----<BR>Ambarish=20
  =
Malpani&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  650.759.9045<BR>Malpani Consulting=20
  =
Services&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
[e-mail]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
  <A href=3D"http://www.malpani.biz/"=20
  target=3D_blank>http://www.malpani.biz</A><BR><BR></FONT></P>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B>=20
    [e-mail] =
[mailto:[e-mail]]<B>On=20
    Behalf Of </B>mars<BR><B>Sent:</B> Monday, October 07, 2002 10:54=20
    AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> OCSP Nonce=20
    Syntax<BR><BR></FONT></DIV>
    <DIV class=3DSection1>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Which <SPAN=20
    class=3DSpellE>RFCs</SPAN> or drafts contain a definition for a =
Nonce, besides=20
    3161 (which uses an INTEGER)? <o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Is it a standard =
practice to=20
    encode the NONCE as an OCTET STRING for =
OCSP?<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Thanks in=20
    advance,<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-no-proof: =
yes">Miguel A.=20
    Rodriguez</SPAN></FONT><SPAN=20
style=3D"mso-no-proof: yes"><o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-no-proof: =
yes">SeguriDATA</SPAN></FONT><SPAN=20
    style=3D"mso-no-proof: yes"><o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><st1:country-region><st1:place><FONT =
face=3DArial=20
    size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-no-proof: =
yes">Mexico</SPAN></FONT></st1:place></st1:country-region><o:p></o:p></P>=

    <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BLOCKQUOTE>=
</BODY></HTML>

------=_NextPart_000_001D_01C26E1A.F18FE6A0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g97KQZx25343 for ietf-pkix-bks; Mon, 7 Oct 2002 13:26:35 -0700 (PDT)
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 g97KQYv25339 for <[e-mail]>; Mon, 7 Oct 2002 13:26:34 -0700 (PDT)
Subject: Re: OCSP Nonce Syntax
To: "mars" <[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, 7 Oct 2002 14:11:14 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 10/07/2002 04:29:32 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>

a list of RFCs containing references to nonce or nonce useage, some just
have quoted string as definition, quite a few have integer. are you
referring to any nonce definition ... or specifically ASN.1 nonce
definition?

1492 1510 1969 2002 2005 2006 2069 2408 2409 2412 2419 2420 2510 2518 2522
2543 2617 2659 2660 2693 2792 2797 2828 2831 2930 2941 2943 2951 2985 3029
3087 3118 3161 3168 3220 3261 3310 3344  3360



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g97Iexe19447 for ietf-pkix-bks; Mon, 7 Oct 2002 11:40:59 -0700 (PDT)
Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g97Ievv19443 for <[e-mail]>; Mon, 7 Oct 2002 11:40:58 -0700 (PDT)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maila.telia.com (8.12.5/8.12.5) with SMTP id g97Iewis029268; Mon, 7 Oct 2002 20:40:58 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <001c01c26e30$1b70d460$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Aisenberg, Michael" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Employee Certificates - Security Issues
Date: Mon, 7 Oct 2002 20:33:37 +0200
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>

Michael,

>Don't know if anyone is aware that the EU is presently reviewing a new
>draft Directive on invoicing.....

I sure am.   The EU have very interesting ideas about security.
Their preference is that you use Advanced Electronic Signatures which
are PKI-based such tied to an _individual_.  When I asked if telecom-
operators are supposed to hire hundreds of employees for signing
"e-invoices" using PIN-codes etc. in order to create valid invoices,
I got the answer that you can use "EDI" (!) instead to avoid the
signature requirement.  I wonder how secure XML is supposed to
be :-)

Cross-border invoicing is probably years away as each country
may do their own security variant.

Anders

----- Original Message ----- 
From: "Aisenberg, Michael" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, October 07, 2002 18:51
Subject: RE: Employee Certificates - Security Issues



Michael Aisenberg
--VeriSign/D.C.--


-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]] 
Sent: Monday, October 07, 2002 11:17 AM
To: Housley, Russ
Cc: [e-mail]
Subject: Re: Employee Certificates - Security Issues



Russ,

What I'm basically saying is that authority should be a part
of message "payload" otherwise we don't gain much by
going from paper to electronics.  For the very first contact between two
prospective business parties, you need some out-of-band communication,
but that should be it.

Using the Internet-bank model you have all the means to do this,
_today_, and using arbitrary authorization "granularity" as well.

The Internet-bank model eliminates out-of-band authority- management,
reduces privacy problems, and enables automatic non-intrusive archiving
and control.

As this model leads a 1000-1 deployment-wise compared to
inter-enterprise-PKI, it ought at least be taken in consideration, by
particularly the public sector, before they are trapped into
monstrosities like bridge CAs etc. creating systems supporting _none_ of
the qualities described above.

Actually I would be extremely happy if someone else wrote
how a simple thing like a purchase order should be handled
in a classical enterprise-PKI, including possible business systems.
Without such a description this entire thread becomes both
unintelligible and pretty boring.

=========================================
Russ, would you care to take on this completely death-
defying challenge?
=========================================

Regards
Anders



----- Original Message ----- 
From: "Housley, Russ" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, October 07, 2002 15:37
Subject: Re: Employee Certificates - Security Issues


Anders:

In the paper world, any employee of a company can sign a letter on the 
company's stationary.  The use of the company letterhead may give the 
message recipient a warm fuzzy feeling, but it doe not immediately mean 
that the signer has the authority to commit the company's resources.
This 
can be confirmed.

Similarly, the use of a digital signature issued by a company provides a

similar warm fuzzy feeling.  However, the need to confirm the authority
to 
commit company resources is still needed.

Russ

At 07:25 AM 10/4/2002 +0200, Anders Rundgren wrote:

>"I, the Company"
>
>When employees have been equipped with digital certificates, linked to 
>the organization, interesting things happen: Employees can now sign on 
>behalf of the organization.  Due to the absence of a generally 
>understood X509 "authority" system, you can probably sign whatever you 
>want and an external receiver is meant to believe that you have the 
>right to do it.  This is probably as far from an organization-adapted 
>solution one can get (as organizations want to have control over their 
>internal and external actions), and is an indication that this scheme 
>is not suitable for large-scale deployment.
>
>As a countermeasure one could think of having an
>"authority control server" checking and logging all employee actions. 
>Unfortunately that does not work; if you have an employee certificate 
>you can fairly easy create messages that to receivers, look perfectly 
>valid without going trough the authority server.
>
>Summary: An architecture that is fundamentally broken.
>And, yes, I forgot to mention costs, privacy, archiving, and the 
>multitude of roots that you have to cope with.
>
>Comments?
>
>Anders Rundgren




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g97HsGY17400 for ietf-pkix-bks; Mon, 7 Oct 2002 10:54:16 -0700 (PDT)
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g97HsFv17396 for <[e-mail]>; Mon, 7 Oct 2002 10:54:15 -0700 (PDT)
Received: from MarsXP ([148.233.248.105]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 7 Oct 2002 12:54:38 -0500
From: "mars" <[e-mail]>
To: <[e-mail]>
Subject: OCSP Nonce Syntax
Date: Mon, 7 Oct 2002 12:53:56 -0500
Message-ID: <001901c26e2a$820d0b90$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C26E00.99370390"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 07 Oct 2002 17:54:38.0312 (UTC) FILETIME=[9AB65E80:01C26E2A]
Sender: [e-mail]
Precedence: 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_001A_01C26E00.99370390
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Which RFCs or drafts contain a definition for a Nonce, besides 3161
(which uses an INTEGER)? 
Is it a standard practice to encode the NONCE as an OCTET STRING for
OCSP?
 
Thanks in advance,
 
Miguel A. Rodriguez
SeguriDATA
Mexico
 

------=_NextPart_000_001A_01C26E00.99370390
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<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@01C26E00.98D7A580">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"country-region"/>
<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:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	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:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	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:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	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:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	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=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Which <span class=3DSpellE>RFCs</span> or drafts =
contain a
definition for a Nonce, besides 3161 (which uses an INTEGER)? =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Is it a standard practice to encode the NONCE as an =
OCTET
STRING for OCSP?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks in advance,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-no-proof:yes'>Miguel A. =
Rodriguez</span></font><span
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-no-proof:yes'>SeguriDATA</span></font><span
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

<p class=3DMsoNormal><st1:country-region><st1:place><font size=3D2 =
face=3DArial><span
  =
style=3D'font-size:10.0pt;font-family:Arial;mso-no-proof:yes'>Mexico</spa=
n></font></st1:place></st1:country-region><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_001A_01C26E00.99370390--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g97Gqcg13080 for ietf-pkix-bks; Mon, 7 Oct 2002 09:52:38 -0700 (PDT)
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g97Gqav13075 for <[e-mail]>; Mon, 7 Oct 2002 09:52:36 -0700 (PDT)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA11038; Mon, 7 Oct 2002 12:52:35 -0400 (EDT)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <TF9X2MCQ>; Mon, 7 Oct 2002 12:52:35 -0400
Message-ID: <[e-mail]>
From: "Aisenberg, Michael" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Employee Certificates - Security Issues
Date: Mon, 7 Oct 2002 12:51:37 -0400 
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_000D_01C26E00.3D643D30"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: 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_000D_01C26E00.3D643D30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Don't know if anyone is aware that the EU is presently reviewing a new
draft
Directive on invoicing.....

Michael Aisenberg
--VeriSign/D.C.--


-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]] 
Sent: Monday, October 07, 2002 11:17 AM
To: Housley, Russ
Cc: [e-mail]
Subject: Re: Employee Certificates - Security Issues



Russ,

What I'm basically saying is that authority should be a part
of message "payload" otherwise we don't gain much by
going from paper to electronics.  For the very first contact between two
prospective business parties, you need some out-of-band communication,
but that should be it.

Using the Internet-bank model you have all the means to do this,
_today_, and using arbitrary authorization "granularity" as well.

The Internet-bank model eliminates out-of-band authority- management,
reduces privacy problems, and enables automatic non-intrusive archiving
and control.

As this model leads a 1000-1 deployment-wise compared to
inter-enterprise-PKI, it ought at least be taken in consideration, by
particularly the public sector, before they are trapped into
monstrosities like bridge CAs etc. creating systems supporting _none_ of
the qualities described above.

Actually I would be extremely happy if someone else wrote
how a simple thing like a purchase order should be handled
in a classical enterprise-PKI, including possible business systems.
Without such a description this entire thread becomes both
unintelligible and pretty boring.

=========================================
Russ, would you care to take on this completely death-
defying challenge?
=========================================

Regards
Anders



----- Original Message ----- 
From: "Housley, Russ" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, October 07, 2002 15:37
Subject: Re: Employee Certificates - Security Issues


Anders:

In the paper world, any employee of a company can sign a letter on the 
company's stationary.  The use of the company letterhead may give the 
message recipient a warm fuzzy feeling, but it doe not immediately mean 
that the signer has the authority to commit the company's resources.
This 
can be confirmed.

Similarly, the use of a digital signature issued by a company provides a

similar warm fuzzy feeling.  However, the need to confirm the authority
to 
commit company resources is still needed.

Russ

At 07:25 AM 10/4/2002 +0200, Anders Rundgren wrote:

>"I, the Company"
>
>When employees have been equipped with digital certificates, linked to 
>the organization, interesting things happen: Employees can now sign on 
>behalf of the organization.  Due to the absence of a generally 
>understood X509 "authority" system, you can probably sign whatever you 
>want and an external receiver is meant to believe that you have the 
>right to do it.  This is probably as far from an organization-adapted 
>solution one can get (as organizations want to have control over their 
>internal and external actions), and is an indication that this scheme 
>is not suitable for large-scale deployment.
>
>As a countermeasure one could think of having an
>"authority control server" checking and logging all employee actions. 
>Unfortunately that does not work; if you have an employee certificate 
>you can fairly easy create messages that to receivers, look perfectly 
>valid without going trough the authority server.
>
>Summary: An architecture that is fundamentally broken.
>And, yes, I forgot to mention costs, privacy, archiving, and the 
>multitude of roots that you have to cope with.
>
>Comments?
>
>Anders Rundgren

------=_NextPart_000_000D_01C26E00.3D643D30
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCCAj0w
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+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEIzCCA4ygAwIBAgIQ
C4Pe+b9ZzSY6cFoTNpDgKTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDExMDExMDAwMDAwWhcNMDIx
MDExMjM1OTU5WjBzMREwDwYDVQQKEwhWRVJJU0lHTjEQMA4GA1UECxMHVkEtRUFTVDETMBEGA1UE
AxMKUmVjaXBpZW50czE3MDUGA1UEAxMubWFpc2VuYmVyZyAoQWlzZW5iZXJnIE1pY2hhZWwsIFZl
cmlTaWduLCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvUXjng0fglmjCF7bE23A
cpGiPS0Ci+9Ws6i/NDsGOYt21EbGOT1B+u6wazYjy29sKJkR5cicvJfyylRJ2Zl1Fc5sgewN+a88
g9x7hxQXITWaAlCPKUD/KB4qNeZvGSj1hu+ZdZvIm7N+/cUKT5W5Lvfd41B7bxlnQyADZHy3u8UC
AwEAAaOCAXwwggF4MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNy
bC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3Js
MAsGA1UdDwQEAwIFoDAiBgNVHREEGzAZgRdtYWlzZW5iZXJnQHZlcmlzaWduLmNvbTCBrAYDVR0g
BIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNp
Z24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWdu
J3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ
YIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0B
AQQFAAOBgQA8lpyvzHVxE92Tr9AX/8HdW2dKffNef2wIZXCd43hsblythAXOmU78nW4+W54zEonQ
jUoicXgE+oQZd/PVHLfEm8f67IZlrl38/wMJoNNqaaWJiCSH0qsGtNvxhNOKaspYIP5nyiT1gKcy
0F8WRd+fYUF6pq0IDxUClzkLftrxRzGCA94wggPaAgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2ln
biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlz
IHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5
OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQC4Pe+b9ZzSY6cFoTNpDg
KTAJBgUrDgMCGgUAoIICcjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wMjEwMDcxNjUxMjJaMCMGCSqGSIb3DQEJBDEWBBTQXtMYFnq/ZViSNgxLWh+zGeLV5zBnBgkq
hkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH
BgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB0gYJKwYBBAGCNxAE
MYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQQIQC4Pe+b9ZzSY6cFoTNpDgKTCB1AYLKoZIhvcNAQkQAgsxgcSggcEwgawxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw
RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhAL
g975v1nNJjpwWhM2kOApMA0GCSqGSIb3DQEBAQUABIGAJnZoDo6TbDEjrchc+igc2bVVhLj1Veok
1gkXlQaiDkZwVLW2riBnO9VV48AH283D7Jby1mlwC7gsHQ0FPoK+ounTCr42tBHGuYVvmR8e3NNA
OG32tP37SGivm0S4BvNpw/ffyvSfpG5C1slH7reZemjch5ucYIsPObsMlI/ToTMAAAAAAAA=

------=_NextPart_000_000D_01C26E00.3D643D30--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g97FNxG09012 for ietf-pkix-bks; Mon, 7 Oct 2002 08:23:59 -0700 (PDT)
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 g97FNvv09006 for <[e-mail]>; Mon, 7 Oct 2002 08:23:57 -0700 (PDT)
Received: from arport ([62.119.75.13]) by blooper.utfors.se (8.12.6/8.12.6) with SMTP id g97FNqtA002159; Mon, 7 Oct 2002 17:23:52 +0200 (MEST)
Message-ID: <023401c26e14$9328c880$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Employee Certificates - Security Issues
Date: Mon, 7 Oct 2002 17:16:56 +0200
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>

Russ,

What I'm basically saying is that authority should be a part
of message "payload" otherwise we don't gain much by
going from paper to electronics.  For the very first contact
between two prospective business parties, you need some
out-of-band communication, but that should be it.

Using the Internet-bank model you have all the means to do this,
_today_, and using arbitrary authorization "granularity" as well.

The Internet-bank model eliminates out-of-band authority-
management, reduces privacy problems, and enables automatic
non-intrusive archiving and control.

As this model leads a 1000-1 deployment-wise compared to
inter-enterprise-PKI, it ought at least be taken in consideration,
by particularly the public sector, before they are trapped into
monstrosities like bridge CAs etc. creating systems supporting
_none_ of the qualities described above.

Actually I would be extremely happy if someone else wrote
how a simple thing like a purchase order should be handled
in a classical enterprise-PKI, including possible business
systems.  Without such a description this entire thread
becomes both unintelligible and pretty boring.

=========================================
Russ, would you care to take on this completely death-
defying challenge?
=========================================

Regards
Anders



----- Original Message ----- 
From: "Housley, Russ" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, October 07, 2002 15:37
Subject: Re: Employee Certificates - Security Issues


Anders:

In the paper world, any employee of a company can sign a letter on the 
company's stationary.  The use of the company letterhead may give the 
message recipient a warm fuzzy feeling, but it doe not immediately mean 
that the signer has the authority to commit the company's resources.  This 
can be confirmed.

Similarly, the use of a digital signature issued by a company provides a 
similar warm fuzzy feeling.  However, the need to confirm the authority to 
commit company resources is still needed.

Russ

At 07:25 AM 10/4/2002 +0200, Anders Rundgren wrote:

>"I, the Company"
>
>When employees have been equipped with digital certificates,
>linked to the organization, interesting things happen: Employees
>can now sign on behalf of the organization.  Due to the absence of
>a generally understood X509 "authority" system, you can probably
>sign whatever you want and an external receiver is meant to believe
>that you have the right to do it.  This is probably as far from an
>organization-adapted solution one can get (as organizations want to
>have control over their internal and external actions), and is an
>indication that this scheme is not suitable for large-scale deployment.
>
>As a countermeasure one could think of having an
>"authority control server" checking and logging all employee actions.
>Unfortunately that does not work; if you have an employee certificate
>you can fairly easy create messages that to receivers, look perfectly
>valid without going trough the authority server.
>
>Summary: An architecture that is fundamentally broken.
>And, yes, I forgot to mention costs, privacy, archiving, and
>the multitude of roots that you have to cope with.
>
>Comments?
>
>Anders Rundgren




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g97E3WO03959 for ietf-pkix-bks; Mon, 7 Oct 2002 07:03:32 -0700 (PDT)
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 g97E3Vv03946 for <[e-mail]>; Mon, 7 Oct 2002 07:03:31 -0700 (PDT)
Subject: RE: Employee Certificates - Security Issues
To: "=?iso-8859-1?Q?S=E4rs=2C_Camillo?=" <[e-mail]>
Cc: "Anders Rundgren" <[e-mail]>, "=?iso-8859-1?Q?S=E4rs=2C_Camillo?=" <[e-mail]>, [e-mail], [e-mail], "Guida, Richard [JJCUS]" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Mon, 7 Oct 2002 08:01:44 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 10/07/2002 10:06:28 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>

this is also been discussed in the context of contracts and other use of
"paper" signatures as "intent" .... did  the person "intend" to perform the
signature in the sense that they also "agreed" to the T&Cs of the thing
that was signed. a digital signature can be interpreted as conveying much
less than a paper signature (legally; in the sense that it doesn't actually
imply all the stuff that a paper signature implies). the use of the term
"digital signature" with the word "signature" being used may create
semantic confusion for some automagically equating digital signature with
manual/paper signature .... just because the word "signature" appears in
both terms.  the concepts of intention and agreeing then is also involved
in non-repudiation ....  aka my machine may have signed a message ...  for
authentication and integrity purposes .... but my machine doesn't have
authority to agree/approve terms of contract that may been contained in the
body of a message.

some past threads on intent &/or non-repudiation:
http://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary &
taxonomy
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative
to PKI?
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case,
or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#12 TOC for world bank e-security
paper
http://www.garlic.com/~lynn/aadsm12.htm#18 Overcoming the potential
downside of TCPA
http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during
ownership change (Re: Overcoming the potential downside of TCPA)
http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and
their users [was Re: Cryptogram:  Palladium Only for DRM]

http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security'
site.
http://www.garlic.com/~lynn/2001d.html#8 Invalid certificate on 'security'
site.
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#51 future of e-commerce
http://www.garlic.com/~lynn/2001j.html#7 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001n.html#75 A PKI question and an  answer
http://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
http://www.garlic.com/~lynn/2002g.html#37 Security Issues of using Internet
Banking
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
http://www.garlic.com/~lynn/2002h.html#13 Biometric authentication for
intranet websites?
http://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you
are?
http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman  schema
belong to Public Key schema family?
http://www.garlic.com/~lynn/2002i.html#77 Does Diffie-Hellman  schema
belong to Public Key schema family?
http://www.garlic.com/~lynn/2002j.html#24 Definition of "Non-Repudiation" ?
http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
http://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and
hashing
http://www.garlic.com/~lynn/2002l.html#28 Two questions on HMACs and
hashing
http://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce
using POWF


sars.camillo <[e-mail] on 10/07/2002 1:21 am wrote:

Unfortunately this is not the way identity certificates are interpreted
today.  You should note that the digital signature conveys far more
information than a "paper signature".  The digital signature actually
proves
integrity, that is, nobody has tampered with the document since it was
signed.  This property unfortunately has also been used to imply
authenticity, that is, that the person who signed the document actually
knew
what he was signing.  To date, I have yet to see a consumer-grade system
that
would be able to enforce authenticity as a security property.





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g97DcUw02955 for ietf-pkix-bks; Mon, 7 Oct 2002 06:38:30 -0700 (PDT)
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 g97DcSv02951 for <[e-mail]>; Mon, 7 Oct 2002 06:38:28 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 Oct 2002 13:38:30 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 JAA16672 for <[e-mail]>; Mon, 7 Oct 2002 09:38:29 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g97DZvh24681 for <[e-mail]>; Mon, 7 Oct 2002 09:35:57 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPV818Z>; Mon, 7 Oct 2002 09:38:27 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.22]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPV818T; Mon, 7 Oct 2002 09:38:22 -0400
From: "Housley, Russ" <[e-mail]>
To: Anders Rundgren <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 07 Oct 2002 09:37:05 -0400
Subject: Re: Employee Certificates - Security Issues
In-Reply-To: <006101c26b66$6a667150$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>

Anders:

In the paper world, any employee of a company can sign a letter on the 
company's stationary.  The use of the company letterhead may give the 
message recipient a warm fuzzy feeling, but it doe not immediately mean 
that the signer has the authority to commit the company's resources.  This 
can be confirmed.

Similarly, the use of a digital signature issued by a company provides a 
similar warm fuzzy feeling.  However, the need to confirm the authority to 
commit company resources is still needed.

Russ

At 07:25 AM 10/4/2002 +0200, Anders Rundgren wrote:

>"I, the Company"
>
>When employees have been equipped with digital certificates,
>linked to the organization, interesting things happen: Employees
>can now sign on behalf of the organization.  Due to the absence of
>a generally understood X509 "authority" system, you can probably
>sign whatever you want and an external receiver is meant to believe
>that you have the right to do it.  This is probably as far from an
>organization-adapted solution one can get (as organizations want to
>have control over their internal and external actions), and is an
>indication that this scheme is not suitable for large-scale deployment.
>
>As a countermeasure one could think of having an
>"authority control server" checking and logging all employee actions.
>Unfortunately that does not work; if you have an employee certificate
>you can fairly easy create messages that to receivers, look perfectly
>valid without going trough the authority server.
>
>Summary: An architecture that is fundamentally broken.
>And, yes, I forgot to mention costs, privacy, archiving, and
>the multitude of roots that you have to cope with.
>
>Comments?
>
>Anders Rundgren


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g977LUo25803 for ietf-pkix-bks; Mon, 7 Oct 2002 00:21:30 -0700 (PDT)
Received: from dfmail.f-secure.com (dfmail.f-secure.com [194.252.6.39]) by above.proper.com (8.11.6/8.11.3) with SMTP id g977LSv25799 for <[e-mail]>; Mon, 7 Oct 2002 00:21:29 -0700 (PDT)
Received: (qmail 21476 invoked by uid 0); 7 Oct 2002 07:21:20 -0000
Received: from fsav4im2.f-secure.com (HELO fsav4im2) (193.110.108.82) by dfmail.f-secure.com with SMTP; 7 Oct 2002 07:21:20 -0000
Received: from [10.128.128.81]:44457 (HELO dfintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.0.34 Release) with SMTP; Mon, 7 Oct 2002 07:23:51 -0000
Received: (qmail 28894 invoked from network); 7 Oct 2002 07:21:18 -0000
Received: from unknown (HELO fsfimail1.fi.f-secure.com) (10.128.128.19) by dfintra.f-secure.com with SMTP; 7 Oct 2002 07:21:18 -0000
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Employee Certificates - Security Issues
Date: Mon, 7 Oct 2002 10:21:18 +0300
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Employee Certificates - Security Issues
Thread-Index: AcJruiRU0Pac2uAPTT6FITkQ+3rM2gCFmS9A
From: =?iso-8859-1?Q?=22S=E4rs=2C_Camillo=22?= <[e-mail]>
To: "Guida, Richard [JJCUS]" <[e-mail]>, "Anders Rundgren" <[e-mail]>, <[e-mail]>
Cc: =?iso-8859-1?Q?=22S=E4rs=2C_Camillo=22?= <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g977LTv25800
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> A digital identity certificate proves (to whatever degree the certificate 
> policy underlying it affords) identity.  It does not prove authority 
> to take an action.  (I am omitting attribute certs from this 
> discussion.)

Unfortunately this is not the way identity certificates are interpreted
today.  You should note that the digital signature conveys far more
information than a "paper signature".  The digital signature actually proves
integrity, that is, nobody has tampered with the document since it was
signed.  This property unfortunately has also been used to imply
authenticity, that is, that the person who signed the document actually knew
what he was signing.  To date, I have yet to see a consumer-grade system that
would be able to enforce authenticity as a security property.

> Not to say they won't be used for a long time to come - but I certainly
hope 
> to free my children from the tyranny of dozens of passwords 
> and migrate them to the strength of a single digital 
> credential, a certificate, with the private key held on a 
> hardware token and unlocked using a passphrase known only by 
> the token, not by a server somewhere out of my control.

I wish people would stop marketing the "one key to rule them all" approach.
Using a single, all-powerful public key pair violates one of the most
fundamental security design strategies "principle of least authority".
Trying to build a global system where an individual would only be using a
single public key is foolish on the border of ciminal.  It would also make it
trivial to cross-correlate many different customer and government databases,
which in effect makes any such attempts illegal in the EU.  Fundamental
privacy principles mandate that separate databases must use separate unique
identifiers for individuals, to make cross-correlation difficult.

"The strength" of a single digital credential is simply something that I see
as completely incompatible with an open democracy.

Regards,
Camillo Särs
-- 
Camillo Särs <[e-mail]>          http://www.iki.fi/ged/
Senior Security Researcher, F-Secure Corporation  http://www.F-Secure.com

          F-Secure products: Securing the Mobile Enterprise


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g96LJUA22128 for ietf-pkix-bks; Sun, 6 Oct 2002 14:19:30 -0700 (PDT)
Received: from ncsusraimge05.jnj.com (ncsusraimge05.jnj.com [148.177.2.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g96LJSv22124 for <[e-mail]>; Sun, 6 Oct 2002 14:19:28 -0700 (PDT)
Received: from NCSUSRAWSC6.na.jnj.com (NCSUSRAWSC6.na.jnj.com [10.4.20.26]) by ncsusraimge05.jnj.com (Switch-2.2.3/Switch-2.2.3) with SMTP id g96LBEC23459 for <[e-mail]>; Sun, 6 Oct 2002 17:11:14 -0400 (EDT)
Received: FROM ncsusraexims3.rar.ncsus.jnj.com BY NCSUSRAWSC6.na.jnj.com ; Sun Oct 06 17:18:54 2002 -0400
Received: by ncsusraexims3.rar.ncsus.jnj.com with Internet Mail Service (5.5.2653.19) id <4F8AVBNF>; Sun, 6 Oct 2002 17:19:25 -0400
Message-ID: <[e-mail]>
From: "Guida, Richard [JJCUS]" <[e-mail]>
To: Anders Rundgren <[e-mail]>, [e-mail]
Subject: RE: Employee Certificates - Security Issues
Date: Sun, 6 Oct 2002 17:19:23 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26D7E.0A35749C"
Sender: [e-mail]
Precedence: 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_01C26D7E.0A35749C
Content-Type: text/plain;
	charset="iso-8859-1"


Thanks for the suggestions, Anders, but I'm afraid life is a bit more
complicated than you posit.  Additionally, we do not want to tie our entire
security infrastructure (which the PKI underlies) to an outside source of
certificates.  We want to run our security infrastructure ourselves.  And I
think we have taken up enough bandwidth from others on this thread, so this
will be my last posting (and my apologies to those of you who have patiently
sorted through the e-mails wondering when the thread would be over; it is).
Best regards -- Rich


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: Anders Rundgren [mailto:[e-mail]]
Sent: Sunday, October 06, 2002 10:00 AM
To: Guida, Richard [JJCUS]; [e-mail]
Subject: Re: Employee Certificates - Security Issues


Thanx Richard,

Note though that by using the Internet-bank model you can

- completely offload business parties from reading CPs
- give bosses and security officers the tools needed to monitor
   and control employees' external activities (regardless if they
   feel they need it or not)
- get automatic archiving
- essentially never have to transfer authorization data out-of-band
  as the Internet-bank model is an on-line system in contrast to the
  employee-PKIs' off-line paradigm
- deploy authorization schemes ranging from  the very basic which
  is the organization (rather than an employee), to sophisticated schemes
  using external authorities vouching for this and that
- easily add SAML for extranet authentication
- be compatible with coming e-business systems
- be able to efficiently manage a multitude of electronic business parties,
  long-term reducing costs
- increase "precision" and "trust" in your organizations' dealings with
  external parties

You current PKI would still operate and be worth preserving but would
never (when fully adapted), be the outermost (most authoritative) system
as the bank-model requires an organizational stamp in order to produce
an externally valid operation.

Also worth nothing is that this can be implemented now using existing
standard-technology, unlike end-to-end client-based PKI schemes
that today offers zero support for on-line authorization.  I cannot see
that it is even technically possible to obtain this functionality in
a client-based end-to-end PKI.

That this cannot happen overnight is for sure, but one can start
thinking about it at least.  Do some pilots etc.

cheers,
Anders

----- Original Message -----
From: Guida, Richard [JJCUS]
To: Anders Rundgren ; [e-mail]
Sent: Sunday, October 06, 2002 14:36
Subject: RE: Employee Certificates - Security Issues


Anders - this topic is not conducive to a full description in this thread,
too complicated and too easy to misinterpret.  So I have
to give you a simple and noncomplete answer: employees are trusted to use
their electronic credentials as they are trusted to use
other credentials issued them by the company.  If I took my company picture
ID and used it at a local merchant as proof of who I am
for writing a check, AND the merchant accepted that ID, is the company
liable if the ID were forged or if I just left the company
and "forgot" to turn it in (and the company failed to demand it be
surrendered)?  Same issue with certificates - if the relying
party wants to rely on a certificate: (a) without checking a CRL; and (b)
without checking the Certificate Policy (our CP explicitly
says the certs can only be used for J&J business and only establish
identity, do not established authorization to perform an act),
then the relying party is incurring the risk.  And the employee who is
improperly using the credential is subject to disciplinary
action (or if a former employee, subject potentially to charges of fraud).
Now I realize in the litigious U.S. the "deep pockets"
theory often results in large corporations being hit with liability
(responsibility) that they don't deserve, but thankfully that is
not true in much of the rest of the world.
As for security officers taking the approach of "we don't trust anyone,"
that is a bit simplistic.  I proceed from the premise that
the vast majority of employees want to do the right thing but may get
confused or may not know what "the right thing" is, so
training and awareness are paramount.  For those few who are miscreants, you
have to have in place an approach with overchecks and
safeguards to catch them before they can do much damage.  But to proceed
from the premise that every employee, given the
opportunity, will do something evil against his/her company is a scary
proposition.  I would not want to work for a company where
management holds that view - and I do not.
Authorization determinations are indeed handled "out of band," and hopefully
at some point we will employ SAML-based technology for
that purpose.  Authorization is (as you and others have commented) an
immensely complex topic, especially given legacy systems and
the fact that operating units (correctly) demand autonomy in making such
decisions regarding access to their own applications.
Authentication, by contrast, is far more straightforward.
Best regards -- Rich


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: Anders Rundgren [mailto:[e-mail]]
Sent: Saturday, October 05, 2002 2:09 PM
To: Guida, Richard [JJCUS]; [e-mail]
Subject: Re: Employee Certificates - Security Issues



Richard,
It would be very interesting to know how J&J handles archiving
and authorization, as the conclusion from your answers seems
to be, "we trust all our employees for doing the right thing",
which BTW is in strong contrast to what security officers in
general say.  Not to mention bosses. :-)
In particular, how is authorization with respect to _external_
parties handled?  Based on out-of-band arrangements?
Although workable, I believe this is a very inefficient way to
perform "e-business", whatever the "business" is.
Anders
----- Original Message -----
From: Guida, Richard [JJCUS]
To: Anders Rundgren ; [e-mail]
Sent: Friday, October 04, 2002 21:30
Subject: RE: Employee Certificates - Security Issues


Anders - I don't think I misunderstood.  Your last e-mail makes the point
very well - you say that a company PKI is as bad as giving
employees company credit cards.  Well - I had a government credit card when
I worked for the USGovernment (as did almost everyone
else - at least those who traveled which was almost everyone, very few
exceptions), and I have one from my current employer as well
(again the majority of employees do).  Same is true for every company which
I know through professional affiliation.  So I agree
with the implication of your logic - we should do with certs for employees
the same as companies have done with credit cards for
employees.  That makes my case better than anything.  Thanks -- Rich



Richard A. Guida
Director, Information Securityu (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: Anders Rundgren [mailto:[e-mail]]
Sent: Friday, October 04, 2002 12:24 PM
To: [e-mail]; Guida, Richard [JJCUS]
Subject: Re: Employee Certificates - Security Issues


Richard,
I think you have mostly misinterpreted my messages.
Employee-PKI means (I do at least), that the employee has a certificate
that allows him/her to act on behalf on their employer.  This is
a fundamental characteristic of the US Federal PKI and commercial
efforts like Identrus.
What I'm saying is that this opens the organization to massive
and non-controllable attacks from disloyal employees etc.  It is a
smart as giving the entire work-force company credit-cards.
Regarding the market, it is interesting to note that there is not a
business system maker of any significance that support a model
where the client's certificate and signature is a part of _outgoing_
messages.  In the same way as there is not a single bank in the
world that does this either.  And this fact is completely independent
of the availability of client-side PKI.
Note: Client-side PKI is absolutely not a bad idea, it is
the idea to hand over specific "company keys" to employees
that is not such a terribly good idea.
Anders


------_=_NextPart_001_01C26D7E.0A35749C
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: Employee Certificates - Security Issues</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>Thanks for the suggestions, Anders, but I'm afraid =
life is a bit more complicated than you posit.&nbsp; Additionally, we =
do not want to tie our entire security infrastructure (which the PKI =
underlies) to an outside source of certificates.&nbsp; We want to run =
our security infrastructure ourselves.&nbsp; And I think we have taken =
up enough bandwidth from others on this thread, so this will be my last =
posting (and my apologies to those of you who have patiently sorted =
through the e-mails wondering when the thread would be over; it =
is).&nbsp; Best regards -- Rich</FONT></P>
<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: Anders Rundgren [<A =
HREF=3D"mailto:[e-mail]">mailto:anders.rundgren@telia.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Sunday, October 06, 2002 10:00 AM</FONT>
<BR><FONT SIZE=3D2>To: Guida, Richard [JJCUS]; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Employee Certificates - Security =
Issues</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Thanx Richard,</FONT>
</P>

<P><FONT SIZE=3D2>Note though that by using the Internet-bank model you =
can</FONT>
</P>

<P><FONT SIZE=3D2>- completely offload business parties from reading =
CPs</FONT>
<BR><FONT SIZE=3D2>- give bosses and security officers the tools needed =
to monitor</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; and control employees' external =
activities (regardless if they</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; feel they need it or not)</FONT>
<BR><FONT SIZE=3D2>- get automatic archiving</FONT>
<BR><FONT SIZE=3D2>- essentially never have to transfer authorization =
data out-of-band</FONT>
<BR><FONT SIZE=3D2>&nbsp; as the Internet-bank model is an on-line =
system in contrast to the</FONT>
<BR><FONT SIZE=3D2>&nbsp; employee-PKIs' off-line paradigm</FONT>
<BR><FONT SIZE=3D2>- deploy authorization schemes ranging from&nbsp; =
the very basic which</FONT>
<BR><FONT SIZE=3D2>&nbsp; is the organization (rather than an =
employee), to sophisticated schemes</FONT>
<BR><FONT SIZE=3D2>&nbsp; using external authorities vouching for this =
and that</FONT>
<BR><FONT SIZE=3D2>- easily add SAML for extranet authentication</FONT>
<BR><FONT SIZE=3D2>- be compatible with coming e-business =
systems</FONT>
<BR><FONT SIZE=3D2>- be able to efficiently manage a multitude of =
electronic business parties,</FONT>
<BR><FONT SIZE=3D2>&nbsp; long-term reducing costs</FONT>
<BR><FONT SIZE=3D2>- increase &quot;precision&quot; and =
&quot;trust&quot; in your organizations' dealings with</FONT>
<BR><FONT SIZE=3D2>&nbsp; external parties</FONT>
</P>

<P><FONT SIZE=3D2>You current PKI would still operate and be worth =
preserving but would</FONT>
<BR><FONT SIZE=3D2>never (when fully adapted), be the outermost (most =
authoritative) system</FONT>
<BR><FONT SIZE=3D2>as the bank-model requires an organizational stamp =
in order to produce</FONT>
<BR><FONT SIZE=3D2>an externally valid operation.</FONT>
</P>

<P><FONT SIZE=3D2>Also worth nothing is that this can be implemented =
now using existing</FONT>
<BR><FONT SIZE=3D2>standard-technology, unlike end-to-end client-based =
PKI schemes</FONT>
<BR><FONT SIZE=3D2>that today offers zero support for on-line =
authorization.&nbsp; I cannot see</FONT>
<BR><FONT SIZE=3D2>that it is even technically possible to obtain this =
functionality in</FONT>
<BR><FONT SIZE=3D2>a client-based end-to-end PKI.</FONT>
</P>

<P><FONT SIZE=3D2>That this cannot happen overnight is for sure, but =
one can start</FONT>
<BR><FONT SIZE=3D2>thinking about it at least.&nbsp; Do some pilots =
etc.</FONT>
</P>

<P><FONT SIZE=3D2>cheers,</FONT>
<BR><FONT SIZE=3D2>Anders</FONT>
</P>

<P><FONT SIZE=3D2>----- Original Message -----</FONT>
<BR><FONT SIZE=3D2>From: Guida, Richard [JJCUS]</FONT>
<BR><FONT SIZE=3D2>To: Anders Rundgren ; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Sent: Sunday, October 06, 2002 14:36</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Employee Certificates - Security =
Issues</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Anders - this topic is not conducive to a full =
description in this thread, too complicated and too easy to =
misinterpret.&nbsp; So I have</FONT></P>

<P><FONT SIZE=3D2>to give you a simple and noncomplete answer: =
employees are trusted to use their electronic credentials as they are =
trusted to use</FONT></P>

<P><FONT SIZE=3D2>other credentials issued them by the company.&nbsp; =
If I took my company picture ID and used it at a local merchant as =
proof of who I am</FONT></P>

<P><FONT SIZE=3D2>for writing a check, AND the merchant accepted that =
ID, is the company liable if the ID were forged or if I just left the =
company</FONT></P>

<P><FONT SIZE=3D2>and &quot;forgot&quot; to turn it in (and the company =
failed to demand it be surrendered)?&nbsp; Same issue with certificates =
- if the relying</FONT></P>

<P><FONT SIZE=3D2>party wants to rely on a certificate: (a) without =
checking a CRL; and (b) without checking the Certificate Policy (our CP =
explicitly</FONT></P>

<P><FONT SIZE=3D2>says the certs can only be used for J&amp;J business =
and only establish identity, do not established authorization to =
perform an act),</FONT></P>

<P><FONT SIZE=3D2>then the relying party is incurring the risk.&nbsp; =
And the employee who is improperly using the credential is subject to =
disciplinary</FONT></P>

<P><FONT SIZE=3D2>action (or if a former employee, subject potentially =
to charges of fraud).&nbsp; Now I realize in the litigious U.S. the =
&quot;deep pockets&quot;</FONT></P>

<P><FONT SIZE=3D2>theory often results in large corporations being hit =
with liability (responsibility) that they don't deserve, but thankfully =
that is</FONT></P>

<P><FONT SIZE=3D2>not true in much of the rest of the world.</FONT>
<BR><FONT SIZE=3D2>As for security officers taking the approach of =
&quot;we don't trust anyone,&quot; that is a bit simplistic.&nbsp; I =
proceed from the premise that</FONT></P>

<P><FONT SIZE=3D2>the vast majority of employees want to do the right =
thing but may get confused or may not know what &quot;the right =
thing&quot; is, so</FONT></P>

<P><FONT SIZE=3D2>training and awareness are paramount.&nbsp; For those =
few who are miscreants, you have to have in place an approach with =
overchecks and</FONT></P>

<P><FONT SIZE=3D2>safeguards to catch them before they can do much =
damage.&nbsp; But to proceed from the premise that every employee, =
given the</FONT></P>

<P><FONT SIZE=3D2>opportunity, will do something evil against his/her =
company is a scary proposition.&nbsp; I would not want to work for a =
company where</FONT></P>

<P><FONT SIZE=3D2>management holds that view - and I do not.</FONT>
<BR><FONT SIZE=3D2>Authorization determinations are indeed handled =
&quot;out of band,&quot; and hopefully at some point we will employ =
SAML-based technology for</FONT></P>

<P><FONT SIZE=3D2>that purpose.&nbsp; Authorization is (as you and =
others have commented) an immensely complex topic, especially given =
legacy systems and</FONT></P>

<P><FONT SIZE=3D2>the fact that operating units (correctly) demand =
autonomy in making such decisions regarding access to their own =
applications.</FONT></P>

<P><FONT SIZE=3D2>Authentication, by contrast, is far more =
straightforward.</FONT>
<BR><FONT SIZE=3D2>Best regards -- Rich</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Richard A. Guida</FONT>
<BR><FONT SIZE=3D2>Director, Information Security (Medical Devices and =
Diagnostics)</FONT>
<BR><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>
<BR><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: Anders Rundgren [<A =
HREF=3D"mailto:[e-mail]">mailto:anders.rundgren@telia.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Saturday, October 05, 2002 2:09 PM</FONT>
<BR><FONT SIZE=3D2>To: Guida, Richard [JJCUS]; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Employee Certificates - Security =
Issues</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Richard,</FONT>
<BR><FONT SIZE=3D2>It would be very interesting to know how J&amp;J =
handles archiving</FONT>
<BR><FONT SIZE=3D2>and authorization, as the conclusion from your =
answers seems</FONT>
<BR><FONT SIZE=3D2>to be, &quot;we trust all our employees for doing =
the right thing&quot;,</FONT>
<BR><FONT SIZE=3D2>which BTW is in strong contrast to what security =
officers in</FONT>
<BR><FONT SIZE=3D2>general say.&nbsp; Not to mention bosses. :-)</FONT>
<BR><FONT SIZE=3D2>In particular, how is authorization with respect to =
_external_</FONT>
<BR><FONT SIZE=3D2>parties handled?&nbsp; Based on out-of-band =
arrangements?</FONT>
<BR><FONT SIZE=3D2>Although workable, I believe this is a very =
inefficient way to</FONT>
<BR><FONT SIZE=3D2>perform &quot;e-business&quot;, whatever the =
&quot;business&quot; is.</FONT>
<BR><FONT SIZE=3D2>Anders</FONT>
<BR><FONT SIZE=3D2>----- Original Message -----</FONT>
<BR><FONT SIZE=3D2>From: Guida, Richard [JJCUS]</FONT>
<BR><FONT SIZE=3D2>To: Anders Rundgren ; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, October 04, 2002 21:30</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Employee Certificates - Security =
Issues</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Anders - I don't think I misunderstood.&nbsp; Your =
last e-mail makes the point very well - you say that a company PKI is =
as bad as giving</FONT></P>

<P><FONT SIZE=3D2>employees company credit cards.&nbsp; Well - I had a =
government credit card when I worked for the USGovernment (as did =
almost everyone</FONT></P>

<P><FONT SIZE=3D2>else - at least those who traveled which was almost =
everyone, very few exceptions), and I have one from my current employer =
as well</FONT></P>

<P><FONT SIZE=3D2>(again the majority of employees do).&nbsp; Same is =
true for every company which I know through professional =
affiliation.&nbsp; So I agree</FONT></P>

<P><FONT SIZE=3D2>with the implication of your logic - we should do =
with certs for employees the same as companies have done with credit =
cards for</FONT></P>

<P><FONT SIZE=3D2>employees.&nbsp; That makes my case better than =
anything.&nbsp; Thanks -- Rich</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Richard A. Guida</FONT>
<BR><FONT SIZE=3D2>Director, Information Securityu (Medical Devices and =
Diagnostics)</FONT>
<BR><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>
<BR><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: Anders Rundgren [<A =
HREF=3D"mailto:[e-mail]">mailto:anders.rundgren@telia.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, October 04, 2002 12:24 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]; Guida, Richard [JJCUS]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Employee Certificates - Security =
Issues</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Richard,</FONT>
<BR><FONT SIZE=3D2>I think you have mostly misinterpreted my =
messages.</FONT>
<BR><FONT SIZE=3D2>Employee-PKI means (I do at least), that the =
employee has a certificate</FONT>
<BR><FONT SIZE=3D2>that allows him/her to act on behalf on their =
employer.&nbsp; This is</FONT>
<BR><FONT SIZE=3D2>a fundamental characteristic of the US Federal PKI =
and commercial</FONT>
<BR><FONT SIZE=3D2>efforts like Identrus.</FONT>
<BR><FONT SIZE=3D2>What I'm saying is that this opens the organization =
to massive</FONT>
<BR><FONT SIZE=3D2>and non-controllable attacks from disloyal employees =
etc.&nbsp; It is a</FONT>
<BR><FONT SIZE=3D2>smart as giving the entire work-force company =
credit-cards.</FONT>
<BR><FONT SIZE=3D2>Regarding the market, it is interesting to note that =
there is not a</FONT>
<BR><FONT SIZE=3D2>business system maker of any significance that =
support a model</FONT>
<BR><FONT SIZE=3D2>where the client's certificate and signature is a =
part of _outgoing_</FONT>
<BR><FONT SIZE=3D2>messages.&nbsp; In the same way as there is not a =
single bank in the</FONT>
<BR><FONT SIZE=3D2>world that does this either.&nbsp; And this fact is =
completely independent</FONT>
<BR><FONT SIZE=3D2>of the availability of client-side PKI.</FONT>
<BR><FONT SIZE=3D2>Note: Client-side PKI is absolutely not a bad idea, =
it is</FONT>
<BR><FONT SIZE=3D2>the idea to hand over specific &quot;company =
keys&quot; to employees</FONT>
<BR><FONT SIZE=3D2>that is not such a terribly good idea.</FONT>
<BR><FONT SIZE=3D2>Anders</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C26D7E.0A35749C--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g96E7Em26714 for ietf-pkix-bks; Sun, 6 Oct 2002 07:07:14 -0700 (PDT)
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 g96E7Cv26710 for <[e-mail]>; Sun, 6 Oct 2002 07:07:12 -0700 (PDT)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id g96E7Bf5011828; Sun, 6 Oct 2002 16:07:11 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <010001c26d40$b308fb40$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Guida, Richard [JJCUS]" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Employee Certificates - Security Issues
Date: Sun, 6 Oct 2002 16:00:16 +0200
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 Richard,

Note though that by using the Internet-bank model you can

- completely offload business parties from reading CPs
- give bosses and security officers the tools needed to monitor
   and control employees' external activities (regardless if they
   feel they need it or not)
- get automatic archiving
- essentially never have to transfer authorization data out-of-band
  as the Internet-bank model is an on-line system in contrast to the
  employee-PKIs' off-line paradigm
- deploy authorization schemes ranging from  the very basic which
  is the organization (rather than an employee), to sophisticated schemes
  using external authorities vouching for this and that
- easily add SAML for extranet authentication
- be compatible with coming e-business systems
- be able to efficiently manage a multitude of electronic business parties,
  long-term reducing costs
- increase "precision" and "trust" in your organizations' dealings with
  external parties

You current PKI would still operate and be worth preserving but would
never (when fully adapted), be the outermost (most authoritative) system
as the bank-model requires an organizational stamp in order to produce
an externally valid operation.

Also worth nothing is that this can be implemented now using existing
standard-technology, unlike end-to-end client-based PKI schemes
that today offers zero support for on-line authorization.  I cannot see
that it is even technically possible to obtain this functionality in
a client-based end-to-end PKI.

That this cannot happen overnight is for sure, but one can start
thinking about it at least.  Do some pilots etc.

cheers,
Anders

----- Original Message -----
From: Guida, Richard [JJCUS]
To: Anders Rundgren ; [e-mail]
Sent: Sunday, October 06, 2002 14:36
Subject: RE: Employee Certificates - Security Issues


Anders - this topic is not conducive to a full description in this thread, too complicated and too easy to misinterpret.  So I have
to give you a simple and noncomplete answer: employees are trusted to use their electronic credentials as they are trusted to use
other credentials issued them by the company.  If I took my company picture ID and used it at a local merchant as proof of who I am
for writing a check, AND the merchant accepted that ID, is the company liable if the ID were forged or if I just left the company
and "forgot" to turn it in (and the company failed to demand it be surrendered)?  Same issue with certificates - if the relying
party wants to rely on a certificate: (a) without checking a CRL; and (b) without checking the Certificate Policy (our CP explicitly
says the certs can only be used for J&J business and only establish identity, do not established authorization to perform an act),
then the relying party is incurring the risk.  And the employee who is improperly using the credential is subject to disciplinary
action (or if a former employee, subject potentially to charges of fraud).  Now I realize in the litigious U.S. the "deep pockets"
theory often results in large corporations being hit with liability (responsibility) that they don't deserve, but thankfully that is
not true in much of the rest of the world.
As for security officers taking the approach of "we don't trust anyone," that is a bit simplistic.  I proceed from the premise that
the vast majority of employees want to do the right thing but may get confused or may not know what "the right thing" is, so
training and awareness are paramount.  For those few who are miscreants, you have to have in place an approach with overchecks and
safeguards to catch them before they can do much damage.  But to proceed from the premise that every employee, given the
opportunity, will do something evil against his/her company is a scary proposition.  I would not want to work for a company where
management holds that view - and I do not.
Authorization determinations are indeed handled "out of band," and hopefully at some point we will employ SAML-based technology for
that purpose.  Authorization is (as you and others have commented) an immensely complex topic, especially given legacy systems and
the fact that operating units (correctly) demand autonomy in making such decisions regarding access to their own applications.
Authentication, by contrast, is far more straightforward.
Best regards -- Rich


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: Anders Rundgren [mailto:[e-mail]]
Sent: Saturday, October 05, 2002 2:09 PM
To: Guida, Richard [JJCUS]; [e-mail]
Subject: Re: Employee Certificates - Security Issues



Richard,
It would be very interesting to know how J&J handles archiving
and authorization, as the conclusion from your answers seems
to be, "we trust all our employees for doing the right thing",
which BTW is in strong contrast to what security officers in
general say.  Not to mention bosses. :-)
In particular, how is authorization with respect to _external_
parties handled?  Based on out-of-band arrangements?
Although workable, I believe this is a very inefficient way to
perform "e-business", whatever the "business" is.
Anders
----- Original Message -----
From: Guida, Richard [JJCUS]
To: Anders Rundgren ; [e-mail]
Sent: Friday, October 04, 2002 21:30
Subject: RE: Employee Certificates - Security Issues


Anders - I don't think I misunderstood.  Your last e-mail makes the point very well - you say that a company PKI is as bad as giving
employees company credit cards.  Well - I had a government credit card when I worked for the USGovernment (as did almost everyone
else - at least those who traveled which was almost everyone, very few exceptions), and I have one from my current employer as well
(again the majority of employees do).  Same is true for every company which I know through professional affiliation.  So I agree
with the implication of your logic - we should do with certs for employees the same as companies have done with credit cards for
employees.  That makes my case better than anything.  Thanks -- Rich



Richard A. Guida
Director, Information Securityu (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: Anders Rundgren [mailto:[e-mail]]
Sent: Friday, October 04, 2002 12:24 PM
To: [e-mail]; Guida, Richard [JJCUS]
Subject: Re: Employee Certificates - Security Issues


Richard,
I think you have mostly misinterpreted my messages.
Employee-PKI means (I do at least), that the employee has a certificate
that allows him/her to act on behalf on their employer.  This is
a fundamental characteristic of the US Federal PKI and commercial
efforts like Identrus.
What I'm saying is that this opens the organization to massive
and non-controllable attacks from disloyal employees etc.  It is a
smart as giving the entire work-force company credit-cards.
Regarding the market, it is interesting to note that there is not a
business system maker of any significance that support a model
where the client's certificate and signature is a part of _outgoing_
messages.  In the same way as there is not a single bank in the
world that does this either.  And this fact is completely independent
of the availability of client-side PKI.
Note: Client-side PKI is absolutely not a bad idea, it is
the idea to hand over specific "company keys" to employees
that is not such a terribly good idea.
Anders




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g96Cawl20865 for ietf-pkix-bks; Sun, 6 Oct 2002 05:36:58 -0700 (PDT)
Received: from ncsusraimge05.jnj.com (ncsusraimge05.jnj.com [148.177.2.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g96Cauv20861 for <[e-mail]>; Sun, 6 Oct 2002 05:36:56 -0700 (PDT)
Received: from NCSUSRAWSC6.na.jnj.com (NCSUSRAWSC6.na.jnj.com [10.4.20.26]) by ncsusraimge05.jnj.com (Switch-2.2.3/Switch-2.2.3) with SMTP id g96CSdC16447 for <[e-mail]>; Sun, 6 Oct 2002 08:28:39 -0400 (EDT)
Received: FROM ncsusraexims2.rar.ncsus.jnj.com BY NCSUSRAWSC6.na.jnj.com ; Sun Oct 06 08:36:20 2002 -0400
Received: by ncsusraexims2.rar.ncsus.jnj.com with Internet Mail Service (5.5.2653.19) id <4CDAFZP6>; Sun, 6 Oct 2002 08:36:51 -0400
Message-ID: <[e-mail]>
From: "Guida, Richard [JJCUS]" <[e-mail]>
To: Anders Rundgren <[e-mail]>, [e-mail]
Subject: RE: Employee Certificates - Security Issues
Date: Sun, 6 Oct 2002 08:36:49 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26D35.0A442E90"
Sender: [e-mail]
Precedence: 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_01C26D35.0A442E90
Content-Type: text/plain;
	charset="iso-8859-1"

Anders - this topic is not conducive to a full description in this thread,
too complicated and too easy to misinterpret.  So I have to give you a
simple and noncomplete answer: employees are trusted to use their electronic
credentials as they are trusted to use other credentials issued them by the
company.  If I took my company picture ID and used it at a local merchant as
proof of who I am for writing a check, AND the merchant accepted that ID, is
the company liable if the ID were forged or if I just left the company and
"forgot" to turn it in (and the company failed to demand it be surrendered)?
Same issue with certificates - if the relying party wants to rely on a
certificate: (a) without checking a CRL; and (b) without checking the
Certificate Policy (our CP explicitly says the certs can only be used for
J&J business and only establish identity, do not established authorization
to perform an act), then the relying party is incurring the risk.  And the
employee who is improperly using the credential is subject to disciplinary
action (or if a former employee, subject potentially to charges of fraud).
Now I realize in the litigious U.S. the "deep pockets" theory often results
in large corporations being hit with liability (responsibility) that they
don't deserve, but thankfully that is not true in much of the rest of the
world.

As for security officers taking the approach of "we don't trust anyone,"
that is a bit simplistic.  I proceed from the premise that the vast majority
of employees want to do the right thing but may get confused or may not know
what "the right thing" is, so training and awareness are paramount.  For
those few who are miscreants, you have to have in place an approach with
overchecks and safeguards to catch them before they can do much damage.  But
to proceed from the premise that every employee, given the opportunity, will
do something evil against his/her company is a scary proposition.  I would
not want to work for a company where management holds that view - and I do
not.

Authorization determinations are indeed handled "out of band," and hopefully
at some point we will employ SAML-based technology for that purpose.
Authorization is (as you and others have commented) an immensely complex
topic, especially given legacy systems and the fact that operating units
(correctly) demand autonomy in making such decisions regarding access to
their own applications.  Authentication, by contrast, is far more
straightforward.

Best regards -- Rich


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: Anders Rundgren [mailto:[e-mail]]
Sent: Saturday, October 05, 2002 2:09 PM
To: Guida, Richard [JJCUS]; [e-mail]
Subject: Re: Employee Certificates - Security Issues



Richard,

It would be very interesting to know how J&J handles archiving
and authorization, as the conclusion from your answers seems
to be, "we trust all our employees for doing the right thing",
which BTW is in strong contrast to what security officers in
general say.  Not to mention bosses. :-)

In particular, how is authorization with respect to _external_
parties handled?  Based on out-of-band arrangements?

Although workable, I believe this is a very inefficient way to
perform "e-business", whatever the "business" is.

Anders

----- Original Message -----
From: Guida, Richard [JJCUS]
To: Anders Rundgren ; [e-mail]
Sent: Friday, October 04, 2002 21:30
Subject: RE: Employee Certificates - Security Issues


Anders - I don't think I misunderstood.  Your last e-mail makes the point
very well - you say that a company PKI is as bad as giving
employees company credit cards.  Well - I had a government credit card when
I worked for the USGovernment (as did almost everyone
else - at least those who traveled which was almost everyone, very few
exceptions), and I have one from my current employer as well
(again the majority of employees do).  Same is true for every company which
I know through professional affiliation.  So I agree
with the implication of your logic - we should do with certs for employees
the same as companies have done with credit cards for
employees.  That makes my case better than anything.  Thanks -- Rich



Richard A. Guida
Director, Information Securityu (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: Anders Rundgren [mailto:[e-mail]]
Sent: Friday, October 04, 2002 12:24 PM
To: [e-mail]; Guida, Richard [JJCUS]
Subject: Re: Employee Certificates - Security Issues


Richard,
I think you have mostly misinterpreted my messages.
Employee-PKI means (I do at least), that the employee has a certificate
that allows him/her to act on behalf on their employer.  This is
a fundamental characteristic of the US Federal PKI and commercial
efforts like Identrus.
What I'm saying is that this opens the organization to massive
and non-controllable attacks from disloyal employees etc.  It is a
smart as giving the entire work-force company credit-cards.
Regarding the market, it is interesting to note that there is not a
business system maker of any significance that support a model
where the client's certificate and signature is a part of _outgoing_
messages.  In the same way as there is not a single bank in the
world that does this either.  And this fact is completely independent
of the availability of client-side PKI.
Note: Client-side PKI is absolutely not a bad idea, it is
the idea to hand over specific "company keys" to employees
that is not such a terribly good idea.
Anders


------_=_NextPart_001_01C26D35.0A442E90
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: Employee Certificates - Security Issues</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Anders - this topic is not conducive to a full =
description in this thread, too complicated and too easy to =
misinterpret.&nbsp; So I have to give you a simple and noncomplete =
answer: employees are trusted to use their electronic credentials as =
they are trusted to use other credentials issued them by the =
company.&nbsp; If I took my company picture ID and used it at a local =
merchant as proof of who I am for writing a check, AND the merchant =
accepted that ID, is the company liable if the ID were forged or if I =
just left the company and &quot;forgot&quot; to turn it in (and the =
company failed to demand it be surrendered)?&nbsp; Same issue with =
certificates - if the relying party wants to rely on a certificate: (a) =
without checking a CRL; and (b) without checking the Certificate Policy =
(our CP explicitly says the certs can only be used for J&amp;J business =
and only establish identity, do not established authorization to =
perform an act), then the relying party is incurring the risk.&nbsp; =
And the employee who is improperly using the credential is subject to =
disciplinary action (or if a former employee, subject potentially to =
charges of fraud).&nbsp; Now I realize in the litigious U.S. the =
&quot;deep pockets&quot; theory often results in large corporations =
being hit with liability (responsibility) that they don't deserve, but =
thankfully that is not true in much of the rest of the =
world.</FONT></P>

<P><FONT SIZE=3D2>As for security officers taking the approach of =
&quot;we don't trust anyone,&quot; that is a bit simplistic.&nbsp; I =
proceed from the premise that the vast majority of employees want to do =
the right thing but may get confused or may not know what &quot;the =
right thing&quot; is, so training and awareness are paramount.&nbsp; =
For those few who are miscreants, you have to have in place an approach =
with overchecks and safeguards to catch them before they can do much =
damage.&nbsp; But to proceed from the premise that every employee, =
given the opportunity, will do something evil against his/her company =
is a scary proposition.&nbsp; I would not want to work for a company =
where management holds that view - and I do not.</FONT></P>

<P><FONT SIZE=3D2>Authorization determinations are indeed handled =
&quot;out of band,&quot; and hopefully at some point we will employ =
SAML-based technology for that purpose.&nbsp; Authorization is (as you =
and others have commented) an immensely complex topic, especially given =
legacy systems and the fact that operating units (correctly) demand =
autonomy in making such decisions regarding access to their own =
applications.&nbsp; Authentication, by contrast, is far more =
straightforward.</FONT></P>

<P><FONT SIZE=3D2>Best regards -- Rich</FONT>
</P>
<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: Anders Rundgren [<A =
HREF=3D"mailto:[e-mail]">mailto:anders.rundgren@telia.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Saturday, October 05, 2002 2:09 PM</FONT>
<BR><FONT SIZE=3D2>To: Guida, Richard [JJCUS]; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Employee Certificates - Security Issues<=
/FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Richard,</FONT>
</P>

<P><FONT SIZE=3D2>It would be very interesting to know how J&amp;J =
handles archiving</FONT>
<BR><FONT SIZE=3D2>and authorization, as the conclusion from your =
answers seems</FONT>
<BR><FONT SIZE=3D2>to be, &quot;we trust all our employees for doing =
the right thing&quot;,</FONT>
<BR><FONT SIZE=3D2>which BTW is in strong contrast to what security =
officers in</FONT>
<BR><FONT SIZE=3D2>general say.&nbsp; Not to mention bosses. :-)</FONT>
</P>

<P><FONT SIZE=3D2>In particular, how is authorization with respect to =
_external_</FONT>
<BR><FONT SIZE=3D2>parties handled?&nbsp; Based on out-of-band =
arrangements?</FONT>
</P>

<P><FONT SIZE=3D2>Although workable, I believe this is a very =
inefficient way to</FONT>
<BR><FONT SIZE=3D2>perform &quot;e-business&quot;, whatever the =
&quot;business&quot; is.</FONT>
</P>

<P><FONT SIZE=3D2>Anders</FONT>
</P>

<P><FONT SIZE=3D2>----- Original Message -----</FONT>
<BR><FONT SIZE=3D2>From: Guida, Richard [JJCUS]</FONT>
<BR><FONT SIZE=3D2>To: Anders Rundgren ; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, October 04, 2002 21:30</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Employee Certificates - Security =
Issues</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Anders - I don't think I misunderstood.&nbsp; Your =
last e-mail makes the point very well - you say that a company PKI is =
as bad as giving</FONT></P>

<P><FONT SIZE=3D2>employees company credit cards.&nbsp; Well - I had a =
government credit card when I worked for the USGovernment (as did =
almost everyone</FONT></P>

<P><FONT SIZE=3D2>else - at least those who traveled which was almost =
everyone, very few exceptions), and I have one from my current employer =
as well</FONT></P>

<P><FONT SIZE=3D2>(again the majority of employees do).&nbsp; Same is =
true for every company which I know through professional =
affiliation.&nbsp; So I agree</FONT></P>

<P><FONT SIZE=3D2>with the implication of your logic - we should do =
with certs for employees the same as companies have done with credit =
cards for</FONT></P>

<P><FONT SIZE=3D2>employees.&nbsp; That makes my case better than =
anything.&nbsp; Thanks -- Rich</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Richard A. Guida</FONT>
<BR><FONT SIZE=3D2>Director, Information Securityu (Medical Devices and =
Diagnostics)</FONT>
<BR><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>
<BR><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: Anders Rundgren [<A =
HREF=3D"mailto:[e-mail]">mailto:anders.rundgren@telia.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, October 04, 2002 12:24 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]; Guida, Richard [JJCUS]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Employee Certificates - Security =
Issues</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Richard,</FONT>
<BR><FONT SIZE=3D2>I think you have mostly misinterpreted my =
messages.</FONT>
<BR><FONT SIZE=3D2>Employee-PKI means (I do at least), that the =
employee has a certificate</FONT>
<BR><FONT SIZE=3D2>that allows him/her to act on behalf on their =
employer.&nbsp; This is</FONT>
<BR><FONT SIZE=3D2>a fundamental characteristic of the US Federal PKI =
and commercial</FONT>
<BR><FONT SIZE=3D2>efforts like Identrus.</FONT>
<BR><FONT SIZE=3D2>What I'm saying is that this opens the organization =
to massive</FONT>
<BR><FONT SIZE=3D2>and non-controllable attacks from disloyal employees =
etc.&nbsp; It is a</FONT>
<BR><FONT SIZE=3D2>smart as giving the entire work-force company =
credit-cards.</FONT>
<BR><FONT SIZE=3D2>Regarding the market, it is interesting to note that =
there is not a</FONT>
<BR><FONT SIZE=3D2>business system maker of any significance that =
support a model</FONT>
<BR><FONT SIZE=3D2>where the client's certificate and signature is a =
part of _outgoing_</FONT>
<BR><FONT SIZE=3D2>messages.&nbsp; In the same way as there is not a =
single bank in the</FONT>
<BR><FONT SIZE=3D2>world that does this either.&nbsp; And this fact is =
completely independent</FONT>
<BR><FONT SIZE=3D2>of the availability of client-side PKI.</FONT>
<BR><FONT SIZE=3D2>Note: Client-side PKI is absolutely not a bad idea, =
it is</FONT>
<BR><FONT SIZE=3D2>the idea to hand over specific &quot;company =
keys&quot; to employees</FONT>
<BR><FONT SIZE=3D2>that is not such a terribly good idea.</FONT>
<BR><FONT SIZE=3D2>Anders</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C26D35.0A442E90--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g95IdRn03333 for ietf-pkix-bks; Sat, 5 Oct 2002 11:39:27 -0700 (PDT)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g95IdQv03328 for <[e-mail]>; Sat, 5 Oct 2002 11:39:26 -0700 (PDT)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maild.telia.com (8.12.5/8.12.5) with SMTP id g95IdRUL008107 for <[e-mail]>; Sat, 5 Oct 2002 20:39:27 +0200 (CEST)
X-Original-Recipient: <[e-mail]>
Message-ID: <014201c26c9d$92e85480$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Re: Employee Certificates - Security Issues
Date: Sat, 5 Oct 2002 20:32:34 +0200
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 thing worth mentioning in the context "employee
certificates", is extranet authentication.

As certificates do usually not contain "information" needed for
many relations, such data must be transferred out-of-band
or use POSTed HTML forms (where clients can fake the
information).

OASIS SAML and similar schemes allow information to
_securely_ be passed during authentication, where the information
may even be different for each extranet partner and relation.

So this, at one time considered "killer app", for employee
certificates is [also] mostly just a relic.

cheers,
Anders





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g95IG7H02297 for ietf-pkix-bks; Sat, 5 Oct 2002 11:16:07 -0700 (PDT)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g95IG5v02291 for <[e-mail]>; Sat, 5 Oct 2002 11:16:06 -0700 (PDT)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maild.telia.com (8.12.5/8.12.5) with SMTP id g95IG5UL019857; Sat, 5 Oct 2002 20:16:05 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <012901c26c9a$4f934490$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Guida, Richard [JJCUS]" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Employee Certificates - Security Issues
Date: Sat, 5 Oct 2002 20:09:13 +0200
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>

Richard,

It would be very interesting to know how J&J handles archiving
and authorization, as the conclusion from your answers seems
to be, "we trust all our employees for doing the right thing",
which BTW is in strong contrast to what security officers in
general say.  Not to mention bosses. :-)

In particular, how is authorization with respect to _external_
parties handled?  Based on out-of-band arrangements?

Although workable, I believe this is a very inefficient way to
perform "e-business", whatever the "business" is.

Anders

----- Original Message -----
From: Guida, Richard [JJCUS]
To: Anders Rundgren ; [e-mail]
Sent: Friday, October 04, 2002 21:30
Subject: RE: Employee Certificates - Security Issues


Anders - I don't think I misunderstood.  Your last e-mail makes the point very well - you say that a company PKI is as bad as giving
employees company credit cards.  Well - I had a government credit card when I worked for the USGovernment (as did almost everyone
else - at least those who traveled which was almost everyone, very few exceptions), and I have one from my current employer as well
(again the majority of employees do).  Same is true for every company which I know through professional affiliation.  So I agree
with the implication of your logic - we should do with certs for employees the same as companies have done with credit cards for
employees.  That makes my case better than anything.  Thanks -- Rich



Richard A. Guida
Director, Information Securityu (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: Anders Rundgren [mailto:[e-mail]]
Sent: Friday, October 04, 2002 12:24 PM
To: [e-mail]; Guida, Richard [JJCUS]
Subject: Re: Employee Certificates - Security Issues


Richard,
I think you have mostly misinterpreted my messages.
Employee-PKI means (I do at least), that the employee has a certificate
that allows him/her to act on behalf on their employer.  This is
a fundamental characteristic of the US Federal PKI and commercial
efforts like Identrus.
What I'm saying is that this opens the organization to massive
and non-controllable attacks from disloyal employees etc.  It is a
smart as giving the entire work-force company credit-cards.
Regarding the market, it is interesting to note that there is not a
business system maker of any significance that support a model
where the client's certificate and signature is a part of _outgoing_
messages.  In the same way as there is not a single bank in the
world that does this either.  And this fact is completely independent
of the availability of client-side PKI.
Note: Client-side PKI is absolutely not a bad idea, it is
the idea to hand over specific "company keys" to employees
that is not such a terribly good idea.
Anders




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g95FbQc22839 for ietf-pkix-bks; Sat, 5 Oct 2002 08:37:26 -0700 (PDT)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g95FbPv22834 for <[e-mail]>; Sat, 5 Oct 2002 08:37:25 -0700 (PDT)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maild.telia.com (8.12.5/8.12.5) with SMTP id g95FbPUL017517; Sat, 5 Oct 2002 17:37:25 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <00d501c26c84$24c41bb0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <003b01c26bc2$7ee835d0$0500a8c0@arport> <[e-mail]>
Subject: Re: Employee Certificates - Security Issues
Date: Sat, 5 Oct 2002 17:30:32 +0200
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 Michael,

>> Employee-PKI means (I do at least), that the employee has a certificate
>> that allows him/her to act on behalf on their employer.

>Nope!
>As others already stated you're wildly mixing authentication and authorization.

I do, as I look on this from a real-world-perspecitive.

For typical, high-volume, day-to-day tasks in many commercial enterprises,
the concept of authorization is an internal issue.  E.g. purchase orders
and invoices are by [de-facto] definition "authorized".

That means that for receivers it does not really matter if an order
is signed by John Doe today, and by his replacement Jane Doe tomorrow.
What is important is that the organizational part of the identity
stays the same.  Sounds primitive?  As there is no X509-way to
express purchaser authority what else can you do?

However, by using the Internet-bank approach there is not a
chance for an unauthorized person to create a valid purchase
order.  By doing that, authorization can continue to [mostly]
be an internal issue, with the difference that it becomes
trustworthy as well.   This though excludes the use of true
end-to-end PKIs for employees like the ones represented
by the US Federal Agency and Identrus.

<snip>

cheers,
Anders




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g95DX0g15501 for ietf-pkix-bks; Sat, 5 Oct 2002 06:33:00 -0700 (PDT)
Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g95DWwv15497 for <[e-mail]>; Sat, 5 Oct 2002 06:32:59 -0700 (PDT)
Received: from fwd09.sul.t-online.de  by mailout11.sul.t-online.com with smtp  id 17xp32-0001PZ-0E; Sat, 05 Oct 2002 15:32:48 +0200
Received: from junker.stroeder.com (520010731148-0001@[193.159.30.130]) by fmrl09.sul.t-online.com with esmtp id 17xp2u-24xw80C; Sat, 5 Oct 2002 15:32:40 +0200
Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id BEEE71581AA; Sat,  5 Oct 2002 15:27:30 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Sat, 05 Oct 2002 15:27:29 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
Reply-To: [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: Anders Rundgren <[e-mail]>
Cc: [e-mail]
Subject: Re: Employee Certificates - Security Issues
References: <[e-mail]> <01a901c26be8$bef35d00$0500a8c0@arport>
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
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>

Anders Rundgren wrote:
> 
> Assume that a purchaser had a PKC + AC where the AC in some
> way says that the purhaser has a $1000 limt.  By doing multiple
> purchases at $999 the purchaser made this information useless.

What does the $1000 limit mean? You did not specify the limit completely as 
you did not specify a business process behind it. Therefore I can't follow 
your argument.

> That's one reason why ACs are unlikely to become very important.

As I stated in a former posting quite a while ago there's not much sense 
putting a general $$$ limit into an AC. But I wouldn't conclude from this 
that ACs in general do not make sense. (I believe that ACs won't fly because 
we don't even have a seriously working X.509-based PKI for PKCs. But that'a 
another story...)

> Another reason is that most sophisticated information systems today are
> built on XML which is superior for ACs as there is both a human-
> readable format (almost at least), and even more important, there is
> the powerful  XML "Schema" language.

Blah... even if you're right the reduction of the business-oriented 
discussion to the long-lasting technical fight XML vs. ASN.1 only shows lack 
of conceptual ideas.

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g95DWvh15495 for ietf-pkix-bks; Sat, 5 Oct 2002 06:32:57 -0700 (PDT)
Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g95DWtv15491 for <[e-mail]>; Sat, 5 Oct 2002 06:32:55 -0700 (PDT)
Received: from fwd07.sul.t-online.de  by mailout09.sul.t-online.com with smtp  id 17xp38-0005Ak-06; Sat, 05 Oct 2002 15:32:54 +0200
Received: from junker.stroeder.com (520010731148-0001@[193.159.30.130]) by fmrl07.sul.t-online.com with esmtp id 17xp2u-1yp5OKC; Sat, 5 Oct 2002 15:32:40 +0200
Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id D75581581A6; Sat,  5 Oct 2002 15:19:02 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Sat, 05 Oct 2002 15:19:02 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
Reply-To: [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: Anders Rundgren <[e-mail]>
Cc: [e-mail]
Subject: Re: Employee Certificates - Security Issues
References: <[e-mail]> <003b01c26bc2$7ee835d0$0500a8c0@arport>
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
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>

Anders Rundgren wrote:
> 
> Employee-PKI means (I do at least), that the employee has a certificate
> that allows him/her to act on behalf on their employer.

Nope!

As others already stated you're wildly mixing authentication and authorization.

BTW: Anders, go into a big group (e.g. consisting of around 300+ companies) 
and ask people for a general long-lasting definition of "employee" e.g. in 
opposite to external workers. You won't get a good definition.

>  This is
> a fundamental characteristic of the US Federal PKI and commercial
> efforts like Identrus.

Don't know about 'US Federal PKI' but AFAIK 'Identrus' is not an employee 
PKI at all.

> What I'm saying is that this opens the organization to massive
> and non-controllable attacks from disloyal employees etc.  It is a
> smart as giving the entire work-force company credit-cards.  

Again: You're wildly mixing authentication and authorization.

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g94MpYk05369 for ietf-pkix-bks; Fri, 4 Oct 2002 15:51:34 -0700 (PDT)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94MpXv05365 for <[e-mail]>; Fri, 4 Oct 2002 15:51:33 -0700 (PDT)
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 4 Oct 2002 15:51:30 -0700
Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 04 Oct 2002 15:51:30 -0700
Received: from RED-MSG-10.redmond.corp.microsoft.com ([157.54.12.42]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 4 Oct 2002 15:51:30 -0700
x-mimeole: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: Cross Certification RFCs
Date: Fri, 4 Oct 2002 15:51:30 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Cross Certification RFCs
thread-index: AcJrwMujIqeoM7UBTjqzBzMPyKnZ7wAN7oMw
From: "David Cross" <[e-mail]>
To: "mars" <[e-mail]>, <[e-mail]>
Cc: "Ignacio Mendivil Gutierrez" <[e-mail]>
X-OriginalArrivalTime: 04 Oct 2002 22:51:30.0442 (UTC) FILETIME=[945476A0:01C26BF8]
Sender: [e-mail]
Precedence: 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.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C26BF8.94158D58"

------_=_NextPart_001_01C26BF8.94158D58
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

RFC 3280 and RFC 2459
=20
I have a draft whitepaper that will help explain this technology from a
Microsoft perspective.
=20
Regards,
=20
=20
David B. Cross
Program Manager
Windows Security
	-----Original Message-----
	From: mars [mailto:[e-mail]]=20
	Sent: Friday, October 04, 2002 9:07 AM
	To: [e-mail]
	Subject: Cross Certification RFCs
=09
=09
	What are the RFCs and drafts that contain requirements and
information regarding cross certification?
	=20
	Best regards,
	=20
	Miguel A. Rodriguez
	SeguriDATA
	Mexico
	=20

------_=_NextPart_001_01C26BF8.94158D58
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>Message</TITLE>=

<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<META content=3D"Microsoft Word 10" name=3DOriginator><LINK=20
href=3D"cid:filelist.xml@01C26B96.1C0D1100" =
rel=3DFile-List><o:SmartTagType=20
name=3D"country-region"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[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:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 90.0pt =
72.0pt 90.0pt; mso-header-margin: 35.4pt; mso-footer-margin: 35.4pt; =
mso-paper-source: 0; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: =
personal-compose; mso-style-noshow: yes; mso-ansi-font-size: 10.0pt; =
mso-bidi-font-size: 10.0pt; mso-ascii-font-family: Arial; =
mso-hansi-font-family: Arial; mso-bidi-font-family: Arial
}
SPAN.SpellE {
	mso-style-name: ""; mso-spl-e: yes
}
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:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	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 style=3D"tab-interval: 36.0pt" vLink=3Dpurple =
link=3Dblue>
<DIV>
<DIV><SPAN class=3D578324822-04102002><FONT face=3DArial color=3D#008080 =

size=3D2><STRONG>RFC 3280 and RFC 2459</STRONG></FONT></SPAN></DIV>
<DIV><SPAN class=3D578324822-04102002><STRONG><FONT face=3DArial =
color=3D#008080=20
size=3D2></FONT></STRONG></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D578324822-04102002><STRONG><FONT face=3DArial =
color=3D#008080=20
size=3D2>I have a draft whitepaper that will help explain this =
technology from a=20
Microsoft perspective.</FONT></STRONG></SPAN></DIV>
<DIV><SPAN class=3D578324822-04102002><STRONG><FONT face=3DArial =
color=3D#008080=20
size=3D2></FONT></STRONG></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D578324822-04102002><STRONG><FONT face=3DArial =
color=3D#008080=20
size=3D2>Regards,</FONT></STRONG></SPAN></DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dleft>
<P dir=3Dltr align=3Dleft><FONT size=3D1><FONT face=3DArial>David B.=20
Cross<BR></FONT></FONT><FONT size=3D1><FONT face=3DArial>Program =
Manager<BR><FONT=20
color=3D#ff0000>Windows Security</FONT></FONT></FONT></P></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> mars =

  [mailto:[e-mail]] <BR><B>Sent:</B> Friday, October 04, 2002 =
9:07=20
  AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> Cross =
Certification=20
  RFCs<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">What are the <SPAN=20
  class=3DSpellE>RFCs</SPAN> and drafts that contain requirements and =
information=20
  regarding cross certification?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Best=20
  regards,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-no-proof: =
yes">Miguel A.=20
  Rodriguez</SPAN></FONT><SPAN style=3D"mso-no-proof: =
yes"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-no-proof: =
yes">SeguriDATA</SPAN></FONT><SPAN=20
  style=3D"mso-no-proof: yes"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><st1:country-region><st1:place><FONT face=3DArial =

  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-no-proof: =
yes">Mexico</SPAN></FONT></st1:place></st1:country-region><o:p></o:p></P>=

  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML=
>
=00
------_=_NextPart_001_01C26BF8.94158D58--

--------------InterScan_NT_MIME_Boundary--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g94MK4G04321 for ietf-pkix-bks; Fri, 4 Oct 2002 15:20:04 -0700 (PDT)
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 g94MK2v04310 for <[e-mail]>; Fri, 4 Oct 2002 15:20:02 -0700 (PDT)
Subject: Re: Employee Certificates - Security Issues
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail], [e-mail], "Guida, Richard [JJCUS]" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 4 Oct 2002 13:32:33 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 10/04/2002 06:23:02 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>

the other way of looking at it ... is most certificates have been assumed
to be certifying something that an institution already knows (or has been
obtained by a TTP for use by other, relying parties).

In the case of a relying-only-party certificate ... where the institution
typically already has a business process in place that has vented the
information and it is stored in something like an employee record or a
client record .... or some similar type of record .... transposing a subset
of that information into a stale, r/o copy of such a record (aka into a
certificate) ... for their own use .... is frequently redundant and
superfulous and an artificial artifact of varous COTS digital signature
software that they might be using.

A r-p-o certificate needs little else than a reference to the account
record where the real, up-to-date information is stored ... and such
reference is aleady typically carriend in the main body of the signed
message and it is redundant to also carry it an additionally appended
separate signed message (called a certificate).
Additional information (other than a record locator) frequently can be
construed as a serious privacy issue (especially in consumer/retail
setting)

A non r-p-o certificate ... for others use,  is where some additional
information might need to be carried ... but that opens up the whole bag of
worms regarding privacy and liability and what if any (liability)
commitment is the certifying body making with respect to the information
carried in such a certificate ...

in otherwords

1) can i trust my own information that might also be carried in a redundant
& superfulous r-p-o certificate

2) what reason, if any, should anybody else trust any information carried
in a certificate (and if they were to construe any such information in a
financial/business setting is there implied liability)

one way of making sure there is no implied reliance on a r-p-o certificate
and therefor no implied liability (and/or even privacy exposure) ... is to
not actually every transmit such a certificate ... if it never actually
exists ... then it is hard for other parties to claim reliance (&/or
liability).



anders rundgren <[e-mail]> on 10/4/2002 10:24 am wrote:

Richard,
I think you have mostly misinterpreted my messages.

Employee-PKI means (I do at least), that the employee has a certificate
that allows him/her to act on behalf on their employer.  This is
a fundamental characteristic of the US Federal PKI and commercial
efforts like Identrus.

What I'm saying is that this opens the organization to massive
and non-controllable attacks from disloyal employees etc.  It is a
smart as giving the entire work-force company credit-cards.

Regarding the market, it is interesting to note that there is not a
business system maker of any significance that support a model
where the client's certificate and signature is a part of _outgoing_
messages.  In the same way as there is not a single bank in the
world that does this either.  And this fact is completely independent
of the availability of client-side PKI.

Note: Client-side PKI is absolutely not a bad idea, it is
the idea to hand over specific "company keys" to employees
that is not such a terribly good idea.

Anders





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g94L55w02265 for ietf-pkix-bks; Fri, 4 Oct 2002 14:05:05 -0700 (PDT)
Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94L53v02261 for <[e-mail]>; Fri, 4 Oct 2002 14:05:04 -0700 (PDT)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maila.telia.com (8.12.5/8.12.5) with SMTP id g94L51ZH005326; Fri, 4 Oct 2002 23:05:01 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <01a901c26be8$bef35d00$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Roberto Opazo" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Employee Certificates - Security Issues
Date: Fri, 4 Oct 2002 22:58:09 +0200
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>

Roberto,
May I challenge this a bit?

Assume that a purchaser had a PKC + AC where the AC in some
way says that the purhaser has a $1000 limt.  By doing multiple
purchases at $999 the purchaser made this information useless.

Static solutions to dynamic problems is not a "hit".

That's one reason why ACs are unlikely to become very important.

Another reason is that most sophisticated information systems today are
built on XML which is superior for ACs as there is both a human-
readable format (almost at least), and even more important, there is
the powerful  XML "Schema" language.

cheers,
Anders

----- Original Message ----- 
From: "Roberto Opazo" <[e-mail]>
To: <[e-mail]>
Sent: Friday, October 04, 2002 22:15
Subject: RE: Employee Certificates - Security Issues



Hello everybody,

This tread is just showing some of the problems you can have when mixing a
public key certificate (PKC) with an attribute certificate (AC), the
solution is very ease: Do not do so.

RFC 3281 states:
"Some people constantly confuse PKCs and ACs.  An analogy may make the
   distinction clear.  A PKC can be considered to be like a passport: it
   identifies the holder, tends to last for a long time, and should not
   be trivial to obtain.  An AC is more like an entry visa: it is
   typically issued by a different authority and does not last for as
   long a time.  As acquiring an entry visa typically requires
   presenting a passport, getting a visa can be a simpler process.

   Authorization information may be placed in a PKC extension or placed
   in a separate attribute certificate (AC).  The placement of
   authorization information in PKCs is usually undesirable for two
   reasons.  First, authorization information often does not have the
   same lifetime as the binding of the identity and the public key.
   When authorization information is placed in a PKC extension, the
   general result is the shortening of the PKC useful lifetime.  Second,
   the PKC issuer is not usually authoritative for the authorization
   information.  This results in additional steps for the PKC issuer to
   obtain authorization information from the authoritative source."

Now than we have a standard to solve this problem, lets use it!

We need applications using this standard, not another discussion to define a
new standard, to need again, applications using the new standard. We could
repeat this circle as many times as we want.

Best regards,

Roberto Opazo

> -----Mensaje original-----
> De: [e-mail] [mailto:[e-mail]]En
> nombre de Anders Rundgren
> Enviado el: viernes, 04 de octubre de 2002 12:24
> Para: [e-mail]; Guida, Richard [JJCUS]
> Asunto: Re: Employee Certificates - Security Issues
>
>
>
> Richard,
> I think you have mostly misinterpreted my messages.
>
> Employee-PKI means (I do at least), that the employee has a certificate
> that allows him/her to act on behalf on their employer.  This is
> a fundamental characteristic of the US Federal PKI and commercial
> efforts like Identrus.
>
> What I'm saying is that this opens the organization to massive
> and non-controllable attacks from disloyal employees etc.  It is a
> smart as giving the entire work-force company credit-cards.
>
> Regarding the market, it is interesting to note that there is not a
> business system maker of any significance that support a model
> where the client's certificate and signature is a part of _outgoing_
> messages.  In the same way as there is not a single bank in the
> world that does this either.  And this fact is completely independent
> of the availability of client-side PKI.
>
> Note: Client-side PKI is absolutely not a bad idea, it is
> the idea to hand over specific "company keys" to employees
> that is not such a terribly good idea.
>
> Anders




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g94KJ4728427 for ietf-pkix-bks; Fri, 4 Oct 2002 13:19:04 -0700 (PDT)
Received: from slx_cus_mai02.custodium.com ([216.241.20.228]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94KJ2v28423 for <[e-mail]>; Fri, 4 Oct 2002 13:19:02 -0700 (PDT)
Received: from ww2kropazo ([192.168.4.100]) by slx_cus_mai02.custodium.com (8.12.2/8.12.2) with SMTP id g94KIbmm031828 for <[e-mail]>; Fri, 4 Oct 2002 16:18:52 -0400
From: "Roberto Opazo" <[e-mail]>
To: <[e-mail]>
Subject: RE: Employee Certificates - Security Issues
Date: Fri, 4 Oct 2002 16:15:00 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: High
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <003b01c26bc2$7ee835d0$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>

Hello everybody,

This tread is just showing some of the problems you can have when mixing a
public key certificate (PKC) with an attribute certificate (AC), the
solution is very ease: Do not do so.

RFC 3281 states:
“Some people constantly confuse PKCs and ACs.  An analogy may make the
   distinction clear.  A PKC can be considered to be like a passport: it
   identifies the holder, tends to last for a long time, and should not
   be trivial to obtain.  An AC is more like an entry visa: it is
   typically issued by a different authority and does not last for as
   long a time.  As acquiring an entry visa typically requires
   presenting a passport, getting a visa can be a simpler process.

   Authorization information may be placed in a PKC extension or placed
   in a separate attribute certificate (AC).  The placement of
   authorization information in PKCs is usually undesirable for two
   reasons.  First, authorization information often does not have the
   same lifetime as the binding of the identity and the public key.
   When authorization information is placed in a PKC extension, the
   general result is the shortening of the PKC useful lifetime.  Second,
   the PKC issuer is not usually authoritative for the authorization
   information.  This results in additional steps for the PKC issuer to
   obtain authorization information from the authoritative source.”

Now than we have a standard to solve this problem, lets use it!

We need applications using this standard, not another discussion to define a
new standard, to need again, applications using the new standard. We could
repeat this circle as many times as we want.

Best regards,

Roberto Opazo

> -----Mensaje original-----
> De: [e-mail] [mailto:[e-mail]]En
> nombre de Anders Rundgren
> Enviado el: viernes, 04 de octubre de 2002 12:24
> Para: [e-mail]; Guida, Richard [JJCUS]
> Asunto: Re: Employee Certificates - Security Issues
>
>
>
> Richard,
> I think you have mostly misinterpreted my messages.
>
> Employee-PKI means (I do at least), that the employee has a certificate
> that allows him/her to act on behalf on their employer.  This is
> a fundamental characteristic of the US Federal PKI and commercial
> efforts like Identrus.
>
> What I'm saying is that this opens the organization to massive
> and non-controllable attacks from disloyal employees etc.  It is a
> smart as giving the entire work-force company credit-cards.
>
> Regarding the market, it is interesting to note that there is not a
> business system maker of any significance that support a model
> where the client's certificate and signature is a part of _outgoing_
> messages.  In the same way as there is not a single bank in the
> world that does this either.  And this fact is completely independent
> of the availability of client-side PKI.
>
> Note: Client-side PKI is absolutely not a bad idea, it is
> the idea to hand over specific "company keys" to employees
> that is not such a terribly good idea.
>
> Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g94JUIA25893 for ietf-pkix-bks; Fri, 4 Oct 2002 12:30:18 -0700 (PDT)
Received: from ncsusraimge05.jnj.com (ncsusraimge05.jnj.com [148.177.2.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94JUGv25889 for <[e-mail]>; Fri, 4 Oct 2002 12:30:16 -0700 (PDT)
Received: from NCSUSRAWSC6.na.jnj.com (NCSUSRAWSC6.na.jnj.com [10.4.20.26]) by ncsusraimge05.jnj.com (Switch-2.2.3/Switch-2.2.3) with SMTP id g94JM1C23581 for <[e-mail]>; Fri, 4 Oct 2002 15:22:01 -0400 (EDT)
Received: FROM ncsusraexims1.rar.ncsus.jnj.com BY NCSUSRAWSC6.na.jnj.com ; Fri Oct 04 15:30:12 2002 -0400
Received: by ncsusraexims1.rar.ncsus.jnj.com with Internet Mail Service (5.5.2653.19) id <4CCV7XD7>; Fri, 4 Oct 2002 15:30:10 -0400
Message-ID: <[e-mail]>
From: "Guida, Richard [JJCUS]" <[e-mail]>
To: Anders Rundgren <[e-mail]>, [e-mail]
Subject: RE: Employee Certificates - Security Issues
Date: Fri, 4 Oct 2002 15:30:02 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26BDC.6F33A36C"
Sender: [e-mail]
Precedence: 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_01C26BDC.6F33A36C
Content-Type: text/plain;
	charset="iso-8859-1"

Anders - I don't think I misunderstood.  Your last e-mail makes the point
very well - you say that a company PKI is as bad as giving employees company
credit cards.  Well - I had a government credit card when I worked for the
USGovernment (as did almost everyone else - at least those who traveled
which was almost everyone, very few exceptions), and I have one from my
current employer as well (again the majority of employees do).  Same is true
for every company which I know through professional affiliation.  So I agree
with the implication of your logic - we should do with certs for employees
the same as companies have done with credit cards for employees.  That makes
my case better than anything.  Thanks -- Rich



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: Anders Rundgren [mailto:[e-mail]]
Sent: Friday, October 04, 2002 12:24 PM
To: [e-mail]; Guida, Richard [JJCUS]
Subject: Re: Employee Certificates - Security Issues


Richard,
I think you have mostly misinterpreted my messages.

Employee-PKI means (I do at least), that the employee has a certificate
that allows him/her to act on behalf on their employer.  This is
a fundamental characteristic of the US Federal PKI and commercial
efforts like Identrus.

What I'm saying is that this opens the organization to massive
and non-controllable attacks from disloyal employees etc.  It is a
smart as giving the entire work-force company credit-cards.  

Regarding the market, it is interesting to note that there is not a
business system maker of any significance that support a model
where the client's certificate and signature is a part of _outgoing_
messages.  In the same way as there is not a single bank in the
world that does this either.  And this fact is completely independent
of the availability of client-side PKI.

Note: Client-side PKI is absolutely not a bad idea, it is
the idea to hand over specific "company keys" to employees
that is not such a terribly good idea.

Anders

------_=_NextPart_001_01C26BDC.6F33A36C
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: Employee Certificates - Security Issues</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Anders - I don't think I misunderstood.&nbsp; Your =
last e-mail makes the point very well - you say that a company PKI is =
as bad as giving employees company credit cards.&nbsp; Well - I had a =
government credit card when I worked for the USGovernment (as did =
almost everyone else - at least those who traveled which was almost =
everyone, very few exceptions), and I have one from my current employer =
as well (again the majority of employees do).&nbsp; Same is true for =
every company which I know through professional affiliation.&nbsp; So I =
agree with the implication of your logic - we should do with certs for =
employees the same as companies have done with credit cards for =
employees.&nbsp; That makes my case better than anything.&nbsp; Thanks =
-- Rich</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: Anders Rundgren [<A =
HREF=3D"mailto:[e-mail]">mailto:anders.rundgren@telia.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, October 04, 2002 12:24 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]; Guida, Richard [JJCUS]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Employee Certificates - Security =
Issues</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Richard,</FONT>
<BR><FONT SIZE=3D2>I think you have mostly misinterpreted my =
messages.</FONT>
</P>

<P><FONT SIZE=3D2>Employee-PKI means (I do at least), that the employee =
has a certificate</FONT>
<BR><FONT SIZE=3D2>that allows him/her to act on behalf on their =
employer.&nbsp; This is</FONT>
<BR><FONT SIZE=3D2>a fundamental characteristic of the US Federal PKI =
and commercial</FONT>
<BR><FONT SIZE=3D2>efforts like Identrus.</FONT>
</P>

<P><FONT SIZE=3D2>What I'm saying is that this opens the organization =
to massive</FONT>
<BR><FONT SIZE=3D2>and non-controllable attacks from disloyal employees =
etc.&nbsp; It is a</FONT>
<BR><FONT SIZE=3D2>smart as giving the entire work-force company =
credit-cards.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Regarding the market, it is interesting to note that =
there is not a</FONT>
<BR><FONT SIZE=3D2>business system maker of any significance that =
support a model</FONT>
<BR><FONT SIZE=3D2>where the client's certificate and signature is a =
part of _outgoing_</FONT>
<BR><FONT SIZE=3D2>messages.&nbsp; In the same way as there is not a =
single bank in the</FONT>
<BR><FONT SIZE=3D2>world that does this either.&nbsp; And this fact is =
completely independent</FONT>
<BR><FONT SIZE=3D2>of the availability of client-side PKI.</FONT>
</P>

<P><FONT SIZE=3D2>Note: Client-side PKI is absolutely not a bad idea, =
it is</FONT>
<BR><FONT SIZE=3D2>the idea to hand over specific &quot;company =
keys&quot; to employees</FONT>
<BR><FONT SIZE=3D2>that is not such a terribly good idea.</FONT>
</P>

<P><FONT SIZE=3D2>Anders</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C26BDC.6F33A36C--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g94GVF317381 for ietf-pkix-bks; Fri, 4 Oct 2002 09:31:15 -0700 (PDT)
Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94GVEv17376 for <[e-mail]>; Fri, 4 Oct 2002 09:31:14 -0700 (PDT)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maila.telia.com (8.12.5/8.12.5) with SMTP id g94GVDZH002656; Fri, 4 Oct 2002 18:31:13 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <003b01c26bc2$7ee835d0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Guida, Richard [JJCUS]" <[e-mail]>
References: <[e-mail]>
Subject: Re: Employee Certificates - Security Issues
Date: Fri, 4 Oct 2002 18:24:21 +0200
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>

Richard,
I think you have mostly misinterpreted my messages.

Employee-PKI means (I do at least), that the employee has a certificate
that allows him/her to act on behalf on their employer.  This is
a fundamental characteristic of the US Federal PKI and commercial
efforts like Identrus.

What I'm saying is that this opens the organization to massive
and non-controllable attacks from disloyal employees etc.  It is a
smart as giving the entire work-force company credit-cards.  

Regarding the market, it is interesting to note that there is not a
business system maker of any significance that support a model
where the client's certificate and signature is a part of _outgoing_
messages.  In the same way as there is not a single bank in the
world that does this either.  And this fact is completely independent
of the availability of client-side PKI.

Note: Client-side PKI is absolutely not a bad idea, it is
the idea to hand over specific "company keys" to employees
that is not such a terribly good idea.

Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g94G7Sd16510 for ietf-pkix-bks; Fri, 4 Oct 2002 09:07:28 -0700 (PDT)
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94G7Rv16506 for <[e-mail]>; Fri, 4 Oct 2002 09:07:27 -0700 (PDT)
Received: from MarsXP ([148.233.248.105]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 4 Oct 2002 11:07:46 -0500
From: "mars" <[e-mail]>
To: <[e-mail]>
Subject: Cross Certification RFCs
Date: Fri, 4 Oct 2002 11:06:59 -0500
Message-ID: <000001c26bc0$14ef11a0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C26B96.2C1909A0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 04 Oct 2002 16:07:46.0453 (UTC) FILETIME=[2DB51450:01C26BC0]
Sender: [e-mail]
Precedence: 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_0001_01C26B96.2C1909A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

What are the RFCs and drafts that contain requirements and information
regarding cross certification?
 
Best regards,
 
Miguel A. Rodriguez
SeguriDATA
Mexico
 

------=_NextPart_000_0001_01C26B96.2C1909A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<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@01C26B96.1C0D1100">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"country-region"/>
<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:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	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:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	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:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	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:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	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=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>What are the <span class=3DSpellE>RFCs</span> and =
drafts that
contain requirements and information regarding cross =
certification?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Best regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-no-proof:yes'>Miguel A. =
Rodriguez</span></font><span
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-no-proof:yes'>SeguriDATA</span></font><span
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

<p class=3DMsoNormal><st1:country-region><st1:place><font size=3D2 =
face=3DArial><span
  =
style=3D'font-size:10.0pt;font-family:Arial;mso-no-proof:yes'>Mexico</spa=
n></font></st1:place></st1:country-region><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0001_01C26B96.2C1909A0--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g94G3td16429 for ietf-pkix-bks; Fri, 4 Oct 2002 09:03:55 -0700 (PDT)
Received: from uni04du.unity.ncsu.edu (uni04du.unity.ncsu.edu [152.1.2.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94G3rv16425 for <[e-mail]>; Fri, 4 Oct 2002 09:03:53 -0700 (PDT)
Received: (from hhuang2@localhost) by uni04du.unity.ncsu.edu (8.8.4/EC02Jan97) id MAA17545; Fri, 4 Oct 2002 12:03:43 -0400 (EDT)
Date: Fri, 4 Oct 2002 12:03:43 -0400 (EDT)
From: He Huang <[e-mail]>
To: [e-mail]
Message-ID: <[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>

Hello,

I'm interested in mechanism and rules in assigning CAs
in different layers of the hierarchical diagram in real world.
Does anyone have such resources as deployed PKI example in
the real world? Thanks in advance,

He Huang



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g94FObi13725 for ietf-pkix-bks; Fri, 4 Oct 2002 08:24:37 -0700 (PDT)
Received: from ncsusraimge05.jnj.com (ncsusraimge05.jnj.com [148.177.2.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94FOZv13720 for <[e-mail]>; Fri, 4 Oct 2002 08:24:36 -0700 (PDT)
Received: from NCSUSRAWSC6.na.jnj.com (NCSUSRAWSC6.na.jnj.com [10.4.20.26]) by ncsusraimge05.jnj.com (Switch-2.2.3/Switch-2.2.3) with SMTP id g94FGMC09039 for <[e-mail]>; Fri, 4 Oct 2002 11:16:22 -0400 (EDT)
Received: FROM ncsusraexims2.rar.ncsus.jnj.com BY NCSUSRAWSC6.na.jnj.com ; Fri Oct 04 11:24:31 2002 -0400
Received: by ncsusraexims2.rar.ncsus.jnj.com with Internet Mail Service (5.5.2653.19) id <4CC000YX>; Fri, 4 Oct 2002 11:24:30 -0400
Message-ID: <[e-mail]>
From: "Guida, Richard [JJCUS]" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, [e-mail]
Subject: RE: Employee Certificates - Security Issues
Date: Fri, 4 Oct 2002 11:24:20 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26BB6.1570F760"
Sender: [e-mail]
Precedence: 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_01C26BB6.1570F760
Content-Type: text/plain;
	charset="iso-8859-1"

Thanks, Anders, always good to be forgiven, although I usually hope to get
that from a cleric.  I think it is safe to say we have a different
world-view on how electronic signatures are actually used in intracompany
and intercompany commerce.  Digital signatures remain the strongest method
for that purpose, but like any tool, a relying party can misinterpret or
misuse a received dig sig just as he/she can misinterpret or misuse any
other form of e-signature or wet signature (if we were to eschew a
technology just because it has the potential for misinterpretation or
misuse, life would be somewhat less interesting).  Regardless, one can use
certificates (as you know) for much more than just e-signatures - they can
also be employed for user authentication and data confidentiality.  I know
of no single credential type or infrastructure which supports all of those
functionalities in such a robust fashion.  I use my company-supplied
signature and encryption certificates (and of course the private keys
corresponding the public keys in those certs) dozens of times every day,
with many internal applications as well as externally facing ones, so the
technology is real and it has arrived.  So rather than theorizing about
things, let's see how the marketplace really evolves.  PKI was going to the
savior of us all (no), then it was deemed to be next to useless (also no),
the truth is inbetween.  As an engineer, I firmly believe that the devil is
in the details of any security infrastructure; with that in mind, PKI
affords the firmest foundation upon which to construct a security framework.
But like any foundation, one has to build appropriate structures on top of
it - like privilege management and authorization functionality - to have a
full solution.  Best regards -- Rich


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: Anders Rundgren [mailto:[e-mail]]
Sent: Friday, October 04, 2002 10:37 AM
To: Guida, Richard [JJCUS]; [e-mail]
Subject: Re: Employee Certificates - Security Issues


Richard,

>Anders - forgive me but you have a simplistic and incorrect view of
>how things really work.  

I forgive you.  But don't forget that the outside world does not have
this granularity.  It is probably even more "simplistic" than I am :-)

>A digital identity certificate proves (to whatever degree the certificate
>policy underlying it affords) identity. 
>It does not prove authority to take an action. 

Agreed, but what about purchase orders to take a simple example.
If the partner (the employee's organization) is already a customer, I
would say that most orders would be expedited as the identity of
the employee is of secondary importance.  That the purchase order
was created on a market-place somewhere and that the employee
"forgot" to notify purchasing about it, is an example of a very low-
quality IT-architecture that I would not spend a penny on. 

That my company can sue me _after_ they filed for bankruptcy
due to my ordering of that big 4WD-car is a limited comfort. 
Using the Internet-bank model I would have not been able to do
this purchase at all.  It is always _much_ cheaper to solve
problems _before_ they are actually created :-)

cheers,
Anders


------_=_NextPart_001_01C26BB6.1570F760
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: Employee Certificates - Security Issues</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Thanks, Anders, always good to be forgiven, although =
I usually hope to get that from a cleric.&nbsp; I think it is safe to =
say we have a different world-view on how electronic signatures are =
actually used in intracompany and intercompany commerce.&nbsp; Digital =
signatures remain the strongest method for that purpose, but like any =
tool, a relying party can misinterpret or misuse a received dig sig =
just as he/she can misinterpret or misuse any other form of e-signature =
or wet signature (if we were to eschew a technology just because it has =
the potential for misinterpretation or misuse, life would be somewhat =
less interesting).&nbsp; Regardless, one can use certificates (as you =
know) for much more than just e-signatures - they can also be employed =
for user authentication and data confidentiality.&nbsp; I know of no =
single credential type or infrastructure which supports all of those =
functionalities in such a robust fashion.&nbsp; I use my =
company-supplied signature and encryption certificates (and of course =
the private keys corresponding the public keys in those certs) dozens =
of times every day, with many internal applications as well as =
externally facing ones, so the technology is real and it has =
arrived.&nbsp; So rather than theorizing about things, let's see how =
the marketplace really evolves.&nbsp; PKI was going to the savior of us =
all (no), then it was deemed to be next to useless (also no), the truth =
is inbetween.&nbsp; As an engineer, I firmly believe that the devil is =
in the details of any security infrastructure; with that in mind, PKI =
affords the firmest foundation upon which to construct a security =
framework.&nbsp; But like any foundation, one has to build appropriate =
structures on top of it - like privilege management and authorization =
functionality - to have a full solution.&nbsp; Best regards -- =
Rich</FONT></P>
<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: Anders Rundgren [<A =
HREF=3D"mailto:[e-mail]">mailto:anders.rundgren@telia.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, October 04, 2002 10:37 AM</FONT>
<BR><FONT SIZE=3D2>To: Guida, Richard [JJCUS]; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Employee Certificates - Security =
Issues</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Richard,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Anders - forgive me but you have a simplistic and =
incorrect view of</FONT>
<BR><FONT SIZE=3D2>&gt;how things really work.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>I forgive you.&nbsp; But don't forget that the =
outside world does not have</FONT>
<BR><FONT SIZE=3D2>this granularity.&nbsp; It is probably even more =
&quot;simplistic&quot; than I am :-)</FONT>
</P>

<P><FONT SIZE=3D2>&gt;A digital identity certificate proves (to =
whatever degree the certificate</FONT>
<BR><FONT SIZE=3D2>&gt;policy underlying it affords) identity. </FONT>
<BR><FONT SIZE=3D2>&gt;It does not prove authority to take an action. =
</FONT>
</P>

<P><FONT SIZE=3D2>Agreed, but what about purchase orders to take a =
simple example.</FONT>
<BR><FONT SIZE=3D2>If the partner (the employee's organization) is =
already a customer, I</FONT>
<BR><FONT SIZE=3D2>would say that most orders would be expedited as the =
identity of</FONT>
<BR><FONT SIZE=3D2>the employee is of secondary importance.&nbsp; That =
the purchase order</FONT>
<BR><FONT SIZE=3D2>was created on a market-place somewhere and that the =
employee</FONT>
<BR><FONT SIZE=3D2>&quot;forgot&quot; to notify purchasing about it, is =
an example of a very low-</FONT>
<BR><FONT SIZE=3D2>quality IT-architecture that I would not spend a =
penny on. </FONT>
</P>

<P><FONT SIZE=3D2>That my company can sue me _after_ they filed for =
bankruptcy</FONT>
<BR><FONT SIZE=3D2>due to my ordering of that big 4WD-car is a limited =
comfort. </FONT>
<BR><FONT SIZE=3D2>Using the Internet-bank model I would have not been =
able to do</FONT>
<BR><FONT SIZE=3D2>this purchase at all.&nbsp; It is always _much_ =
cheaper to solve</FONT>
<BR><FONT SIZE=3D2>problems _before_ they are actually created =
:-)</FONT>
</P>

<P><FONT SIZE=3D2>cheers,</FONT>
<BR><FONT SIZE=3D2>Anders</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C26BB6.1570F760--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g94EhhH11074 for ietf-pkix-bks; Fri, 4 Oct 2002 07:43:43 -0700 (PDT)
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 g94Ehgv11070 for <[e-mail]>; Fri, 4 Oct 2002 07:43:42 -0700 (PDT)
Received: from arport ([62.119.75.13]) by blooper.utfors.se (8.12.6/8.12.6) with SMTP id g94EhVtA006479; Fri, 4 Oct 2002 16:43:31 +0200 (MEST)
Message-ID: <030701c26bb3$769772b0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Guida, Richard [JJCUS]" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Employee Certificates - Security Issues
Date: Fri, 4 Oct 2002 16:36:40 +0200
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>

Richard,

>Anders - forgive me but you have a simplistic and incorrect view of
>how things really work.  

I forgive you.  But don't forget that the outside world does not have
this granularity.  It is probably even more "simplistic" than I am :-)

>A digital identity certificate proves (to whatever degree the certificate
>policy underlying it affords) identity. 
>It does not prove authority to take an action. 

Agreed, but what about purchase orders to take a simple example.
If the partner (the employee's organization) is already a customer, I
would say that most orders would be expedited as the identity of
the employee is of secondary importance.  That the purchase order
was created on a market-place somewhere and that the employee
"forgot" to notify purchasing about it, is an example of a very low-
quality IT-architecture that I would not spend a penny on. 

That my company can sue me _after_ they filed for bankruptcy
due to my ordering of that big 4WD-car is a limited comfort. 
Using the Internet-bank model I would have not been able to do
this purchase at all.  It is always _much_ cheaper to solve
problems _before_ they are actually created :-)

cheers,
Anders




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g94Ee5J10983 for ietf-pkix-bks; Fri, 4 Oct 2002 07:40:05 -0700 (PDT)
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 g94Ee3v10972 for <[e-mail]>; Fri, 4 Oct 2002 07:40:03 -0700 (PDT)
Subject: Re: Employee Certificates - Security Issues
To: "Anders Rundgren" <[e-mail]>
Cc: "Juergen Brauckmann" <[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: Fri, 4 Oct 2002 07:54:24 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 10/04/2002 10:35:18 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>

there are two other scenarios given in
http://www.garlic.com/~lynn/index.html#aads

it is a traditional PKI but either

1) the Certification Authority is issuing a relying-party-only certificate
... however it is interested in saving bandwidth. It realizes that the
certificate will only be used in valid transactions with the institution
and that PKI allows for cached certificates .... so it pre-caches the
certificate original in the respective account record and saves the
bandwidth of sending a certificate copy back to the key-owner (and
eliminates the key-owner ever having to attach the certificate copy to a
transaction and return it to the certifying/relying party ... that already
has pre-cached the certificate original and therefor returning the
certificate copy to the entity that has the certificate original is
redundant and superfulous)

2) the Certification Authority is issuing a relying-party-only certificate
... however it is interested in saving bandwidth. It realizes that all the
fields in the certificate are already present at the relying/certifying
party and that there are PKI standards for compressing certificates. Using
the simple principle of knowledge compression, it is possible to "compess"
from the certificate fields that are already present at the
certifying/relying party. As a result, the certifying/relying party
compresses all duplicate fields from the certificate resulting in a zero
byte certificate. The key owner receives this zero byte certificate and
attaches it to every transaction.

Now as to the storage of the original certificate at the relying/certifying
party. Typically something like ASN.1 encoding is used for encoding the
certificate ... primarily for transmission and interoperability. However
since the relying/certifying party is just recording the information ....
after either 1) or 2) above ... the certifying party pre-decodes the ASN..1
encoding prior to storing the information (either 1) the original
certificate or 2) the individual fields).



anders.rundgren <[e-mail]> on 10/4/2002 3:15 am wrote:

No, the Internet-bank model does not require any "particular" client-
certificates, it is enough that you are recognized/accepted/trusted as
no traces of client certs ever leaves your bank.  You can use a "civil"
ID-card with no information about bank, employment etc.
A major Swedish bank is buying such from a TPP to take a example.
So could other organizations do as well.





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g94EA7308694 for ietf-pkix-bks; Fri, 4 Oct 2002 07:10:07 -0700 (PDT)
Received: from ncsusraimge05.jnj.com (ncsusraimge05.jnj.com [148.177.2.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94EA6v08688 for <[e-mail]>; Fri, 4 Oct 2002 07:10:06 -0700 (PDT)
Received: from NCSUSRAWSC6.na.jnj.com (NCSUSRAWSC6.na.jnj.com [10.4.20.26]) by ncsusraimge05.jnj.com (Switch-2.2.3/Switch-2.2.3) with SMTP id g94E1qC22548 for <[e-mail]>; Fri, 4 Oct 2002 10:01:52 -0400 (EDT)
Received: FROM ncsusraexims2.rar.ncsus.jnj.com BY NCSUSRAWSC6.na.jnj.com ; Fri Oct 04 10:10:01 2002 -0400
Received: by ncsusraexims2.rar.ncsus.jnj.com with Internet Mail Service (5.5.2653.19) id <4CC00343>; Fri, 4 Oct 2002 10:10:01 -0400
Message-ID: <[e-mail]>
From: "Guida, Richard [JJCUS]" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, [e-mail]
Subject: RE: Employee Certificates - Security Issues
Date: Fri, 4 Oct 2002 10:09:53 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26BAE.3E1ACAE0"
Sender: [e-mail]
Precedence: 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_01C26BAE.3E1ACAE0
Content-Type: text/plain;
	charset="iso-8859-1"

Anders - forgive me but you have a simplistic and incorrect view of how
things really work.  A digital identity certificate proves (to whatever
degree the certificate policy underlying it affords) identity.  It does not
prove authority to take an action.  (I am omitting attribute certs from this
discussion.)  Today, we all face the same issue in an electronic world when
we use a password or PIN to prove who we are.  There is still that critical
authorization step which has to be gone through before an action consummates
(or before a "relying party" should accept the action) - i.e., is the person
authorized to take the action.  Substituting a digital signature for an
electronic signature made using a PIN or password (permitted between
companies under US law and, I believe, the European e-sig directive) is a
positive step, not a negative one.  So you should think of a company-issued
digital certificate as an electronic credential proving, in a more efficient
and profound way, who the named party in the cert is (and possibly what role
he/she occupies, such as quality control inspector).  That's all it does,
nothing more and nothing less.  And that makes it eminently more powerful
than the use of passwords/PINs which, as we all know, are system "shared
secrets" and thus oxymorons.  Not to say they won't be used for a long time
to come - but I certainly hope to free my children from the tyranny of
dozens of passwords and migrate them to the strength of a single digital
credential, a certificate, with the private key held on a hardware token and
unlocked using a passphrase known only by the token, not by a server
somewhere out of my control.  Best regards -- Rich



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: Anders Rundgren [mailto:[e-mail]]
Sent: Friday, October 04, 2002 1:25 AM
To: [e-mail]
Subject: Employee Certificates - Security Issues



"I, the Company"

When employees have been equipped with digital certificates,
linked to the organization, interesting things happen: Employees
can now sign on behalf of the organization.  Due to the absence of
a generally understood X509 "authority" system, you can probably
sign whatever you want and an external receiver is meant to believe
that you have the right to do it.  This is probably as far from an
organization-adapted solution one can get (as organizations want to
have control over their internal and external actions), and is an
indication that this scheme is not suitable for large-scale deployment.

As a countermeasure one could think of having an 
"authority control server" checking and logging all employee actions.
Unfortunately that does not work; if you have an employee certificate
you can fairly easy create messages that to receivers, look perfectly
valid without going trough the authority server.

Summary: An architecture that is fundamentally broken.
And, yes, I forgot to mention costs, privacy, archiving, and
the multitude of roots that you have to cope with.

Comments?

Anders Rundgren


------_=_NextPart_001_01C26BAE.3E1ACAE0
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: Employee Certificates - Security Issues</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Anders - forgive me but you have a simplistic and =
incorrect view of how things really work.&nbsp; A digital identity =
certificate proves (to whatever degree the certificate policy =
underlying it affords) identity.&nbsp; It does not prove authority to =
take an action.&nbsp; (I am omitting attribute certs from this =
discussion.)&nbsp; Today, we all face the same issue in an electronic =
world when we use a password or PIN to prove who we are.&nbsp; There is =
still that critical authorization step which has to be gone through =
before an action consummates (or before a &quot;relying party&quot; =
should accept the action) - i.e., is the person authorized to take the =
action.&nbsp; Substituting a digital signature for an electronic =
signature made using a PIN or password (permitted between companies =
under US law and, I believe, the European e-sig directive) is a =
positive step, not a negative one.&nbsp; So you should think of a =
company-issued digital certificate as an electronic credential proving, =
in a more efficient and profound way, who the named party in the cert =
is (and possibly what role he/she occupies, such as quality control =
inspector).&nbsp; That's all it does, nothing more and nothing =
less.&nbsp; And that makes it eminently more powerful than the use of =
passwords/PINs which, as we all know, are system &quot;shared =
secrets&quot; and thus oxymorons.&nbsp; Not to say they won't be used =
for a long time to come - but I certainly hope to free my children from =
the tyranny of dozens of passwords and migrate them to the strength of =
a single digital credential, a certificate, with the private key held =
on a hardware token and unlocked using a passphrase known only by the =
token, not by a server somewhere out of my control.&nbsp; Best regards =
-- Rich</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: Anders Rundgren [<A =
HREF=3D"mailto:[e-mail]">mailto:anders.rundgren@telia.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, October 04, 2002 1:25 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Employee Certificates - Security =
Issues</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&quot;I, the Company&quot;</FONT>
</P>

<P><FONT SIZE=3D2>When employees have been equipped with digital =
certificates,</FONT>
<BR><FONT SIZE=3D2>linked to the organization, interesting things =
happen: Employees</FONT>
<BR><FONT SIZE=3D2>can now sign on behalf of the organization.&nbsp; =
Due to the absence of</FONT>
<BR><FONT SIZE=3D2>a generally understood X509 &quot;authority&quot; =
system, you can probably</FONT>
<BR><FONT SIZE=3D2>sign whatever you want and an external receiver is =
meant to believe</FONT>
<BR><FONT SIZE=3D2>that you have the right to do it.&nbsp; This is =
probably as far from an</FONT>
<BR><FONT SIZE=3D2>organization-adapted solution one can get (as =
organizations want to</FONT>
<BR><FONT SIZE=3D2>have control over their internal and external =
actions), and is an</FONT>
<BR><FONT SIZE=3D2>indication that this scheme is not suitable for =
large-scale deployment.</FONT>
</P>

<P><FONT SIZE=3D2>As a countermeasure one could think of having an =
</FONT>
<BR><FONT SIZE=3D2>&quot;authority control server&quot; checking and =
logging all employee actions.</FONT>
<BR><FONT SIZE=3D2>Unfortunately that does not work; if you have an =
employee certificate</FONT>
<BR><FONT SIZE=3D2>you can fairly easy create messages that to =
receivers, look perfectly</FONT>
<BR><FONT SIZE=3D2>valid without going trough the authority =
server.</FONT>
</P>

<P><FONT SIZE=3D2>Summary: An architecture that is fundamentally =
broken.</FONT>
<BR><FONT SIZE=3D2>And, yes, I forgot to mention costs, privacy, =
archiving, and</FONT>
<BR><FONT SIZE=3D2>the multitude of roots that you have to cope =
with.</FONT>
</P>

<P><FONT SIZE=3D2>Comments?</FONT>
</P>

<P><FONT SIZE=3D2>Anders Rundgren</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C26BAE.3E1ACAE0--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g94Dbq608078 for ietf-pkix-bks; Fri, 4 Oct 2002 06:37:52 -0700 (PDT)
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 g94Dbpv08074 for <[e-mail]>; Fri, 4 Oct 2002 06:37:51 -0700 (PDT)
Subject: Re: Employee Certificates - Security Issues
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: Fri, 4 Oct 2002 07:31:45 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 10/04/2002 09:33:06 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>

there were (at least) 2-3 reason for relying-party-only certificates
(basically only an accont number and a public key .... and no other
information)

1) privacy .... even just a person's name (and no other information) is a
serious privacy concern for retail financial transactions .... EU directive
that electronic retail financial transactions sould be as anonomous as cash
.... any personal information in a certificate is major privacy issue.

2) liability .... your point ... that they wanted absolutely no
misunderstanding that the certificate would convey or imply anything ...
the certificate was purefly a convienient bit-string required for
conforming to COTS digital signature software (see #3)

3) most COTS easily available digital signature software required a
certificate to exist ... even tho the actual business process transactions
were online ... not offline ... so from a business and information flow ...
the existance of a certificate was redundant and superfulous ... purely an
artificial artifact of the COTS digital signature software that was easily
available.

insitutions doing online transactions between themselves and their member
entities (clients, account holders, employees, etc) will typically directly
refererence the actual trust repository .... a R/O, stale, subset copy of
such information is typically only useful for offline, low/no value
operaions (by definition, most value operations easily justify access to
near real time or aggregated data).

A simple example would be a supplier/customer relationship would be
embodied by an account record representing various things typically might
be found in contract T&Cs ... possibly limits, payment terms, negotiated
prices, volumes, etc.

Similar information might be for employees ... they could be given a
hardware token ... that for some no/low secure external doors .... operate
the unlocking of the door in offline mode (the existance of the token is
sufficient for unlocking low-security external door). Higher security
access is likely to migrate to things like online door access operation
that supports being able to fire & revoke access in real time.





[e-mail] on 10/3/2002 11.25 pm wrote


"I, the Company"

When employees have been equipped with digital certificates,
linked to the organization, interesting things happen: Employees
can now sign on behalf of the organization.  Due to the absence of
a generally understood X509 "authority" system, you can probably
sign whatever you want and an external receiver is meant to believe
that you have the right to do it.  This is probably as far from an
organization-adapted solution one can get (as organizations want to
have control over their internal and external actions), and is an
indication that this scheme is not suitable for large-scale deployment.

As a countermeasure one could think of having an
"authority control server" checking and logging all employee actions.
Unfortunately that does not work; if you have an employee certificate
you can fairly easy create messages that to receivers, look perfectly
valid without going trough the authority server.

Summary: An architecture that is fundamentally broken.
And, yes, I forgot to mention costs, privacy, archiving, and
the multitude of roots that you have to cope with.

Comments?

Anders Rundgren








Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g94D5mI05504 for ietf-pkix-bks; Fri, 4 Oct 2002 06:05:48 -0700 (PDT)
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 g94D5lv05499 for <[e-mail]>; Fri, 4 Oct 2002 06:05:47 -0700 (PDT)
Received: from arport ([62.119.75.13]) by blooper.utfors.se (8.12.6/8.12.6) with SMTP id g94D56tA002305; Fri, 4 Oct 2002 15:05:06 +0200 (MEST)
Message-ID: <01fd01c26ba5$b70529e0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Marc Poulaud" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Employee Certificates - Security Issues
Date: Fri, 4 Oct 2002 14:58:15 +0200
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>

Marc,

>Understand the business problem, then address the right technical solution.

I believe I just did :-)

Archiving and control of employees' activities is an integral part of _every_
business process worth mentioning.  By deploying solutions that do not
support these basics, PKI does only add costs but no real security or
trust for the employee organization.  And organizations, in the same way
as individuals, tend to care most about themselves.

>x.509 or the architecture ain't broken.

X509 is certainly not broken, it is the concept of employee-based PKIs
that is broken.  It is a merely direct copy from the paper-world, which
has proven to work pretty bad in many other cases.  Like it has for
credit-card numbers on the Internet.

cheers,
Anders




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g949MDR19724 for ietf-pkix-bks; Fri, 4 Oct 2002 02:22:13 -0700 (PDT)
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 g949MCv19720 for <[e-mail]>; Fri, 4 Oct 2002 02:22:12 -0700 (PDT)
Received: from arport ([62.119.75.13]) by blooper.utfors.se (8.12.6/8.12.6) with SMTP id g949M6tA022819; Fri, 4 Oct 2002 11:22:06 +0200 (MEST)
Message-ID: <008801c26b86$8cc47470$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Juergen Brauckmann" <[e-mail]>
Cc: <[e-mail]>
References: <006101c26b66$6a667150$0500a8c0@arport> <[e-mail]> <008001c26b70$a511c6b0$0500a8c0@arport> <[e-mail]> <002601c26b7a$a87b4bf0$0500a8c0@arport> <[e-mail]>
Subject: Re: Employee Certificates - Security Issues
Date: Fri, 4 Oct 2002 11:15:14 +0200
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>

Juergen,

><snip>
>> The keys needed for transferring money from one bank to another
>> [company keys], are _never_, _ever_ distributed to clients.
><snip>

>I don't see the relevance of your example to your initial statement that
>employee certificates are "fundamentally broken" [I hope that I did not
>misunderstand you here].

[company keys] is the key to the answer :-)
Employee certificate => company key => no control => "fundamentally broken" 

>Of course it is possible to create architectures that enhance the
>reliability and trustworthiness of electronic transactions. And of
>course there are scenarios where these architectures are needed. 

Why bother with PKI if you don't need reliability and trustworthiness?
Particularly if the context is external communication.

>And almost certainly these architectures will use (employee)
>certificates. 

No, the Internet-bank model does not require any "particular" client-
certificates, it is enough that you are recognized/accepted/trusted as
no traces of client certs ever leaves your bank.  You can use a "civil"
ID-card with no information about bank, employment etc.
A major Swedish bank is buying such from a TPP to take a example.
So could other organizations do as well.

>But a) there are enough cases where you don't have to spend much money
>on highly secure solutions because simpler solutions with other trust
>models work as well,

The Internet-bank model is a lot cheaper than deploying PKI over
an entire organization.  That's why it has been a great success
compared to employee-PKI.

> and b) what is the relation to certificates and public key infrastructures?

If we talk client-PKI it ranges from 0 to 100%.  Only the server is
100% PKI.  Organization (only)-PKI.  Web-Server PKI.

Anders





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g948gar15891 for ietf-pkix-bks; Fri, 4 Oct 2002 01:42:36 -0700 (PDT)
Received: from mystic2.trustcenter.de (mystic2.trustcenter.de [193.194.157.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g948gZv15883 for <[e-mail]>; Fri, 4 Oct 2002 01:42:35 -0700 (PDT)
Received: (from uucp@localhost) by mystic2.trustcenter.de (8.11.6+Sun/8.11.6) id g948oPg11050; Fri, 4 Oct 2002 10:50:25 +0200 (MEST)
Received: from venus.trustcenter.de(192.168.202.4) by mystic2.trustcenter.de via csmap (V6.0) id srcAAAHPaiLv; Fri, 4 Oct 02 10:50:24 +0200
Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id g948gjc13804; Fri, 4 Oct 2002 10:42:45 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Fri, 04 Oct 2002 10:42:27 +0200
From: Juergen Brauckmann <[e-mail]>
Organization: TC TrustCenter AG
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail]
Subject: Re: Employee Certificates - Security Issues
References: <006101c26b66$6a667150$0500a8c0@arport> <[e-mail]> <008001c26b70$a511c6b0$0500a8c0@arport> <[e-mail]> <002601c26b7a$a87b4bf0$0500a8c0@arport>
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>

Anders Rundgren wrote:
> The Internet-banks, used by 42 million people
> only in Europe, already have.  They let clients [employees]
> authenticate to bank-servers [company business systems] and
> transactions are created by the server only.  After doing various
> checks of the user, and performing archiving [carbon-copy].
> The keys needed for transferring money from one bank to another
> [company keys], are _never_, _ever_ distributed to clients.
>
> Are organization-based transactions, decisions, purchase orders,
> etc. really very different to banking?  In my opinion they are not.

I don't see the relevance of your example to your inital statement that
employee certificates are "fundamentally broken" [I hope that I did not
misunderstand you here].

Of course it is possible to create architectures that enhance the
reliability und trustworthiness of electronic transactions. And of
course there are scenarios where these architectures are needed. And
almost certainly these architectures will use (employee) certificates. 

But a) there are enough cases where you don't have to spend much money
on highly secure solutions because simpler solutions with other trust
models work as well, and b) what is the relation to certificates and
public key infrastructures?

Regards,
   Juergen


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9487vS10381 for ietf-pkix-bks; Fri, 4 Oct 2002 01:07:57 -0700 (PDT)
Received: from mta07-svc.ntlworld.com (mta07-svc.ntlworld.com [62.253.162.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9487uv10373 for <[e-mail]>; Fri, 4 Oct 2002 01:07:56 -0700 (PDT)
Received: from f67j40j ([80.5.45.65]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20021004080755.EXDH28004.mta07-svc.ntlworld.com@f67j40j> for <[e-mail]>; Fri, 4 Oct 2002 09:07:55 +0100
From: "Marc Poulaud" <[e-mail]>
To: <[e-mail]>
Subject: RE: Employee Certificates - Security Issues
Date: Fri, 4 Oct 2002 09:07:41 +0100
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)
In-Reply-To: <006101c26b66$6a667150$0500a8c0@arport>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

Umm. I always think back to the good old days of the real world and how
things get done on paper.

Simply put, a digital signature replaces the wet equivalent. It in no way
infers authority to any action i.e. it only says something about the
identity of the employee (in this example). Authority is something else.

I think it is also useful to consider the act of signing separately to the
act of due diligence on the part of the relying party. This will differ
based on the context in which the business is taking place, and consequently
the solution used to check this authority/entitlement/permission etc.

Importantly also, is the need to consider this as a set of layers. Solve the
identity piece at one, authorisation at the next. The business problem being
addressed will affect both (and all) layers. Therefore, I think your example
solution to this problem and this particular level may work in some business
scenarios (but not all :).

Also, the consideration of identity and authority of the Authoriser needs to
be considered. You wouldn't want to rely on my say-so, for example.

x.509 or the architecture ain't broken. Understand the business problem,
then address the right technical solution.

Marc.
-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Anders Rundgren
Sent: 04 October 2002 06:25
To: [e-mail]
Subject: Employee Certificates - Security Issues



"I, the Company"

When employees have been equipped with digital certificates,
linked to the organization, interesting things happen: Employees
can now sign on behalf of the organization.  Due to the absence of
a generally understood X509 "authority" system, you can probably
sign whatever you want and an external receiver is meant to believe
that you have the right to do it.  This is probably as far from an
organization-adapted solution one can get (as organizations want to
have control over their internal and external actions), and is an
indication that this scheme is not suitable for large-scale deployment.

As a countermeasure one could think of having an
"authority control server" checking and logging all employee actions.
Unfortunately that does not work; if you have an employee certificate
you can fairly easy create messages that to receivers, look perfectly
valid without going trough the authority server.

Summary: An architecture that is fundamentally broken.
And, yes, I forgot to mention costs, privacy, archiving, and
the multitude of roots that you have to cope with.

Comments?

Anders Rundgren




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g947v6E07604 for ietf-pkix-bks; Fri, 4 Oct 2002 00:57:06 -0700 (PDT)
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 g947v5v07597 for <[e-mail]>; Fri, 4 Oct 2002 00:57:05 -0700 (PDT)
Received: from arport ([62.119.75.13]) by blooper.utfors.se (8.12.6/8.12.6) with SMTP id g947uwtA018445; Fri, 4 Oct 2002 09:56:59 +0200 (MEST)
Message-ID: <002601c26b7a$a87b4bf0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Juergen Brauckmann" <[e-mail]>
Cc: <[e-mail]>
References: <006101c26b66$6a667150$0500a8c0@arport> <[e-mail]> <008001c26b70$a511c6b0$0500a8c0@arport> <[e-mail]>
Subject: Re: Employee Certificates - Security Issues
Date: Fri, 4 Oct 2002 09:49:40 +0200
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>

Juergen,

>> Obviously you believe that it is of fundamental value to transfer all
>> the weaknesses of the "paper-world" into the "e-world".

>Obvious answer: No, I don't believe that. But I also don't believe in
>constructing solutions that have no corresponding problem.

You don't have to.  The Internet-banks, used by 42 million people 
only in Europe, already have.  They let clients [employees]
authenticate to bank-servers [company business systems] and
transactions are created by the server only.  After doing various
checks of the user, and performing archiving [carbon-copy].
The keys needed for transferring money from one bank to another 
[company keys], are _never_, _ever_ distributed to clients.

Are organization-based transactions, decisions, purchase orders,
etc. really very different to banking?  In my opinion they are not.


Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9479qn00831 for ietf-pkix-bks; Fri, 4 Oct 2002 00:09:52 -0700 (PDT)
Received: from mystic2.trustcenter.de (mystic2.trustcenter.de [193.194.157.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9479pv00822 for <[e-mail]>; Fri, 4 Oct 2002 00:09:51 -0700 (PDT)
Received: (from uucp@localhost) by mystic2.trustcenter.de (8.11.6+Sun/8.11.6) id g947HfO10590; Fri, 4 Oct 2002 09:17:41 +0200 (MEST)
Received: from venus.trustcenter.de(192.168.202.4) by mystic2.trustcenter.de via csmap (V6.0) id srcAAAipaORu; Fri, 4 Oct 02 09:17:40 +0200
Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id g947A1c09870; Fri, 4 Oct 2002 09:10:01 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Fri, 04 Oct 2002 09:09:43 +0200
From: Juergen Brauckmann <[e-mail]>
Organization: TC TrustCenter AG
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail]
Subject: Re: Employee Certificates - Security Issues
References: <006101c26b66$6a667150$0500a8c0@arport> <[e-mail]> <008001c26b70$a511c6b0$0500a8c0@arport>
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>

Anders,

Anders Rundgren wrote:
> Obviously you believe that it is of fundamental value to transfer all
> the weaknesses of the "paper-world" into the "e-world".

Obvious answer: No, I don't believe that. But I also don't believe in
constructing solutions that have no corresponding problem.
 
You said:
> Summary: An architecture that is fundamentally broken.

This is simply not true, as the current situation in the e-world is not
worse than in the paper world. And paper world works.

Of course there is room for improvements, e.g. means of authorizing
transaction, but "fundamentally broken" is not the reality.

Regards,
   Juergen


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g946jKL26240 for ietf-pkix-bks; Thu, 3 Oct 2002 23:45:20 -0700 (PDT)
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 g946jIv26236 for <[e-mail]>; Thu, 3 Oct 2002 23:45:18 -0700 (PDT)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailc.telia.com (8.12.5/8.12.5) with SMTP id g946jH0b009440; Fri, 4 Oct 2002 08:45:17 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <008001c26b70$a511c6b0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Juergen Brauckmann" <[e-mail]>
Cc: <[e-mail]>
References: <006101c26b66$6a667150$0500a8c0@arport> <[e-mail]>
Subject: Re: Employee Certificates - Security Issues
Date: Fri, 4 Oct 2002 08:38:26 +0200
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>

Juergen,

Obviously you believe that it is of fundamental value to transfer all
the weaknesses of the "paper-world" into the "e-world".

I find this odd since the characteristics of the "e-world" are completely
different, e.g. you don't see or hear your partners.  And there are no
"carbon-copies" either.

Anders

----- Original Message ----- 
From: "Juergen Brauckmann" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, October 04, 2002 08:25
Subject: Re: Employee Certificates - Security Issues


Anders Rundgren wrote:
> 
> "I, the Company"
> 
> When employees have been equipped with digital certificates,
> linked to the organization, 

"When employees have been equipped with paper with the official letter
head of the organization..." 

> interesting things happen: Employees
> can now sign on behalf of the organization.  
[...]
> Summary: An architecture that is fundamentally broken.

Only if you see PKIs as something completely separate to how business is
done in the non-PKI-world. If you regard PKIs as an additional means of
supporting business, you will not have the fundamental problems you
describe. People can write letters that look like authorized papers from
their company today, and this is definitely not a big problem. Of course
you need some measures against unauthorized actions by employees, but
these don't have to be enforced by technical solutions.


Regards,
   Juergen



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g946Pp223229 for ietf-pkix-bks; Thu, 3 Oct 2002 23:25:51 -0700 (PDT)
Received: from mystic2.trustcenter.de (mystic2.trustcenter.de [193.194.157.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g946Pov23221 for <[e-mail]>; Thu, 3 Oct 2002 23:25:50 -0700 (PDT)
Received: (from uucp@localhost) by mystic2.trustcenter.de (8.11.6+Sun/8.11.6) id g946XdL10428; Fri, 4 Oct 2002 08:33:39 +0200 (MEST)
Received: from venus.trustcenter.de(192.168.202.4) by mystic2.trustcenter.de via csmap (V6.0) id srcAAAnxayxu; Fri, 4 Oct 02 08:33:39 +0200
Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id g946Pxc08393; Fri, 4 Oct 2002 08:26:00 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Fri, 04 Oct 2002 08:25:42 +0200
From: Juergen Brauckmann <[e-mail]>
Organization: TC TrustCenter AG
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail]
Subject: Re: Employee Certificates - Security Issues
References: <006101c26b66$6a667150$0500a8c0@arport>
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>

Anders Rundgren wrote:
> 
> "I, the Company"
> 
> When employees have been equipped with digital certificates,
> linked to the organization, 

"When employees have been equipped with paper with the official letter
head of the organization..." 

> interesting things happen: Employees
> can now sign on behalf of the organization.  
[...]
> Summary: An architecture that is fundamentally broken.

Only if you see PKIs as something completely separate to how business is
done in the non-PKI-world. If you regard PKIs as an additional means of
supporting business, you will not have the fundamental problems you
describe. People can write letters that look like authorized papers from
their company today, and this is definitely not a big problem. Of course
you need some measures against unauthorized actions by employees, but
these don't have to be enforced by technical solutions.


Regards,
   Juergen


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9462CQ17798 for ietf-pkix-bks; Thu, 3 Oct 2002 23:02:12 -0700 (PDT)
Received: from mystic2.trustcenter.de (mystic2.trustcenter.de [193.194.157.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9462Bv17787 for <[e-mail]>; Thu, 3 Oct 2002 23:02:11 -0700 (PDT)
Received: (from uucp@localhost) by mystic2.trustcenter.de (8.11.6+Sun/8.11.6) id g946A3G10334; Fri, 4 Oct 2002 08:10:03 +0200 (MEST)
Received: from venus.trustcenter.de(192.168.202.4) by mystic2.trustcenter.de via csmap (V6.0) id srcAAA4PaOlu; Fri, 4 Oct 02 08:10:03 +0200
Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id g9462Nc07567; Fri, 4 Oct 2002 08:02:23 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Fri, 04 Oct 2002 08:02:05 +0200
From: Juergen Brauckmann <[e-mail]>
Organization: TC TrustCenter AG
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: RFC3281 and tagging
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>

"Housley, Russ" wrote:
> 
> RFC 3281 is correct.  Many thanks to Rich Nicholas for performing a quick
> investigation.  Here are the details.
> 
> Juergen is referencing the wrong X.509 module.  The attribute certificate
> definitions are defined in the AttributeCertificateDefinitions module, not
> the AuthenticationFramework module.  The AttributeCertificateDefinitions
> module defined in X.509 (2000) uses IMPLICIT tagging, the same tagging used
> in the PKIXAttributeCertificate module defined in RFC 3281.

Thank you for your answer. OK, know I see what I was missing. 

I did not see that X.509v3 defines AttributeCertificates.v1 as being
part of the AuthenticationFramework module (with EXPLICIT tagging), but
X.509v4 has AttributeCertificates.v2 in a separate module with IMPLICIT
tagging.
 
Thanks again,
    Juergen

> 
> Russ
> 
> At 02:10 PM 10/2/2002 +0200, Juergen Brauckmann wrote:
> 
> >Hi.
> >
> >I see a tagging problem in RFC3281. I hope that I'm wrong; perhaps
> >someone can have a look at it?
> >
> >There are already some mails in the list archive regarding this issue
> >(<http://www.imc.org/ietf-pkix/mail-archive/msg02005.html>), but I still
> >don't understand it.
> >
> >
> >The ASN.1 module in Appendix B of RFC3281 has a module default of
> >"IMPLICIT":
> >===================================================
> >    PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
> >                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
> >                 id-mod-attribute-cert(12)}
> >
> >       DEFINITIONS IMPLICIT TAGS ::=
> >
> >       BEGIN
> >==================================================
> >
> >My copy of X.509v4 (I admit that I only have draft v7, so I apologise if
> >that is the source of my confusion) defines the ASN.1 module in Annex A
> >as:
> >=====================================================
> >AuthenticationFramework {joint-iso-itu-t ds(5) module(1)
> >authenticationFramework(7) 4}
> >DEFINITIONS ::=
> >BEGIN
> >======================================================
> >
> >Clause 12.2 of X.680 says: The "TagDefault" is taken as "EXPLICIT TAGS"
> >if it is "empty".
> >
> >So basically X.509 defines EXPLICIT tags as the module default and
> >RFC3281 defines IMPLICIT tags. This has some consequences, e.g. for
> >structures such as "Holder" inside Attribute certificates, which is
> >defined in AuthenticationFramework from ISO with EXPLICIT tags and in
> >PKIXAttributeCertificate with IMPLICIT tags.
> >
> >Where am I wrong?
> >
> >Regards,
> >    Juergen


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g945W2r16865 for ietf-pkix-bks; Thu, 3 Oct 2002 22:32:02 -0700 (PDT)
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 g945W0v16861 for <[e-mail]>; Thu, 3 Oct 2002 22:32:01 -0700 (PDT)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailc.telia.com (8.12.5/8.12.5) with SMTP id g945Vx0b025682 for <[e-mail]>; Fri, 4 Oct 2002 07:32:04 +0200 (CEST)
X-Original-Recipient: <[e-mail]>
Message-ID: <006101c26b66$6a667150$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Employee Certificates - Security Issues
Date: Fri, 4 Oct 2002 07:25:08 +0200
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>

"I, the Company"

When employees have been equipped with digital certificates,
linked to the organization, interesting things happen: Employees
can now sign on behalf of the organization.  Due to the absence of
a generally understood X509 "authority" system, you can probably
sign whatever you want and an external receiver is meant to believe
that you have the right to do it.  This is probably as far from an
organization-adapted solution one can get (as organizations want to
have control over their internal and external actions), and is an
indication that this scheme is not suitable for large-scale deployment.

As a countermeasure one could think of having an 
"authority control server" checking and logging all employee actions.
Unfortunately that does not work; if you have an employee certificate
you can fairly easy create messages that to receivers, look perfectly
valid without going trough the authority server.

Summary: An architecture that is fundamentally broken.
And, yes, I forgot to mention costs, privacy, archiving, and
the multitude of roots that you have to cope with.

Comments?

Anders Rundgren




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g940IA328374 for ietf-pkix-bks; Thu, 3 Oct 2002 17:18:10 -0700 (PDT)
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 g940I9v28368 for <[e-mail]>; Thu, 3 Oct 2002 17:18:09 -0700 (PDT)
Received: from Chokhani ([12.91.134.220]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20021004001800.MSKD12219.mtiwmhc12.worldnet.att.net@Chokhani>; Fri, 4 Oct 2002 00:18:00 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: Identifying the right CRL for a given certificate
Date: Thu, 3 Oct 2002 20:18:48 -0400
Message-ID: <006101c26b3b$9c4d4f70$0a00a8c0@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 V5.50.4910.0300
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>

Sarbari:

See my comments in-line in [].

-----Original Message-----
From: Sarbari Gupta [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2002 11:42 PM
To: Santosh Chokhani; [e-mail]
Subject: RE: Identifying the right CRL for a given certificate


Santosh,

I like the flavor of the new constraints on CRL validation that you have
specified.

You're also right about 2a and 2b. I should probably have expressed them
as:

	a) If the same Issuer entity signs both the certificate and the
CRL, then the Issuer Names of both have to match
	b) If different Issuers sign the certificate and CRL,
then the Issuer Name of the CRL has to match the cRLIssuer in the CDP
extension of the certificate.

[I agree]

However, the point I was trying to make was that in pairing up a
certificate and CRL, 6.3.3 specifies that only the Issuer Name matches
are of relevance (ignoring delta CRLs and partitioned CRLs).

I can think of a simple case where this may be a problem in the current
RFC 3280. Assume that the certificate CERT1 asserts the CDP extension
with no cRLIssuer and a single DP field which represents the address for
LDAP retrieval of the associated CRL. There happens to be a CRL CRL2 in
the Relying Party's local cache that has the same Issuer Name as CERT1;
however, CRL2 verifies under a different trust anchor than CERT1.
According to RFC 3280, CRL2 is acceptable for CERT1. Intuitively,
though, we know this is incorrect - there needs to be something more
than a simple name match and the ability to verify CRL2 to one of the
trust roots. The bottom line is that pairing up certificates and CRLs
based on issuer names without constraining them to be verifiable under
the same trust root, makes 6.3.3 rather weak.

[I agree.  That is why I have listed the three rules above]

AN ADDITIONAL POINT:
I also think the area of CRL usage and validation (with respect to a
given
certificate) needs to be less complex and more specific.

[I am not sure it can be made less complex]

For example, Section 6.3.3 item (2)(b)(i) states:

"If the distribution point name is present in the IDP CRL extension and
the distribution point is omitted from the DP (field of the CDP
extension in the
certificate) then verify that one of the names of the IDP matches one of
the names in the cRLIssuer field of the DP."

I don't understand the reason for this complication at all. If the DP
field is not present in the CDP extension in the certificate, why does
it make sense for the CRL IDP extension to have a distribution point
name, and why does this need to match the cRLIssuer field in the
certificate?

[RFC 3280 is correct in this regard.  Here are the answers to your
questions.  If you have a CRL that asserts a DP field in the IDP
extension, the relying party does not know whether it is a full CRL.
Thus, relying party must determine whether the CRL is relevant for the
certificate.  That is where CDP comes in.  Normally, DP in IDP should be
matched with DP in CDP.  But, in order not overload the certificate, if
CDP asserts cRLIssuer, that name is the DP by default unless a full name
or name relative to cRLIssuer is asserted.  Please look at the syntax of
the CDP extension carefully.  Thus, given that the IDP had DP and the
CDP does not, DP in IDP must match the cRLIssuer]

My suggestion would be to delete this portion of (2)(b)(i) altogether.
[That would be WRONG]

A related suggestion would be to require that is the certificate asserts
the DP field in the CDP extension, then the related CRL MUST assert the
distribution point field of the IDP extension and the two must match up
in order to be acceptable as a pair.

[Again, in the area of path processing, just because the certificate
asserts a DP, does not mean you can not use a full CRL, i.e., a CRL that
does not assert DP in IDP.  You should be able to either accept a full
CRL or a CRL whose IDP has the same DP.  I think that is what 3280 is
trying to say.  Thus, rejecting full CRL and only accepting an IDP CRL
in this case will be unnecessarily limiting.  I encourage you to review
Annex B in X.509 for CRL processing.  That may be a bit easier to follow
that 3280.  That Annex also provides some background material to make
the CRL processing more understandable.]

- Sarbari
==============================
Sarbari Gupta
Electrosoft Services, Inc.
Tel: [phone]
Cell:[phone]
FAX: [phone]
Email:  [e-mail]
Web: <http://www.electrosoft-inc.com> ==============================

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Wednesday, October 02, 2002 9:18 PM
To: [e-mail]; [e-mail]
Subject: RE: Identifying the right CRL for a given certificate


Sarbari:

Section 6.3.3 of 3280 does not imply anything regarding your assertions
2a and 2b.  It is not clear to me as to how you arrived at 2a and 2b. In
Section 6.3.3 of 3280, the operative item for the CRL signing key is
bullet f which states:

(f)  Obtain and validate the certification path for the complete CRL
   issuer.  If a key usage extension is present in the CRL issuer's

I agree that the RFC is missing guidance on CRL path building.  In my
mind a CRL path must be further constrained by the following rule:

1.  The trust must emanate from the same trust anchor as the
certification path for certificate for which the CRL is being sought.

2.  The DNs for the certification path for the certificate should match
the DNs for the certification path for the CRL (ignoring self-issued
certificates).  Of course, the last DN (namely the subscriber DN) will
be missing from the CRL certification path.

3.  The CRL certification path must be good for the same policy as the
subscriber.

I am not a CA product vendor and hence can not answer your other
questions.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Sarbari Gupta
Sent: Wednesday, October 02, 2002 4:30 PM
To: [e-mail]
Subject: Identifying the right CRL for a given certificate



I have been reviewing the RFC 3280 specs to understand how to identify
the correct CRL for a given certificate, and made the following
observations:

1) It appears to be possible to validate a certificate along a path that
leads to trust anchor TA1, while validating the CRL for that certificate
along a path that leads to trust anchor TA2. Intuitively, this seems
like a bad idea, however, I have not stumbled across anything in the RFC
that restricts Relying Parties from allowing this behavior.

2) Section 6.3.3 of the RFC seems to indicate that the primary means of
pairing up a certificate with the appropriate CRL are as follows:

	a) If the same key signs both the certificate and the CRL, then
the Issuer Names of both have to match
	b) If different keys are used to sign the certificate and CRL,
then the Issuer Name of the CRL has to match the cRLIssuer in the CDP
extension of the certificate

If this observation is coupled with observation (1) above, there seems
to be a possible security problem in matching on name fields when the
certificate and CRL emanate from different trust roots. This is
especially alarming since most of us have a large number of preloaded
trust roots in our systems, and it is possible that the same DN is used
within two different trust domains, either intentionally or
unintentionally.

3) Although it is acceptable that the same or different private keys are
used to sign certificates and CRLs for a given CA, there seems to be no
definition of conforming behavior for Relying Parties that says RPs
SHOULD be able to deal with both scenarios. The result is that certain
vendor's RPs only support one scenario or the other, leading to
non-interoperable implementations although both are in compliance with
the standard.

Am I missing something? I welcome comments.

Also, it would be very interesting to find out how the different vendors
have implemented the functionality to pair up certificates with the
correct CRLs.

==============================
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 g9404cc27700 for ietf-pkix-bks; Thu, 3 Oct 2002 17:04:38 -0700 (PDT)
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9404av27695 for <[e-mail]>; Thu, 3 Oct 2002 17:04:36 -0700 (PDT)
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9404XhG203246; Thu, 3 Oct 2002 20:04:33 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9404UQo150650; Thu, 3 Oct 2002 20:04:30 -0400
Importance: Normal
Sensitivity: 
Subject: Re: Identifying the right CRL for a given certificate
To: <[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, 3 Oct 2002 20:04:26 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11  |July 29, 2002) at 10/03/2002 08:04:31 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>

      Sarbari:

      I have tried to produce a fairly thorough analysis of your problem
#1.  First, the certificate which signs a CRL is most often either the CA
certificate (the original one which signed the EE or a later generation one
signed by that original) or a CRL certificate issued by that same CA.  In
either of these cases, a trust path for the CRL signer could be constructed
so as to lead to the same trust anchor as was used for the EE certificate.
They might lead to different anchors, however, because of the indeterminacy
of tracing a path backward to a trust anchor.  In the simplest case,
suppose that the issuer of an EE certificate also used a CRL signing
certificate which it had issued and had received cross-certificates from 3
different CA's, C1, C2, and C3.  A user who trusted both C1 and C3 could
easily construct paths alternately between the two of them.  While the EE
certificate would be verified against a different anchor than the CRL, it
could equally easily be verified against different anchors on two
successive verifications, which is no less strange a result.  Thus, I would
not consider this case to be a problem.
      It would also be possible, to take a relatively reasonable case, for
a hierarchical subordinate CA to get a CRL signing certificate issued
directly by its hierarchical parent and for the subordinate to be directly
cross-certified by C1 as above while the parent is cross-certified by C3.
In this case, the shortest certification path for the EE certificate is
EE-CA-C1, while the shortest one for the CRL is CRL-H-C3.  The EE can, in
this case, have a path EE-CA-H-C3 as well, but the CRL has no path leading
back to C1.  Again, this is a legitimate situation.
      For an EE certificate and a CRL certificate to be validatable using
separate trust anchors but not to be validatable with any shared trust
anchor, one of two basic conditions seems to be necessary: either the CRL
certificate was issued by an authority which does not trust the issuer
whose certificates the CRL governs, or one of the two certificates violates
a constraint levied by an issuer which must be used in verifying the other
one.  The first of these conditions would seem likeliest to happen if a CRL
signing key was stolen and its certificate reused by a rogue CA, but such a
CA could avoid such difficulties by issuing his own certificate for the CRL
signer.  The second of them is probably more of an issue, since it would
most often occur through the issuance of EE certificates violating a name
or policy constraint placed by the hierarchical parent of the CA issuing
them.  In the sample above, H might place a name constraint on CA which
EE's certificate violates, while C1 would either place no name constraint
or a more permissive one on CA.
      I don't see what would be done about it, however.  Do you think we
should require in RFC 3280 6.3.3 step f that if CRL validation is being
invoked in the context of a certificate validation, the CRL's certification
path may not contain any CA certificates other than those in the base
certificate validation?  If we did that, validation using OCSP could give a
different result than using CRL's even if the OCSP server was being fed by
the same set of CRL's.

            Tom Gindin


"Sarbari Gupta" <[e-mail]>@mail.imc.org on 10/02/2002
04:30:24 PM

Please respond to <[e-mail]>

Sent by:    [e-mail]


To:    <[e-mail]>
cc:
Subject:    Identifying the right CRL for a given certificate



I have been reviewing the RFC 3280 specs to understand how to identify the
correct CRL for a given certificate, and made the following observations:

1) It appears to be possible to validate a certificate along a path that
leads to trust anchor TA1, while validating the CRL for that certificate
along a path that leads to trust anchor TA2. Intuitively, this seems like a
bad idea, however, I have not stumbled across anything in the RFC that
restricts Relying Parties from allowing this behavior.

2) Section 6.3.3 of the RFC seems to indicate that the primary means of
pairing up a certificate with the appropriate CRL are as follows:

             a) If the same key signs both the certificate and the CRL,
then the Issuer
Names of both have to match
             b) If different keys are used to sign the certificate and CRL,
then the
Issuer Name of the CRL has to match the cRLIssuer in the CDP extension of
the certificate

If this observation is coupled with observation (1) above, there seems to
be
a possible security problem in matching on name fields when the certificate
and CRL emanate from different trust roots. This is especially alarming
since most of us have a large number of preloaded trust roots in our
systems, and it is possible that the same DN is used within two different
trust domains, either intentionally or unintentionally.

3) Although it is acceptable that the same or different private keys are
used to sign certificates and CRLs for a given CA, there seems to be no
definition of conforming behavior for Relying Parties that says RPs SHOULD
be able to deal with both scenarios. The result is that certain vendor's
RPs
only support one scenario or the other, leading to non-interoperable
implementations although both are in compliance with the standard.

Am I missing something? I welcome comments.

Also, it would be very interesting to find out how the different vendors
have implemented the functionality to pair up certificates with the correct
CRLs.

==============================
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 g93NkXS27364 for ietf-pkix-bks; Thu, 3 Oct 2002 16:46:33 -0700 (PDT)
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 g93NkVv27354 for <[e-mail]>; Thu, 3 Oct 2002 16:46:31 -0700 (PDT)
Subject: Re: I-D ACTION:draft-ietf-pkix-usergroup-01.txt
To: Michael StJohns <[e-mail]>
Cc: [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: Thu, 3 Oct 2002 17:46:11 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 10/03/2002 07:41:49 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>

The bit strings are essentially r/o (typically stale and significant
subset) of trust information in some sort of trust repository.These trust
bit strings were originally designed for use in offline environments where
there was something inhibiting the access to the actual trust repository.
They can currently be useful in environments where it isn't worthwhile to
know the actual timely &/or aggregated information ... for instance you
don't need to know things like whether your online account is active, your
have sufficient funds in your account and/or you have exceeded your credit
limit (aka useful for low or no value operations).

the scenario is somewhat similar to the credit card industry of the '60s
that was non-electronic and offline. In the '70s, the online economics was
sufficient that it allowed a direct transition to electonic and online
(with some residual non-electonic/offline lingering on). The certificate
actrivity of the '80s was essentially a paradigm step backwards in time ...
to the '60s ... but with a offline electronic ... rather than a offline
non-electronic.

special purpose types of certificate are in effect the same or very similar
to the "relying-party-only" certificates that various financial (and other)
institutions were making use of by at least the mid-90s.  However, it is
trivial to show that for any kind of value, online operation the
relying-party-only certificates are redundant and superfulous (again
leaving just the domain of offline, low/no value operations).

misc. past r-p-o certificates references:
http://www.garlic.com/~lynn/subtopic.html#rpo

and of course ... the misc postings on end-game of why eventually TTPs
would even be issuing server domain name certificates
http://www.garlic.com/~lynn/subtopic.html#sslcerts



michael stjohns <[e-mail]> on 10/3/2002 3:44 pm wrote:


A 100% outsourced PKI should also be able to generate certificates which
use Subject and IssuerAltName extensions for at least the specified name
forms (e.g. RFC822 and DNS).  This is just another plugin, and if it gets
into the normal PKI specification, a 100% outsourced PKI should be able to
issue this type of certificate.  Its not a reasonable argument to make that

because it wasn't specified before no one will implement or use it.  If it
doesn't have sufficient functionality, or breaks something  - that's the
argument I'd actually like to hear.

Also, certificates are just bit strings - I don't need or want to use the
same certificate over and over again to access different resources.  That
requires way too much centralization.  Let me give you an example:  Should
the same certificate I use to access local company resources be the same
one I use to make purchases on the internet which get charged to my Visa
card?  I hope not.  Let's look at the trust relationships.  In the former,
I need a trust relationship with my local sysadmin who also has a trust
relationship with the local resources.  By virtue of his/her position he
can establish a transitive trust relationship between me and the resources
by issuing me a certificate.  In the Visa case, I have a relationship with
Visa as does the merchant (the transaction Acceptor).  We both have
credentials issued to us by Visa which allow us to participate in a
commercial exchange under Visa's rules.  The acceptor doesn't need to know
who I am, it just needs to know that Visa accepts me (or rather the holder
of the certificates private key) as someone who has a trust relationship
with Visa for the purpose of commercial exchanges of a particular type.  I
don't need a global identity for that set of transactions. And indeed, a
global identity has all sorts of privacy issues.

I guess what I'm saying is that I'm not sure why paying Verisign to issue
client certificates makes a lot of sense.





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g93LjJl22697 for ietf-pkix-bks; Thu, 3 Oct 2002 14:45:19 -0700 (PDT)
Received: from sentry.gw.tislabs.com ([e-mail] [192.94.214.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g93LjHv22693 for <[e-mail]>; Thu, 3 Oct 2002 14:45:17 -0700 (PDT)
Received: by sentry.gw.tislabs.com; id RAA05787; Thu, 3 Oct 2002 17:45:11 -0400 (EDT)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma005764; Thu, 3 Oct 02 21:45:04 GMT
Received: from STJOHNS-LAPTOP.tislabs.com (dyn083.gw.tislabs.com [10.33.10.83]) by raven.gw.tislabs.com (8.11.6/8.11.6) with ESMTP id g93LjBo27956; Thu, 3 Oct 2002 17:45:11 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 03 Oct 2002 17:44:04 -0400
To: [e-mail]
From: Michael StJohns <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-usergroup-01.txt
Cc: [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>

[e-mail] wrote:
>This is indeed an interesting topic...
>
>Essentially there are two ways to make certificates more adapted
>to their working environment:
>
>1. Clobber certificates with more "stuff" to as the draft suggests

Actually, its not "more" stuff, its different stuff.  X509 certificates use 
a name form (RDN) designed to work with the mostly defunct X500 directory 
service protocols.  Except for certificates and some well hidden names 
within things like LDAP, no one uses RDN to represent names.

[ Sidebar - I just did a google search and I couldn't find anything more 
recent than '99 that talked about using or developing X500 technology - 
except for what was already there for LDAP]

My comment related to the above - why are we still pushing these .. 
obsolete? .. names, especially given  that we never had full consensus on 
their structure, content and specific relationship to things like DNS 
names?  The subjectAltName extension was created specifically because the 
X500 name was neither expressive enough, nor closely enough related to how 
things were actually named.


>2. Use a mapping facility that maps a certificate into whatever
>     is needed by the working environment
>
>A major advantage with mapping is that you can use TTP-issued
>certificates (a.k.a. 100% outsourced PKI), and that the very same
>certificates can be used by multiple relying parties in many different
>environments.

A 100% outsourced PKI should also be able to generate certificates which 
use Subject and IssuerAltName extensions for at least the specified name 
forms (e.g. RFC822 and DNS).  This is just another plugin, and if it gets 
into the normal PKI specification, a 100% outsourced PKI should be able to 
issue this type of certificate.  Its not a reasonable argument to make that 
because it wasn't specified before no one will implement or use it.  If it 
doesn't have sufficient functionality, or breaks something  - that's the 
argument I'd actually like to hear.

Also, certificates are just bit strings - I don't need or want to use the 
same certificate over and over again to access different resources.  That 
requires way too much centralization.  Let me give you an example:  Should 
the same certificate I use to access local company resources be the same 
one I use to make purchases on the internet which get charged to my Visa 
card?  I hope not.  Let's look at the trust relationships.  In the former, 
I need a trust relationship with my local sysadmin who also has a trust 
relationship with the local resources.  By virtue of his/her position he 
can establish a transitive trust relationship between me and the resources 
by issuing me a certificate.  In the Visa case, I have a relationship with 
Visa as does the merchant (the transaction Acceptor).  We both have 
credentials issued to us by Visa which allow us to participate in a 
commercial exchange under Visa's rules.  The acceptor doesn't need to know 
who I am, it just needs to know that Visa accepts me (or rather the holder 
of the certificates private key) as someone who has a trust relationship 
with Visa for the purpose of commercial exchanges of a particular type.  I 
don't need a global identity for that set of transactions. And indeed, a 
global identity has all sorts of privacy issues.

I guess what I'm saying is that I'm not sure why paying Verisign to issue 
client certificates makes a lot of sense.

>A major disadvantage with mapping is that Microsoft and probably
>most others as well, do not yet support this fundamental capability
>except to a very limited extent.  Contributing to that, is the fact that
>current PKI-standards do not offer the kind of manageble mapping
>support needed for efficient usage of TTP-issued certificates.


In 15 years, this manageable mapping capability has yet to come into 
existence. Why would you think that there's any reason it ever will?  It 
also requires far more infrastructure in the form of lookup capabilities 
(e.g. directory, directory protocol, administrative interface, client 
lookup interface, mapping trust interface) than simply encoding the userid 
(e.g. a handle into an ACL) into the certificate.


>If Microsoft and others are to upgrade their PKI support
>(which both solutions require), I really hope that they settle
>for a mapping solution.
>
>cheers,
>Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g933frq03540 for ietf-pkix-bks; Wed, 2 Oct 2002 20:41:53 -0700 (PDT)
Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g933fqv03532 for <[e-mail]>; Wed, 2 Oct 2002 20:41:52 -0700 (PDT)
Received: from sgupta (68.100.200.151) by mail.san.yahoo.com (6.5.029) id 3D9AD21E000683CD; Wed, 2 Oct 2002 20:40:13 -0700
Reply-To: <[e-mail]>
From: "Sarbari Gupta" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
Subject: RE: Identifying the right CRL for a given certificate
Date: Wed, 2 Oct 2002 23:42:03 -0400
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.4807.1700
Importance: Normal
In-Reply-To: <002f01c26a7a$afd2b010$0a00a8c0@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 like the flavor of the new constraints on CRL validation that you have
specified.

You're also right about 2a and 2b. I should probably have expressed them as:

	a) If the same Issuer entity signs both the certificate and the CRL, then
the Issuer Names of both have to match
	b) If different Issuers sign the certificate and CRL,
then the Issuer Name of the CRL has to match the cRLIssuer in the CDP
extension of the certificate

However, the point I was trying to make was that in pairing up a certificate
and CRL, 6.3.3 specifies that only the Issuer Name matches are of relevance
(ignoring delta CRLs and partitioned CRLs).

I can think of a simple case where this may be a problem in the current RFC
3280. Assume that the certificate CERT1 asserts the CDP extension with no
cRLIssuer and a single DP field which represents the address for LDAP
retrieval of the associated CRL. There happens to be a CRL CRL2 in the
Relying Party's local cache that has the same Issuer Name as CERT1; however,
CRL2 verifies under a different trust anchor than CERT1. According to RFC
3280, CRL2 is acceptable for CERT1. Intuitively, though, we know this is
incorrect - there needs to be something more than a simple name match and
the ability to verify CRL2 to one of the trust roots. The bottom line is
that pairing up certificates and CRLs based on issuer names without
constraining them to be verifiable under the same trust root, makes 6.3.3
rather weak.

AN ADDITIONAL POINT:
I also think the area of CRL usage and validation (with respect to a given
certificate) needs to be less complex and more specific. For example,
Section 6.3.3 item (2)(b)(i) states:

"If the distribution point name is present in the IDP CRL extension and the
distribution point is omitted from the DP (field of the CDP extension in the
certificate) then verify that one of the names of the IDP matches one of the
names in the cRLIssuer field of the DP."

I don't understand the reason for this complication at all. If the DP field
is not present in the CDP extension in the certificate, why does it make
sense for the CRL IDP extension to have a distribution point name, and why
does this need to match the cRLIssuer field in the certificate?

My suggestion would be to delete this portion of (2)(b)(i) altogether. A
related suggestion would be to require that is the certificate asserts the
DP field in the CDP extension, then the related CRL MUST assert the
distribution point field of the IDP extension and the two must match up in
order to be acceptable as a pair.

- Sarbari
==============================
Sarbari Gupta
Electrosoft Services, Inc.
Tel: [phone]
Cell:[phone]
FAX: [phone]
Email:  [e-mail]
Web: <http://www.electrosoft-inc.com>
==============================

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Wednesday, October 02, 2002 9:18 PM
To: [e-mail]; [e-mail]
Subject: RE: Identifying the right CRL for a given certificate


Sarbari:

Section 6.3.3 of 3280 does not imply anything regarding your assertions
2a and 2b.  It is not clear to me as to how you arrived at 2a and 2b.
In Section 6.3.3 of 3280, the operative item for the CRL signing key is
bullet f which states:

(f)  Obtain and validate the certification path for the complete CRL
   issuer.  If a key usage extension is present in the CRL issuer's

I agree that the RFC is missing guidance on CRL path building.  In my
mind a CRL path must be further constrained by the following rule:

1.  The trust must emanate from the same trust anchor as the
certification path for certificate for which the CRL is being sought.

2.  The DNs for the certification path for the certificate should match
the DNs for the certification path for the CRL (ignoring self-issued
certificates).  Of course, the last DN (namely the subscriber DN) will
be missing from the CRL certification path.

3.  The CRL certification path must be good for the same policy as the
subscriber.

I am not a CA product vendor and hence can not answer your other
questions.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Sarbari Gupta
Sent: Wednesday, October 02, 2002 4:30 PM
To: [e-mail]
Subject: Identifying the right CRL for a given certificate



I have been reviewing the RFC 3280 specs to understand how to identify
the correct CRL for a given certificate, and made the following
observations:

1) It appears to be possible to validate a certificate along a path that
leads to trust anchor TA1, while validating the CRL for that certificate
along a path that leads to trust anchor TA2. Intuitively, this seems
like a bad idea, however, I have not stumbled across anything in the RFC
that restricts Relying Parties from allowing this behavior.

2) Section 6.3.3 of the RFC seems to indicate that the primary means of
pairing up a certificate with the appropriate CRL are as follows:

	a) If the same key signs both the certificate and the CRL, then
the Issuer Names of both have to match
	b) If different keys are used to sign the certificate and CRL,
then the Issuer Name of the CRL has to match the cRLIssuer in the CDP
extension of the certificate

If this observation is coupled with observation (1) above, there seems
to be a possible security problem in matching on name fields when the
certificate and CRL emanate from different trust roots. This is
especially alarming since most of us have a large number of preloaded
trust roots in our systems, and it is possible that the same DN is used
within two different trust domains, either intentionally or
unintentionally.

3) Although it is acceptable that the same or different private keys are
used to sign certificates and CRLs for a given CA, there seems to be no
definition of conforming behavior for Relying Parties that says RPs
SHOULD be able to deal with both scenarios. The result is that certain
vendor's RPs only support one scenario or the other, leading to
non-interoperable implementations although both are in compliance with
the standard.

Am I missing something? I welcome comments.

Also, it would be very interesting to find out how the different vendors
have implemented the functionality to pair up certificates with the
correct CRLs.

==============================
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 g931H9H25426 for ietf-pkix-bks; Wed, 2 Oct 2002 18:17:09 -0700 (PDT)
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 g931H8v25422 for <[e-mail]>; Wed, 2 Oct 2002 18:17:08 -0700 (PDT)
Received: from Chokhani ([12.92.115.96]) by mtiwmhc13.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20021003011705.DEFX8940.mtiwmhc13.worldnet.att.net@Chokhani>; Thu, 3 Oct 2002 01:17:06 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: Identifying the right CRL for a given certificate
Date: Wed, 2 Oct 2002 21:17:47 -0400
Message-ID: <002f01c26a7a$afd2b010$0a00a8c0@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
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sarbari:

Section 6.3.3 of 3280 does not imply anything regarding your assertions
2a and 2b.  It is not clear to me as to how you arrived at 2a and 2b.
In Section 6.3.3 of 3280, the operative item for the CRL signing key is
bullet f which states:

(f)  Obtain and validate the certification path for the complete CRL
   issuer.  If a key usage extension is present in the CRL issuer's

I agree that the RFC is missing guidance on CRL path building.  In my
mind a CRL path must be further constrained by the following rule:

1.  The trust must emanate from the same trust anchor as the
certification path for certificate for which the CRL is being sought.

2.  The DNs for the certification path for the certificate should match
the DNs for the certification path for the CRL (ignoring self-issued
certificates).  Of course, the last DN (namely the subscriber DN) will
be missing from the CRL certification path.

3.  The CRL certification path must be good for the same policy as the
subscriber.

I am not a CA product vendor and hence can not answer your other
questions.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Sarbari Gupta
Sent: Wednesday, October 02, 2002 4:30 PM
To: [e-mail]
Subject: Identifying the right CRL for a given certificate



I have been reviewing the RFC 3280 specs to understand how to identify
the correct CRL for a given certificate, and made the following
observations:

1) It appears to be possible to validate a certificate along a path that
leads to trust anchor TA1, while validating the CRL for that certificate
along a path that leads to trust anchor TA2. Intuitively, this seems
like a bad idea, however, I have not stumbled across anything in the RFC
that restricts Relying Parties from allowing this behavior.

2) Section 6.3.3 of the RFC seems to indicate that the primary means of
pairing up a certificate with the appropriate CRL are as follows:

	a) If the same key signs both the certificate and the CRL, then
the Issuer Names of both have to match
	b) If different keys are used to sign the certificate and CRL,
then the Issuer Name of the CRL has to match the cRLIssuer in the CDP
extension of the certificate

If this observation is coupled with observation (1) above, there seems
to be a possible security problem in matching on name fields when the
certificate and CRL emanate from different trust roots. This is
especially alarming since most of us have a large number of preloaded
trust roots in our systems, and it is possible that the same DN is used
within two different trust domains, either intentionally or
unintentionally.

3) Although it is acceptable that the same or different private keys are
used to sign certificates and CRLs for a given CA, there seems to be no
definition of conforming behavior for Relying Parties that says RPs
SHOULD be able to deal with both scenarios. The result is that certain
vendor's RPs only support one scenario or the other, leading to
non-interoperable implementations although both are in compliance with
the standard.

Am I missing something? I welcome comments.

Also, it would be very interesting to find out how the different vendors
have implemented the functionality to pair up certificates with the
correct CRLs.

==============================
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 g92MxYG19222 for ietf-pkix-bks; Wed, 2 Oct 2002 15:59:34 -0700 (PDT)
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 g92MxVv19218 for <[e-mail]>; Wed, 2 Oct 2002 15:59:31 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 Oct 2002 22:59:35 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 SAA01449 for <[e-mail]>; Wed, 2 Oct 2002 18:59:34 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g92Mv5b21265 for <[e-mail]>; Wed, 2 Oct 2002 18:57:05 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPV6Q6R>; Wed, 2 Oct 2002 18:59:32 -0400
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 3TPV6Q6Q; Wed, 2 Oct 2002 18:59:28 -0400
From: "Housley, Russ" <[e-mail]>
To: Juergen Brauckmann <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 02 Oct 2002 18:59:18 -0400
Subject: Re: RFC3281 and tagging
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>

RFC 3281 is correct.  Many thanks to Rich Nicholas for performing a quick 
investigation.  Here are the details.

Juergen is referencing the wrong X.509 module.  The attribute certificate 
definitions are defined in the AttributeCertificateDefinitions module, not 
the AuthenticationFramework module.  The AttributeCertificateDefinitions 
module defined in X.509 (2000) uses IMPLICIT tagging, the same tagging used 
in the PKIXAttributeCertificate module defined in RFC 3281.

Russ

At 02:10 PM 10/2/2002 +0200, Juergen Brauckmann wrote:

>Hi.
>
>I see a tagging problem in RFC3281. I hope that I'm wrong; perhaps
>someone can have a look at it?
>
>There are already some mails in the list archive regarding this issue
>(<http://www.imc.org/ietf-pkix/mail-archive/msg02005.html>), but I still
>don't understand it.
>
>
>The ASN.1 module in Appendix B of RFC3281 has a module default of
>"IMPLICIT":
>===================================================
>    PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
>                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
>                 id-mod-attribute-cert(12)}
>
>       DEFINITIONS IMPLICIT TAGS ::=
>
>       BEGIN
>==================================================
>
>My copy of X.509v4 (I admit that I only have draft v7, so I apologise if
>that is the source of my confusion) defines the ASN.1 module in Annex A
>as:
>=====================================================
>AuthenticationFramework {joint-iso-itu-t ds(5) module(1)
>authenticationFramework(7) 4}
>DEFINITIONS ::=
>BEGIN
>======================================================
>
>Clause 12.2 of X.680 says: The "TagDefault" is taken as "EXPLICIT TAGS"
>if it is "empty".
>
>So basically X.509 defines EXPLICIT tags as the module default and
>RFC3281 defines IMPLICIT tags. This has some consequences, e.g. for
>structures such as "Holder" inside Attribute certificates, which is
>defined in AuthenticationFramework from ISO with EXPLICIT tags and in
>PKIXAttributeCertificate with IMPLICIT tags.
>
>Where am I wrong?
>
>Regards,
>    Juergen


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g92KUPk13374 for ietf-pkix-bks; Wed, 2 Oct 2002 13:30:25 -0700 (PDT)
Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g92KUOv13370 for <[e-mail]>; Wed, 2 Oct 2002 13:30:24 -0700 (PDT)
Received: from sgupta (68.100.200.151) by mail.san.yahoo.com (6.5.029) id 3D9AD21E0003FBDD for [e-mail]; Wed, 2 Oct 2002 13:28:33 -0700
Reply-To: <[e-mail]>
From: "Sarbari Gupta" <[e-mail]>
To: <[e-mail]>
Subject: Identifying the right CRL for a given certificate
Date: Wed, 2 Oct 2002 16:30:24 -0400
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 have been reviewing the RFC 3280 specs to understand how to identify the
correct CRL for a given certificate, and made the following observations:

1) It appears to be possible to validate a certificate along a path that
leads to trust anchor TA1, while validating the CRL for that certificate
along a path that leads to trust anchor TA2. Intuitively, this seems like a
bad idea, however, I have not stumbled across anything in the RFC that
restricts Relying Parties from allowing this behavior.

2) Section 6.3.3 of the RFC seems to indicate that the primary means of
pairing up a certificate with the appropriate CRL are as follows:

	a) If the same key signs both the certificate and the CRL, then the Issuer
Names of both have to match
	b) If different keys are used to sign the certificate and CRL, then the
Issuer Name of the CRL has to match the cRLIssuer in the CDP extension of
the certificate

If this observation is coupled with observation (1) above, there seems to be
a possible security problem in matching on name fields when the certificate
and CRL emanate from different trust roots. This is especially alarming
since most of us have a large number of preloaded trust roots in our
systems, and it is possible that the same DN is used within two different
trust domains, either intentionally or unintentionally.

3) Although it is acceptable that the same or different private keys are
used to sign certificates and CRLs for a given CA, there seems to be no
definition of conforming behavior for Relying Parties that says RPs SHOULD
be able to deal with both scenarios. The result is that certain vendor's RPs
only support one scenario or the other, leading to non-interoperable
implementations although both are in compliance with the standard.

Am I missing something? I welcome comments.

Also, it would be very interesting to find out how the different vendors
have implemented the functionality to pair up certificates with the correct
CRLs.

==============================
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 g92EOcj23496 for ietf-pkix-bks; Wed, 2 Oct 2002 07:24:38 -0700 (PDT)
Received: from mystic2.trustcenter.de (mystic2.trustcenter.de [193.194.157.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g92EOav23492 for <[e-mail]>; Wed, 2 Oct 2002 07:24:37 -0700 (PDT)
Received: (from uucp@localhost) by mystic2.trustcenter.de (8.11.6+Sun/8.11.6) id g92EWS329749; Wed, 2 Oct 2002 16:32:28 +0200 (MEST)
Received: from venus.trustcenter.de(192.168.202.4) by mystic2.trustcenter.de via csmap (V6.0) id srcAAAvYaGg6; Wed, 2 Oct 02 16:32:28 +0200
Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id g92EOlc17689; Wed, 2 Oct 2002 16:24:47 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Wed, 02 Oct 2002 16:24:30 +0200
From: Juergen Brauckmann <[e-mail]>
Organization: TC TrustCenter AG
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: DUBUISSON Olivier <[e-mail]>
CC: [e-mail]
Subject: Re: RFC3281 and tagging
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>

DUBUISSON Olivier wrote:
> I can only see a drawback (not a problem) in case the code is
> handcrafted (because you cannot reuse code).
> When you use an ASN.1 compiler, you don't have to worry, for the
> encoder/decoder are generated according to each ASN.1 module whether it
> includes an IMPLICIT or EXPLICIT tagging mode.

Yes. I was not talking about code, just about the specification. And if
the specifications do not match, so will the code that the compiler
generates.

Regards,
   Juergen


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g92EK0M23397 for ietf-pkix-bks; Wed, 2 Oct 2002 07:20:00 -0700 (PDT)
Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g92EJwv23392 for <[e-mail]>; Wed, 2 Oct 2002 07:19:58 -0700 (PDT)
Received: from francetelecom.com ([10.193.13.119]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 2 Oct 2002 16:18:58 +0200
Message-ID: <[e-mail]>
Date: Wed, 02 Oct 2002 16:18:58 +0200
From: DUBUISSON Olivier <[e-mail]>
Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Juergen Brauckmann <[e-mail]>
CC: [e-mail]
Subject: Re: RFC3281 and tagging
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Oct 2002 14:18:58.0617 (UTC) FILETIME=[A5FCDA90:01C26A1E]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Juergen Brauckmann wrote:
> 
> Hi.
> 
> I see a tagging problem in RFC3281. I hope that I'm wrong; perhaps
> someone can have a look at it?
> 
> There are already some mails in the list archive regarding this issue
> (<http://www.imc.org/ietf-pkix/mail-archive/msg02005.html>), but I still
> don't understand it.
> 
> The ASN.1 module in Appendix B of RFC3281 has a module default of
> "IMPLICIT":
> ===================================================
>    PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
>                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
>                 id-mod-attribute-cert(12)}
> 
>       DEFINITIONS IMPLICIT TAGS ::=
> 
>       BEGIN
> ==================================================
> 
> My copy of X.509v4 (I admit that I only have draft v7, so I apologise if
> that is the source of my confusion) defines the ASN.1 module in Annex A
> as:
> =====================================================
> AuthenticationFramework {joint-iso-itu-t ds(5) module(1)
> authenticationFramework(7) 4}
> DEFINITIONS ::=
> BEGIN
> ======================================================
> 
> Clause 12.2 of X.680 says: The "TagDefault" is taken as "EXPLICIT TAGS"
> if it is "empty".
> 
> So basically X.509 defines EXPLICIT tags as the module default and
> RFC3281 defines IMPLICIT tags. This has some consequences, e.g. for
> structures such as "Holder" inside Attribute certificates, which is
> defined in AuthenticationFramework from ISO with EXPLICIT tags and in
> PKIXAttributeCertificate with IMPLICIT tags.

I can only see a drawback (not a problem) in case the code is
handcrafted (because you cannot reuse code).
When you use an ASN.1 compiler, you don't have to worry, for the 
encoder/decoder are generated according to each ASN.1 module whether it 
includes an IMPLICIT or EXPLICIT tagging mode.
-- 
Olivier DUBUISSON
france telecom R&D

DTL/TAL - 22307 Lannion Cedex - France
t: [phone] - f: [phone] - http://asn1.elibel.tm.fr/


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g92CAR315235 for ietf-pkix-bks; Wed, 2 Oct 2002 05:10:27 -0700 (PDT)
Received: from mystic2.trustcenter.de (mystic2.trustcenter.de [193.194.157.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g92CAPv15230 for <[e-mail]>; Wed, 2 Oct 2002 05:10:26 -0700 (PDT)
Received: (from uucp@localhost) by mystic2.trustcenter.de (8.11.6+Sun/8.11.6) id g92CIIZ29055 for <[e-mail]>; Wed, 2 Oct 2002 14:18:18 +0200 (MEST)
Received: from venus.trustcenter.de(192.168.202.4) by mystic2.trustcenter.de via csmap (V6.0) id srcAAAkpaWV4; Wed, 2 Oct 02 14:18:17 +0200
Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id g92CAac09792 for <[e-mail]>; Wed, 2 Oct 2002 14:10:36 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Wed, 02 Oct 2002 14:10:19 +0200
From: Juergen Brauckmann <[e-mail]>
Organization: TC TrustCenter AG
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: RFC3281 and tagging
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>

Hi.

I see a tagging problem in RFC3281. I hope that I'm wrong; perhaps
someone can have a look at it?

There are already some mails in the list archive regarding this issue
(<http://www.imc.org/ietf-pkix/mail-archive/msg02005.html>), but I still
don't understand it.


The ASN.1 module in Appendix B of RFC3281 has a module default of
"IMPLICIT":
===================================================
   PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
                internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
                id-mod-attribute-cert(12)}

      DEFINITIONS IMPLICIT TAGS ::=

      BEGIN
==================================================

My copy of X.509v4 (I admit that I only have draft v7, so I apologise if
that is the source of my confusion) defines the ASN.1 module in Annex A
as:
=====================================================
AuthenticationFramework {joint-iso-itu-t ds(5) module(1)
authenticationFramework(7) 4}
DEFINITIONS ::=
BEGIN
======================================================

Clause 12.2 of X.680 says: The "TagDefault" is taken as "EXPLICIT TAGS"
if it is "empty".

So basically X.509 defines EXPLICIT tags as the module default and
RFC3281 defines IMPLICIT tags. This has some consequences, e.g. for
structures such as "Holder" inside Attribute certificates, which is
defined in AuthenticationFramework from ISO with EXPLICIT tags and in
PKIXAttributeCertificate with IMPLICIT tags.

Where am I wrong?

Regards,
   Juergen


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g927Sbw16235 for ietf-pkix-bks; Wed, 2 Oct 2002 00:28:37 -0700 (PDT)
Received: from mr2.ipartners.pl (mr2.ipartners.pl [157.25.5.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g927SYv16231 for <[e-mail]>; Wed, 2 Oct 2002 00:28:35 -0700 (PDT)
Received: from eserwer (dlp-gtc-as1-as14.ipartners.pl [217.8.169.15]) by mr2.ipartners.pl with SMTP id g927RqF25987; Wed, 2 Oct 2002 09:27:53 +0200 (CEST)
Message-ID: <005b01c269e4$1f2825e0$0fa908d9@eserwer>
From: =?ISO-8859-1?Q?Karol_G=F3rski?= <[e-mail]>
To: <[e-mail]>, "Terry Hayes" <[e-mail]>, <[e-mail]>, "Russ" <[e-mail]>
Cc: "Tom Gindin" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Questions on Authority/Subject Key Identifiers
Date: Wed, 2 Oct 2002 09:19:50 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01C269F4.DBD0B4E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
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_0054_01C269F4.DBD0B4E0
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Peter,

You are correct. I did not want to imply that it is necessary to match =
the authority/subject key identifiers in successive certificates on a =
certification path. I was attempting to describe a (valid) situation =
where one of the fields in these extensions (keyIdentifier) is the same =
in two certificates yet the issuer/serial number fields do not match.=20

Karol
  ----- Original Message -----=20
  From: Peter Hesse=20
  To: Karol G=F3rski ; Terry Hayes ; [e-mail] ; Russ=20
  Cc: Tom Gindin ; [e-mail]=20
  Sent: Friday, September 27, 2002 9:18 PM
  Subject: RE: Questions on Authority/Subject Key Identifiers


  Karol,

  I am not sure that I agree with your interpretation.  It is not clear =
to me that AKID/SKID must match for a path to be considered valid.  In =
fact, I think that it would be best for path development operations to =
be written flexible enough to deal with cases in which AKID/SKID do not =
match, no matter which form of AKID is being used.

  Here's where I'm coming from: most CA products currently available do =
not allow the specification of the subject key identifier of a CA that =
they are to cross-certify with.  For example, if A is to cross-certify =
B, A must ensure that the certificate A issues to B contains a subject =
key identifier that matches the authority key identifier in all =
certificates B issues. =20

  Currently, when most CA products perform cross-certification, they =
calculate the SKID based upon the public key.  Hopefully, if the CAs are =
the same brand, or due to luck or configuration, they will calculate the =
SKID in the same fashion.  However, since there are no guarantees on how =
the SKID is calculated (the methods provided in RFC 2459/3280 are just =
common methods, not requirements) it is quite possible that this will =
result in a mismatch. =20

  If your path development algorithm cannot handle this mismatch, you =
will be unable to build a path when a valid one exists.  Certainly =
matching AKID/SKID should take priority over those that do not, but last =
I checked there is nothing in the certificate path validation process =
for X.509, RFC 2459, or RFC 3280 that fails a path based upon a =
mismatched AKID/SKID.

  --Peter

  +---------------------------------------------------------------+
  | Peter Hesse                    [e-mail]     |
  | Phone: [phone]         Gemini Security Solutions, Inc.  |
  | ICQ: 1942828                     www.geminisecurity.com       |
  +---------------------------------------------------------------+
  "Pay no attention to what the critics say; there has never been=20
  a statue set up in honor of a critic." --Jean Sibelius



------=_NextPart_000_0054_01C269F4.DBD0B4E0
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>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Peter,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>You are correct. I did not want to =
imply that it is=20
necessary to match the authority/subject key identifiers in successive=20
certificates on a certification path. I was attempting to describe a =
(valid)=20
situation where one of the fields in these extensions (keyIdentifier) is =
the=20
same in two certificates yet the issuer/serial number fields do not =
match.=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Karol</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-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 title=[e-mail]=20
  href=3D"mailto:[e-mail]">Peter Hesse</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">Karol G=F3rski</A> ; <A=20
  title=[e-mail] href=3D"mailto:[e-mail]">Terry =
Hayes</A> ;=20
  <A title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> ; <A=20
  title=[e-mail] =
href=3D"mailto:[e-mail]">Russ</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">Tom Gindin</A> ; <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, September 27, =
2002 9:18=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Questions on=20
  Authority/Subject Key Identifiers</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
  face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT =
face=3DArial=20
  size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
  size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
  size=3D2></FONT><BR></DIV>
  <DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
  size=3D2>Karol,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
  size=3D2>I am not sure that I agree with your interpretation.&nbsp; It =
is not=20
  clear to me that AKID/SKID must match for a path to be considered =
valid.&nbsp;=20
  In fact, I think that it would be best for path development operations =
to be=20
  written flexible enough to deal with cases in which AKID/SKID do not =
match, no=20
  matter which form of AKID is being used.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D849400319-27092002></SPAN><SPAN=20
  class=3D849400319-27092002></SPAN><SPAN =
class=3D849400319-27092002><FONT=20
  face=3D"Comic Sans MS" color=3D#800080 =
size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
  size=3D2>Here's where I'm coming from: most CA products currently =
available do=20
  not allow the specification of the subject key identifier of a CA that =
they=20
  are to cross-certify with.&nbsp; For example, if A is to cross-certify =
B, A=20
  must ensure that the certificate A issues to B contains a subject key=20
  identifier that matches the authority key identifier&nbsp;in all=20
  certificates&nbsp;B issues.&nbsp; </FONT></SPAN></DIV>
  <DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
  size=3D2>Currently, when most CA products perform cross-certification, =
they=20
  calculate the SKID based upon the public key.&nbsp; Hopefully, if the =
CAs are=20
  the same brand, or due to luck or configuration, they =
will&nbsp;calculate the=20
  SKID in the same fashion.&nbsp; However, s</FONT></SPAN><SPAN=20
  class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080 size=3D2>ince=20
  there are no guarantees on how the SKID is calculated (the methods =
provided in=20
  RFC 2459/3280 are just common methods, not requirements) it is quite =
possible=20
  that this will result in a mismatch.&nbsp; </FONT></SPAN></DIV>
  <DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
  size=3D2>If your path development algorithm cannot handle this =
mismatch, you=20
  will be unable to build a path when a valid one exists.&nbsp; =
Certainly=20
  matching AKID/SKID should take priority over those that do not, but =
last I=20
  checked there is nothing in the certificate path validation process =
for X.509,=20
  RFC 2459, or RFC 3280 that fails a path based upon a mismatched=20
  AKID/SKID.</FONT></SPAN></DIV>
  <DIV><FONT face=3D"Comic Sans MS" color=3D#800080 =
size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Comic Sans MS" color=3D#800080 size=3D2><SPAN=20
  class=3D849400319-27092002>--Peter</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Comic Sans MS" color=3D#800080 =
size=3D2></FONT>&nbsp;</DIV><FONT=20
  face=3D"Courier New" size=3D2><FONT=20
  =
color=3Dgray>+-----------------------------------------------------------=
----+<BR>|&nbsp;</FONT><FONT=20
  color=3D#3333cc>Peter=20
  =
Hesse</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT=20
  =
color=3Dblue>[e-mail]</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;<FONT=20
  color=3Dgray>|<BR>|&nbsp;</FONT><FONT color=3D#3333cc>Phone:=20
  =
[phone]</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;<FONT=20
  color=3D#3333cc>Gemini Security Solutions, =
Inc.&nbsp;&nbsp;</FONT><FONT=20
  color=3Dgray>|<BR>|&nbsp;</FONT><FONT color=3D#3333cc>ICQ:=20
  =
1942828</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT =

  =
color=3Dblue>www.geminisecurity.com</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;<FONT=20
  =
color=3Dgray>|<BR>+------------------------------------------------------=
---------+<BR><FONT=20
  color=3Dteal>"Pay no attention to what the critics say; there has =
never been=20
  <BR>a statue set up in honor of a critic." --Jean=20
  Sibelius</FONT><BR></FONT></FONT>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr=20
  =
align=3Dleft><TT></TT>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML=
>

------=_NextPart_000_0054_01C269F4.DBD0B4E0--