Subject: Should PKIX protocols support XML well

From: Ambarish Malpani <[email-masked]>
Date: Fri, 10 Nov 2000 11:08:48 -0800

There are a bunch of industries/communities that are using XML
throughout their systems - all their messages are in XML, all
their development is in XML and XML is their chosen future
direction.

We may or may not agree about whether this is a wise decision, but
that decision has been made and is one that we (PKIX) can not
change.

Now the question is, do we try and support such groups in their
efforts or do we say: "Sorry, we think you did the wrong thing
by not picking ASN.1, so go figure out how to do public key
cryptography by yourself - we won't help"

My personal bias is that if a significant percent of the world
is headed towards XML, it makes more sense for us to support that
group and make sure that when they do PKI, they do it in a
secure way, rather than ignore that world and have them do PKI
either insecurely, or in n different ways. After having seen
different standards groups, I am quite convinced that IETF
actually do a pretty good job with their specifications and the
thoroughness with which specifications are reviewed. I think it
is our responsibility to help set the standards so that people
can use them in most significant environments, rather than have us
ignore the issue and have people not only do it in less secure
ways, but also have different groups do the same job in
different ways.

[Note: I am not trying to say that IETF should set all standards
in the world, but it does need to acknowledge and react to the
needs of large and diverse groups. And the XML community is one
such group].

Comments?
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

---

From: "Jeff Davis" <[email-masked]>
Date: Sat, 11 Nov 2000 13:56:49 -0000

Ambarish,

I for one totally agree with you.  We use XML extensively and wish to
move into using PKI within our development.  If we could do that within
XML life would be that much better for us.

Jeff

---

From: Timothy Fisher <[email-masked]>
Date: Sat, 11 Nov 2000 17:28:12 -0500

Ambarish,

I support your comments and think they they are well put...

Outside of the IETF, I know from personal experience that there is
a growing opinion that the PKI standards based on ASN1 are "behind the
times."  Those of you who don't agree with that statement, please
don't argue the point to me, I am simply conveying what I feel is a
growing opinion.

The IETF would be wise to consider XML in future PKI work...

-- 
Sincerely,
 Timothy Fisher                       mailto:[email-masked]

Friday, November 10, 2000, 2:08:48 PM, you wrote:

AM> There are a bunch of industries/communities that are using XML
AM> throughout their systems - all their messages are in XML, all
AM> their development is in XML and XML is their chosen future
AM> direction.

AM> We may or may not agree about whether this is a wise decision, but
AM> that decision has been made and is one that we (PKIX) can not
AM> change.

AM> Now the question is, do we try and support such groups in their
AM> efforts or do we say: "Sorry, we think you did the wrong thing
AM> by not picking ASN.1, so go figure out how to do public key
AM> cryptography by yourself - we won't help"

AM> My personal bias is that if a significant percent of the world
AM> is headed towards XML, it makes more sense for us to support that
AM> group and make sure that when they do PKI, they do it in a
AM> secure way, rather than ignore that world and have them do PKI
AM> either insecurely, or in n different ways. After having seen
AM> different standards groups, I am quite convinced that IETF
AM> actually do a pretty good job with their specifications and the
AM> thoroughness with which specifications are reviewed. I think it
AM> is our responsibility to help set the standards so that people
AM> can use them in most significant environments, rather than have us
AM> ignore the issue and have people not only do it in less secure
AM> ways, but also have different groups do the same job in
AM> different ways.

AM> [Note: I am not trying to say that IETF should set all standards
AM> in the world, but it does need to acknowledge and react to the
AM> needs of large and diverse groups. And the XML community is one
AM> such group].

AM> Comments?
AM> Ambarish

AM> ---------------------------------------------------------------------
AM> Ambarish Malpani
AM> Architect                                                650.567.5457
AM> ValiCert, Inc.                                  [email-masked]
AM> 339 N. Bernardo Ave.                          http://www.valicert.com
AM> Mountain View, CA 94043

---

From: Surendra K Reddy <[email-masked]>
Date: Sat, 11 Nov 2000 15:23:53 -0800 (PST)

I do agree with both of you on this. Around 2 years back, I have 
implemented PKIX operational protocols using XML(XSN.1 -- XML
Syntax Notation 1) encoding as a proof of concept and I also 
submitted a draft to ietf called WebCAP. There was a push back from PKIX
working group supporting XML based PKIX protocols. Now XML being used in
every sort of application, It is critical to support the effort to
standardize PKIX/XML.

Surendra Reddy
(650) 506 5441

---

From: "Peter Lipp" <[email-masked]>
Date: Mon, 13 Nov 2000 13:55:57 +0100

>either insecurely, or in n different ways.

I agree. And I fear if there is nothing on the horizon rather fast, we will
see several versions of things like e.g. XML-based certificates shortly. The
question is who will take the responsibility to head this? W3C having XML
under control? IETF having PKI-experience? A joint effort like with XMLDSig
seems optimal!

Peter

---

From: Paul Koning <[email-masked]>
Date: Mon, 13 Nov 2000 13:39:16 -0500 (EST)

>>>>> "Timothy" == Timothy Fisher <[email-masked]> writes:

 Timothy> Ambarish,

 Timothy> I support your comments and think they they are well put...

 Timothy> Outside of the IETF, I know from personal experience that
 Timothy> there is a growing opinion that the PKI standards based on
 Timothy> ASN1 are "behind the times."  Those of you who don't agree
 Timothy> with that statement, please don't argue the point to me, I
 Timothy> am simply conveying what I feel is a growing opinion.

 Timothy> The IETF would be wise to consider XML in future PKI work...

If the basis of that desire is religious bias, which is what phrases
like "behind the times" suggests, then I see no merit in this.

On the other hand, if there are technical benefits, that's different.
Certainly I'm no fan of BER (don't know DER as well).  But if the best
argument against this set of standards is that they are old fashioned,
that's not an argument with merit.  Growing opinion or not -- that
doesn't matter.

	paul

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Nov 2000 14:04:29 -0500

Ambarish,

XML has various benefits for representing certain kinds of data, but 
none of those seem especially relevant to the encoding of certs or 
CRLs. Moreover, at a time when people in various quarters (e.g., 
wireless folks) complain about the size of certs, it would not seem 
especially appropriate to adopt an XML encoding, which would increase 
the size of these data items.

I am not persuaded by comments that allude only to the "trendiness" 
of XML vs. ASN.1 encoding, as several others have pointed out. PKIX 
was started as a profiler of X.509 protocols, and we have expanded 
our charter to create new protocols that support X.509 certs and 
which seem appropriate to PKI use in the Internet. That makes it hard 
to justify developing new syntax for existing data structures, as 
noted above.  However, as Russ pointed out, standards for carriage of 
certs and CRLs (ASN.1 encoded) in an XML context are not out of the 
question.

Steve

---

From: Russ Housley <[email-masked]>
Date: Mon, 13 Nov 2000 17:00:16 -0500

Steve:

I agree with both of your points.  However, XML-enabled clients are of 
interest when those clients are using XML digital signatures.

I would like to see a solution where clients that are prepared to deal with 
ASN.1 can get a signed response in the CMS format (RFC 2630), and clients 
that are prepared to deal with Signed XML can get a response in that 
yet-to-be-finalized format.

Further, the XML client should be able to treat the X.509 certificate as an 
octet blob.  They simply pass the certificate to the trusted server, and 
the server returns a signed testament that the certificate is valid, the 
public key, and alt names.  There may be other fields that should be 
returned, but we need to explore this model further to understand what they 
might be.

Russ

At 02:04 PM 11/13/2000 -0500, Stephen Kent wrote:
>Ambarish,
>
>XML has various benefits for representing certain kinds of data, but none 
>of those seem especially relevant to the encoding of certs or CRLs. 
>Moreover, at a time when people in various quarters (e.g., wireless folks) 
>complain about the size of certs, it would not seem especially appropriate 
>to adopt an XML encoding, which would increase the size of these data items.
>
>I am not persuaded by comments that allude only to the "trendiness" of XML 
>vs. ASN.1 encoding, as several others have pointed out. PKIX was started 
>as a profiler of X.509 protocols, and we have expanded our charter to 
>create new protocols that support X.509 certs and which seem appropriate 
>to PKI use in the Internet. That makes it hard to justify developing new 
>syntax for existing data structures, as noted above.  However, as Russ 
>pointed out, standards for carriage of certs and CRLs (ASN.1 encoded) in 
>an XML context are not out of the question.
>
>Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 14 Nov 2000 00:35:54 +0100

Steve,

> CRLs.

Agreed, assuming we talk PKCs.  ACs are rather different creatures as they
are functionally comparable to "messages", featuring a possibly dynamic, application-specific,
information-rich content, that is to be fully digested (by the application) and acted upon, in 
contrast to static PKCs that usually only identify an entity.  And each AC "message type" would
benefit *tremendously* by being expressed as a *unique* XML schema instead of being "squeezed"
into the current "one-size-fits-all try-to-guess-this-ac-profile" approach.

> Moreover, at a time when people in various quarters (e.g., 

These guys have so far had practically zero success in deployment due to high
traffic costs and slow transmission.  I would not consider their arguments
that important when the general expectancy is streaming multimedia in our phones
next year or so.  In that perspective PKIX structures look real neat and tiny.

<snip>

Regards
Anders

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Nov 2000 08:55:51 -0500

>into the current "one-size-fits-all try-to-guess-this-ac-profile" approach.

Although ACs are generally assumed to be more dynamic than PKCs, but 
different usage models call for different validity intervals.  Thus I 
don't agree that they are as message like as you suggest. The 
XML-based schema you suggest would be more flexible, and arguably 
less interoperable. Also, we have lots of examples of how more 
dynamic, more flexible aspects of applications lead to security 
problems, e.g., the many e-mail attacks based on scripting 
capabilities. So, flexibility has it downside in security contexts.

>next year or so.  In that perspective PKIX structures look real neat and tiny.

I have not considered their arguments too seriously, for various 
reasons, but I use those arguments as an example of the wide range of 
often conflicting "requirements" that are proposed.

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 14 Nov 2000 18:14:01 +0100

Steve,

>Although ACs are generally assumed to be more dynamic than PKCs, but different usage models
>call for different validity intervals. Thus I don't agree that they are as message like as you suggest.
>The XML-based schema you suggest would be more flexible, and arguably less interoperable. 

Here we apparently differ.  IMO AC are potentially *extremely* application-dependent
which makes interoperability an entirely different story than for PKCs.

That an AC-app using "my" scheme would reject anything that does not *exactly* match a
(usually very limited) set of known AC-app-specific schemas is *by design*.  I.e. there is no
(will not be is probably more correct), such thing as a generic AC application.

There can (and should) still be a framework but it should be split into a standardized part and
one which is entirely application-defined.  Then you can create a generic AC reader/verifier.

BTW, take a look on the postings

"With XML-ACs extensions become unnecessary"

                and

"XML-AC - Sample Java Code"

Anders

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Nov 2000 21:56:09 -0500

Anders,

>which makes interoperability an entirely different story than for PKCs.

We have traditionally use standard access control mechanisms in 
operating systems to provide a basis for access controls for a 
variety of applications. Having a consistent basis for AC helps 
reduce design and implementation vulnerabilities. Our disagreement is 
with regard to where the commonality ends. You suggest that a common 
language (XML) suffices, while AC advocates argue for a common 
language (ASN.1), syntax, and base semantics.

>(will not be is probably more correct), such thing as a generic AC 

This does nothing to protect against intentional attacks, since such 
attackers are presumed capable of matching the syntax on per 
application basis, although it might help with accidental "attacks."

>generic AC reader/verifier.

Again, it's a difference of opinion of where the common layer should terminate.

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 15 Nov 2000 09:46:50 +0100

Steve,

----- Original Message ----- 
From: "Stephen Kent" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 15, 2000 03:56
Subject: Re: Should PKIX protocols support XML well

> application basis, although it might help with accidental "attacks."

Using an XML schema you know when you are going to act on received data that:
- The elements that the app "knows" are there.  No more, no less
- The elements have the proper format.  I.e. no a 100k strings if the schema says 80

And you get this for free.  No coding whatsoever.

That ought to be *more* secure than trying to "decipher" potentially arbitrary ASN.1 extensions.

To add executable script code to XML would indeed introduce a security hole, but why
would you do that in the context of ACs?

Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 15 Nov 2000 10:48:29 +0100

This conversion of things to XML from ASN.1 is IMO not that interesting as XML in itself 
(except for being "trendy", "free", and "human readable") does not offer any advantages
over ASN.1.  Rather adds som disadvantages like bloated size.

It is sad, some XML "marketers" even claim that XML solves semantics as well (using "magic"),
but they are dead wrong!

But if you use XML *schemas* you could also:

- Immediately recognize the message type by its schema name as found by the parser. You could
even dispatch the parsed message to various apps directly based on found message type!
Schema=>Application=>Implict semantics.

- Have the parser automatically check that all expected elements are there (no more, no less), and
fully conform to their format and possible restrictions (i.e. not 100K UserIDs etc.)  Supporting standardized
diagnostics like: "Address" field too long.  Missing "Session ID" tag etc.

- Let each "application profile" have it own schema.  As in BizTalk.  And let applications evolve in
their own pace.  Much simplier (and futureproof) than trying to squeeze in things like it is done in AC.

- Have "wizards" generate access class objects directly from the XML app-schema if you want.  Click
on the fields of interest and you are there!  That is a quantum leap above trying to decode arbitrary
extension at application level (well, to be honest, I am pretty old-fashioned and seldom use wizards but all
"new" people seem very thrilled by such tools...).

- Let you [automatically] verify that your output conforms to the spec.  Just to be a nice guy.

So IMO, ACs and similar which I consider very application-specific (*not* PKCs), would benefit
tremendously by being split into a header document and an application document using schemas
to avoid extensions and app-level parsing completely.

Unfortunately the XML schema route does not have an ASN.1 counterpart. A truly one-way-street.

Off-list I have been adviced to start a new WG to avoid these time-wasting ASN.1 - XML wars.  
Is that maybe the general feeling?  How do I proceed?

Regards
Anders Rundgren

---

From: Stephen Kent <[email-masked]>
Date: Wed, 15 Nov 2000 12:42:51 -0500

Anders,

>- The elements have the proper format.  I.e. no a 100k strings if 

This is also enforced by ASN.1 compiler-generated structure decoding 
code, so there's no feature difference here.

>And you get this for free.  No coding whatsoever.

No coding other than the DTD/schema defintion, I presume, which is 
equivalent to writing the ASN.1 syntax definition.

>arbitrary ASN.1 extensions.

One does not "try to decipher" extensions. Either one knows the 
extension syntax, or one does not, and the extension is uniquely 
identified bu=y an OID. If one does not know the OID, one skips the 
extension. If one does know the syntax, the ASN.1 code decodes the 
extension, and if there is a syntax error, i.e., if the data does not 
match the syntactic definition, the decoding routine returns an 
indication of the error.

>would you do that in the context of ACs?

I think you misunderstood my analogy. Never mind.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 15 Nov 2000 12:45:05 -0500

Anders,

If your goal is to create a competing technology serving the same 
function as ACs, but based exclusively on XML, then I think it might 
be appropriate to create a new WG.  Contact the Security ADs.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 15 Nov 2000 13:50:49 -0500

Russ,

>Steve:
>
>I agree with both of your points.  However, XML-enabled clients are 
>of interest when those clients are using XML digital signatures.
>
>I would like to see a solution where clients that are prepared to 
>deal with ASN.1 can get a signed response in the CMS format (RFC 
>2630), and clients that are prepared to deal with Signed XML can get 
>a response in that yet-to-be-finalized format.

>Further, the XML client should be able to treat the X.509 
>certificate as an octet blob.  They simply pass the certificate to 
>the trusted server, and the server returns a signed testament that 
>the certificate is valid, the public key, and alt names.  There may 
>be other fields that should be returned, but we need to explore this 
>model further to understand what they might be.
>

That seems reasonable based on your examples, but how do you want to 
translate this into a standards requirement? If we made support for 
ASN.1 or XML formats mandatory and the other optional it would 
disadvantage one class of clients or the other. We can have two 
distinct standards and let vendors choose which one to support, but 
do we do that for both clients and servers, or do we plave the burden 
on servers to support both forms of requests and to generate both 
forms of responses?

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 15 Nov 2000 20:39:32 +0100

Steve,

> code, so there's no feature difference here.

I know, but it is pretty to hard to do anything concering attributes already defined
in the AC draft.  I.e. if your app would like passwords to be max 80
bytes you must perform this check at application-level (or rewriting AC).

Using XML app-schemas you would not do that.   Well, somebody have to write
the app-schema.  ONCE. And will contain just the stuff needed for that app.
If the "ASN.1 camp" can do distributable app-shemas, fine.  It is odd though that they
currently don't except at laboratory level.  The "XML camp" do this in production.  Today.

Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 15 Nov 2000 20:51:47 +0100

Steve,
 
> be appropriate to create a new WG.  Contact the Security ADs.

The goal is not to create a "competing" technolgy.  But to build new exciting things
on the platform that many believe has a better chance to become mainstream than the
current one.

The scope would certainly not be restricted to ACs, but it could be a good "starter".

Anders

---

From: Paul Koning <[email-masked]>
Date: Wed, 15 Nov 2000 17:03:52 -0500 (EST)

>>>>> "Anders" == Anders Rundgren <[email-masked]> writes:

 Anders> Steve,
 >> >Using an XML schema you know when you are going to act on
 >> received data that: >- The elements that the app "knows" are
 >> there.  No more, no less >- The elements have the proper format.
 >> I.e. no a 100k strings if >the schema says 80
 >> 
 >> This is also enforced by ASN.1 compiler-generated structure
 >> decoding code, so there's no feature difference here.

 Anders> I know, but it is pretty to hard to do anything concering
 Anders> attributes already defined in the AC draft.  I.e. if your app
 Anders> would like passwords to be max 80 bytes you must perform this
 Anders> check at application-level (or rewriting AC).

Or you just tweak the standard ASN.1 file before submitting it to the
compiler.  That's generally the easiest solution.

 Anders> Using XML app-schemas you would not do that.  Well, somebody
 Anders> have to write the app-schema.  ONCE. And will contain just
 Anders> the stuff needed for that app.  If the "ASN.1 camp" can do
 Anders> distributable app-shemas, fine.  It is odd though that they
 Anders> currently don't except at laboratory level.  The "XML camp"
 Anders> do this in production.  Today.

If the schema is already defined before you discover the need to
implement the restriction, don't you have the same problem?

If you're going to compare meaningfully, you must compare new files of
type A with new files of type B, not old (already frozen) files of
type A with newly written files of type B.

     paul

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 16 Nov 2000 00:03:33 +0100

Paul,

> implement the restriction, don't you have the same problem?

The app-developer community (not PKIX) defines in (an hopefully) collaborative way 
*exactly* what their particular app needs so I really don't understand the question. 

Such a community can be a person, a nation, an organization, whatever. 

If somebody needs a restriction they must ask the appropriate community for a revision 
(=new schema) instead of imposing a local restriction that would break every now and then
when fed with other's (potentially unrestricted) data. 

If they only use things locally they define their own schema = app. By *design* auto-rejects 
anything else. 

At the same time extremely rigid, extremely flexible, *and* secure. 

Clearances, userids, authorizations, tickets, coupons etc. IMO benefit by such a model.
Yes, I know that this is contrary to the golden rule: Be tolerant with what you receive, be strict
with what you send.

Using schemas you [the app community] can be as strict (or sloppy if that is what you want), as required by
the app.  The lower limit is that you don't accept data based on a schema "you are not programmed for".

Below is a revised AC showing "in principle" what I suggest (although I would skip ASN.1 completely):

           AttributeCertificate ::= SEQUENCE {
                acinfo               AttributeCertificateInfo,
                signatureAlgorithm   AlgorithmIdentifier,
                signatureValue       BIT STRING
           }

           AttributeCertificateInfo ::= SEQUENCE {
                version              AttCertVersion DEFAULT v1,
                holder               Holder,
                issuer               AttCertIssuer,
                signature            AlgorithmIdentifier,
                serialNumber         CertificateSerialNumber,
                attrCertValidityPeriod   AttCertValidityPeriod,
// PKIX:
                attributes           SEQUENCE OF Attribute,
// XML-AC: 
                attributes           embedded-XML-data-using-a-unique-identifyable-app-defined-attribute-schema, 
                                                 // No predefined attributes (or extensions) whatsoever

                issuerUniqueID       UniqueIdentifier OPTIONAL,

// The following would (if it would stay at all) refer to extensions of the generic (container) part
                extensions           Extensions OPTIONAL
           }

Anders

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Nov 2000 12:40:57 -0500

Anders,

>The scope would certainly not be restricted to ACs, but it could be 

We obviously define "competing" differently.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Nov 2000 18:34:05 -0500

Anders,

>received data that:

Based on your comments, it seems that most of the differences you see 
between ACs in ASN.1 and analogous structures in XML seems to hinge 
on the question of when one defines syntax for the structures. The 
two representations are obviously capable of supporting syntax agreed 
to well in advance and adopted by many apps, or syntax that has more 
app-specific scope.  So, this does not appear to be a good basis for 
distinguishing between the two.

Steve