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

From: "Ambarish Malpani" <[email-masked]>
Date: Thu, 1 Jul 1999 03:50:42 -0700

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.				        [email-masked]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833

> -----Original Message-----
> From: Carlisle Adams [mailto:[email-masked]]
> Sent: Tuesday, June 29, 1999 7:26 AM
> To: 'Paul Hoffman / IMC'
> Cc: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> 
> 
> 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: "Salter, Thomas A" <[email-masked]>
Date: Thu, 1 Jul 1999 13:07:34 -0400

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.

---

From: [email-masked]
Date: Thu, 1 Jul 1999 14:28:09 -0400

Actually, I'm not sure that cutting down on OPTIONAL for primitive fields
is a big savings - I'd argue that it's DEFAULT that costs a lot.  If each
element at a given level has a unique tag (not normal in ASN.1, admittedly, but
not hard to arrange), and the caller asks for the pointer and length
corresponding to class C and tag T, OPTIONAL costs almost nothing - when you
don't find the requested tag, you just return { NULL, 0 }.  You could also have
another routine looking for the N'th occurrence of universal tag T (or class C
and tag T, for that matter) to accomodate most existing sequences (and almost
all SEQUENCE OF's and SET OF's), but that one would require that no occurrence
of tag T other than the last one be OPTIONAL.  Handling general cases of
OPTIONAL in the syntax might be harder, but designing to these rules would make
the structure easy to handle with a minimal parser.

          Tom Gindin

---

From: [email-masked]
Date: Fri, 2 Jul 1999 11:09:26 +1000

All, 
Since the discussion started, have we received any 'at last' greetings from
small device manufactures? They should be the first to reply and the
majority among the participants. Where are you, guys??? Aren't you that much
concerned about complexity of handling ASN.1?

Would love to hear from anybody from the 'small-devices' camp who was
stopped on their way by the science of ASN.1 parsing. I appreciate that
information could be proprietary, but just give us a hint. 

Otherwise, I'm not sure we are talking the reality here, proposing a
'simple' alternative to ASN.

Simple (shareware?) ASN.1 parser sounds cool indeed. Thanks for
volunteering, David.

Regards

Michael Zolotarev

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[email-masked]]
Sent: Friday, July 02, 1999 5:07 AM
To: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt

At 02:39 PM 7/1/1999 -0400, David P. Kemp wrote:
>Sorry, but the idea of a protocol that says "here is a certificate,
>give me the public key" just makes me gag.

Um, have you read the draft? The protocol gives back much more than that. 
Reading the draft may help prevent future gagging.

>   What device has enough oomph
>to run a protocol engine but not enough to extract the key from an
>X.509 cert?

Probably none; the protocol returns much more than the key. There are lots 
of devices who do not have the oomph to do good path validation with all of 
the constraints. Getting just the public key is not interesting, given that 
you want to validate it.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 3 Jul 1999 10:04:18 +0100

Hi Michel,
Here are some comments on the tiny format

>concerned about complexity of handling ASN.1?

No, particularly if one looks a couple a years ahead.
Only within certain places like in static data in smart-cards ASN.1 parsing is
a problem and in these places ASN.1 will be supplemented by ASN.1 opaque objects
containing hard-code binary data.

<snip>
>'simple' alternative to ASN.

XML is my candidate.  Universal, hyped and human-readable.  It is not a compact
format though but that is not such a big problem anymore. 

Regards
Anders Rundgren

http://www.mobilephones-tng.com

---

From: [email-masked]
Date: Mon, 5 Jul 1999 11:10:54 +1000

I knew you would turn up, Anders. A big voice from small devices :)

1.What makes XML any better then ASN in PKI world?
2.Any more solid proposals/ideas about XML usage? 
3.Any known implementations?

Looking forward...

Regards
MichaelZ

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Saturday, July 03, 1999 7:04 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt

Hi Michel,

No, particularly if one looks a couple a years ahead.
Only within certain places like in static data in smart-cards ASN.1 parsing
is
a problem and in these places ASN.1 will be supplemented by ASN.1 opaque
objects
containing hard-code binary data.

<snip>
>'simple' alternative to ASN.

XML is my candidate.  Universal, hyped and human-readable.  It is not a
compact
format though but that is not such a big problem anymore. 

Regards
Anders Rundgren

---

From: Zahid Ahmed <[email-masked]>
Date: Thu, 8 Jul 1999 15:26:18 -0700

I think there can be advantages of using XML to
describe certificate/identity and management documents 
being included in PKIX description. 

The reason is that most customer/enterprise/application
data is not described in ASN.1. A lot of it may end
up being mapped to XML data description languages. When
such data needs to be included in X.509 certs, e.g.,
we will need to do a mapping between XML and ASN.1.
Most of the time this is straightforward; however,
there are cost involved in converting security data
to and from application data model(s).

Another alternative, I think, within PKIX could be 
to add some v3 or v4 extensions for XML instances.

---Zahid

> From: Kathy Dally [mailto:[email-masked]]
> Sent: Thursday, July 08, 1999 3:23 PM
> To: Anders Rundgren
> Cc: PKIX-List; Stephen Kent; [email-masked]; 
> William Z Pope
> Hi Anders!
> Two reactions:
> 	Wrapping XML/XSL in ASN.1 encoding means 
> implementations must deal with
> both 
> 	types of encoding.
> 
> 	Is XSL encoding always unique or will there be a 
> BER/DER-like problem?
> 
> Thanks,
> Kathy Dally
> 
> 
> Anders Rundgren wrote:
> > 
> > Well,
> > sorry for bringing this up.  For certificates with huge 
> informational contents I
> > see some gain by wrapping an XML information object into ASN.1 X509
> > wrapper.  If PKI goes big, certificates proliferate the 
> decoding part (RP debugging)
> > will be helped by using XML rather than ASN.1.  
> Particularly if XML becomes
> > the lingua franca of the Web.   But of course XML is not 
> required, it is just
> > something that could be worth considering for lets say X509.v4
> > 
> > Anders
> > 
> > >I agree with you that the XSL standard does indeed address 
> the encoding
> > >standards, but ther real issue is why change from the 
> standard ASN.1 mindset
> > >to XML.
> > >
> > >What is the gain here?
> > >
> > >Todd
> > >
> > >----- Original Message -----
> > >From: William Z Pope <[email-masked]>
> > >To: [email-masked] 
> <[email-masked]>; Anders
> > >Rundgren <[email-masked]>; Stephen Kent 
> <[email-masked]>
> > >Cc: <[email-masked]>
> > >Sent: Thursday, July 08, 1999 1:14 PM
> > >> A point of clarification, XML is a human readable data 
> description
> > >> format.  I has nothing to do with presentation.  XSL 
> defines presentation
> > >> options for XML documents based on the structure and 
> content of the XML
> > >> document.
> > >>
> > >> I now return you to your regularly scheduled discussion :^)
> > >>
> > >> =bill
> > >>
> > >> > From: [email-masked]
> > >> > [mailto:[email-masked]]
> > >> > Sent: Thursday, July 08, 1999 12:48 PM
> > >> > To: Anders Rundgren; Stephen Kent
> > >> > Cc: [email-masked]
> > >> > Steve is absolutely right here. The While XML will 
> likely expand to
> > >> > encompass a number of the presentation processing 
> formats, ass the core
> > >> > representation mechanism we need something better.
> > >> >
> > >> > Hard to believe but I support Steve's commentary in this 100%
> > >> >
> > >> >
> > >> > Todd
> > >> > ----- Original Message -----
> > >> > From: Stephen Kent <[email-masked]>
> > >> > To: Anders Rundgren <[email-masked]>
> > >> > Cc: <[email-masked]>
> > >> > Sent: Wednesday, July 07, 1999 3:04 PM
> > >> > > Anders,
> > >> > > We have heard from others who work for large 
> companies who use the
> > >> > > technology base that you cite as unable to process 
> ASN.1 structures,
> > >and
> > >> > > their comments are at odds with yours.
> > >> > >
> > >> > > Yes, there are a lot of folks who are enamored with 
> XML, as one would
> > >> > > expect of any new mechanism that has gotten so much hype in
> > >> > trade rags.  I
> > >> > > don't question the value of XML in some 
> applications, but given the
> > >> > > commitment we already have to ASN.1 in our protocols 
> and in the
> > >> > base cert
> > >> > > and CRL syntax, I don't see a good argument to change here.
> > >> > >
> > >> > > Barring more evidence to the contrary, we should 
> stick with ASN.1.
> > >> > >
> > >> > > Steve
> > >> > >
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
> > >
>

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 9 Jul 1999 01:23:30 +0100

Hi Kathy,

Comments in line

>
>Two reactions:
>
> Wrapping XML/XSL in ASN.1 encoding means implementations must deal with
>both 
> types of encoding.

That is true.  However, if the XML object for a certificate has a fixed OID there should
be no hard problems to generalize a certificate decoder.

> Is XSL encoding always unique or will there be a BER/DER-like problem?

So far as I know there are no such problems

/Anders

---

From: Michael Zolotarev <[email-masked]>
Date: Fri, 9 Jul 1999 11:38:09 +1000

>Actually if that is your intent,  I would think that the real win here is
>having a number of different cert representation formats that include
>ASN.1/BER-DER, Binary, XML, and SMIME, myself.

>and have the approved Cert Management Protocols support these
>inter-deployment interoperability issues directly.

Replying with your own question, Todd - what is the gain?

Should we just leave ASN.1 as the only cert format? And let another media to absorb it. So that let XML guys define a standard tag for ASN.1-encoded cert. And MIME to define content type for cert (or use degenerated PKCS7 with SMIME), etc, etc.

Anybody having troubles parsing ASN.1 - last week we had a lovely discussion about, didn't we?

Of course, it may worth considering profiling 'data-store' extensions for the X.509 Vxxx cert, to include a general type content, that can be XML, or anything.

Michael

---

From: Michael Zolotarev <[email-masked]>
Date: Fri, 9 Jul 1999 11:51:10 +1000

A little suggestion: please, can we be more considerate about the Subject of the mails? So we change it accordingly when the topic is changed? Otherwise it becomes more of a police detective's job to go through the discussion threads.

Thank you
Michael 

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Friday, July 09, 1999 10:24 AM
To: PKIX-List; Kathy Dally
Cc: William Z Pope; [email-masked]; Stephen Kent
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt

Hi Kathy,

Comments in line

/Anders

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 13 Jul 1999 05:59:30 (NZST)

Ben Laurie <[email-masked]> writes:

>OpenSSL/SSLeay itself failed to correctly construct SETs for years and no-
>one noticed.

There's one case where it might get noticed, in S/MIME signed attributes.  I
used to output them sorted by OID (which made debugging a lot easier) and it
turned out that there are some S/MIME clients which will check for correct
sorted SET's.  I think I've currently got it set up to sort by OID for debug
builds and by DER rules for release builds for the clients which check for
this.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 15 Jul 1999 02:05:08 (NZST)

Stephen Kent <[email-masked]> writes:

>Your sample may not be too representative, especially with respect to the 
>topic at hand.  Do you know what products were used to generate the certs?

I many cases I could guess based on the encoding bugs present (certain products
leave a signature (in the non-crypto sense) on the certs they generate based on
encoding bugs), in others it wasn't possible to tell.  I would hope the sample 
was representative of what's out there, the whole point of grabbing a random
sample of publicly-available certs was to test what was being used in the real
world.

>Also, were the errors in question encoding ones, relevant to this debate, or 
>did they have to do with the data values per se?

Mostly encoding ones, since I couldn't locate CA certs for many of the certs I
grabbed I never even got as far as checking whether the values themselves were
valid/consistent.

Peter.