headers
mzolotarev | 1 Jul 1999 02:22

RE: Time Stamp: Usage of TDTs

Bill,

Ok, another question: If one day NIST will implement TSA services itself,
would I, as a client, need a TDT in the TST produced by a NIST server? I
guess no.
In general case, if a TDA can attest to the quality of time (because it
knows it better, presumably), what stops it to provide TSA services itself?
So the clients can go 'right to the source', and get a 100% guaranteed pure
time reference, instead of having to worry about secondary verification,
etc.

Waiting for replies...

Regards
MichaelZ

-----Original Message-----
From: Bill Lattin [mailto:wlattin <at> earthlink.net]
Sent: Thursday, July 01, 1999 7:12 AM
To: mzolotarev <at> baltimore.com; "Denis.Pinkas[Denis.Pinkas" <at> bull.net];
ietf-pkix <at> imc.org
Cc: drobinson <at> gat.com; rholm <at> datum.com; mike <at> wetstonetech.com;
gdowd <at> datum.com
Subject: RE: Time Stamp: Usage of TDTs

Michael,

Thanks for the feedback.

Depending on the application, a client could be very interested in
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ambarish Malpani | 1 Jul 1999 12:40

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


Unsigned requests are *not* insecure, as long as they contain
the RequestHash and the client verifies that it gets the same
RequestHash in the signed response.

(Paul, I think our example is broken - it doesn't reflect the
RequestHash in the response).

Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        ambarish <at> valicert.com
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833

> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:phoffman <at> imc.org]
> Sent: Monday, June 28, 1999 8:17 PM
> To: ietf-pkix <at> imc.org
> Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> 
> 
> At 08:07 PM 6/28/1999 -0700, Aram Perez wrote:
> > > It has the public key of the server built-in without a 
> cert. Remember, you
> > > don't need certs for root keys.
> >
> >This is fine but implies a limited number of SCVP servers.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ambarish Malpani | 1 Jul 1999 12:50

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


Carlisle,
    If you are a small device that is trying to avoid the overhead
of understanding certs, it won't hurt too much if you tell it - here
is a key that you can trust for SCVP responses. You can build in a
lifetime for that trust - that doesn't need to be done in the form
of certs. Given that the usage of the cert is fixed - SCVP signing,
I am not sure that the device is going to benefit a whole bunch
by seeing the appropriate OIDs in the self-signed cert. Basically
you are trying to establish out of band trust for a key - whether
that is done with a self signed cert or in some other way doesn't
really matter a lot.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        ambarish <at> valicert.com
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833

> -----Original Message-----
> From: Carlisle Adams [mailto:carlisle.adams <at> entrust.com]
> Sent: Tuesday, June 29, 1999 7:26 AM
> To: 'Paul Hoffman / IMC'
> Cc: ietf-pkix <at> imc.org
> Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Lattin | 1 Jul 1999 16:39
Picon
Favicon

RE: Time Stamp: Usage of TDTs

Michael,

I suppose that if a TDA issuing this type of TDT wanted to perform the other
activities associated with a TSA it could; however, I don't necessarily see
a merging of the two since the business issues associated with each
(liability, customer support, application interfaces, policy support, etc)
are quite different.  Also, not all applications requiring a time stamp need
that level of accuracy - hence the variation in service offerings I
previously mentioned.

Cheers,

Bill

> -----Original Message-----
> From: mzolotarev <at> baltimore.com [mailto:mzolotarev <at> baltimore.com]
> Sent: Wednesday, June 30, 1999 17:23
> To: wlattin <at> earthlink.net; Denis.Pinkas; ietf-pkix <at> imc.org
> Cc: drobinson <at> gat.com; rholm <at> datum.com; mike <at> wetstonetech.com;
> gdowd <at> datum.com
> Subject: RE: Time Stamp: Usage of TDTs
>
>
> Bill,
>
> Ok, another question: If one day NIST will implement TSA services itself,
> would I, as a client, need a TDT in the TST produced by a NIST server? I
> guess no.
> In general case, if a TDA can attest to the quality of time (because it
> knows it better, presumably), what stops it to provide TSA
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Hoffman / IMC | 1 Jul 1999 17:56
Picon

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

At 03:40 AM 7/1/1999 -0700, Ambarish Malpani wrote:
>(Paul, I think our example is broken - it doesn't reflect the
>RequestHash in the response).

Yipes! You're right. I had the RequestHash in the request but not in the 
response, which goes against the second MUST in section 3.18. I'll fix this.

--Paul Hoffman, Director
--Internet Mail Consortium
Permalink | Reply | 0 comments |
headers
Paul Hoffman / IMC | 1 Jul 1999 17:57
Picon

Fwd: I-D ACTION:draft-moskowitz-cmpinterop-00.txt

Another new draft that might interest a few folks in this group.

>To: IETF-Announce: ;
>From: Internet-Drafts <at> ietf.org
>Reply-to: Internet-Drafts <at> ietf.org
>Subject: I-D ACTION:draft-moskowitz-cmpinterop-00.txt
>Date: Thu, 01 Jul 1999 07:53:17 -0400
>Sender: nsyracus <at> NS.CNRI.RESTON.VA.US
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : CMP Interoperability Testing:
>                           Results and Agreements
>         Author(s)       : R. Moskowitz
>         Filename        : draft-moskowitz-cmpinterop-00.txt
>         Pages           : 23
>         Date            : 30-Jun-99
>
>This memo describes the results of the first two interoperability
>tests of public key infrastructure (PKI) implementations based on
>RFC 2459, RFC 2510, and RFC 2511.  PKI implementations fall into
>three general classes: certification authorities (CAs), registration
>authorities (RAs), and PKI clients.  Interoperability testing
>focused on transactions to obtain and revoke certificates.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-moskowitz-cmpinterop-00.txt
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Petra Gloeckner | 1 Jul 1999 18:32
Permalink | Reply | 0 comments |
headers
Salter, Thomas A | 1 Jul 1999 19:07
Picon

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

Are you sure that the tiny syntax saves all that much parsing code?

It seems to me that you could accomplish much of what you want by
restricting the protocol to a very small subset of ASN.1.  Suppose, for
instance, that all protocol elements are implicitly tagged and encoded as
DER.  Then the biggest difference between that and 'tiny' syntax is that the
variable-length length field (and perhaps a variable length tag).

(I would only apply the DER restriction to elements parsed by the client;
the client could encode using any BER encoding.)

My question is whether a 'tiny' parser is enough smaller than a parser for
an ASN.1 subset to be worth inventing a new encoding scheme.
Permalink | Reply | 0 comments |
headers
David P. Kemp | 1 Jul 1999 19:51

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


I agree that the perception that ASN.1 cannot be used in a tiny syntax
is largely undeserved.  I would be happy to write a small ASN.1 parser
that should compare favorably in runtime and memory footprint with the
software required to support the alternate encoding.  Support for
indefinite-length (non-DER) coding costs almost nothing so a DER
restriction is not necessary, but using implicit tagging for
context-tagged OPTIONAL elements will save a couple of bytes per
element in the encoded data and one tiny subroutine in the code.
Making every element non-OPTIONAL but potentially zero length would
save more code.

Anyone care for a syntax bakeoff? :-)

>From: "Salter, Thomas A" <Thomas.Salter <at> unisys.com>
>
> Are you sure that the tiny syntax saves all that much parsing code?
> 
> It seems to me that you could accomplish much of what you want by
> restricting the protocol to a very small subset of ASN.1.  Suppose, for
> instance, that all protocol elements are implicitly tagged and encoded as
> DER.  Then the biggest difference between that and 'tiny' syntax is that the
> variable-length length field (and perhaps a variable length tag).
> 
> (I would only apply the DER restriction to elements parsed by the client;
> the client could encode using any BER encoding.)
> 
> My question is whether a 'tiny' parser is enough smaller than a parser for
> an ASN.1 subset to be worth inventing a new encoding scheme.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Hoffman / IMC | 1 Jul 1999 20:08
Picon

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

At 01:51 PM 7/1/1999 -0400, David P. Kemp wrote:
>I agree that the perception that ASN.1 cannot be used in a tiny syntax
>is largely undeserved.

Maybe so, but it is a widespread perception.

>   I would be happy to write a small ASN.1 parser
>that should compare favorably in runtime and memory footprint with the
>software required to support the alternate encoding.

A single instance of a parser is not going to convince many people that 
constrained ASN.1 is sufficient. A syntax that implementors can understand 
well enough to write a parser is what is needed. If we can describe the 
ASN.1 syntax well enough to prove that such a parser is fairly easy to 
write, then there is a win, but I suspect that is impossible due to many 
things, including the lack of easily-findable documentation for creating 
ASN.1 interpreters.

>   Support for
>indefinite-length (non-DER) coding costs almost nothing so a DER
>restriction is not necessary, but using implicit tagging for
>context-tagged OPTIONAL elements will save a couple of bytes per
>element in the encoded data and one tiny subroutine in the code.
>Making every element non-OPTIONAL but potentially zero length would
>save more code.

We did not try to optimize for smallest messages; in fact, we didn't see 
that as a requirement at all. A single subroutine is also not important.

>Anyone care for a syntax bakeoff? :-)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane