RE: dual-use digital signature [EMAIL PROTECTED]

2004-08-01 Thread Peter Gutmann
[EMAIL PROTECTED] writes:

Your certificate definition says additionalRecipients, mine says
additionalSubjects, Fred-over-there's says coKeyOwners. The OIDs for
these extensions end up all different. A human may be able to parse the
intent from the ASN.1 it but email programs will have difficulty.

What I meant was that if there was any demand for this, someone would define a
standard place to store the info, which apps would (eventually) display.  At
the moment there's neither a additionalRecipients, a additionalSubjects, a
coKeyOwners, or anything else, because no-one's ever asked for it.

Given the complete lack of demand for this to date I suspect that even if you
did do an RFC for it it'd be relegated to Experimental status and everyone
would ignore it... what exactly is the intent of adding this information?
Under what circumstances would it be used?  What's the UI for it?  Do you
throw up a warning?  Warning of what?  If it's Others are listening in then
the alternative is to not use the cert at all, in which case the choice given
to the users will be Allow one or two others to listen in vs. Allow anyone
to listen in, since everyone will choose the former there's not much point in
putting it there in the first place.  etc etc etc.

(There have been similar suggestions made about other warn-the-user type
 features on the S/MIME list, which tend to get shot down with some variant of
 I wouldn't even know how to begin to do a UI for this, with a backup of
 This amounts to giving the user a choice of communicate or don't
 communicate, guess which one they'll choose?).

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: dual-use digital signature [EMAIL PROTECTED]

2004-07-30 Thread Peter Gutmann
[EMAIL PROTECTED] writes:

2 centsIn the business cases pointed out where it is good that the multiple
parties hold the private key, I feel the certificate should indicate that
there are multiple parties so that Bob can realize he is having authenticated
and private communications with Alice _and_ Alice's employer. X.509 does not
provide a standard way to encode multiple subjects./2 cents

Yes it does, if you needed this you could add an extension (say)
additionalRecipients with a SEQUENCE of GeneralName naming the additional
parties listening in.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: dual-use digital signature [EMAIL PROTECTED]

2004-07-28 Thread Peter Gutmann
Anne  Lynn Wheeler [EMAIL PROTECTED] write:

the assertion here is possible threat model confusion when the same exact
technology is used for two significantly different business purposes.

I don't think there's any confusion about the threat model, which is Users
find it too difficult to generate keys/obtain certs, so if the CA doesn't do
it for them the users will complain, or not become users at all.  Having the
CA generate the key addresses this threat model.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: dual-use digital signature [EMAIL PROTECTED]

2004-07-28 Thread Peter Gutmann
Richard Levitte - VMS Whacker [EMAIL PROTECTED] writes:

Peter, are you talking about generic CAs or in-corporation ones?

Both.  Typically what happens is that the CA generates the key and cert and
mails it to the user as a PKCS #12 file, either in plaintext, with the
password in the same email, or occasionally with the password in separate
email.  See How to build a PKI that works on my home page (direct link at
http://www.cs.auckland.ac.nz/~pgut001/pubs/howto.pdf, Challenge #2 starting on
p.25) for details, including a few sample quotes from users.

I can definitely see different needs between those.

Actually they both seem to have the same need, it's the least effort to do it
this way.  Occasionally you see it dressed up as something else, e.g. We
don't trust our users to generate the keys properly themselves (one of those
was from a CA that's distinguished itself through the bugginess of its
software, which makes the comment rather amusing coming from them), but it
almost always boils down to the same thing.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: dual-use digital signature [EMAIL PROTECTED]

2004-07-28 Thread Ian Grigg
Peter Gutmann wrote:
A depressing number of CAs generate the private key themselves and mail out to
the client.  This is another type of PoP, the CA knows the client has the
private key because they've generated it for them.
It's also cost-effective.  The CA model as presented
is too expensive.  If a group makes the decision to
utilise the infrastructure for signing or encryption,
then it can significantly reduce costs by rolling out
from the centre.
I see this choice as smart.  They either don't do it
at all, or they do it cheaply.  This way they have a
benefit.
(Then, there is still the option for upgrading to self-
created keys later on, if the project proves successful,
and the need can be shown.)
As a landmark, I received my first ever correctly
signed x.509 message the other day.  I've yet to find
the button on my mailer to generate a cert, so I could
not send a signed reply.  Another landmark for the
future, of course.
iang
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: dual-use digital signature [EMAIL PROTECTED]

2004-07-28 Thread Michael_Heyman
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Peter Gutmann
 Sent: Saturday, July 24, 2004 9:07 PM
 [SNIP]
 A depressing number of CAs generate the private key 
 themselves and mail out to the client.

Replies to this talked about business cases to have control of the
private key not only under the identity upheld by the certificate.

I would like to point out that whether or not a CA actually has the
private key is largely immaterial because it always _can_ have the
private key - a CA can always create a certificate for Alice whether or
not Alice provided a public key.

Whether or not Alice has complete control over her private key makes no
difference to Bob. If the CA works properly, Bob and Alice can have a
authenticated and private communications. If the CA is compromised (or
inherently malicious), Bob will think he is having authenticated and
private communications with Alice but will actually have it with an
agent of the CA's choosing. This is the way the system was designed. Bob
trusts the CA to provide for authenticated and private communications
with Alice.

2 centsIn the business cases pointed out where it is good that the
multiple parties hold the private key, I feel the certificate should
indicate that there are multiple parties so that Bob can realize he is
having authenticated and private communications with Alice _and_ Alice's
employer. X.509 does not provide a standard way to encode multiple
subjects./2 cents

-Michael Heyman

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: dual-use digital signature [EMAIL PROTECTED]

2004-07-26 Thread Anne Lynn Wheeler
At 07:07 PM 7/24/2004, Peter Gutmann wrote:
A depressing number of CAs generate the private key themselves and mail out to
the client.  This is another type of PoP, the CA knows the client has the
private key because they've generated it for them.
one could claim that there might be two possible useage scenarios, 
involving two different thread models: encryption and authentication.

from a business standpoint the encryption of corporate data (especially 
data at rest  which might include some of the corporate jewels) can 
represent single point of failures ... if private key is required for the 
recovery of corporate jewels and the private key isn't reliably replicated 
(to avoid single points of failure); then there is a serious, corporate, 
overriding availability threat.

the claim can be made that the trade-off for authentication and digital 
signature would result in no escrow or replication of private key  
since the overriding threat model is a) impersonation and/or b) not being 
able to reliably attribute certain actions to specific people.

the assertion here is possible threat model confusion when the same exact 
technology is used for two significantly different business purposes.

 in general, no key escrow or no key replication is frequently bad in 
the encryption business process scenario

... while no key escrow or no key replication is good in the 
authentication/digital signature business process scenario.

a problem arises when the business purpose uses of the public/private key 
pair isn't sufficiently described ... leading to confusion (and/or the same 
public/private key pair are used for different business processes with 
possibly conflicting threat models).

--
Anne  Lynn Wheelerhttp://www.garlic.com/~lynn/ 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: dual-use digital signature [EMAIL PROTECTED]

2004-07-26 Thread Richard Levitte - VMS Whacker
In message [EMAIL PROTECTED] on Sun, 25 Jul 2004 13:41:56 -0600, Anne  Lynn Wheeler 
[EMAIL PROTECTED] said:

lynn At 07:07 PM 7/24/2004, Peter Gutmann wrote:
lynn A depressing number of CAs generate the private key themselves
lynn and mail out to the client.  This is another type of PoP, the
lynn CA knows the client has the private key because they've
lynn generated it for them.

Peter, are you talking about generic CAs or in-corporation ones?  I
can definitely see different needs between those.

lynn one could claim that there might be two possible useage
lynn scenarios, involving two different thread models: encryption and
lynn authentication.
lynn 
lynn from a business standpoint the encryption of corporate data
lynn (especially data at rest  which might include some of the
lynn corporate jewels) can represent single point of failures ... if
lynn private key is required for the recovery of corporate jewels and
lynn the private key isn't reliably replicated (to avoid single
lynn points of failure); then there is a serious, corporate,
lynn overriding availability threat.

That's all and well, but I can't see why that would be interesting to
a generic, third-party CA.  If you're talking about a CA within the
same corporation, then I can understand, since they usually (as far as
I can guess) work from a different standpoint and with different
priorities.

What you describe feels to me like encryption is ill understood and
placed in the hands of random individuals.  If you want safety and
recoverability, there's nothing like one or several backups, maybe
protected with different means (different encryption, different
storage media (including vaults), different keys, and so on).

-
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte   \ Tunnlandsvägen 52 \ [EMAIL PROTECTED]
[EMAIL PROTECTED]  \ S-168 36  BROMMA  \ T: +46-708-26 53 44
\  SWEDEN   \
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

-
A: Because it fouls the order in which people normally read text. 
Q: Why is top-posting such a bad thing? 
A: Top-posting. 
Q: What is the most annoying thing on usenet and in e-mail?

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: dual-use digital signature [EMAIL PROTECTED]

2004-07-26 Thread Anne Lynn Wheeler
At 02:00 PM 7/26/2004, Richard Levitte - VMS Whacker wrote:
That's all and well, but I can't see why that would be interesting to
a generic, third-party CA.  If you're talking about a CA within the
same corporation, then I can understand, since they usually (as far as
I can guess) work from a different standpoint and with different
priorities.
What you describe feels to me like encryption is ill understood and
placed in the hands of random individuals.  If you want safety and
recoverability, there's nothing like one or several backups, maybe
protected with different means (different encryption, different
storage media (including vaults), different keys, and so on).
I believe there was at least one large institutional effort where
keys were generated, escrowed and loaded into hardware tokens
and distributed. the persons were expected to use the hardware
tokens for both authentication and encryption. if the hardware token
failed (like if the battery died), they could get a new hardware token
issued with the same keys.
the obviously needed the original keys if they had used the hardware
token for encryption (of data that turned out to be laying around
someplace).
however, it wasn't necessary to have escrowed keys for authentication,
simply issuing a new hardware tokens with new (authentication) keys
would have been sufficient (and reregistering the new public key).
here is an issue where, if they're using hardware tokens for key protection ...
they really need to distinguish between encryption keys and authentication
keys  either a single hardware token with two different sets of keys ...
and the token knows how to consistently differentiate their use between
encryption and authentication ... or two different hardware tokens ...
consistently used for the different (business) purposes.
there is a side issue with institutional delivered hardware tokens ...
and if they were to replace existing shared-secret pins/passwords ...
where a person might have a hundred unique shared-secrets for
their various electronic relationships  and potentially be issued
at least one hardware token to be used in lieu of every pin/password
... and potentially a second hardware token for encryption only
purposes (say in dongle form ... a key chain with 100-120 or dongles
... in need of medium sized ruck sack just to lug them around).
--
Anne  Lynn Wheelerhttp://www.garlic.com/~lynn/ 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: dual-use digital signature [EMAIL PROTECTED]

2004-07-25 Thread Peter Gutmann
Sean W. Smith [EMAIL PROTECTED] writes:

I would have thought that de facto standard approach is: the client
constructs the certificate request message, which contains things like the
public key and identifying info, and signs it.  The CA then checks the
signature against the public key in the message.

A depressing number of CAs generate the private key themselves and mail out to
the client.  This is another type of PoP, the CA knows the client has the
private key because they've generated it for them.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]