Subject: I-D ACTION:draft-ietf-pkix-scvp-00.txt

From: [email-masked]
Date: Mon, 28 Jun 1999 08:51:36 -0400

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

	Title		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	:  A. Malpani, P. Hoffman
	Filename	: draft-ietf-pkix-scvp-00.txt
	Pages		: 
	Date		: 25-Jun-99
	
The SCVP protocol allows a client to offload certificate handling to a
server. The server can give a variety of valuable information about the
certificate, such as whether or not it is valid, what the public key
and subject of the certificate is, and so on.

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: [email-masked]
Date: Tue, 29 Jun 1999 11:46:19 +1000

The first glance impression. 

The purpose of the verification, as I understood it, is to attain to the
validity of the certificate.
I guess it will provide more value if the result (phrasing it out freely)
was " a certificate was valid (or otherwise) at a particular moment of
time". 
I can imagine that it is of a big importance for the clients to know if a
certificate WAS valid at some moment in the past (when it was actually used
for signing etc). So should the request contain an extra [optional]
timeOfInterest field?

1. Note, it is not the same as the ProducedAt field you have proposed.

2. Hmm, sounds very much like a digital Notary to me :)

Michael Zolotarev
Technical Architect, Baltimore Technologies Pty Ltd (Australia)

> http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-00.txt
[snip]

---

From: [email-masked]
Date: Tue, 29 Jun 1999 12:27:04 +1000

Hardcoded SHA-1:
Why not to use the X509 AlgorithmIdentifier? It gives you a flexibility to
use any (but just one) hash algorithm.
AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }

Request/Response signatures:
Could the PKCS#7 encapsulation be used for the request and response?
signedContent for normal comms, and dataContent for secure/authenticated
wire?

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 28 Jun 1999 19:39:52 -0700

>2. Hmm, sounds very much like a digital Notary to me :)

Yes, it sure does. If we overload the protocol, the "S" becomes a "C". I'd 
rather leave this in the notary work.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Carlisle Adams <[email-masked]>
Date: Tue, 29 Jun 1999 10:25:47 -0400

Hi Paul,

> ----------
> From: 	Paul Hoffman / IMC[SMTP:[email-masked]]
> Sent: 	Monday, June 28, 1999 9:49 PM
> To: 	[email-masked]
> Subject: 	Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> 
> At 06:24 PM 6/28/1999 -0700, Aram Perez wrote:
> >1) I like the idea of SCVP but if the SCVP response is signed, how does
> the
> >client verify the signature if it can't handle certs?
> 
> It has the public key of the server built-in without a cert. Remember, you
> 
> don't need certs for root keys.
 
Quite true, if you expect the key to live forever and to be unfettered with
all those annoying policies, CPSs, key usages, key identifiers, and so on.

If there is value in constraining the use and power of this key in any way
whatsoever (and there typically is), the utility of a self-signed cert
really becomes apparent.

Just a thought...

Carlisle.

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 29 Jun 1999 12:52:11 -0400 (EDT)

> From: "Aram Perez" <[email-masked]>
>
> >>2) Section 3.20 states "The CertID item has an identifier for the type of
> >>certificate and the SHA-1 [SHA-1] hash of the octets of the certificate
> >>itself." While I agree with specifying SHA-1 to *identify the certs*, I
> >>recently got beat up on this mailing list because IETF is always supposed to
> >>allow algorithm independence ;-)
> >
> > Not always. There is a tradeoff of multiple algorithms for safety (in case
> > SHA-1 gets broken) versus complexity (having to include another identifier
> > and having clients understand it). What do others think here? I hard-coded
> > SHA-1 for simplicity.
> 
> Believe me, I agree with specifying just one algorithm for simplicity (and
> interoperability) sake. It's just that I wanted someone else to get beat up
> like I was ;-)

In this case I believe simplicity should win.  Algorithm agility is good
where there are actual or potential tradeoffs between algorithms.  But I don't
see any tradeoffs in this case.

Implementation complexity: at least one algorithm must be mandatory for
interoperability, so even if SHA-1 is "broken", support for it must be
continued.  If it were acceptable to break backwards compatibility to
designate a different mandatory algorithm, it would also be acceptable to
designate a different hard-coded algorithm.

Security: A hash used as a cert identifier should uniquely identify a
certificate.  Cryptographic advances may someday "break" SHA-1 by making
it computationally easier to find colliding inputs, but they will not change
the values of those inputs; two octet strings which have different SHA-1
hashes today will not suddenly have the same SHA-1 hash tomorrow.  I'll
start to worry when there are 2^80 meaningful certificates in the
universe.

---

From: "Aram Perez" <[email-masked]>
Date: Tue, 29 Jun 1999 10:16:16 -0700

Hi Dave,

> see any tradeoffs in this case.

This was precisely the point I was trying to make earlier. Where were you
when I was getting beat up ;-)

Regards,
Aram Perez

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 29 Jun 1999 10:48:17 -0700

>all those annoying policies, CPSs, key usages, key identifiers, and so on.

Not so. When the server's key is installed in the client, any of those 
could be hard-wired in, just as they are (or aren't) when you install root 
certificates. They just don't have to be wrapped in a formal certificate.

Which is not to say that they can't be. If the client understands certs, 
the interface for that client might only allow the installation of a root 
key which comes in a self-signed cert, and that installation might act on 
all the parameters. That's a perfectly reasonable way to get the server's 
public key. But it is not required for the very simple reason that many 
SCVP clients cannot even parse a cert, much less interpret it.

>whatsoever (and there typically is), the utility of a self-signed cert

You mean *that's* what we've been talking about on this mailing list?! :-)

If you want to exclude clients that can't interpret certs from SCVP, then 
there is little value to SCVP other than to aid some clients do 
chain-building. The purpose of SCVP, as stated in the intro, is to help 
clients that can use public keys, but not PKIX certs, to get value out of 
PKIX certs. Without SCVP, the makers of these clients might need to invent 
yet another cert format that is easier to parse and interpret; that would 
hurt the whole PKIX market.

--Paul Hoffman, Director