Subject: Re: Who can help me?

From: [email-masked] (Peter Gutmann)
Date: Wed, 6 Dec 2000 04:48:57 (NZDT)

pki_wby_cn <[email-masked]> writes:

>Please tell me why I cannot got the correct result ????????

This question should be in some sort of FAQ since it comes up every month or
so, it should also be added to son-of-2459... here's the reply I posted the
last time it came up:

-- Snip --

The keyIdentifier is supposed to be an explicit value, not something which is
implicitly generated according to some particular formula.  That is, you get
the key ID by reading out of the extension whatever value is present there, not
by hashing something and taking that as the key ID.

(I don't know what range of certs you've worked with, but eventually you're
 going to run into key ID's which contain 32-bit values, 64 bit values which
 don't follow RFC 2459, ASCII strings, and who knows what else, so assuming you
 can implicitly create them will lead to problems).

-- Snip --

Peter.

---

From: Tim Polk <[email-masked]>
Date: Wed, 06 Dec 2000 16:56:46 -0500

Folks,

I have attached the tentative agenda for next week's PKIX sessions.   As 
usual, we have a rather full agenda.  Both days should be 
interesting;  we'll discuss the path validation protocols on Tuesday and 
XML on Wednesday.  In between, we'll cover the status of our twenty current 
I-Ds.

I am projecting a half hour for discussions on XML and PKI.  So far, Phil 
has requested time to describe XKMS.  If you would like to present under 
this general topic, please send me email.  I will try to get everyone some 
time to present their views.

Thanks,

Tim Polk

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 7 Dec 2000 09:36:24 +0100

Tim, 
What you are saying is that there _will_ be some kind of a PKIXML session (short but something at least) 
which I have asked Steve K to arrange in and off this list with no success. 

Unfortunately, I and few others cannot waste their precious time on things that are decided 
in the last minute with no previous information. As we have discussed this subject for a month 
or so, I am pretty disappointed on how PKIX handled this.  OK, maybe it is a "win" in somebody's 
view that the loudest PKI-XML proponent (who still insists that this is a _market_ thing as well) will
not be there... 

Anders

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 07 Dec 2000 13:33:51 +0100

> XML on Wednesday.  In between, we'll cover the status of our twenty current

The agenda says the WG Last call for Time Stamp Protocols draft (TSP) is
finished, and that the draft is now under Area Director Review.

What would be a tentative time-line until publication as an RFC, or until
attribution of a RFC number ?

---

From: Tim Polk <[email-masked]>
Date: Thu, 07 Dec 2000 09:31:49 -0500

Anders,

It is very important that we come to some consensus regarding how 
X.509-based PKIs can be integrated with XML-based clients.  This topic is 
in my opinion within the scope of our charter.  The PKIX WG has spent a lot 
of cycles on the list discussing this topic, so there is clearly 
interest.  It makes sense to deal with it as much as we can during the 
session.  I deferred this discussion to the end since it will consume any 
available time.

This is very different from a session on XML-based PKIs, where ASN.1 is 
never used.  That is the session I thought you were requesting, and it is 
well outside our charter.  It is not my role or Steve's to be organizing 
such a session.  To be honest, I personally believe that XML is an 
inappropriate encoding format for certificates (public key *or* attribute).

I am sorry you assumed we wouldn't discuss PKI and XML at all.  The 
discussion is incomplete if the "loudest PKI-XML proponent" (or opponent) 
is not present.

Tim

---

From: Polar Humenn <[email-masked]>
Date: Thu, 7 Dec 2000 10:10:24 -0500 (EST)

On Thu, 7 Dec 2000, Tim Polk wrote:

<snipped>

> To be honest, I personally believe that XML is an 

Forgive me, I'm just an academic. So, my I ask, what does the encoding
format really matter? And especially, why is XML "inappropriate" for
certificates?

Cheers,
-Polar

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[email-masked]       2-212 CST      
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 7 Dec 2000 16:19:12 +0100

Tim,
Thanx for the answer.
My idea was really that a BOF-like discussion should set the scope of PKIXML which
could be very humble (add an optional message syntax as in SVCP and see if
anybody likes it), to "rewriting it all XML".  The latter will surely happen some day if the
"trend" persists, but is unlikely to be priority #1, even for the loudest XML proponents.

BTW, I have just read the S2ML 0.7a draft which is like an XML replacement for PKIX-ACs
so the heat is already on [PKIX].

Regards
Anders Rundgren

---

From: Tim Polk <[email-masked]>
Date: Thu, 07 Dec 2000 12:00:08 -0500

Polar,

>format really matter? And especially, why is XML "inappropriate" for

I'm just a government hack, so take it for what it's worth:

The W3C describes XML as "the universal format for structured documents 
*and data* on the Web" (my emphasis).  One of the reasons given for putting 
data from into XML is that it "allows you, if necessary, to look at the 
data without the program that produced it."

Hmm.  I can accept XML for documents.  I can rationalize XML for 
human-readable data (e.g., spreadsheet data).  But certificates?  I don't 
want to read certificates, I want to process them efficiently.  This leaves 
us one "advantage" - it's the universal format.

I see tow major problems with XML as a near term solution for 
certificates.  Perhaps they can be resolved in the future, but they seem 
like issues today.

First, I believe that significant work remains to handle signed XML at 
all.   In its basic form, XML encoded documents can be modified without 
changing the document.  That breaks signatures.  Canonicalization 
techniques may fix that in the future, but they seem to be a major 
interoperability headache today.

Secondly, XML certificates are going to bring a significant increase in 
size.  One of the SPKI WG's premises was that X.509 certificates were too 
large already.   Some of the wireless folks consider this an issue as 
well.  How big do you expect an XML certificate to be?

I don't have a crystal ball, but it seems that ASN.1 DER encoding serves 
our purpose.  It has its warts, as Peter Gutmann's X.509 Style Guide 
demonstrates, but we know how to make it work.

Tim Polk

---

From: Aram Perez <[email-masked]>
Date: Thu, 07 Dec 2000 08:58:28 -0800

> format really matter? And especially, why is XML "inappropriate" for

I'm not an academic, and I really don't care if I have to use ASN.1 or XML
to transfer security related information. But I really would like to see an
answer to Polar's questions.

Feliz Navidad,
Aram Perez

---

From: Aram Perez <[email-masked]>
Date: Thu, 07 Dec 2000 09:25:17 -0800

Just for fun, I've attached the PKIX example #1 certificate converted from
ASN.1 to XML.

Enjoy,
Aram Perez

----------
From: Aram Perez <[email-masked]>
Date: Thu, 07 Dec 2000 08:58:28 -0800
To: PKIX <[email-masked]>
Subject: Re: PKIXML session.  Was: PKIX WG tentative agenda

Feliz Navidad,
Aram Perez

---

From: Tim Polk <[email-masked]>
Date: Thu, 07 Dec 2000 13:49:13 -0500

Jean-Marc,

The IESG process does not operate on a fixed schedule, so we really can't 
predict when an RFC number might be available.  The IETF process consists 
of repeated discussion and debate regarding the merits of a 
specification.  At any stage, we could conceivably discover a problem that 
needs to be resolved.  Every problem that is encountered will take 
additional time.

TSP has several hurdles to cross. Once the ADs are satisfied, TSP will 
still need to go through IETF Last Call, be approved by the IESG, and wait 
in the IETF editing queue.  After successfully completing this process, it 
will get an RFC number.  (Note that IETF Last Call is a minimum of two 
weeks, and documents seem to be spending at least a month in the editing 
queue.  Many documents spend more time in each stage.)

I expect TSP to go through the process rather cleanly.  My experience is 
that documents which survive PKIX itself are already fairly well scrubbed.

Tim Polk

---

From: [email-masked] (Terry Hayes)
Date: Thu, 07 Dec 2000 11:00:24 -0800

> format really matter? And especially, why is XML "inappropriate" for

At the end of the day, the encoding format doesn't really matter.  As 
long as the required data is included in the payload, and all the 
parties involved can decode and process the message, the desired results 
will be acheived.

However,  there currently is a widely deployed and useful infrastructure 
for certificates that uses ASN.1, DER and X.509 as the standard way of 
representing the payload.  There are applications and protocols that use 
this infrastructure such as TLS/SSL, S/MIME and even XMLDSIG that embed 
these existing formats.  There is infrastructure developed and deployed 
for generating these certificates.  There are standard interfaces to 
devices that provided mechanisms for dealing with X.509 certificates 
(I'm thinking of PKCS#11).

Why would you want to replace all of these just for the sake of "purity 
of XML"?

Terry

---

From: Ed Gerck <[email-masked]>
Date: Thu, 07 Dec 2000 11:19:49 -0800

Tim Polk wrote:

> <snip>
> changing the document.  That breaks signatures.

But not the document.  This is IMO good point #1 -- and you can always prove
that the document was signed.

> size.

This is just a question of proper compression.  The information capacity of
the certificate (viewed as a Shannon communication channel) versus its size
is not only a function of the pre-encoding used but also of the post-encoding.

So, this is IMO good point #2 -- you can reduce a XML certificate size *below* the
ASN.1 size.

> demonstrates, but we know how to make it work.

A Florida election official said the same the other day about chads and paper-ballots:
-- sometjing like "Now that every voter knows the problem, the system will be really
accurate. We can continue to use punch-cards".

But this is not the problem, is it?

Cheers,

Ed Gerck

---

From: Tim Polk <[email-masked]>
Date: Thu, 07 Dec 2000 15:08:06 -0500

Ed,

>that the document was signed.

I don't get it.  If the signature is broken, you cannot prove the document 
was signed.  All you know is that the signature does not verify.

>So, this is IMO good point #2 -- you can reduce a XML certificate size 

Much of the information cannot be compressed, though.  Keys and signatures 
should look like random data, so there shouldn't be much of a gain 
there.  If you compress the remaining parts, it won't be readable, and the 
client system has to implement special processing rules to obtain the 
needed information.  Hmm, sounds like decoding the ASN.1 to me.

>But this is not the problem, is it?

Point well taken, but I am not convinced that XML is simpler, clearer or 
more interoperable solution.  The difference with voting is that NIST 
identified these problems back in '88.  No one noticed or cared back then.

Thanks,

Tim

---

From: Ed Gerck <[email-masked]>
Date: Thu, 07 Dec 2000 14:20:16 -0800

Tim Polk wrote:

> Ed Gerck wrote:

If XML encoded documents can be modified without changing the
document, then presenting one XML encoded document which has
a valid signature is enough to allow any number of documents equal
to that one to be verified -- irrespective of their XML encoded form.

In other words, if F: X --> Y is a mapping between two sets X and Y
such that several different x in X have the same image y0 in Y, then presenting
a valid signature for one x0 is enough, together with a certified F, to certify all
other x that have the same image as the certified x0 mapped by the certified F,
which is y0.

> there.

The same happens with ASN.1, so both are tied for anything that is random.
But anything else can be compressed and presents a benefit for compressed
XML over ASN.1.

>  If you compress the remaining parts, it won't be readable, and the

Except that the transmitted data can be smaller, which is the point here --
when you mention size as a prime factor. But you can always trade-off for
speed and not compress at all, or compress with a simpler method.

> identified these problems back in '88.  No one noticed or cared back then.

and in 89, 90, 91, 92, ... 99 when the problem again raised its ugly head
and was again mentioned.  But paper printing is a good business and
in the name of "current implementations" the situation grew worse,
at the cost of $3 to $7 dollar per cast vote.

Some parallels can be drawn with the present case, I am sure, even though
a certificate costs between $30 to $300 and there is no paper involved. In the
good name of "current implementations", change is stalled. But reality knocks
on the door, sooner or later.  The King is nude in elections.

Now, with more and more of our economy depending on digital certificates and
almost-there-but-not-quite PKI technology, it is my opinion that we cannot yet
block innovation in name of business, or a "preferred encoding".

This PKIX WG should support a subgroup that could avoid the usual mistakes
and may provide us with more markets, not less markets -- more uses, not less uses.

Just my opinion, of course.

Cheers,

Ed Gerck

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 8 Dec 2000 13:18:15 +1100

> -----Original Message-----
> From: Aram Perez [mailto:[email-masked]]
> Sent: Friday, 8 December 2000 4:25
> To: PKIX
> Subject: FW: PKIXML session. Was: PKIX WG tentative agenda
>
>

That's one way to encode a certificate in XML, but not a method I find
particularly appealing. The following XML encoding of the same certificate
is my best guess (possibly way off) at what represents current thinking on
the ASN.1 group's XML encoding rules mailing list. I would name the elements
in a SET OF or SEQUENCE OF differently, but that is an argument for a
different forum.

<Certificate>
  <toBeSigned>
    <version>
      v3
    </version>
    <serialNumber>
      17
    </serialNumber>
    <signature>
      <algorithm>
         { 1 2 840 10040 4 3 }
      </algorithm>
    </signature>
    <issuer>
      <rdnSequence>
        <RelativeDistinguishedName>
          <AttributeTypeAndValue>
            <type>{ 2 5 4 6 }</type>
            <value>US</value>
          </AttributeTypeAndValue>
        </RelativeDistinguishedName>
        <RelativeDistinguishedName>
          <AttributeTypeAndValue>
            <type>{ 2 5 4 10 }</type>
            <value>gov</value>
          </AttributeTypeAndValue>
        </RelativeDistinguishedName>
        <RelativeDistinguishedName>
          <AttributeTypeAndValue>
            <type>{ 2 5 4 11 }</type>
            <value>nist</value>
          </AttributeTypeAndValue>
        </RelativeDistinguishedName>
      </rdnSequence>
    </issuer>
    <validity>
      <notBefore>
        970630000000Z
      </notBefore>
      <notAfter>
        971231000000Z
      </notAfter>
    </validity>
    <subject>
      <rdnSequence>
        <RelativeDistinguishedName>
          <AttributeTypeAndValue>
            <type>{ 2 5 4 6 }</type>
            <value>US</value>
          </AttributeTypeAndValue>
        </RelativeDistinguishedName>
        <RelativeDistinguishedName>
          <AttributeTypeAndValue>
            <type>{ 2 5 4 10 }</type>
            <value>gov</value>
          </AttributeTypeAndValue>
        </RelativeDistinguishedName>
        <RelativeDistinguishedName>
          <AttributeTypeAndValue>
            <type>{ 2 5 4 11 }</type>
            <value>nist</value>
          </AttributeTypeAndValue>
        </RelativeDistinguishedName>
      </rdnSequence>
    </subject>
    <subjectPublicKeyInfo>
      <algorithm>
        <algorithm>{ 1 2 840 10040 4 1 }</algorithm>
        <parameters>
          <p>
            d43802c5357bd50ba17e5d72596355d3
            4556eae2251a6bc5a4abaa0bd462b4d2
            21b195a2c601c9c3fa016f7986833d03
            61e1f192acbc034e89a3c9534af7e2a6
            48cf421e21b15c2b3a7fbabe6b5af70a
            26d88e1bebecbf1e5a3f45c0bd3123be
            6971a7c290fea5d680b524dc449ceb4d
            f9daf0c8e8a24c99075c8e352b7d578d
          </p>
          <q>
            a7839bf3bd2c2007fc4ce7e89ff33983510ddcdd
          </q>
          <g>
            0e3b46318a0a58864084e3a1220d88ca
            908857649f0121e01505942482e21090
            d9e14e105ce7546bd40c2b1b590aa0b5
            a17db507e3657cea90d88e3042e485bb
            acfa4e764b780edf6ce5a6e1bd59777d
            a69759c529a7b33f953e9df1592df742
            87623ff1b86fc73d4bb88d74c4ca4490
            cf67dbde1460974ad1f76d9e0994c40d
          </g>
        </parameters>
      </algorithm>
      <subjectPublicKey>
        028180aa98ea1394a2dbf15b7f982f78
        e7d8e3b97186f6802f4039c3da3b4b13
        4626ee0d56c5a33a39b77d33c26b5c77
        92f255659039cd1a3c86e132eb25bc91
        c4ff804f3661bdcce26104e07e6013ca
        c09cdde0ea41de33c1f144a9bc71decf
        59d46eda44993c2164e478549dd07bba
        4ef5184d5e3930bfe0d1f6f483254f14
        aa71e1
      </subjectPublicKey>
    </subjectPublicKeyInfo>
    <extensions>
      <Extension>
          <extnId>
          { 2 5 29 19 }
        </extnId>
        <critical>
          TRUE
        </critical>
        <extnValue>
          30030101ff
        </extnValue>
      </Extension>
      <Extension>
        <extnId>
          { 2 5 29 14 }
        </extnId>
        <extnValue>
          0414e726c554cd5ba36f356895aad5ff1c21e42275d6
        </extnValue>
      </Extension>
    </extensions>
  </toBeSigned>
  <algorithmIdentifier>
    <algorithm>
      { 1 2 840 10040 4 3 }
    </algorithm>
  </algorithmIdentifier>
  <encrypted>
    302c0214a066c176339913518d93642f
    ca1373de791a7d3302145d90f6ce924a
    bf2911248028a65a8e73b6760268
  </encrypted>
</Certificate>

Regards,
Steven

---

From: Aram Perez <[email-masked]>
Date: Thu, 07 Dec 2000 18:29:28 -0800

Hi Steven,

I should have stated, "I've attached the PKIX example #1 certificate
converted from BER/DER to XML.

Regards,
Aram Perez

> From: Steven Legg <[email-masked]>
> Reply-To: [email-masked]
> Date: Fri, 08 Dec 2000 13:18:15 +1100
> To: 'Aram Perez' <[email-masked]>, 'PKIX' <[email-masked]>
> Subject: RE: PKIXML session.  Was: PKIX WG tentative agenda
> 
> 
>

---

From: Juergen Brauckmann <[email-masked]>
Date: Fri, 08 Dec 2000 08:32:33 +0100

> other x that have the same image as the certified x0 mapped by the certified F,

So we can have an F() which transforms any pattern "$10 " into a "$1000
" for any given XML documents, so that a document verifies with $10 and
with $1000? Yes, this sounds really useful for signed documents;-)

Sorry, couldn't resist... .
 
> But anything else can be compressed and presents a benefit for compressed

You can compress your ASN.1 data too. "Compressed XML" is IMHO no
standard or RFC, just like there is no "Compressed ASN.1". When you
compress you DER certificates, they will be smaller than compressed XML
structures. For normally sized DNs  I even doubt that compressed XML
would be smaller than uncompressed ASN.1.

> block innovation in name of business, or a "preferred encoding".

Nobody wants to block innovation. The question is wether XML
certificates really would be an innovation. One example: It seems to be
necessary to define and use Transformations or C14N methods for any XML
signed data (for XML certificates that would be necessary too). The
Transformations are an *additional* processing step, where all kinds of
things can go wrong. This alone looks like a disadvantage regarding
interoperability and ease of implementation. And I guess that other
people have many more concerns about XML signatures.

Regards,
   Juergen

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 08 Dec 2000 09:14:27 +0100

Tim,

> still need to go through IETF Last Call, be approved by the IESG, 

Wake-up ! Last call at the IESG level has already been performed on Monday,
28 Aug 2000

Here is the quoted E-mail:

" The IESG has received a request from the Public-Key Infrastructure
(X.509) Working Group to consider Internet X.509 Public Key
Infrastructure Time Stamp Protocols (TSP)
<draft-ietf-pkix-time-stamp-09.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by September 8, 2000."

Denis

> and wait

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 08 Dec 2000 10:20:30 +0100

Denis Pinkas wrote:

> > predict when an RFC number might be available.

My question had the key words "would", "tentative".
I'm aware nothing can be garanteed.

> Wake-up ! Last call at the IESG level has already been performed on Monday,

That's not what you want to hear, Denis, but did not the edition of a revised version
reset this and mean that there must be a new last call even if the changes are minors
?

> > that documents which survive PKIX itself are already fairly well scrubbed.

Thank you.
A best case time line and an opinion on whether it should go cleanly or not is all I
was expecting.

---

From: Tim Polk <[email-masked]>
Date: Fri, 08 Dec 2000 09:19:27 -0500

Denis,

Thanks for the reminder!  I was simply using the IESG status listing, which 
still says "Under AD Review".  That reduces the timeline a bit...

Tim

---

From: Tim Polk <[email-masked]>
Date: Fri, 08 Dec 2000 09:39:08 -0500

Jean-Marc,

The changes in the last edition of TSP were the result of minor comments 
received during Last Call.  The changes do not require recycling at IETF 
Last Call.

Thanks,

Tim

---

From: Ed Gerck <[email-masked]>
Date: Fri, 08 Dec 2000 10:48:52 -0800

> Sorry, couldn't resist... .

I am glad you did not.  If you have a certified F() that transforms "$10" in US Dollars
to "$1000" in another currency, this might be really useful.  So, even though this
is not the case here (because we are talking about control codes, not values), it
could well be useful also for values.

The bottom line is that if F() is certified between two sets, that F() is useful to
connect a certified x0 in X to a y0 in Y which then becomes certified.

> structures.

Wait.  This is a general affirmation, and so it is probably false. But, please
prove it.

Cheers,

Ed Gerck

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Fri, 08 Dec 2000 15:09:30 -0500

> in a SET OF or SEQUENCE OF differently, but that is an argument for a

Steven,

I can't speak for everyone involved in the ASN.1/
XML work, but this is a very good guess as to where
we seem to be headed. But there are many particulars 
still to be discussed and resolved and many different
opinions to consider. 

For example, the representation of OID values has
spawned a great deal of discussion. While I have
favored <tag>1.2.3.4</tag> that mimics the notation
used in LDAP, other prefer the ASN.1 value notation
format that you've used below. But there is also some
sentiment for relying on the urn:oid work currently 
being progressed in the IETF, as well as proponents
of the <tag>iso(1) identified-organization(3)</tag>
style format.

And that's just one small issue. The work plan has 
just been announced and is scheduled for 22 January
through 2 February 2001, in Geneva, Switzerland. For
anyone that is interested, they might wish to monitor
the discussion list at [email-masked], as the details 
of this work are probably a bit off topic for pkix.

I would comment though that the benefit of this new
notation is obscured somewhat by the examples being
used. Certificates are not very interesting to look
at for most humans in any format and seem to be at 
their best in a small, efficient binary format that
is mechanically processed. Only a few of their parts
have much use as display items. 

These examples do serve to illustrate how verbose tagged
text formats can be. But what will be more beneficial to
consider for ASN.1 users I believe, will be the ability
to generate default ASN.1 specified XML mark up for the 
likes of protocol messages, say perhaps the request and 
response messages specified in tools such as OCSP. 

Phil