Subject: encoding an X.509 certificate

From: "Tom Scavo" <[email-masked]>
Date: Thu, 6 Nov 2008 12:49:10 -0500

I've asked the following question in a number of forums with no luck.
I'm hoping someone with intimate knowledge of ASN.1 encodings can help
me out here.  Many thanks in advance.

Currently there are three profiles before the OASIS Security Services
Technical Committee (SSTC) that rely on XML elements of the form:

<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
 <ds:X509Data>
   <ds:X509Certificate>
MII...
   </ds:X509Certificate>
 </ds:X509Data>
</ds:KeyInfo>

Interestingly, the above element has sparked a vigorous debate within
the SSTC, which has since spread to the W3C XML Signature WG.  The
issue involves the ASN.1 encoding of the underlying certificate (which
is base64 encoded in the XML).  Specifically, should the certificate
be DER-encoded or should the encoding be left unspecified?

So my question is:  If you were given an X.509 certificate of unknown
encoding, could you determine the encoding by simply inspecting the
bytes?  Does your favorite ASN.1 library support such a function?

Thanks for shedding some light on this issue.

Tom Scavo
NCSA

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 6 Nov 2008 13:52:46 -0500

DER Vs Base 64 is not the correct trade-off.

An X.509 certificate is always DER encoded.

After that for transport, do you send this as binary or convert the
binary as base 64 is the trade-off.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Tom Scavo
Sent: Thursday, November 06, 2008 12:49 PM
To: pkix
Subject: encoding an X.509 certificate

Tom Scavo
NCSA

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 6 Nov 2008 20:02:05 +0100

Hi Tom,

It was fascinating to hear about a debate starting 7 years after the specification became finalized!

I can't really tell based on the XML Dsig but it appears that the interpretation is DER
http://java.sun.com/j2se/1.5.0/docs/api/java/security/cert/Certificate.html#getEncoded()
since this is the only decoding available, in at least in standard Java.

Presumably other decodings are incompatible with existing libraries as well.

I would call this a de-facto standard for XML.

Regards
Anders

----- Original Message ----- 
From: "Tom Scavo" <[email-masked]>
To: "pkix" <[email-masked]>
Sent: Thursday, November 06, 2008 18:49
Subject: encoding an X.509 certificate

Tom Scavo
NCSA

---

From: "Perez, Aram" <[email-masked]>
Date: Thu, 6 Nov 2008 11:05:35 -0800

Hi Tom,

> be DER-encoded or should the encoding be left unspecified?

RFCs 3280 and 5280 clearly state in section 4.1: "The X.509 v3 certificate
basic syntax is as follows.  For signature calculation, the data that is to
be signed is encoded using the ASN.1 distinguished encoding rules (DER)
[X.690].  ASN.1 DER encoding is a tag, length, value encoding system for
each element."

> bytes? 

I've never seen an X.509 certificate that is not DER encoded but I'm sure I
may have miss those encoded differently.

> Does your favorite ASN.1 library support such a function?

My BERViewer application (<http://homepage.mac.com/aramperez>) will display
any BER/DER encoded file but it does not tell you the encoding. May Peter
Gutmann's dumpasn1 (<http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>)
does.

Regards,
Aram Perez

---

From: "Tom Scavo" <[email-masked]>
Date: Thu, 6 Nov 2008 14:13:58 -0500

> DER Vs Base 64 is not the correct trade-off.

Sorry, I didn't make that very clear.  The XML Signature spec says the
certificate is base64 encoded before it is inserted in the XML but it
says nothing about the encoding of the underlying certificate, so the
question is, what ASN.1 encoding should be applied to the certificate
before it is base64 encoded?

> An X.509 certificate is always DER encoded.

That is the answer I was looking for, yes (although not everyone seems
to agree).

> binary as base 64 is the trade-off.

The certificate is always base64 encoded before it is inserted in the XML.

Thanks!

Tom

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 6 Nov 2008 14:21:19 -0500

There is no header ("magic bits") at the beginning of an encoded
transfer string, so there is not a deterministic mechanism for
determining an arbitrary encoding.  However, heuristically it is trivial
to examine a transfer string and determine that it is a) BER/DER/CER
encoded, b) XER endoded, or c) PER encoded.  In practice, if you were
given an X.509 certificate of unknown encoding, there is only one
encoding that it could possibly be (DER) because no other encoding is
ever used.  Because the signature is computed over the DER-encoded
transfer string, a certificate in any other format would need to be
re-encoded into DER before validating the signature, and that's too much
effort for most applications.

Dave

-----Original Message-----

Tom Scavo
NCSA

---

From: "Tom Scavo" <[email-masked]>
Date: Thu, 6 Nov 2008 14:25:00 -0500

> It was fascinating to hear about a debate starting 7 years after the specification became finalized!

A significant observation, surely.

> since this is the only decoding available, in at least in standard Java.

Good point.

> Presumably other decodings are incompatible with existing libraries as well.

That is one thing I'm trying to find out, yes.

> I would call this a de-facto standard for XML.

Thanks,
Tom

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 6 Nov 2008 14:35:03 -0500

Tom,

DER

-----Original Message-----
From: Tom Scavo [mailto:[email-masked]] 
Sent: Thursday, November 06, 2008 2:14 PM
To: Santosh Chokhani
Cc: pkix
Subject: Re: encoding an X.509 certificate

> binary as base 64 is the trade-off.

The certificate is always base64 encoded before it is inserted in the
XML.

Thanks!

Tom

---

From: Ben Laurie <[email-masked]>
Date: Thu, 06 Nov 2008 20:36:23 +0000

> That is one thing I'm trying to find out, yes.

Obviously the signature will only verify if it is DER encoded. So,
there's generally not much point in supporting other encodings.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Ben Laurie <[email-masked]>
Date: Thu, 06 Nov 2008 20:34:03 +0000

> bytes?  Does your favorite ASN.1 library support such a function?

Surely an X.509 certificate is, by definition, in DER?

Cheers,

Ben.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 6 Nov 2008 15:56:08 -0500

I stand corrected.

Certificate and signature could be encoded ways other than DER.  But, in
order to verify the signature you need to encode the payload in DER
since the signature is computed on DER.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ben Laurie
Sent: Thursday, November 06, 2008 3:34 PM
To: Tom Scavo
Cc: pkix
Subject: Re: encoding an X.509 certificate

Cheers,

Ben.

---

From: "Juan Gonzalez" <[email-masked]>
Date: Thu, 6 Nov 2008 15:19:33 -0600

Tom:
 
>From my pont of view, the X.509 standard assumes DER encoding for certificates.
 
I'm not shure if it mandates DER, but the certificate concept is applied in other
standards such as ISO 9735 (EDIFACT), where a series of "segments" represent the serial number,
the issuer name, the validity period, the subject names, the public key and the signature
- including algorithms for digest and signature.
 
In EDIFACT there are no attributes.  We have software that "converts" from DER encoding to
EDIFACT (using of course, aditional attributes that contain the EDIFACT signature and parameters)
 
About how to distinguish a DER encoding from a Base64 encoding, you can analize the
first three bytes:
 
1. If first byte is "0" (0x30) it is likely to be DER encoded (possibly BER/CER.  More analysis would be needed)
2. If first bytes are "MII" (0x4D, 0x49, 0x49) it is likely to be Base64 containing a DER/BER/CER encoded certificate
      More analysis would be needed to determine DER/BER/CER encoding
3. If first bytes are "USC" it is likely to be an EDIFACT Public Key (let's call it an "EDIFACT certificate")
4. If first byte were "<" (0x3c) it would be likely to be an XML encoded certificate (does it exist?, I don't know...)
 
Juan
SeguriDATA

________________________________

De: [email-masked] en nombre de Kemp, David P.
Enviado el: jue 06/11/2008 01:21
Para: Tom Scavo; pkix
Asunto: RE: encoding an X.509 certificate

Dave

-----Original Message-----

Tom Scavo
NCSA

---

From: "Tom Scavo" <[email-masked]>
Date: Thu, 6 Nov 2008 16:18:27 -0500

> Surely an X.509 certificate is, by definition, in DER?

Strictly speaking, no, that is not true (at least AFAICT).  That
appears to be true in practice, however.

Tom

---

From: "Tom Scavo" <[email-masked]>
Date: Thu, 6 Nov 2008 16:38:13 -0500

> there's generally not much point in supporting other encodings.

Well, that brings up a good point, which I neglected to make clear.
The SAML profile that makes use of the XML structure posted earlier
does not require that the certificate in question be validated by the
receiving party.  The certificate is merely a container for a public
key, for which the client proves possession of the corresponding
private key, nothing more.

If the receiving party is a SAML identity provider, the presented
certificate is bound to a SAML assertion (using the XML structure
posted earlier).  If the receiving party is a SAML service provider,
the presented certificate is compared to the certificate bound to the
SAML assertion.  So the actual encoding applied to the certificate is
not important, except of course the identity provider and the service
provider need to be on the same page, otherwise certificate comparison
at the service provider will fail.

Obviously, if the identity provider is required to bind a base64
encoding of a DER-encoded certificate, the service provider will have
no problem (or so it seems), but there are some who are inclined not
to specify DER explicitly, to future-proof the profile, as it were.

I hope this helps to clarify.  I had hoped to avoid the details but I
see that may not be possible.

Thanks,
Tom

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 6 Nov 2008 23:04:45 +0100

Tom,
I would be very surprised if X509Certificate elements in SAML assertions (or in other XML schemes) 
would pass many implementations if they were not correctly (DER) encoded because otherwise you 
cannot really be sure that you even got the public key.

I think you can safely conclude based on the number of people responding to this request that it is 
DER and nothing else that's counts.  At least if compatibility with the existing code-base, and 
habits is wanted.

Anders
who do not even know how to do a BER, PER, CER, or XER encoded certificate

----- Original Message ----- 
From: "Tom Scavo" <[email-masked]>
To: "Ben Laurie" <[email-masked]>
Cc: "Anders Rundgren" <[email-masked]>; "pkix" <[email-masked]>
Sent: Thursday, November 06, 2008 22:38
Subject: Re: encoding an X.509 certificate

Thanks,
Tom

---

From: Russ Housley <[email-masked]>
Date: Thu, 06 Nov 2008 17:18:23 -0500

Please use DER.  If you use BER, then the recipient will have to 
decode the certificate and re-encode it with DER in order to validate 
the signature, wasting much effort.

Russ

---

From: Steven Legg <[email-masked]>
Date: Fri, 07 Nov 2008 10:01:42 +1100

Tom,

> to specify DER explicitly, to future-proof the profile, as it were.

David Kemp already made the point that there are no "magic bits" in
an ASN.1 encoding that identify which encoding rules have been used
(though there are heuristics), so identification of the encoding needs
to be external to the encoding itself. You have two appropriate
choices when embedding an ASN.1 encoding in a protocol message:

(1) specify that one particular encoding is to be used, or

(2) provide a separate field in the protocol that identifies which
     encoding has been used.

In your case, since (I presume) there is currently no separate field
associated with <ds:X509Certificate> to identify the encoding, and it
seems everyone is assuming that the encoding is DER, you might as well
formally specify that, i.e., use option (1). If and when it becomes
necessary to allow for alternative encodings of the certificate, then
an XML attribute could be added to <ds:X509Certificate> to indicate
that an encoding other than DER has been used.

Regards,
Steven

---

From: Steven Legg <[email-masked]>
Date: Fri, 07 Nov 2008 10:37:00 +1100

Russ,

Russ Housley wrote:
> 
> Please use DER.  If you use BER, then the recipient will have to decode 
> the certificate and re-encode it with DER in order to validate the 
> signature, wasting much effort.

What's actually needed is the original encoding over which the signature
was calculated, which although it's supposed to be the DER encoding
sometimes isn't quite (in which case any re-encoding of the certificate
breaks the signature). The safest thing to do is accept BER and preserve
the exact encoding received. That's what directory implementations do.

Regards,
Steven

---

From: Ben Laurie <[email-masked]>
Date: Fri, 07 Nov 2008 08:19:51 +0000

> at the service provider will fail.

If that's true, then your first paragraph is incorrect - all of the
certificate matters. However, if all you really care about is the public
key, why does the receiving party not just check that and ignore the
certificate?

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 07 Nov 2008 10:56:11 +0100

> From my pont of view, the X.509 standard assumes DER encoding for 
IMO it does not do that at all. A certficate is an ASN.1 data structure
which is independant from a transfer syntax. X.509 does not even indicate
that one must encode it in DER when it is transfered or stored. I vaguely
remember that somewhere else in ASN.1 there is a suggestion that
when a part of a data structure is signed, that one should use DER
as a transfer syntax in order to avoid reencoding.

In practice I have never seen a certficate encoded in anything else
than DER except in XER like flavour.

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 7 Nov 2008 12:42:31 +0100

Everybody is right :-)

If we cut down the question to the original issue which was how X509Certificate XML Dsig objects are 
encoded, existing systems use Base64 over DER and there is no chance (or reason) for changing that. 
What's apparent is that the specification is a bit unclear on this point which should be possible to 
fix any old day since it doesn't break any code, it just formalizes the de-facto standard.

Anders

----- Original Message ----- 
From: "Peter Sylvester" <[email-masked]>
To: "Juan Gonzalez" <[email-masked]>
Cc: "Kemp, David P." <[email-masked]>; "Tom Scavo" <[email-masked]>; "pkix" 
<[email-masked]>
Sent: Friday, November 07, 2008 10:56
Subject: Re: encoding an X.509 certificate

---

From: "Timothy J. Miller" <[email-masked]>
Date: Fri, 7 Nov 2008 08:05:24 -0600

> fix any old day since it doesn't break any code, it just formalizes the de-facto standard.

IMHO the specification is clear.  Certificates are data structures, with 
the signature portion defined as using the ASN.1 DER encoding of that 
data structure.

After that, how you marshal that data structure for transport is up to 
your application.  This grants maximum flexibility.

-- Tim

---

From: Russ Housley <[email-masked]>
Date: Fri, 07 Nov 2008 09:45:37 -0500

>>decode the certificate and re-encode it with DER in order to 
>>validate the signature, wasting much effort.
>

Steve, you are completely correct.  All of the PKIX specifications 
talk about signing the DER-encoded certificate.  RFC 5280 says:

    For signature calculation, the data that is to be signed is encoded
    using the ASN.1 distinguished encoding rules (DER) [X.690].

Once the certificate is signed, it would be great if the certificate 
was carried as a blob and the encoding was not 
changed.  Unfortunately, this is not my experience.  I recall a 
system that used an X.500 Directory in the mid-1990s.  Post a 
DER-encoded certificate, and then fetch it again, and it came back 
BER-encoded.  The client had to re-encode the certificate with DER in 
order to perform signature validation.

You claim that "directory implementations" do not change the 
encoding.  I hope that is what happens today.  Much effort was wasted 
encoding and re-encoding the certificates.  We know that the CAs did 
DER properly in that system, otherwise no certificate validation 
would have been successful.

In summary, create the certificate using DER, and then carry it 
without changing the encoding.

Russ

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 07 Nov 2008 15:54:18 +0100

Tomas Gustavsson wrote:
>
> Hmm, chapter 4.1 in RFC3280 clearly states:
> -----
> 4.1  Basic Certificate Fields
>
>    The X.509 v3 certificate basic syntax is as follows.  For signature
>    calculation, the data that is to be signed is encoded using the ASN.1
>    distinguished encoding rules (DER) [X.690].  ASN.1 DER encoding is a
>    tag, length, value encoding system for each element.
> -----
>
It says 'For signature calculation the date is encoded'. It does not say
that how you encode it when you transfer it to someone.

> Tomas
> Peter Sylvester wrote:

-- 

<http://www.edelweb.fr>
*Edel/W/eb* 	Peter SYLVESTER
Consultant Sécurité des Systèmes d'Information
-----------------------------------------------------------
EdelWeb - Groupe ON-X
15, quai de Dion-Bouton
F-92816 Puteaux Cedex
Tel : +33.1.40.99.14.14 / Fax : +33.1.40.99.99.58
www.edelweb.fr <http://www.edelweb.fr> / www.on-x.com <http://www.on-x.com>
-----------------------------------------------------------
To verify the message signature, see edelpki.edelweb.fr 
<http://edelpki.edelweb.fr/>
Cela vous permet de charger le certificat de l'autorité de racine 
<http://edelpki.edelweb.fr/cacerts/EdelPKI-ca.der>;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 08 Nov 2008 04:35:43 +1300

>An X.509 certificate is always DER encoded.

Actually I should have edited the above to say:

  >An X.509 certificate is always DER encoded.

In practice it's actually:

  "An X.509 certificate is always encoded in any damn way the originator
  pleases, as long as MSIE, Netscape/FF, and OpenSSL can still swallow the
  result".

with the corollary:

  "Any downstream party keeps a copy of the binary exactly as originally
  encoded and reuses that as and when required".

In other words "there is only one encoding rule and that is memcpy()".  There
have been CAs whose certs break into BER in the middle of the cert, whose
certs contain totally incorrect ASN.1, in at least one memorable occasion
which didn't even contain ASN.1 at all but just raw binary data (and these
were major commercial CAs, Verisign, Thawte, European government-level CAs,
operations at that level), and no-one noticed because they just accepted
whatever they were given without being too choosy.  It's stil going on today,
I got a non-DER cert as recently as a week ago, in this case one with the
keyUsage encoded wrong.

So trying to enforce any kind of encoding is just going to lead to endless
pain.  Given their ongoing c18n problems I'd have thought the XML security
guys would be more aware of this than most :-).

[Reading through numerous other posts from people all saying you use DER,
 e.g.]:

>order to verify the signature you need to encode the payload in DER since the
>signature is computed on DER.

>Please use DER.  If you use BER, then the recipient will have to decode the
>certificate and re-encode it with DER in order to validate the signature,
>wasting much effort.

>order to verify the signature you need to encode the payload in DER since the
>signature is computed on DER.

>Obviously the signature will only verify if it is DER encoded. So, there's
>generally not much point in supporting other encodings.

No, you need to leave the payload exactly in whatever form the signer left it
(and specifically not DER-encode it) or your sig-checks will start failing.

Sheesh, are there *any* implementers still left on this list?  Everyone seems
to be blindly repeating X.509 dogma without any (apparent) awareness of how
things really work.  The repeated advice to enforce DER is just going to cause
your signatures to fail whenever you encounter something that isn't DER-
encoded.

>What's actually needed is the original encoding over which the signature was
>calculated, which although it's supposed to be the DER encoding sometimes
>isn't quite (in which case any re-encoding of the certificate breaks the
>signature). The safest thing to do is accept BER and preserve the exact
>encoding received. That's what directory implementations do.

OK, so there is at least one :-).

Peter.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 7 Nov 2008 10:39:57 -0500

Peter,

How do you reconcile what you say with the following in Section 4.1 of
5280:

"The X.509 v3 certificate basic syntax is as follows.  For signature
calculation, the data that is to be signed is encoded using the ASN.1
   distinguished encoding rules (DER) [X.690].  

-----Original Message-----
From: pgut001 [mailto:[email-masked]] 
Sent: Friday, November 07, 2008 10:36 AM
To: [email-masked]; Santosh Chokhani; [email-masked]
Subject: RE: encoding an X.509 certificate

  "An X.509 certificate is always encoded in any damn way the originator
  pleases, as long as MSIE, Netscape/FF, and OpenSSL can still swallow
the
  result".

with the corollary:

In other words "there is only one encoding rule and that is memcpy()".
There
have been CAs whose certs break into BER in the middle of the cert,
whose
certs contain totally incorrect ASN.1, in at least one memorable
occasion
which didn't even contain ASN.1 at all but just raw binary data (and
these
were major commercial CAs, Verisign, Thawte, European government-level
CAs,
operations at that level), and no-one noticed because they just accepted
whatever they were given without being too choosy.  It's stil going on
today,
I got a non-DER cert as recently as a week ago, in this case one with
the
keyUsage encoded wrong.

So trying to enforce any kind of encoding is just going to lead to
endless
pain.  Given their ongoing c18n problems I'd have thought the XML
security
guys would be more aware of this than most :-).

[Reading through numerous other posts from people all saying you use
DER,

>order to verify the signature you need to encode the payload in DER
since the

>Please use DER.  If you use BER, then the recipient will have to decode
the

>order to verify the signature you need to encode the payload in DER
since the

>Obviously the signature will only verify if it is DER encoded. So,
there's
>generally not much point in supporting other encodings.

No, you need to leave the payload exactly in whatever form the signer
left it
(and specifically not DER-encode it) or your sig-checks will start
failing.

Sheesh, are there *any* implementers still left on this list?  Everyone
seems
to be blindly repeating X.509 dogma without any (apparent) awareness of
how
things really work.  The repeated advice to enforce DER is just going to
cause
your signatures to fail whenever you encounter something that isn't DER-
encoded.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 08 Nov 2008 05:02:38 +1300

"Santosh Chokhani" <[email-masked]> writes:

>How do you reconcile what you say with the following in Section 4.1 of 5280:
>

The standard says all sorts of odd things that implementors/implementations
completely ignore.  That's exactly what I was pointing out.

Peter.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 7 Nov 2008 11:55:09 -0500

Peter,

What does that do to interoperability or performance since you get
certificates from various sources who can encode them whichever way.

-----Original Message-----
From: pgut001 [mailto:[email-masked]] 
Sent: Friday, November 07, 2008 11:03 AM
To: [email-masked]; [email-masked]; Santosh Chokhani;
[email-masked]

>distinguished encoding rules (DER) [X.690].

The standard says all sorts of odd things that
implementors/implementations
completely ignore.  That's exactly what I was pointing out.

Peter.

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 7 Nov 2008 17:50:51 +0100

Peter,

That was both interesting and entertaining!

The assumption must then be that implementations always keep the original blob and never normalize 
it to DER, BER etc.

Life is about learning.  I learnt something today :-) :-)

So the response to the XML Dsig people must be "keep that certificate in whatever shape it was" but 
translated to a more standards-conformant lingo.

Anders

----- Original Message ----- 
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, November 07, 2008 16:35
Subject: RE: encoding an X.509 certificate

with the corollary:

Peter.

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 7 Nov 2008 12:45:30 -0500

The same thing that happens to people who don't lint or bounds-check
their C code - it works most of the time, so it must not matter if the
code is actually correct.  "X.509 dogma" is just for anal people who
want 100% reliability.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Friday, November 07, 2008 11:55 AM
To: pgut001; [email-masked]; [email-masked]
Subject: RE: encoding an X.509 certificate

Peter,

-----Original Message-----
From: pgut001 [mailto:[email-masked]] 
Sent: Friday, November 07, 2008 11:03 AM
To: [email-masked]; [email-masked]; Santosh Chokhani;
[email-masked]

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 08 Nov 2008 20:21:07 +1300

"Kemp, David P." <[email-masked]> writes:

>The same thing that happens to people who don't lint or bounds-check their C
>code - it works most of the time, so it must not matter if the code is
>actually correct.  "X.509 dogma" is just for anal people who want 100%
>reliability.

If you follow the spec in this regard you get 100% unreliability, not
reliability - your PKI application when shipped will break repeatedly whenever
it encounters a non-DER certificate, while everything else will work just
fine.  So "X.509 dogma" is for X.509 dogmatists and pretty much no-one else.

(I actually had a bit of trouble replying to this message, it's not often that
 you see the terms "100% reliability" and "X.509" used in the same sentence 
 (in fact this may be the first time I've ever seen it without a negation in
 there as well), there were so many ways I could have replied to this :-).

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 08 Nov 2008 20:22:31 +1300

>certificates from various sources who can encode them whichever way.

Since pretty much everything follows the "the only encoding rule is memcpy()"
rule (and anyone who doesn't learns pretty quickly) there's no effect.  If
people did actually enforce the DER rules as per the spec, that'd kill any
chance of interoperability (and also reduce performance due to the re-encoding
that's necessary, so the net effect is negative on both counts if you follow
the spec).

My intention in pointing out the issues was to at least give the XML guys the
option of having their spec approximate reality, but whether they choose to do
this or to follow PKIX practice is up to them, all I can do is point out the
problem.

(Editorialising a bit, I'm somewhat disturbed that this kind of thing is
 actually news to people.  I've had a few emails off-list from implementors -
 yes, there are still a few left on the list, although all in read-only mode -
 saying, in effect, "Don't people know this stuff?".  If you want a few real-
 world examples, and this is a pretty small subset of selected examples
 because the full list would fill a book, have a look at
 http://www.cypherpunks.to/~peter/T2a_X509_Certs.pdf, starting at slide #61,
 which would be on about p.30 in the PDF (they're laid out two to a page)).

Peter.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 8 Nov 2008 11:24:42 -0500

Dave,

I also have seen Peter's responses.

Either I am misunderstanding you or we have a genuine disagreement.

In terms of interoperability, I did not think that many clients
recognize the various ASN.1 encodings.

Performance may be a minor item depending on at what point in decoding
you get an error and try another one.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kemp, David P.
Sent: Friday, November 07, 2008 12:46 PM
To: [email-masked]
Subject: RE: encoding an X.509 certificate

-----Original Message-----

Peter,

-----Original Message-----
From: pgut001 [mailto:[email-masked]] 
Sent: Friday, November 07, 2008 11:03 AM
To: [email-masked]; [email-masked]; Santosh Chokhani;
[email-masked]

Peter.

---

From: "Tom Scavo" <[email-masked]>
Date: Sat, 8 Nov 2008 14:49:47 -0500

Hi Ben,

Thanks for gently pushing back on my remarks.  I was trying to distill
the essence of the profile, but I'm not sure I've adequately done
that.  As I said earlier, I probably I have to provide more detail
before the issues clearly emerge.  Please bear with me as I try to do
that below.

>> private key, nothing more.

Sorry, the above is an overstatement on my part.  Although it happens
to be true, it doesn't really have anything to do with my original
question regarding certificate encodings.

> certificate matters.

Well, it depends on the content of the assertion.  In the case of
<ds:X509Certificate>, yes, all of the certificate does matter, but
other kinds of X.509 data may be bound to the assertion, namely,
<ds:X509SKI>, <ds:X509SubjectName>, or <ds:X509IssuerSerial>.  As it
turns out, it's these other elements that require additional
processing of the certificate by both parties.

See this short write-up that discusses each element in some detail:

http://docs.google.com/Doc?id=ddj3qnj2_231hms5vtgq

If a <ds:X509Certificate> element is bound to the assertion, it's
all-or-nothing, yes.  On the other hand, if a <ds:X509SubjectName>
element is bound to the assertion, only the subject DN of the
certificate matters.  Indeed, in that case the identity provider and
the service provider may be holding different certificates.  Moreover,
in the case of <ds:X509SubjectName> we assume the service provider
trusts the issuer of the certificate in its possession.  If not, the
subject DN should not be used by the service provider to confirm the
subject.

> However, if all you really care about is the public

Again, I misspoke (or spoke out of context) earlier.  Now that I've
had a chance to explain myself, would you care to rephrase your
question?

Cheers,
Tom

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 8 Nov 2008 22:17:38 +0100

According to this document DER is a subset of BER:
http://luca.ntop.org/Teaching/Appunti/asn1.html

That probably means that certificate decoders cope with both (or even mixed) formats, but that they 
always keep the original representation in the background if the the binary representation is 
requested.  "Fake serialization".

As Peter Gutmann writes this is sort if a "convention" among implementers which is not well-known 
outside of these circles.   Microsoft states "raw binary representation" in .NET and that seems like 
the only thing that is for sure.  SUN's Java actually claims DER but that is probably incorrect.

I do not fully agree with the following document:
http://docs.google.com/Doc?id=ddj3qnj2_231hms5vtgq
A certificate should [IMO] always be decodable, and verifiable against a trust anchor, otherwise it 
is not much of a certificate.

Couldn't somebody setup something like W3C's HTML validator but for X509 certificates?

Anders

----- Original Message ----- 
From: "Tom Scavo" <[email-masked]>
To: "Ben Laurie" <[email-masked]>
Cc: "Anders Rundgren" <[email-masked]>; "pkix" <[email-masked]>
Sent: Saturday, November 08, 2008 20:49
Subject: Re: encoding an X.509 certificate

Hi Ben,

Cheers,
Tom

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 8 Nov 2008 14:37:11 -0800

>Couldn't somebody setup something like W3C's HTML validator but for X509 certificates?

Of course. Of what possible use would it be? People paying attention to Peter's posting on this thread already know that different CAs emit certs that wouldn't pass the test. Having a public box say so isn't going to change anything.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Tom Scavo" <[email-masked]>
Date: Sat, 8 Nov 2008 18:19:01 -0500

> http://docs.google.com/Doc?id=ddj3qnj2_231hms5vtgq

Can you say why?

> is not much of a certificate.

Decodable is one thing (the only characteristic I'm interested in, in
fact) but "verifiable against a trust anchor" is quite another.  I
like to think that the certificates in this profile are "meaningless":

http://www.ietf.org/internet-drafts/draft-moreau-pkix-aixcm-00.txt

In other words, SAML holder-of-key subject confirmation does not
require an X.509-based PKI.  The goal is to cryptographically
strengthen the SAML flow.  If this can be done without assuming an
X.509-based PKI, so much the better.

Practically speaking, a typical flow is based on TLS client
"authentication."  A client presents a certificate to the identity
provider via TLS and authenticates by unspecified means.  (If the
identity provider trusts the issuer of the certificate, TLS serves
both purposes of course.)  The certificate from the TLS exchange is
the certificate "possessed" by the identity provider.

If we could limit the choices at the identity provider to one
(<ds:X509Certificate>), this would be a done deal.  Unfortunately,
that's not possible, because if there *is* an X.509-based PKI in
place, there are real use cases for the other XML elements specified
in the XML Signature spec.

Tom

---

From: Russ Housley <[email-masked]>
Date: Sun, 09 Nov 2008 16:13:31 -0500

>Couldn't somebody setup something like W3C's HTML validator but for 

I do not know what the W3C HTML validator does, but I aware of the 
NIST PKI testing:

http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html

Russ

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 9 Nov 2008 14:41:10 -0800

At 4:13 PM -0500 11/9/08, Russ Housley wrote:
>I do not know what the W3C HTML validator does, but I aware of the NIST PKI testing:
>

The W3C Validator (<http://validator.w3.org/>) is an online mechanism for people to see whether a web page is valid HTML or XHTML. Some people like showing that their HTML is valid by checking it every time it changes and, if shown valid, put up a cute little logo on their web page.

The NIST PKIX test system is an offline system. I think Anders was hoping that, by putting up an online system, the problems mentioned in this thread might be reduced because CAs issuing certificates could check if they are valid. However, as Peter points out, there seems to be little interest on the part of the CA vendors to enforce the rules of X.509 and PKIX.

Creating a local validation tool inside a CA vendor's lab is trivial. The assumption that individual CA vendors don't know about their lack of conformance to the specs is dubious at best.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 10 Nov 2008 10:42:19 +0100

The point with public validates is to verify your own interpretation or maybe help you when you got 
an unexplainable error.  Here's one example which I have actually used in spite of its somewhat 
"funny" name:

http://tinyurl.com/578h86

Even if Peter is right, there may be a point being compliant because there are probably some less 
used implementations out there that haven't been exposed to all the bad stuff Peter has acquired 
over the years.

Anders

----- Original Message ----- 
From: "Paul Hoffman" <[email-masked]>
To: "Russ Housley" <[email-masked]>; "Anders Rundgren" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sent: Sunday, November 09, 2008 23:41
Subject: Re: encoding an X.509 certificate

>http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html

The W3C Validator (<http://validator.w3.org/>) is an online mechanism for people to see whether a
web page is valid HTML or XHTML. Some people like showing that their HTML is valid by checking it
every time it changes and, if shown valid, put up a cute little logo on their web page.

The NIST PKIX test system is an offline system. I think Anders was hoping that, by putting up an
online system, the problems mentioned in this thread might be reduced because CAs issuing
certificates could check if they are valid. However, as Peter points out, there seems to be little
interest on the part of the CA vendors to enforce the rules of X.509 and PKIX.

Creating a local validation tool inside a CA vendor's lab is trivial. The assumption that individual
CA vendors don't know about their lack of conformance to the specs is dubious at best.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 10 Nov 2008 09:02:18 -0500

No disagreement there - any application that doesn't validate
incorrectly encoded certificates will fail in the marketplace just as
any web browser that doesn't accept non-validated HTML would fail.  That
doesn't:
 * make the validator application useless, or
 * imply that CAs / HTML authors / C coders who do validate their work
products are wasting time by ensuring that their output is correct, or
 * say that an unambiguous standard for what is correct/incorrect output
is "dogma".

CAs that sign non-DER encodings are wrong, whether or not they care what
others think.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Paul Hoffman
Sent: Saturday, November 08, 2008 5:37 PM
To: Anders Rundgren
Cc: pkix
Subject: Re: encoding an X.509 certificate

>Couldn't somebody setup something like W3C's HTML validator but for
X509 certificates?

Of course. Of what possible use would it be? People paying attention to
Peter's posting on this thread already know that different CAs emit
certs that wouldn't pass the test. Having a public box say so isn't
going to change anything.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 10 Nov 2008 10:13:48 -0500

Sorry, I hit "send" before getting to the punchline.

I watched a "60 Minutes" segment last night on e-cycling, where a
company that publicly claims to recycle CRTs in the US using state of
the art methods actually ships them to China to be recycled using less
sophisticated and more toxic methods.  This is against both US and
Chinese law, but many companies do it anyway.  So why would CBS bother
to spend valuable airtime railing against common practice?  Because they
hope publicity will change behavior.

One could hope that an online certificate validation tool could also
change CA behavior by making errors more publicized than just a list
maintained by a crackpot activist :-).   Maybe extra publicity wouldn't
change anything, maybe it would.

The other punchline is that applications should not be penalized for
validating correct certificates - it may address a niche (or even
non-existent) market to be able to validate a DER signature of a
certificate that was transmitted using XER, but being able to do is
undeniably a feature, not a bug.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kemp, David P.
Sent: Monday, November 10, 2008 9:02 AM
To: pkix
Subject: RE: encoding an X.509 certificate

-----Original Message-----

--Paul Hoffman, Director
--VPN Consortium

---

From: "Timothy J. Miller" <[email-masked]>
Date: Wed, 12 Nov 2008 09:31:26 -0600

> fine.  So "X.509 dogma" is for X.509 dogmatists and pretty much no-one else.

Postel's Law, anyone?  :)

-- Tim

---

From: "Timothy J. Miller" <[email-masked]>
Date: Wed, 12 Nov 2008 10:10:47 -0600

> Of course. Of what possible use would it be? People paying attention to Peter's posting on this thread already know that different CAs emit certs that wouldn't pass the test. Having a public box sa…

By itself?  Not much.

If it provided a service mark for use by a vendor?  Quite a bit.  Most 
of the major standards do this and it does work (mostly).

-- Tim

---

From: Tom Gindin <[email-masked]>
Date: Wed, 12 Nov 2008 20:22:48 -0500

"Conservative in what you produce" - CA code should generate DER. 
Not all such code does so, but it should.
        "Liberal in what you accept" - RP code should verify signatures on 
the supplied binary TBSCertificate, rather than re-encoding.  For parsing 
code to accept BER which isn't valid DER is almost harmless.    There may 
well have been a good reason for believing that DER was more secure than 
BER against various digest collision or pre-image attacks when X.509v1 was 
in use and all certificate content had syntax verifiable by every RP (at 
least in theory).  With non-critical extensions, that is no longer the 
case.

                Tom Gindin

"Timothy J. Miller" <[email-masked]> 
Sent by: [email-masked]
11/12/2008 10:31 AM

To
Peter Gutmann <[email-masked]>
cc
[email-masked], [email-masked]
Subject
Re: encoding an X.509 certificate

Postel's Law, anyone?  :)

-- Tim

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Nov 2008 11:40:25 -0500

Tom,

I have to disagree. The standards call for DER to be used for 
signature generation and validation. They are generally silent on 
transport encoding. If we say that an RP should just try to verify 
the signature on whatever it receives, then we encourage (more) 
sloppy behavior by CAs. The preferred approach is for the RP to 
encode the received cert into DER before checking.

Steve

---

From: Eric Norman <[email-masked]>
Date: Mon, 17 Nov 2008 11:24:12 -0600

On Nov 17, 2008, at 10:40 AM, Stephen Kent wrote:

> transport encoding. If we say that an RP should just try to verify the 
> signature on whatever it receives, then we encourage (more) sloppy 
> behavior by CAs. The preferred approach is for the RP to encode the 
> received cert into DER before checking.

So if someone receives a bit blob that contains a certificate,
and the signature would verify if the bit blob was used,
but some parts of that bit blob are BER but not DER encoded,
then certificate validation should fail?

Eric Norman

---

From: Julien Stern <[email-masked]>
Date: Mon, 17 Nov 2008 19:03:41 +0100

> then certificate validation should fail?

Oh well, why not ?
This is really an infamous "matter of local policy", but it would be 
hard to blame an implementation that does not validate the certificate 
in question.

Just recently, we encountered a certificate whose serial number was 
negative. The RFC very specifically states that serial numbers MUST be 
positive integers. Now, it is easy to decode such a certificate, and 
actually, most ASN.1 libraries will not even figure out that this number 
is negative unless someone has specified a constraint or if there is an 
explicit check on this number. So, should certificate validation fail?

I think it really boils down to how big and powerful the company 
implementing the validation is. If a BER encoded certificate (or a 
certificate with a negative serial) is rejected by your implementation 
AND if you can explain to your customers that YOU are doing the right 
thing, then you are fine, otherwise, you'll have to patch your 
implementation to accept the buggy certificates produced by a more 
powerful entity than yours :)

It actually only gets tricky when accepting these buggy certificates is 
linked to a security risk. The intuition is that attacks through hash 
collisions are easier if BER encoding is allowed, however, because 
extensions can also be used to add entropy, it is not clear whether BER 
encoding actually decreases security or not in theoretical attack cases.

Regards,

--
Julien

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Nov 2008 13:50:09 -0500

>then certificate validation should fail?

We're talking about certs, not blobs that contain certs.

Steve

---

From: Arshad Noor <[email-masked]>
Date: Mon, 17 Nov 2008 12:03:59 -0800

I trust you are being facetious, Julien.  If not, why bother with
standards efforts at all?  Lets all just cede the market to the
biggest players in the industry - no matter how ridiculous their
implementations may be - and call it a day.

Arshad Noor
StrongAuth, Inc.

---

From: "Timothy J. Miller" <[email-masked]>
Date: Mon, 17 Nov 2008 14:31:01 -0600

> We're talking about certs, not blobs that contain certs.

You can't fix interoperability in someone else's application.  You can 
only address interoperability in your own.

You *can* make it embarrassing for the bad player.  That's the point of 
things like the USB trademark.

-- Tim

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Nov 2008 15:51:16 -0500

At 2:31 PM -0600 11/17/08, Timothy J. Miller wrote:
>You can't fix interoperability in someone else's application.  You 
>can only address interoperability in your own.

agreed.

>You *can* make it embarrassing for the bad player.  That's the point 
>of things like the USB trademark.
>
>-- Tim

agreed.

Pity we don't have a "PKIX Compliant" trademark :-).

Steve

---

From: Eric Norman <[email-masked]>
Date: Mon, 17 Nov 2008 15:08:46 -0600

> We're talking about certs, not blobs that contain certs.

OK.

So is someone receives a certificate,
and the certificate signature would verify if it (TBS part) were used 
as received,
but some parts of the certificate are BER but not DER encoded,
then certificate validation should fail?

Eric Norman

---

From: Eric Norman <[email-masked]>
Date: Mon, 17 Nov 2008 15:12:51 -0600

> then certificate validation should fail?

To be clear.

Why shouldn't the robustness principle apply in this case?

Eric Norman

---

From: Tom Gindin <[email-masked]>
Date: Mon, 17 Nov 2008 20:41:29 -0500

Steve:

        As a theoretical exercise, let us assume that a relying party 
encounters the following encoding as part of the value of a non-critical 
extension with syntax unknown to the relying party: A1 13 16 03 4F 6E 65 
16 07 45 78 61 6D 70 6C 65 16 03 4E 6F 77.
        How can the relying party tell whether this is a valid DER 
encoding of [1] IMPLICIT SEQUENCE OF PrintableString, an encoding of [1] 
IMPLICIT PrintableString which violates section 10.2 of X.690, or an 
encoding of [1] IMPLICIT SET OF PrintableString which violates section 
11.6 of X.690?  The component string values are "One", "Example", and 
"Now".
        I am not convinced that "re-encode as DER" can be performed by 
general purpose library code.  One can verify that the certificate down to 
the OCTET STRING wrappings for extension values is in DER, but one cannot 
always tell whether the inner values of extensions are in DER, let alone 
re-encode them into DER.

                Tom Gindin

P.S - The above opinions (and those in my last post as well) are mine and 
not necessarily those of my employer

Stephen Kent <[email-masked]> 
11/17/2008 11:40 AM

To
Tom Gindin/Watson/IBM@IBMUS
cc
"Timothy J. Miller" <[email-masked]>, [email-masked], 
[email-masked], Peter Gutmann <[email-masked]>
Subject
Re: encoding an X.509 certificate

Tom,

Steve

---

From: Michael StJohns <[email-masked]>
Date: Mon, 17 Nov 2008 23:05:50 -0500

Eric - if you're referring to "be generous in what you accept" - that's probably not a great idea for things related to security.

E.g. accepting a library card when the preferred credential is a driver's license is probably not a good idea, even though both encode an identity.

Mike

At 04:12 PM 11/17/2008, Eric Norman wrote:

>>and the certificate signature would verify if it (TBS part) were used as received,

---

From: "Timothy J. Miller" <[email-masked]>
Date: Tue, 18 Nov 2008 08:49:26 -0600

> Pity we don't have a "PKIX Compliant" trademark :-).

So what would it take to *make* a certification program?  VPNC runs one 
for IPSec, The Open Group runs one for S/MIME

-- Tim

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Nov 2008 10:12:52 -0500

>then certificate validation should fail?

I assume that you mean to ask "if the cert had its signature computed 
over a mix of DER and BER encoded fields, should the RP consider the 
cert valid, because a signature computed on the cert (as received, a 
mix of DER and BER) matches the signature provided with the cert?"

My answer is yes, the RP should reject the cert. My rationale is that 
if an RP uses the standards-compliant strategy of encoding every 
received cert into DER, before it checks the cert sig, this cert will 
fail the sig check. If we encourage RPs to just compute a hash on a 
cert as received, without encoding to DER, then the "broken" cert you 
describe will verify, but implementations following the procedure I 
described will reject the cert, creating interoperability issues (and 
encouraging bad behavior).

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Nov 2008 10:14:26 -0500

>Why shouldn't the robustness principle apply in this case?

Jon Postel's robustness principle has always been in tension with 
security protocols, since being liberal in what you accept is a 
recipe for insecurity.

Steve

---

From: "Charles W. Gardiner" <[email-masked]>
Date: Tue, 18 Nov 2008 10:24:43 -0500

This raises the question of whether things inside a wrapper must be 
DER-encoded or are they in some way inviolate so one must take them "as is".

Charlie Gardiner

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Nov 2008 10:24:17 -0500

At 8:49 AM -0600 11/18/08, Timothy J. Miller wrote:
>So what would it take to *make* a certification program?  VPNC runs 
>one for IPSec, The Open Group runs one for S/MIME
>
>-- Tim

Ask Paul Hoffman if he is interested, and if he sees enough interest 
from vendors to support a testing program of that sort. Paul has 
excellent experience in this context.

Steve

---

From: Julien Stern <[email-masked]>
Date: Tue, 18 Nov 2008 17:01:16 +0100

Stephen Kent wrote:
> Julien,
> 
> I am painfully aware that if a really big vendor fails to follow 
> standards, then it may cause many other, smaller vendors to have to 
> accept certs, CRLs, OCSP responses, HTML, etc. that are "broken" 
> vis-a-vis the relevant standards.
> 
> But, the IETF works to create standards based on the consensus of 
> knowledgeable individuals who chose to participate in the IETF standards 
> process. I don't think it's appropriate to skew our standards to 
> accommodate the practices of any (large) vendor who violates our 
> standards, and I'd rather we not debate this in the context of an IETF 
> standards WG.

My apologies if this was considered inapropriate, I was being ironic (as 
somehow indicated by the smiley). Please only read it as a way to 
pinpoint the difficulties of being strictly standard compliant in the 
real world.

I did also say that a strictly standard compliant implementation can 
hardly be blamed for being so, and underlined the fact that deciding to 
be "strict in what you produce/liberal in what you accept" should take 
into account the possible security impacts, especially in the context of 
PKIX.

Regards,

--
Julien

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Nov 2008 10:28:42 -0500

Julien,

But, the IETF works to create standards based on the consensus of 
knowledgeable individuals who chose to participate in the IETF 
standards process. I don't think it's appropriate to skew our 
standards to accommodate the practices of any (large) vendor who 
violates our standards, and I'd rather we not debate this in the 
context of an IETF standards WG.

Steve

---

From: "Sood, Kapil" <[email-masked]>
Date: Tue, 18 Nov 2008 08:26:40 -0800

A testing (inter-op, certification) along these lines will be of immense value to numerous organizations that deploy PKI components...

Best Regards,
 
Kapil.
971.506.1700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Tuesday, November 18, 2008 7:24 AM
To: Timothy J. Miller
Cc: Eric Norman; [email-masked]
Subject: Re: encoding an X.509 certificate

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Nov 2008 11:29:50 -0500

At 5:01 PM +0100 11/18/08, Julien Stern wrote:
>My apologies if this was considered inapropriate, I was being ironic 
>(as somehow indicated by the smiley). Please only read it as a way 
>to pinpoint the difficulties of being strictly standard compliant in 
>the real world.
>
>hardly be blamed for being so, and underlined the fact that deciding 
>to be "strict in what you produce/liberal in what you accept" should 
>take into account the possible security impacts, especially in the 
>context of PKIX.
>
>Regards,
>
>--
>Julien

Thanks for the clarifying  message.

Steve

---

From: Julien Stern <[email-masked]>
Date: Tue, 18 Nov 2008 17:50:13 +0100

Stephen Kent wrote:
>> (as somehow indicated by the smiley). Please only read it as a way to 

Steve,

as a side note, while it may already implicitly be the case, a strongly 
worded statement by PKIX that implementations should reject all these 
"bogus" certificates (in BER, with negative serials, without critical 
extensions when they have to be, etc) would certainly help smaller 
vendors to "plead their cause" when they are told that their software 
"do not work" (well, if there is indeed a consensus on this statement, 
of course).

Regards,

--
Julien

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 18 Nov 2008 13:29:05 -0600

We need to be careful to distinguish between "bogus" certificates and 
certificates that were not issued in conformance with RFC 5280.  While 
RFC 5280 requires conforming CAs to use positive serial numbers, there 
is no such requirement in X.509.  Similarly, while X.509 requires that 
some public key certificate extensions be marked non-critical, X.509 
does not require that any public key certificate extensions be marked 
critical.  There are, however, a few CRL and CRL entry extensions that 
X.509 says must be marked critical.

Dave

Julien Stern wrote:
> Steve,
>
> as a side note, while it may already implicitly be the case, a 
> strongly worded statement by PKIX that implementations should reject 
> all these "bogus" certificates (in BER, with negative serials, without 
> critical extensions when they have to be, etc) would certainly help 
> smaller vendors to "plead their cause" when they are told that their 
> software "do not work" (well, if there is indeed a consensus on this 
> statement, of course).
>
> Regards,
>
> -- 
> Julien
>

---

From: Michael StJohns <[email-masked]>
Date: Tue, 18 Nov 2008 14:54:15 -0500

X509 actually - in a backwards way - requires one extension to be marked critical.  The text in X509 is "If this extension field is present and is flagged critical, the subject field of the certificate may contain a null name (e.g., a sequence of zero relative distinguished names) in which case the subject is identified only by the name or names in this extension. "  - note 2 under 8.3.2.1

This refers to the SubjectAltName extension.  Another way of stating it (and this is how 5280 states it) - if the subject field has a null name, there MUST be a subjectAltName and it MUST be critical.

Mike

At 02:29 PM 11/18/2008, David A. Cooper wrote:

>We need to be careful to distinguish between "bogus" certificates and certificates that were not issued in conformance with RFC 5280.  While RFC 5280 requires conforming CAs to use positive serial numbers, there is no such requirement in X.509.  Similarly, while X.509 requires that some public key certificate extensions be marked non-critical, X.509 does not require that any public key certificate extensions be marked critical.  There are, however, a few CRL and CRL entry extensions that X.509 says must be marked critical.
>
>Dave
>
>Julien Stern wrote:
>>Steve,
>>
>>as a side note, while it may already implicitly be the case, a strongly worded statement by PKIX that implementations should reject all these "bogus" certificates (in BER, with negative serials, without critical extensions when they have to be, etc) would certainly help smaller vendors to "plead their cause" when they are told that their software "do not work" (well, if there is indeed a consensus on this statement, of course).
>>
>>Regards,
>>
>>-- 
>>Julien

---

From: Steven Legg <[email-masked]>
Date: Wed, 19 Nov 2008 10:23:51 +1100

Tom,

Tom Gindin wrote:
> general purpose library code.

I'm convinced that it cannot in the general case. You've touched on the
main problem, which is that it is necessary to have perfect knowledge of
the ASN.1 type of an abstract value in order to be able to correctly
re-encode the value in a different set of encoding rules (including the
canonical version of the original encoding). For signed operations in
X.500, for example, it isn't practical to have complete knowledge of the
ASN.1 type of every part of an operation. It's for that reason that X.509
has this to say at the end of clause 6.1:

     The Directory shall follow these rules:

         – It shall preserve the encoding of received information whose
           abstract syntax it does not fully know and which it expects to
           subsequently sign;

         – When signing data for sending, it shall send data whose syntax
           it fully knows with a distinguished encoding and any other data
           with its preserved encoding, and shall sign the actual encoding
           it sends;

         – When checking signatures in received data, it shall check the
           signature against the actual data received rather than its
           conversion of the received data to a distinguished encoding.

Even when the ASN.1 type is fully known, there are still problems. For
one, the DER canonicalization rules for TeletexString are woefully
inadequate. If a BER or DER encoding containing TeletexString values
is re-encoded in, say, XER, which transcodes into UTF-8, then there is
no guarantee that the original encoding will be recoverable. Add to that,
that implementations of TeletexString encoding are often limited and/or
technically non-conformant. If implementors can't get TeletexString right
then they won't be able to get TeletexString canonicalization rules right
either (if they exist at some point in the future). Another problem is
that canonicalization of local time for GeneralizedTime is broken.

As a solution, signing what one sends and preserving what one receives
is simpler to implement, easier to get right, more efficient, and
free of the gotcha's that plague canonical encodings, so why do we
persist with canonical encodings ?

Regards,
Steven

> One can verify that the certificate down to

---

From: Eric Norman <[email-masked]>
Date: Tue, 18 Nov 2008 17:53:08 -0600

> software "do not work" (well, if there is indeed a consensus on this 

As to serial numbers, RFC 5280 already says this:

    Note: Non-conforming CAs may issue certificates with serial numbers
    that are negative or zero.  Certificate users SHOULD be prepared to
    gracefully handle such certificates.

If the intent is that "SHOULD ... gracefully" means that the certificate
must be rejected, then it would be a good idea to say that.  If the
meaning of "SHOULD .. gracefully" is that the robustness principle is
applicable, then it would be a good idea to say so.

Another personal opinion: in this particular case, some of the blame
for non-compliance rests with PKIX.  The requirement that serial
numbers be a positive INTEGER instead of an OCTET_STRING seems silly.

Eric Norman

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Nov 2008 00:39:21 +0000

> numbers be a positive INTEGER instead of an OCTET_STRING seems silly.

Well, the field is an INTEGER and not an OCTET STRING so that choice
isn't available (and if a mistake was made it happened in the 1980's).

The positive integer thing was (as I recall) due to early CA code
generating serials in various ways (e.g. via hashes) but then not
encoding them correctly. I think it was that if the MSB was a 1
and you don't add a 0x00 in front, then the serial is a negative
and that caused problems for matching serial numbers for various
bits of RP code.

I think the positive integer restriction is fine. But it'd be no
harm to generate an erratum for 5280 if you feel that the
"SHOULD...gracefully" isn't  sufficiently clear.

Stephen.

---

From: Steven Legg <[email-masked]>
Date: Wed, 19 Nov 2008 10:23:51 +1100

Tom,

Regards,
Steven

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 19 Nov 2008 05:17:48 +0000

Correct me if I'm wrong, but the core of this issue seems to be a scenario where a certificate is stored in some system. This system is ASN.1 aware and for some reason refuse to store the certificate as is as a chunk of arbitrary bytes, but choose to decode the ASN.1 and store the inner data elements instead together with the signature. Once retrieved again, the system reassembles the certificate using its knowledge about ASN.1 and X.509 certificates for the process. Unfortunately it deploys illegal encoding (BER or XXXER) and delivers back a certificate where the associated signature no longer matches the encoded certificate.

Russ seems to have encountered such system in a distant past.

But are there really any system with any significance around today that operates this way?
Somehow I have a hard time to believe there is.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> On Behalf Of Stephen Farrell
> Sent: den 18 november 2008 18:39
> To: Eric Norman
> Cc: [email-masked]

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 20 Nov 2008 19:49:29 +1300

Paul Hoffman <[email-masked]> writes:

>However, as Peter points out, there seems to be little interest on the part
>of the CA ven dors to enforce the rules of X.509 and PKIX.

There's been an off-list discussion of various instances of this, I don't want
to start quoting other people's private mail but here's a sample from my part
of the discussion:

  The pushback from users of commercial CAs ("It's a large commercial CA, they
  can't be wrong!") is even worse than the "We have thousands of certs already
  deployed" that you mention.  The worst ones are the "This is a CA certified
  and approved by our government, we can't even ask them to fix things".

This isn't going to get fixed, ever.  I have a marvellously broken cert chain
created some years ago by a particular government-approved CA (who were
notified of the problem and requested to fix it) and it expired recently, so I
asked someone in the country where they issue certs whether I could get a
recent cert chain from them (these things make for nice test cases :-).  They
sent me a new cert chain, still broken as before.

When your decision on what to do can be rephrased as "Would you like to
continue doing business in country X?" then the choices are rather limited
(particularly when your company is based in country X and depends heavily on
government contracts, as these guys were).

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 22 Nov 2008 18:42:37 +1300

Julien Stern <[email-masked]> writes:

>Just recently, we encountered a certificate whose serial number was negative.
>The RFC very specifically states that serial numbers MUST be positive
>integers. Now, it is easy to decode such a certificate, and actually, most
>ASN.1 libraries will not even figure out that this number is negative unless
>someone has specified a constraint or if there is an explicit check on this
>number. So, should certificate validation fail?

Given the amount of software that has created these certs in the past
(including one from a vendor called Microsoft, you may have heard of them,
their products have a fair bit of market share), the answer is:

  Yes, if you want your product to fail in the marketplace.

Most parsers that I know of treat all ints as unsigned to deal with the number 
of implementations that forget there's a sign bit at the start when people use 
a MD5/SHA1 hash as a serial number or other such integer, and those that 
didn't initially get modified fairly quickly if they have any exposure to 
real-world certs.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 22 Nov 2008 19:00:05 +1300

"Timothy J. Miller" <[email-masked]> writes:

>If it provided a service mark for use by a vendor?  Quite a bit.  Most of the
>major standards do this and it does work (mostly).

This is exactly what I proposed in my talk at the (then) PKI workshop several
years ago (and then shot down over dinner, since I ran out of time during my
talk to point out why this particular proposal was mostly a strawman :-).  The
problem is, to use David's example of e-cycling, that for something like that
you can show photos of 12-year-old kids boiling circuit boards in acid and the
public will be horrified and demand that something be done.  With
certificates, no-one cares (or at least no-one outside this list and maybe a
few procurement managers somewhere going down a checklist).

So let's say you do set up a service mark, you certify things against it, you
can even make it a USG purchasing requirement that they only buy certified
products, and the same vendors that already craft their products to fit that
particular market keep doing so and everyone else ignores it and nothing
changes.  In my talk at the time I made the observation that I can't think of
a big enough hammer to get this any traction, and the situation hasn't got any
better since.  For USB/HDMI/WUSB/whatever you've got industy consortia that
you have to sign up to and pay license fees to when you introduce a new
product so the old-school-tie process works (and even then for USB only the
minutest fraction of the vast, elephantine bulk that is the USB spec is
actually checked, and even that only barely, see the source code for any USB
driver for proof), but for PKI the universal acceptance check is "if I click
on this in Windows, will it get accepted without an error message?".

What's going to make this even worse is that if the certification really does
test compliance with some of the silly-walks required by the spec, a certified
product will be less interoperable than a non-certified one.  So you end up
trying to certify something that no-one cares about, and where certification
results in less interoperability than being non-certified.

Yeah, that one'll really fly.

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 23 Nov 2008 08:51:31 +0200

On Nov 22, 2008, at 8:00 AM, Peter Gutmann wrote:

> changes.

Oh, but we can make our firewalls inspect TLS handshakes, and drop all  
the ones where the certificate is not properly signed and properly DER.
Then buying at Amazon from work won't work.
Then everybody turns off the feature.
Or we go out of business.
Never mind.

But seriously, a few governments could make a difference, but they  
don't care that much either. It's perceived (and probably rightly so)  
as a problem of interoperability that the Windows people and the  
OpenSSL people have already solved for us.

> In my talk at the time I made the observation that I can't think of

That's very 2004. Maybe even earlier. Now you need to be able to click  
this on Macs, Firefox, and Safari.  Seriously, at least for HTML this  
did make a difference. Websites today are much better written than  
they were at the time when 90% of browsing was done on IE.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 27 Nov 2008 00:23:17 +0100

> certificates from various sources who can encode them whichever way.

When implementing the cert viewer in web2ldap it took me quite a while 
to believe how broken certs of major CAs are. So my development 
performance was really bad. And yes, like all others I've added a 
work-around...

Ciao, Michael.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 26 Nov 2008 21:42:53 -0500

Michael,

The question remains what it does to interoperability and performance since I suspect you are not the sole provider of PK enablement software to the world.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Ströder
Sent: Wednesday, November 26, 2008 6:23 PM
To: [email-masked]
Subject: Re: encoding an X.509 certificate

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 27 Nov 2008 12:03:37 +0100

Santosh Chokhani wrote:
> 
> The question remains what it does to interoperability and performance
> since I suspect you are not the sole provider of PK enablement
> software to the world.

I think the work-arounds added to some software can even lead to 
security problems since the issues are also with the certs' structure 
(not only the encoding).
As an extreme example: I remember discussions on another mailing list 
where a developer even argued to ignore the SEQUENCE's order of subject 
and issuer names. (I guess Peter Sylvester will also remember this 
strange discussion since he raised the issue with wrong name ordering on 
this mailing list.)

Ciao, Michael.

---

From: Steven Legg <[email-masked]>
Date: Fri, 28 Nov 2008 10:51:48 +1100

Santosh,

> The question remains what it does to interoperability and performance since I suspect you are not the sole provider of PK enablement software to the world.

I've lost track of what "it" is, but maybe this will answer your
question. There are four possibilities to consider when a relying
party receives some signed data:

(1) the signature is calculated over the DER encoding of the data
     to be signed and the RP receives this DER encoding, or

(2) the signature is calculated over the DER encoding of the data
     to be signed and the RP receives a non-DER re-encoding
     of the signed data, or

(3) the signature is calculated over a non-DER encoding of the data
     to be signed and the RP receives this same non-DER encoding, or

(4) the signature is calculated over a non-DER encoding of the data
     to be signed and the RP receives a different re-encoding of the
     signed data.

There are two basic strategies an RP can use to attempt to validate
the signature on the signed data:

(a) check the signature using the encoding as received, or

(b) re-encode the received encoding into DER and check the
     signature using the DER encoding.

An RP that just does (a) will validate the signature in cases (1) and (3).
An RP that just does (b) will validate the signature in cases (1) and (2).
There is no practical way of dealing with case (4), so we can disregard it.

We know that signatures calculated over non-DER encodings are accepted
in practice so implementations must generally be avoiding the re-encoding
of signed data. Therefore I expect that (3) is more common than (2), in
which case an RP that does only (a) will have better interoperability than
an RP that does only (b).

To maximise interoperability an RP needs to try both (a) and (b), in
which case it will validate the signature in cases (1), (2) and (3).
If it tries (a) first, then in the best case (i.e., (1) or (3)) it only
does one signature check, and in the worst case (i.e., (2)) it does two
signature checks and a DER re-encoding of the signed data. If it tries
(b) first, then in the best case (i.e., (1) or (2)) it does a DER
re-encoding of the signed data and one signature check, and in the
worst case (i.e., (3)) it does two signature checks and a DER re-encoding
of the signed data.

The "(a) first" strategy is more efficient for (1) and (3), and the
"(b) first" strategy is more efficient for (2). Since I expect (3) is
more common than (2), "(a) first" will be the more efficient strategy
overall.

Regards,
Steven

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 28 Nov 2008 12:45:24 +0100

Hi all,

The reference to X.509 seems to indicate that one should check (a)
and is not required to do (b).
I had forgotten that X.509 was so strict , "shall" means "MUST" in ISO 
terms.

regards

Steven Legg wrote:
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Michael Ströder
>> When implementing the cert viewer in web2ldap it took me quite a 
>> while to believe how broken certs of major CAs are. So my development 

-- 

<http://www.edelweb.fr>

---

From: Tom Gindin <[email-masked]>
Date: Fri, 28 Nov 2008 22:06:12 -0500

Steven:

        Is your recommendation for re-encoding (in case b) that an RP 
should re-encode everything other than extension values into DER, or that 
it should also re-encode extension values whose syntax it recognizes?  The 
statement "re-encode the received encoding into DER" cannot always be 
executed on the values of unrecognized extensions, as I hope I've 
demonstrated in earlier posts, although indefinite length encodings can 
always be eliminated.

                Tom Gindin

Steven Legg <[email-masked]> 
Sent by: [email-masked]
11/27/2008 06:51 PM

To
Santosh Chokhani <[email-masked]>
cc
Michael Ströder <[email-masked]>, [email-masked]
Subject
Re: encoding an X.509 certificate

Santosh,

> The question remains what it does to interoperability and performance 
since I suspect you are not the sole provider of PK enablement software to 
the world.

An RP that just does (a) will validate the signature in cases (1) and (3).
An RP that just does (b) will validate the signature in cases (1) and (2).
There is no practical way of dealing with case (4), so we can disregard 
it.

Regards,
Steven

> From: [email-masked] [mailto:[email-masked]] 
On Behalf Of Michael Ströder

---

From: Steven Legg <[email-masked]>
Date: Mon, 01 Dec 2008 11:58:56 +1100

Tom,

Tom Gindin wrote:
> it should also re-encode extension values whose syntax it recognizes?

In the case of certificate extensions, as far as the ASN.1 is concerned
the extension values are OCTET STRING values so they are not prone to
being altered by vanilla decoders and encoders. I think it is adequate
to leave them as is when re-encoding a certificate in DER, which is
the technically correct thing to do anyway. More so than with the
certificate as a whole, the RP is likely to have received the extension
value encodings that were actually signed.

Of course one could be ultra-interoperable and try the DER re-encoding
both ways.

Regards,
Steven

 > The
> executed on the values of unrecognized extensions,as I hope I've 

Date: Mon, 01 Dec 2008 11:58:56 +1100
From: Steven Legg <[email-masked]>
To: Tom Gindin <[email-masked]>
CC: [email-masked], =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>, Santosh Chokhani <[email-masked]>
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

Tom,

Tom Gindin wrote:
> it should also re-encode extension values whose syntax it recognizes?

In the case of certificate extensions, as far as the ASN.1 is concerned
the extension values are OCTET STRING values so they are not prone to
being altered by vanilla decoders and encoders. I think it is adequate
to leave them as is when re-encoding a certificate in DER, which is
the technically correct thing to do anyway. More so than with the
certificate as a whole, the RP is likely to have received the extension
value encodings that were actually signed.

Of course one could be ultra-interoperable and try the DER re-encoding
both ways.

Regards,
Steven

 > The
> executed on the values of unrecognized extensions,as I hope I've 

Date: Sat, 29 Nov 2008 16:05:55 -0500
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: pkix <[email-masked]>
Subject: New I-D for PRQP published
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms000600000101030905040109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi PKIX,

as promised in Minneapolis I published the new version of the PRQP I-D with
all the announced changes:

    http://www.ietf.org/internet-drafts/draft-ietf-pkix-prqp-01.txt

I added a lot of text for describing the OIDs. Being the first version of the
I-D carrying all the description, I would really appreciate if you could
provide me with feedback especially on them.

I also added the annex on how to use DNS SRV records and DHCP to distribute
the RQA address. Moreover I contacted Ralph Droms from the dhc WG and let him
know that the new version is published. I expect to receive feedback from the
dhc WG on Section B.1 (hopefully soon).

Happy thanksgiving to all of you who celebrated it...

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]  [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------
People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

--------------ms000600000101030905040109
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms000600000101030905040109--

Date: Sat, 29 Nov 2008 16:44:43 +0100
From: "=?ISO-8859-1?Q?Jorge_L=F3pez?=" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Cc: [email-masked]
Sender: [email-masked]

------=_Part_80624_20426458.1227973483990
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi all,
In Spain, we are (un)fortunatelly one of the few countries that have moved
the EU Directive on Electronic Signatures to a National Law. Now, users own
insecure tools to create non-repudiable and legally-binding e-signatures.
What is going on with current business model? Do the users have to cope with
the legal consequences of a signature created on their behalf, just because
a cryptographic validation of a set of bits says that?

The purposes derived from a handwritten signature have been directly
translated to the digital realm by means of PKI and cryptography. However,
the conditions and threats under which a signature is generated in the
digital realm are obviously far away from those of the physical realm. IMHO,
the main reason that make current business model fail is precisely the
uncertainty that end users have respecting the actual security of
PKI-enabled applications and the founded "legal support".

Regards,

Jorge L. Hernandez-Ardieta

2008/11/18 Anders Rundgren <[email-masked]>

>  Some 15 years ago the EU launched a signature directive.  This posting
> tries to describe the consequences of this directive with respect to usage
> of PKI.
>
> *Primary Motivation*
>
> There are a number of processes needing a human-written signature in order
> to fulfill legal requirements.
>
> Some of these processes could without doubt be possible to carry out
> electronically and thus also remote over a network, if there was some kind
> of technology available that could serve as a replacement for a hand-written
> signature.
>
> *The Solution*
>
> Right or wrong, digital signatures using PKI were considered as a
> viable alternative.  To make PKI a credible solution, the EU signature
> directive added a number of requirements including characteristics of the
> signature creation device and policies for CAs.
>
> *Current Deployment*
>
> Apart from Qualified Certificates which (for reasons too diverse for
> describing in an email) have not become truly mainstream, the EU signature
> directive have indeed in local legislations made it possible to perform
> fairly qualified tasks remotely over the Internet.  I.e. the directive has
> functioned as an *ENABLER*.
>
> *Then Something Went Wrong...*
>
> Unfortunately, a few (but influential) people got a bit carried away and
> interpreted the signature directive in way that has severely hampered the
> use of PKI.  Essentially they began claiming that all messages in order to
> be trustworthy should be signed by a qualified signature or at least by a
> digital signature created under the direct control a human being.
>
> From a 50000 ft perspective this may sound like a great idea, but the fact
> is that decades before the signature directive was conceived; yes, even
> before PKI was invented, the concept of secure messaging actually
> existed.  Back in those days secure messaging was facilitated through the
> use of leased lines which allowed banks (and some early b2b networks), to
> securely exchange transaction messages *in a completely automated fashion*
> .
>
> An example:  If you want to wire-transfer money from your bank to another
> bank, the way the transfer is initiated (phone, paper, on-line, etc) has no
> impact on the transaction messaging because it is performed in a transaction
> network that neither the customers, nor most of the staff have direct access
> to.
>
> That such networks have proved to be secure, reliable, cost-efficient, and
> sometimes even globally scalable, apparently did not impress the bunch of
> hard-core signature experts who for example in Germany managed to make PKI a
> *DISABLER* by outlawing non-human digital signatures on invoices.  That
> German paper-invoices do not even require signatures makes this position a
> true mystery.
>
> One had hoped that this would be an exception to the rule but it is not; If
> you scan sites like NIST.GOV, CIO.GOV, and GSA.GOV you'll find literally
> thousands of security-related documents, indeed in a few places mentioning
> PKI, but mostly full of government regulation abbreviations like FISMA,
> giving little if any guidance on how to create secure messaging between
> agencies, not to mention between agencies and the private sector.
>
> I'm happy to see that the Nordic countries plus Estonia have realized that
> all signatures that can be securely bound to an entity (in practice) are
> legally binding, in the extremely rare case somebody would actually
> repudiate a signed invoice.   These governments have all (and independently
> of each other) created local variants of a scheme that I have described in:
> http://webpki.org/papers/web/gateway.pdf
> which could be characterized as a 21st century version of leased lines for
> multi-party automated secure messaging.
> It will probably take another 15 years for this concept to achieve general
> acceptance although it is really (if you look closely) very similar to the
> US e-Authentication scheme, they have just not connected the dots yet: A
> SAML assertion and an server-signed invoice from a specific entity are
> essentially only different in content, not in trustworthiness.
>
> Anders Rundgren
> http://WebPKI.org
>
>
>

------=_Part_80624_20426458.1227973483990
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi all,<div><br></div><div>In Spain, we are&nbsp;(un)fortunatelly one of the few countries that have moved the EU Directive on Electronic Signatures to a National Law. Now, users own insecure tools to create non-repudiable and legally-binding e-signatures. What is going on with current business model? Do the users have to cope with the legal consequences of a signature created on their behalf, just because a cryptographic validation of a set of bits says that?</div>
<div><br></div><div>The purposes derived from a handwritten signature have been directly translated to the digital realm by means of PKI and cryptography. However, the conditions and threats under which a signature is generated in the digital realm are obviously far away from those of the physical realm. IMHO, the main reason that make current business model fail is precisely the uncertainty that end users have respecting the actual security of PKI-enabled applications and the founded &quot;legal support&quot;.</div>
<div><br></div><div>Regards,</div><div><br></div><div>Jorge L. Hernandez-Ardieta</div><div><br><div class="gmail_quote">2008/11/18 Anders Rundgren <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div bgcolor="#ffffff">
<div><font face="Arial" size="2">Some 15 years ago the EU launched a signature 
directive.&nbsp; This posting tries to describe the consequences of this 
directive with respect to usage of PKI.</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial"><strong>Primary Motivation</strong></font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">There are a number of processes&nbsp;needing a 
human-written signature in order to fulfill legal requirements.</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">Some of these processes could without doubt be 
possible to carry out electronically and thus also remote over a network, if 
there was some kind of technology available that could serve as a replacement 
for a hand-written signature.</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial"><strong>The Solution</strong></font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">Right or wrong, digital signatures using PKI were 
considered as&nbsp;a viable&nbsp;alternative.&nbsp; To make PKI a credible 
solution, the EU signature directive added a number of requirements including 
characteristics of the signature creation device and policies for 
CAs.</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial"><strong>Current Deployment</strong></font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2"><font face="Arial" size="2">Apart from Qualified 
Certificates which (for reasons too diverse for describing in an email) have not 
become truly mainstream, the EU signature directive have indeed in local 
legislations made it possible to perform fairly qualified tasks remotely over 
the Internet.&nbsp; I.e. the directive has functioned as an 
<strong>ENABLER</strong>.</font></font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial"><strong>Then Something 
Went&nbsp;Wrong...</strong></font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">Unfortunately, a few (but&nbsp;influential) people 
got a bit carried away and interpreted the signature directive in way that has 
severely hampered the use of PKI.&nbsp; Essentially they began claiming that all 
messages in order to be&nbsp;trustworthy should be signed by a qualified 
signature or at least by a digital signature created&nbsp;under the direct 
control&nbsp;a human being.</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">From a 50000 ft perspective this may sound like a 
great idea, but the fact is that decades before the signature directive was 
conceived; yes, even before PKI was invented, the concept of secure messaging 
actually existed.&nbsp;&nbsp;Back in those days&nbsp;secure messaging was 
facilitated through the use of leased lines which allowed banks (and some early 
b2b networks), to securely exchange transaction messages <em>in a completely 
automated fashion</em>.</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">An example:&nbsp; If you want to wire-transfer 
money from your bank to another bank, the way the transfer is initiated (phone, 
paper,&nbsp;on-line, etc)&nbsp;has no impact on the transaction messaging 
because it is&nbsp;performed in a transaction network that neither 
the&nbsp;customers, nor&nbsp;most of the staff have direct access 
to.&nbsp;</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">That&nbsp;such networks have proved to be secure, 
reliable, cost-efficient, and sometimes even globally scalable, apparently did 
not impress the bunch of hard-core signature experts who for example in Germany 
managed to make PKI a <strong>DISABLER</strong> by outlawing non-human digital 
signatures on invoices.&nbsp; That German paper-invoices do not even require 
signatures&nbsp;makes this position a true mystery.</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">One had hoped that this would be an exception to 
the rule but it is not; If you scan sites like <a href="http://NIST.GOV" target="_blank">NIST.GOV</a>, <a href="http://CIO.GOV" target="_blank">CIO.GOV</a>, and <a href="http://GSA.GOV" target="_blank">GSA.GOV</a> 
you&#39;ll find literally thousands of security-related documents, indeed in a few 
places mentioning PKI, but mostly full of government regulation abbreviations 
like FISMA, giving little if any guidance on how to create secure messaging 
between agencies, not to mention between agencies and the private 
sector.</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">I&#39;m happy to see&nbsp;that the Nordic countries 
plus Estonia have realized that all signatures that can be securely bound to an 
entity (in practice) are legally binding, in the extremely rare case somebody 
would actually repudiate a signed invoice.&nbsp;&nbsp; These governments have 
all (and independently of each other) created local variants of&nbsp;a scheme 
that I have described in:</font></div>
<div><a href="http://webpki.org/papers/web/gateway.pdf" target="_blank"><font face="Arial" size="2">http://webpki.org/papers/web/gateway.pdf</font></a></div>
<div><font face="Arial" size="2">which&nbsp;could be characterized as&nbsp;a 21st 
century version of leased lines for multi-party&nbsp;automated secure 
messaging.</font><br></div>
<div><font face="Arial" size="2">It will probably take another 15 years for this 
concept to achieve general acceptance although it is really (if you look 
closely) very similar&nbsp;to the US e-Authentication scheme, they have just not 
connected the dots yet:&nbsp;A SAML assertion and an server-signed&nbsp;invoice 
from a specific entity are essentially only different in content, not in 
trustworthiness.</font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2">Anders Rundgren</font></div>
<div><font face="Arial" size="2"><a href="http://WebPKI.org" target="_blank">http://WebPKI.org</a></font></div>
<div><font face="Arial" size="2"></font>&nbsp;</div>
<div><font face="Arial" size="2"></font>&nbsp;</div></div>
</blockquote></div><br></div>

------=_Part_80624_20426458.1227973483990--

Date: Sat, 29 Nov 2008 13:01:55 +0100
From: "=?ISO-8859-1?Q?Jorge_L=F3pez?=" <[email-masked]>
To: [email-masked]
Subject: Re: Signing and Encrypting with the same key?
Sender: [email-masked]

------=_Part_79160_8051648.1227960116017
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi all,
This mail was intented for the past discussion about if using the same key
pair for encrypting and signing may derive in a reduction of the security of
the scheme. Sorry if it's too late for that, but I haven't had the URL to
the paper so far. The URL points to the recent results of a research
(preprint version) made by a spanish colleague of mine where they actually
prove the security or insecurity of using the same key pair in both
encryption and signature schemes, depending on the specific situation.

http://eprint.iacr.org/2008/466

Hope this (still) help a bit

Regards,

Jorge L. Hernandez-Ardieta

2008/11/17 Kemp, David P. <[email-masked]>

> > From: Stephen Wilson
> > I'd like to know the precise
> > history of the NR bit in X.509.  Who actually thought of it, were they
> > an engineer or a lawyer, and what if any debate went on at the time?
>
> Trust me, you really, REALLY don't want to know :-).
>
> Those on one side of the argument thought that the NR bit set should be
> used for signatures that could be validated indefinitely (i.e. for what one
> normally thinks of as "signing"), and signatures with the NR bit clear could
> be used only for session authentication.  That way a signed object created
> as part of a login session could not be misrepresented as a signed document.
>
> Those on the other side thought that the NR bit actually had something to
> do with "repudiating" signatures, which IMHO is a ridiculous idea for the
> reasons you suggest.  Those who believe in the current X.509 interpretation
> may defend it if they wish, or spare us the discussion.
>
> Dave
>

------=_Part_79160_8051648.1227960116017
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<span class="Apple-style-span" style="border-collapse: collapse; ">Hi all,<div><br></div><div>This mail was intented for the past discussion about if using the same key pair for encrypting and signing may derive in a reduction of the security of the scheme. Sorry if it&#39;s too late for that, but I haven&#39;t had the URL to the paper so far. The URL points to&nbsp;the recent results of a research (preprint version) made by a spanish colleague of mine where they actually prove the security or insecurity of using the same key pair in both encryption and signature schemes, depending on the specific situation.</div>
<div><br></div><div><a href="http://eprint.iacr.org/2008/466">http://eprint.iacr.org/2008/466</a><br></div><div><br></div><div><span style="border-collapse: collapse; ">Hope this&nbsp;(still)&nbsp;help a bit&nbsp;</span></div><div><span style="border-collapse: collapse; "><br>
</span></div><div><span style="border-collapse: collapse; ">Regards,</span></div><div><span style="border-collapse: collapse; "><br></span></div><div><span style="border-collapse: collapse; ">Jorge L. Hernandez-Ardieta</span></div>
</span><br><div class="gmail_quote">2008/11/17 Kemp, David P. <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d"><br>
<br>
-----Original Message-----<br>
&gt; From: Stephen Wilson<br>
&gt;<br>
&gt; I&#39;d like to know the precise<br>
&gt; history of the NR bit in X.509. &nbsp;Who actually thought of it, were they<br>
&gt; an engineer or a lawyer, and what if any debate went on at the time?<br>
<br>
</div>Trust me, you really, REALLY don&#39;t want to know :-).<br>
<br>
Those on one side of the argument thought that the NR bit set should be used for signatures that could be validated indefinitely (i.e. for what one normally thinks of as &quot;signing&quot;), and signatures with the NR bit clear could be used only for session authentication. &nbsp;That way a signed object created as part of a login session could not be misrepresented as a signed document.<br>

<br>
Those on the other side thought that the NR bit actually had something to do with &quot;repudiating&quot; signatures, which IMHO is a ridiculous idea for the reasons you suggest. &nbsp;Those who believe in the current X.509 interpretation may defend it if they wish, or spare us the discussion.<br>

<br>
Dave<br>
</blockquote></div><br>

------=_Part_79160_8051648.1227960116017--

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-prqp-01.txt 
Date: Fri, 28 Nov 2008 20:15:01 -0800 (PST)
Sender: [email-masked]

--NextPart

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           : PKI Resource Query Protocol (PRQP)
	Author(s)       : M. Pala
	Filename        : draft-ietf-pkix-prqp-01.txt
	Pages           : 34
	Date            : 2008-11-28

One of the most strategic problems still open in PKIX is locating
public data and services associated with a Certification Authority
(CA).  This issue impacts interoperability and usability in PKIX.

This draft describes the PKI Resource Query Protocol (PRQP), its
design, definition, and its impact in already deployed PKIX
protocols.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-pkix-prqp-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

To: Steven Legg <[email-masked]>
Cc: [email-masked], =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>, Santosh Chokhani <[email-masked]>
Subject: Re: encoding an X.509 certificate
From: Tom Gindin <[email-masked]>
Date: Fri, 28 Nov 2008 22:06:12 -0500
Sender: [email-masked]

        Steven:

        Is your recommendation for re-encoding (in case b) that an RP=20
should re-encode everything other than extension values into DER, or that=20
it should also re-encode extension values whose syntax it recognizes?  The =

statement "re-encode the received encoding into DER" cannot always be=20
executed on the values of unrecognized extensions, as I hope I've=20
demonstrated in earlier posts, although indefinite length encodings can=20
always be eliminated.

                Tom Gindin

Steven Legg <[email-masked]>=20
Sent by: [email-masked]
11/27/2008 06:51 PM

To
Santosh Chokhani <[email-masked]>
cc
Michael Str=F6der <[email-masked]>, [email-masked]
Subject
Re: encoding an X.509 certificate

Santosh,

Santosh Chokhani wrote:
> Michael,
>=20
> The question remains what it does to interoperability and performance=20
since I suspect you are not the sole provider of PK enablement software to =

the world.

An RP that just does (a) will validate the signature in cases (1) and (3).
An RP that just does (b) will validate the signature in cases (1) and (2).
There is no practical way of dealing with case (4), so we can disregard=20
it.

Regards,
Steven

>=20
> From: [email-masked] [mailto:[email-masked]] =

On Behalf Of Michael Str=F6der
>=20
>=20
>=20
> When implementing the cert viewer in web2ldap it took me quite a while=20
> to believe how broken certs of major CAs are. So my development=20
> performance was really bad. And yes, like all others I've added a=20
> work-around...
>=20
> Ciao, Michael.
>=20

Date: Fri, 28 Nov 2008 12:45:24 +0100
From: Peter Sylvester <[email-masked]>
To: Steven Legg <[email-masked]>
Cc: Santosh Chokhani <[email-masked]>, =?ISO-8859-1?Q?Michael_S?= =?ISO-8859-1?Q?tr=F6der?= <[email-masked]>, [email-masked]
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms050403060307010308080902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi all,

The reference to X.509 seems to indicate that one should check (a)
and is not required to do (b).
I had forgotten that X.509 was so strict , "shall" means "MUST" in ISO=20
terms.

regards

Steven Legg wrote:
>
>
> Santosh,
>
> Santosh Chokhani wrote:
>> Michael,
>>
>> The question remains what it does to interoperability and performance =

>> since I suspect you are not the sole provider of PK enablement=20
>> software to the world.
>
> An RP that just does (a) will validate the signature in cases (1) and=20
> (3).
> An RP that just does (b) will validate the signature in cases (1) and=20
> (2).
> There is no practical way of dealing with case (4), so we can=20
> disregard it.
>
> in practice so implementations must generally be avoiding the re-encodi=
ng
> of signed data. Therefore I expect that (3) is more common than (2), in=

> which case an RP that does only (a) will have better interoperability=20
> than
> If it tries (a) first, then in the best case (i.e., (1) or (3)) it only=

> does one signature check, and in the worst case (i.e., (2)) it does two=

> worst case (i.e., (3)) it does two signature checks and a DER re-encodi=
ng
>> From: [email-masked]=20
>> [mailto:[email-masked]] On Behalf Of Michael Str=F6der
>> When implementing the cert viewer in web2ldap it took me quite a=20
>> while to believe how broken certs of major CAs are. So my development =

>> performance was really bad. And yes, like all others I've added a=20
>> work-around...
>>
>> Ciao, Michael.
>>
>
>

--=20

<http://www.edelweb.fr>
*Edel/W/eb* 	Peter SYLVESTER
Consultant S=E9curit=E9 des Syst=E8mes d'Information
-----------------------------------------------------------
EdelWeb - Groupe ON-X
15, quai de Dion-Bouton
F-92816 Puteaux Cedex
Tel : +33.1.40.99.14.14 / Fax : +33.1.40.99.99.58
www.edelweb.fr <http://www.edelweb.fr> / www.on-x.com <http://www.on-x.co=
m>
-----------------------------------------------------------
To verify the message signature, see edelpki.edelweb.fr=20
<http://edelpki.edelweb.fr/>
Cela vous permet de charger le certificat de l'autorit=E9 de racine=20
<http://edelpki.edelweb.fr/cacerts/EdelPKI-ca.der>;
die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.

--------------ms050403060307010308080902
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms050403060307010308080902--

Date: Fri, 28 Nov 2008 10:51:48 +1100
From: Steven Legg <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>, [email-masked]
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

Santosh,

Regards,
Steven

> performance was really bad. And yes, like all others I've added a 

Date: Thu, 27 Nov 2008 12:03:37 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

Ciao, Michael.

Content-class: urn:content-classes:message
Subject: RE: encoding an X.509 certificate
Date: Wed, 26 Nov 2008 21:42:53 -0500
From: "Santosh Chokhani" <[email-masked]>
To: =?iso-8859-1?Q?Michael_Str=F6der?= <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Michael,

The question remains what it does to interoperability and performance =
since I suspect you are not the sole provider of PK enablement software =
to the world.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Michael Str=F6der
Sent: Wednesday, November 26, 2008 6:23 PM
To: [email-masked]
Subject: Re: encoding an X.509 certificate

Santosh Chokhani wrote:
>=20

When implementing the cert viewer in web2ldap it took me quite a while=20
to believe how broken certs of major CAs are. So my development=20
performance was really bad. And yes, like all others I've added a=20
work-around...

Ciao, Michael.

Date: Thu, 27 Nov 2008 00:23:17 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: [email-masked]
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

Ciao, Michael.

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-pkix-ecc-subpubkeyinfo (Elliptic Curve  Cryptography Subject Public Key Information) to Proposed  Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Tue, 25 Nov 2008 09:16:00 -0800 (PST)
Sender: [email-masked]

The IESG has received a request from the Public-Key Infrastructure 
(X.509) WG (pkix) to consider the following document:

- 'Elliptic Curve Cryptography Subject Public Key Information '
   <draft-ietf-pkix-ecc-subpubkeyinfo-10.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 substantive comments to the
[email-masked] mailing lists by 2008-12-09. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-10.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16782&rfc_flag=0

From: "Liaquat Khan" <[email-masked]>
To: "'Timothy J. Miller'" <[email-masked]>
Cc: "'Johannes Merkle'" <[email-masked]>, "'Mauricio Balassiano'" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP Responder Status
Date: Tue, 25 Nov 2008 21:59:37 +0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_04E6_01C94F49.1B981B50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

See below

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Timothy J. Miller
Sent: 25 November 2008 21:18
To: Liaquat Khan
Cc: 'Johannes Merkle'; 'Mauricio Balassiano'; [email-masked]
Subject: Re: OCSP Responder Status

Liaquat Khan wrote:
> The problem with your option 3 is that RFC2560 doesn't explain how a
client
> can check that the second responder is acting on behalf of the first CA.
> I.e. it may chain to a trust anchor, allowing you to verify the signature
on
> the OCSP response, but how do you know that the original CA actually
> authorised this second responder to provide status information on the
first
> responder's certificate? 

That's what client configuration control is for.  :)  That's the whole 
point of the trusted responder model--trust in that responder is 
established out-of-band (i.e., not part of the OCSP protocol).

[LK:] :-) of course anything is possible with configuration but the
situation can become quite complex for even administrators to follow,
especially if multiple CAs are being handled.  E.g. our ARP-OCSP client
supports the capability to use AIA extension to locate responders and also
locally configured responder addresses, with the order of which method is to
be used being configurable.   There is also possibility to configure
separate trust anchor sets per CA etc, so that it can be controlled which
CAs trust which responders. Only issue is that generally speaking no one
really uses these advanced features and instead opts for simpler models
(CRLs or no-check).   

> If you are happy to live without this check then this can work, however I
> have not really seen this method actual used (probably because it
introduces
> more complexity than the benefit it offers).  

The DoD OCSP service uses the trusted responder model.  It's a real PITA 
to manage; you have to make sure all the RPs are properly configured. 
Key changing under this model is even worse; the hoops we had to jump 
through were seriously sick.

We're now migrating to the CA designated model.  The CA-issued OCSP 
signing certs will be short-lived certs with longer-lived keys (IIRC, 30 
day cert life with renewal allowed for some period of time).

[LK:] OK sounds interesting, so responder cert will have "no-check" option
and lifetime of 30 days.  Sounds like quite a long lifetime for a
certificate which is supposed to be short-lived :-). 
  
-- Tim

------=_NextPart_000_04E6_01C94F49.1B981B50
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_04E6_01C94F49.1B981B50--

Date: Tue, 25 Nov 2008 11:17:54 -0600
From: "Timothy J. Miller" <[email-masked]>
To: Liaquat Khan <[email-masked]>
CC: "'Johannes Merkle'" <[email-masked]>, "'Mauricio Balassiano'" <[email-masked]>, [email-masked]
Subject: Re: OCSP Responder Status
Sender: [email-masked]

--------------ms010409010602090905080403
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Liaquat Khan wrote:
> The problem with your option 3 is that RFC2560 doesn't explain how a client
> can check that the second responder is acting on behalf of the first CA.
> I.e. it may chain to a trust anchor, allowing you to verify the signature on
> the OCSP response, but how do you know that the original CA actually
> authorised this second responder to provide status information on the first
> responder's certificate? 

That's what client configuration control is for.  :)  That's the whole 
point of the trusted responder model--trust in that responder is 
established out-of-band (i.e., not part of the OCSP protocol).

> If you are happy to live without this check then this can work, however I
> have not really seen this method actual used (probably because it introduces
> more complexity than the benefit it offers).  

The DoD OCSP service uses the trusted responder model.  It's a real PITA 
to manage; you have to make sure all the RPs are properly configured. 
Key changing under this model is even worse; the hoops we had to jump 
through were seriously sick.

We're now migrating to the CA designated model.  The CA-issued OCSP 
signing certs will be short-lived certs with longer-lived keys (IIRC, 30 
day cert life with renewal allowed for some period of time).

-- Tim

--------------ms010409010602090905080403
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms010409010602090905080403--

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-pkix-ecc-subpubkeyinfo (Elliptic Curve  Cryptography Subject Public Key Information) to Proposed  Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Tue, 25 Nov 2008 09:16:00 -0800 (PST)
Sender: [email-masked]

The IESG has received a request from the Public-Key Infrastructure 
(X.509) WG (pkix) to consider the following document:

- 'Elliptic Curve Cryptography Subject Public Key Information '
   <draft-ietf-pkix-ecc-subpubkeyinfo-10.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 substantive comments to the
[email-masked] mailing lists by 2008-12-09. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-10.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16782&rfc_flag=0

From: "Liaquat Khan" <[email-masked]>
To: "'Johannes Merkle'" <[email-masked]>, "'Mauricio Balassiano'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSP Responder Status
Date: Tue, 25 Nov 2008 19:15:45 +0400
Sender: [email-masked]

The problem with your option 3 is that RFC2560 doesn't explain how a client
can check that the second responder is acting on behalf of the first CA.
I.e. it may chain to a trust anchor, allowing you to verify the signature on
the OCSP response, but how do you know that the original CA actually
authorised this second responder to provide status information on the first
responder's certificate? 

If you are happy to live without this check then this can work, however I
have not really seen this method actual used (probably because it introduces
more complexity than the benefit it offers).  

The main method I have seen is the use of CRLs (e.g. Adobe CDS certificates
generally use this to verify the OCSP responder certificate status, or use
the no-check option). 

The other approach I have seen is the IdenTrust one with OCSP responder
hierarchies, but this is one where even the first responder is not certified
by the CA for which it responds, so doesn't apply to scenario described in
the original email. 

Regards,
LK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Johannes Merkle
Sent: 25 November 2008 17:47
To: Mauricio Balassiano
Cc: [email-masked]
Subject: Re: OCSP Responder Status

Mauricio,

> Which other way, other than CRL, could a OCSP Responder certificate be
> checked considering that OCSP No Check extension is not an option ?

An alternative could be another OCSP-Repsponder specified in the first OCSP
responders certificate. For establishing
trust in this second responder, there are the three option mentioned in RFC
2560:
- It uses the CA signing key to sign the OCSP responses (
- It's certificate has also been issued by the CA that issued the
certificate of the first responder. This only
transfers the problem to the second responder
- It's certificate has been issued by another CA, e.g. a root CA. In this
case, the clients must be locally configured
to trust the responders replies.

At the top level of this OCSP hierarchy you will face the problem that
unless you are willing to trust the top-level
responder's certificate without revocation checking (e.g. by using OCSP No
Check), or to use a CA key to sign the
top-level OCSP responses, you must switch to CRLs. I agree that this in not
satisfactory in many circumstances.

For CRLs you'll face a similar problem at the top of the "CRL hierarchy": RP
have to trust the top level CRL signer
without revocation checking. But if you are not willing to issue directs
CRLs (e.g. because the root CA is operated
offline and you wish to avoid daily access to it) then your top level CRL
signer will constitute a kind of second trust
anchor, at least with respect to revocation status checking.

Johannes

--
Johannes Merkle
secunet Security Networks AG
www.secunet.com

Content-class: urn:content-classes:message
Subject: RE: OCSP Responder Status
Date: Tue, 25 Nov 2008 10:11:53 -0500
From: "Santosh Chokhani" <[email-masked]>
To: "Johannes Merkle" <[email-masked]>, "Mauricio Balassiano" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

You have to careful regarding the third option of trust: "- It's
certificate has been issued by another CA, e.g. a root CA. In this case,
the clients must be locally configured to trust the responders replies."

Some of the widely deployed OCSP clients interpret the local policy
option in RFC 2560 to simply mean explicitly trusted Responder.  Thus,
Responder certificate signed by Root will not work for checking the
status of certificates issued by some other CA.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Johannes Merkle
Sent: Tuesday, November 25, 2008 8:47 AM
To: Mauricio Balassiano
Cc: [email-masked]
Subject: Re: OCSP Responder Status

Mauricio,

> Which other way, other than CRL, could a OCSP Responder certificate be
> checked considering that OCSP No Check extension is not an option ?

An alternative could be another OCSP-Repsponder specified in the first
OCSP responders certificate. For establishing
trust in this second responder, there are the three option mentioned in
RFC 2560:
- It uses the CA signing key to sign the OCSP responses (
- It's certificate has also been issued by the CA that issued the
certificate of the first responder. This only
transfers the problem to the second responder
- It's certificate has been issued by another CA, e.g. a root CA. In
this case, the clients must be locally configured
to trust the responders replies.

At the top level of this OCSP hierarchy you will face the problem that
unless you are willing to trust the top-level
responder's certificate without revocation checking (e.g. by using OCSP
No Check), or to use a CA key to sign the
top-level OCSP responses, you must switch to CRLs. I agree that this in
not satisfactory in many circumstances.

For CRLs you'll face a similar problem at the top of the "CRL
hierarchy": RP have to trust the top level CRL signer
without revocation checking. But if you are not willing to issue directs
CRLs (e.g. because the root CA is operated
offline and you wish to avoid daily access to it) then your top level
CRL signer will constitute a kind of second trust
anchor, at least with respect to revocation status checking.

Johannes

--
Johannes Merkle
secunet Security Networks AG
www.secunet.com

Date: Tue, 25 Nov 2008 14:47:08 +0100
From: Johannes Merkle <[email-masked]>
To: Mauricio Balassiano <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP Responder Status
Sender: [email-masked]

Mauricio,

> Which other way, other than CRL, could a OCSP Responder certificate be
> checked considering that OCSP No Check extension is not an option ?

An alternative could be another OCSP-Repsponder specified in the first OCSP responders certificate. For establishing
trust in this second responder, there are the three option mentioned in RFC 2560:
- It uses the CA signing key to sign the OCSP responses (
- It's certificate has also been issued by the CA that issued the certificate of the first responder. This only
transfers the problem to the second responder
- It's certificate has been issued by another CA, e.g. a root CA. In this case, the clients must be locally configured
to trust the responders replies.

At the top level of this OCSP hierarchy you will face the problem that unless you are willing to trust the top-level
responder's certificate without revocation checking (e.g. by using OCSP No Check), or to use a CA key to sign the
top-level OCSP responses, you must switch to CRLs. I agree that this in not satisfactory in many circumstances.

For CRLs you'll face a similar problem at the top of the "CRL hierarchy": RP have to trust the top level CRL signer
without revocation checking. But if you are not willing to issue directs CRLs (e.g. because the root CA is operated
offline and you wish to avoid daily access to it) then your top level CRL signer will constitute a kind of second trust
anchor, at least with respect to revocation status checking.

Johannes

--
Johannes Merkle
secunet Security Networks AG
www.secunet.com

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-10.txt 
Date: Mon, 24 Nov 2008 14:00:01 -0800 (PST)
Sender: [email-masked]

--NextPart

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		: Elliptic Curve Cryptography Subject Public Key Information
	Author(s)	: S. Turner, K. Yiu, D. Brown, R. Housley, W. Polk
	Filename	: draft-ietf-pkix-ecc-subpubkeyinfo-10.txt
	Pages		: 22
	Date		: 2008-11-24
	
This document specifies the syntax and semantics for the Subject 
   Public Key Information field in certificates that support Elliptic 
   Curve Cryptography.  This document updates Sections 2.3.5, 5, and the 
   ASN.1 module of RFC 3279.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ecc-subpubkeyinfo-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--NextPart--

From: "Mauricio Balassiano" <[email-masked]>
To: <[email-masked]>
Subject: OCSP Responder Status
Date: Mon, 24 Nov 2008 15:02:03 -0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_051E_01C94E45.9BC3CC20
Content-Type: multipart/related;
	boundary="----=_NextPart_001_051F_01C94E45.9BC3CC20"

------=_NextPart_001_051F_01C94E45.9BC3CC20
Content-Type: multipart/alternative;
	boundary="----=_NextPart_002_0520_01C94E45.9BC3CC20"

------=_NextPart_002_0520_01C94E45.9BC3CC20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

In a model where the OCSP Responder certificate is issued by the same CA =
who
issues the end entity certificates, isn=92t it a disadvantage to use the =
OCSP
service when CRL is used for checking the validity status of the OCSP
Responder certificate ?
=20
The OCSP RFC says that a CA may specify how the responder's certificate =
be
checked for revocation. This can be done using CRL Distribution Points =
if
the check should be done using CRLs or CRL Distribution Points, or =
Authority
Information Access if the check should be done in some other way.

=20

Which other way, other than CRL, could a OCSP Responder certificate be
checked considering that OCSP No Check extension is not an option ?=20

=20

Thanks,

  _____ =20

 <http://www.certisign.com.br>  <http://www.certisign.com.br/> CERTISIGN
<http://www.certisign.com.br> Mauricio Schueftan Balassiano
Departamento de Normas e Ger=EAncia de PKI
(21) 4501 1850

Certisign Certificadora Digital
certisign.com.br <http://www.certisign.com.br>=20

=20

------=_NextPart_002_0520_01C94E45.9BC3CC20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@Batang";
	panose-1:2 3 6 0 0 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EstiloDeEmail17
	{mso-style-type:personal-compose;
	font-family:Verdana;
	color:windowtext;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1027" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DPT-BR link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Verdana'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<pre><font size=3D2 face=3DVerdana><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Verdana'>In a model where the OCSP Responder certificate is =
issued by the same CA who issues the end entity certificates, =
isn&#8217;t it a disadvantage to use the OCSP service when CRL is used =
for checking the validity status of the OCSP Responder certificate =
?<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3DVerdana><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Verdana'><o:p>&nbsp;</o:p></span></=
font></pre><pre><font
size=3D2 face=3DVerdana><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Verdana'>The OCSP RFC says that a =
CA may specify how the responder's certificate be checked for =
revocation. This can be done using CRL Distribution Points if the check =
should be done using CRLs or CRL Distribution Points, or Authority =
Information Access if the check should be done in some other =
way.<o:p></o:p></span></font></pre>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Verdana'>Which other way, other than CRL, could a =
OCSP
Responder certificate be checked considering that OCSP No Check =
extension is
not an option ? </span></font><font size=3D2 face=3DVerdana><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Verdana'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Verdana'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DVerdana><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Verdana'>Thanks,<o:p></o:p></span></font></p>

<div class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>

<hr size=3D1 width=3D"40%" noshade color=3D"#9d9da1" align=3Dleft>

</span></font></div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><a =
href=3D"http://www.certisign.com.br"></a></span></font><!--[if gte vml =
1]><v:shapetype=20
 id=3D"_x0000_t75" coordsize=3D"21600,21600" o:spt=3D"75" =
o:preferrelative=3D"t"=20
 path=3D"m@4@5l@4@11@9@11@9@5xe" filled=3D"f" stroked=3D"f">
 <v:stroke joinstyle=3D"miter" />
 <v:formulas>
  <v:f eqn=3D"if lineDrawn pixelLineWidth 0" />
  <v:f eqn=3D"sum @0 1 0" />
  <v:f eqn=3D"sum 0 0 @1" />
  <v:f eqn=3D"prod @2 1 2" />
  <v:f eqn=3D"prod @3 21600 pixelWidth" />
  <v:f eqn=3D"prod @3 21600 pixelHeight" />
  <v:f eqn=3D"sum @0 0 1" />
  <v:f eqn=3D"prod @6 1 2" />
  <v:f eqn=3D"prod @7 21600 pixelWidth" />
  <v:f eqn=3D"sum @8 21600 0" />
  <v:f eqn=3D"prod @7 21600 pixelHeight" />
  <v:f eqn=3D"sum @10 21600 0" />
 </v:formulas>
 <v:path o:extrusionok=3D"f" gradientshapeok=3D"t" =
o:connecttype=3D"rect" />
 <o:lock v:ext=3D"edit" aspectratio=3D"t" />
</v:shapetype><v:shape id=3D"Certisign" o:spid=3D"_x0000_s1026" =
type=3D"#_x0000_t75"=20
 alt=3D"CERTISIGN" href=3D"http://www.certisign.com.br/" =
style=3D'position:absolute;
 margin-left:0;margin-top:0;width:57.75pt;height:67.5pt;z-index:1;
 =
mso-wrap-distance-left:0;mso-wrap-distance-top:0;mso-wrap-distance-right:=
0;
 mso-wrap-distance-bottom:0;mso-position-horizontal:left;
 =
mso-position-horizontal-relative:text;mso-position-vertical-relative:line=
'=20
 o:allowoverlap=3D"f" o:button=3D"t">
 <v:imagedata src=3D"cid:[email-masked]" =
o:href=3D"http://certisign.com.br/images/email/icone_90pxls.jpg" />
 <w:wrap type=3D"square"/>
</v:shape><![endif]--><![if !vml]><a =
href=3D"http://www.certisign.com.br/"><img
border=3D0 width=3D77 height=3D90 =
src=3D"cid:[email-masked]"
align=3Dleft alt=3DCERTISIGN longDesc=3D"http://certisign.com.br" =
name=3DCertisign
v:shapes=3D"Certisign"></a><![endif]><a =
href=3D"http://www.certisign.com.br"></a><strong><b><font
size=3D1 face=3D"Times New Roman"><span =
style=3D'font-size:7.5pt'>Mauricio Schueftan
Balassiano</span></font></b></strong><font size=3D1 face=3DVerdana><span
style=3D'font-size:7.5pt;font-family:Verdana'><br>
Departamento de Normas e Ger=EAncia de PKI<br>
(21) 4501 1850<br>
<br>
Certisign Certificadora Digital<br>
<a =
href=3D"http://www.certisign.com.br">certisign.com.br</a></span></font><o=
:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_002_0520_01C94E45.9BC3CC20--

------=_NextPart_001_051F_01C94E45.9BC3CC20
Content-Type: image/jpeg;
	name="image001.jpg"
Content-Transfer-Encoding: base64
Content-ID: <[email-masked]>

------=_NextPart_001_051F_01C94E45.9BC3CC20--

------=_NextPart_000_051E_01C94E45.9BC3CC20
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_051E_01C94E45.9BC3CC20--

Cc: [email-masked], [email-masked], [email-masked], [email-masked]
From: Yoav Nir <[email-masked]>
To: Peter Gutmann <[email-masked]>
Subject: Re: encoding an X.509 certificate
Date: Sun, 23 Nov 2008 08:51:31 +0200
Sender: [email-masked]

> Yeah, that one'll really fly.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Cc: [email-masked]
Date: Sat, 22 Nov 2008 22:11:32 +1300
Sender: [email-masked]

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

>This is sometimes referred to as the "hostage" PKI solution 

Ahh, I knew there must be some name for it :-).

>and must be one of the most flagrant examples of "pushing the envelope" ever
>heard of, 

>From talking to the person who'd had experience with this, and in particular
the totally unnatural business model it was creating, it certainly sounded
exactly like a hostage PKI.

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Cc: [email-masked]
Date: Sat, 22 Nov 2008 22:07:52 +1300
Sender: [email-masked]

Juergen Brauckmann <[email-masked]> writes:

>Actually there are several products and services that you can buy to automate
>qualified signature creation; google shows you some of them if you ask for
>"signature server".

>From talking to someone who's endured this in Germany, the only reason the
services exist is that you're paying them to bypass Anders' PKI-disabler for
you (either that or you exploit loopholes in the requirements, I can't
remember the precise details because they were pretty obscure but there are
tricks around using PDFs as electronic documents to meet the filing
requirements but having them in printed form to meet the archiving
requirements, and other odds and ends).

The system (without using the loopholes) required that not only do you need to
carry out a complex signing ritual but you have to verify cert chains and
CRLs, and then the certs expire so you need timestamping and secure archiving
of the fact that you've verified everything (when he described this to me I
had to keep stopping him to verify things because it sounded like a
description of a pathological torture test that someone had invented as sort
of obstacle course for businesses, but he claimed this wasn't a worst-case
scenario but something that everyone was expected to do).

So it's created a great business model in that you can outsource the pain to
companies that have sprung up to service the market, but first hobbling
businesses and then saying you have all these great new services that take the
hobbles away seems pretty counterproductive unless you happen to be in the
signature services racket.

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: encoding an X.509 certificate
Cc: [email-masked], [email-masked]
Date: Sat, 22 Nov 2008 19:00:05 +1300
Sender: [email-masked]

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: encoding an X.509 certificate
Date: Sat, 22 Nov 2008 18:42:37 +1300
Sender: [email-masked]

Peter.

Date: Fri, 21 Nov 2008 12:19:04 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: minutes posted
Sender: [email-masked]

Folks,

Meeting minutes fro yesterday have been posted. Please send 
corrections to me over the next two weeks.

Thanks,

Steve

Date: Fri, 21 Nov 2008 18:04:24 +0100
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms060307010407040708020303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

There are some firewalls that doesn' like things like:

X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f

I don't know whether it is intended that majordom is not a trustworthy
entity to the local mail daemon.

--------------ms060307010407040708020303
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms060307010407040708020303--

From: "Timothy J Miller" <[email-masked]>
To: "Timothy J Miller" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Fri, 21 Nov 2008 17:21:09 +0100
Sender: [email-masked]

>On the other hand I neither expect nor assume that people will accept  
>or install trust in the MITRE PKI just because I'm signing mail to a  
>list.  But the integrity functions of S/MIME are unimpaired and IMHO  
>as important as the authentication and confidentiality functions.

I could if I had spent some 20 extra minutes, created a certificate that
would be "visually" indistinguishable from your MITRE PKI certificate.
With that I would like to say that integrity without authentication doesn't
buy that much.

[email-masked] impersonating [email-masked] which was
piece of cake since secure Internet mail is a joke.  Although I personally
do not laugh...

Naturally my ISP should have authenticated me and only let me use one
of the e-mail addresses I have registered, but it didn't since there is no
point in doing that because the rest of the security architecture is broken.

Anders-as-Tim

CC: <[email-masked]>
From: Timothy J Miller <[email-masked]>
To: <[email-masked]>
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Fri, 21 Nov 2008 08:17:02 -0600
Sender: [email-masked]

--Apple-Mail-2--138277110
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

On Nov 21, 2008, at 3:13 AM, Stephen Wilson wrote:

> In an open community, one stranger sending a signed e-mail to  
> another is very closely analogous to sending a plain paper fax with  
> a handwritten signature on the bottom.  If you weren't expecting it,  
> and you didn't recognise the sender, you would probably throw such a  
> fax into the trash.  The idea that a receiver would be interested  
> enough to examine the certificate and even read the sender's CA's CP  
> was always fanciful.
>
> So, S/MIME on its own is not terribly useful in business.  [Whether  
> someone signs their e-mail to this list is really immaterial; most  
> of us recognise one another, and in any case the communications are  
> not critical, so authentication is moot.  Frankly I don't know why  
> anyone would bother signing their e-mails, I assume it's habit, and/ 
> or a default.]

Since it's my ears burning, I'll say it's both habit and default.  :)   
Apple Mail is my main MUA; it handles S/MIME settings on a "last set  
is next default" basis.  So if I sign an internal mail--and typically  
have reasons to do so--the next mail will default to signed.  TB is  
the other MUA I use relatively frequently, and it makes it unintuitive  
enough to change S/MIME options on any single email that I've set  
signed as the default.

On the other hand I neither expect nor assume that people will accept  
or install trust in the MITRE PKI just because I'm signing mail to a  
list.  But the integrity functions of S/MIME are unimpaired and IMHO  
as important as the authentication and confidentiality functions.

> So I still don't think that anyone should fixate on messaging as a  
> keystone application of PKI.  The experience of messaging is not an  
> accurate baromoter of the fortunes of PKI.

However, it's been my experience that S/MIME is the flagship PKI  
application *from a typical user's perspective.* In the environment I  
support users see and use it every day, even more than PKI authN to  
web services or even Kerberos PKINIT.  When I say "PKI" to a group of  
users, the response I get is "email"--and that's after years of  
training (though the high turnover rate of some of my user population  
doesn't help here).

And it's the application that causes the most pain and suffering.

-- Tim

--Apple-Mail-2--138277110
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

--Apple-Mail-2--138277110--

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Fri, 21 Nov 2008 13:19:56 +0100
Sender: [email-masked]

Stephen,

>And so S/MIME it was never pushed hard.  The infrastructure and 
>interoperability challenges, while significant, would not have been 
>insurmountable, provided there was sufficient demand to solve them. 
>There wasn't, so they weren't.

I don't really see that there actually could be an economically, politically,
and technically realistic way making a user-based authentication, signing or
encryption solution work outside of a limited community.

Anyway, since S/MIME is pretty much a relic, when I talk about secure
messaging I refer to web services.

I may indeed be "obsessed" with secure messaging, and I do see some
progress in Europe where "PKI-lite" schemes are getting some traction.
The US seems to forever be stuck in the architecture once raised by the
federal government which is a very expensive and slow path to secure
messaging.  To get an Org (legal entity)-cert in the EU is a $300 thing,
while the cost of getting cross-certified with the FBCA ( http://www.cio.gov/fpkipa )
is prohibitive for all but pretty large organizations.

Germany (of course...) tries hard to get the EU countries lining up for
an EU BCA ( http://www.bridge-ca.de ), but I think they begin to see
that this will not be as easy as planned, since the alternative is cheaper,
faster, and integrates nicely with just about any "business" process you
can think of.

I don't know what they are doing "Down Under" but if you have a link
or two, I would appreciate it.

Anders

Date: Fri, 21 Nov 2008 20:13:14 +1100
From: Stephen Wilson <[email-masked]>
Reply-To: [email-masked]
Organization: Lockstep
To: [email-masked]
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Sender: [email-masked]

In my view, S/MIME e-mail is a very generic application.  It does fit 
well my analysis of application-specific versus generic, and I think it 
is actually predictable that S/MIME on its own would be difficult and 
not very beneficial.

In an open community, one stranger sending a signed e-mail to another is 
very closely analogous to sending a plain paper fax with a handwritten 
signature on the bottom.  If you weren't expecting it, and you didn't 
recognise the sender, you would probably throw such a fax into the 
trash.  The idea that a receiver would be interested enough to examine 
the certificate and even read the sender's CA's CP was always fanciful.

So, S/MIME on its own is not terribly useful in business.  [Whether 
someone signs their e-mail to this list is really immaterial; most of us 
recognise one another, and in any case the communications are not 
critical, so authentication is moot.  Frankly I don't know why anyone 
would bother signing their e-mails, I assume it's habit, and/or a default.]

And so S/MIME it was never pushed hard.  The infrastructure and 
interoperability challenges, while significant, would not have been 
insurmountable, provided there was sufficient demand to solve them. 
There wasn't, so they weren't.

There are all sorts of ways to realise "electronic messaging" and S/MINE 
is just one.  I presume that most defence forces have good electornic 
messaging systems.  Some messaging solutions would sensibly use digital 
signatures and certificates; others might not need to.

Meanwhile, there are inumerable other e-business applications separate 
over and above 'messaging;, where PKI is delivering great benefits.

So I still don't think that anyone should fixate on messaging as a 
keystone application of PKI.  The experience of messaging is not an 
accurate baromoter of the fortunes of PKI.

Cheers,

Stephen Wilson.

Anders Rundgren wrote:
> Stephen,
> I completely agree with your view regarding the value and use of community
> or app-specific PKIs.
> 
> However, one of the applications that caught my interest, secure messaging
> over the Internet doesn't fit very well into the categories you are mentioning,
> with S/MIME as the primary example.  That a bunch of people insist signing
> their mails to this list using PKIs that hardly any of the recipients recognize,
> is an indication that the concepts "community-scale security solution" versus
> "Internet-scale security solution" still are largely unknown.
> 
> That this knowledge deficit has limited impact on "nerdy" mailing lists like
> IETF-PKIX is for sure.   However, for governments it is not equally easy.
> 
> Anders
> 
> From: "Stephen Wilson" <[email-masked]>
> To: "Anders Rundgren" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Wednesday, November 19, 2008 01:23
> Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
> 
> 
> 
> Anders Rundgren wrote:
>> ... VeriSign's SSL PKI reaches out over the entire globe, while
>>       employee PKIs (be it PIV or just your local stuff) typically is
>>       unknown at 99.99% of all places, indicates that the employee PKI
>>       model suffers from pretty serious trust establishment issues
> 
> This is another red herring.  It tells us nothing true or deep about the 
> effectiveness of individual certificates.  The fact that employee PKIs 
> don't have global reach is hardly surprising.  To begin with, global 
> recognition of *employees* outside the enterprise is not usually 
> important!  Look at the J&J corporate PKI; seems to be working great 
> with 100,000+ individuals.
> 
> But more importantly, successful PKIs are always application specific. 
> [BTW the application-specificity of SSL server certificates is really 
> one of their most salient features, but almost always overlooked when 
> people try to draw lessons form SSL's success!]  The reach problem that 
> so concerns Anders is really only a matter of root key distribution. 
> With application specific PKI, where 9 times out of 10 the transacting 
> parties run special software (healthcare apps, conveyancing, trade 
> documentation management, Skype etc etc), root key distribution is 
> trivial.
> 
> Cheers,
> 
> Steve Wilson.
> 
> 
> 
> 
> Managing Director
> Lockstep Technologies
> 
> Phone +61 (0)414 488 851
> 
> www.lockstep.com.au/technologies
> -------------------
>   * ABC TV 'The New Inventors' Nov 2008
>   * Global Security Challenge Asia Top Five 2008
>   * Australian Technology Showcase 2008
>   * AusIndustry COMET Grant 2007
>   * ICT Secrets of Innovation Finalist (Security) 2007
>   * Anthill / PwC Cool Company Finalist (Innovation) 2007
> -------------------
> Lockstep Technologies develops unique new smart ID solutions to
> safeguard identity and privacy. Lockstep Consulting provides
> independent specialist advice and analysis on authentication, PKI
> and smartcards.
> 
> 

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Fri, 21 Nov 2008 09:51:58 +0100
Sender: [email-masked]

Stephen,
I completely agree with your view regarding the value and use of community
or app-specific PKIs.

However, one of the applications that caught my interest, secure messaging
over the Internet doesn't fit very well into the categories you are mentioning,
with S/MIME as the primary example.  That a bunch of people insist signing
their mails to this list using PKIs that hardly any of the recipients recognize,
is an indication that the concepts "community-scale security solution" versus
"Internet-scale security solution" still are largely unknown.

That this knowledge deficit has limited impact on "nerdy" mailing lists like
IETF-PKIX is for sure.   However, for governments it is not equally easy.

Anders

----- Original Message ----- 
From: "Stephen Wilson" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 19, 2008 01:23
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective

Anders Rundgren wrote:
> ... VeriSign's SSL PKI reaches out over the entire globe, while
>       employee PKIs (be it PIV or just your local stuff) typically is
>       unknown at 99.99% of all places, indicates that the employee PKI
>       model suffers from pretty serious trust establishment issues

This is another red herring.  It tells us nothing true or deep about the 
effectiveness of individual certificates.  The fact that employee PKIs 
don't have global reach is hardly surprising.  To begin with, global 
recognition of *employees* outside the enterprise is not usually 
important!  Look at the J&J corporate PKI; seems to be working great 
with 100,000+ individuals.

But more importantly, successful PKIs are always application specific. 
[BTW the application-specificity of SSL server certificates is really 
one of their most salient features, but almost always overlooked when 
people try to draw lessons form SSL's success!]  The reach problem that 
so concerns Anders is really only a matter of root key distribution. 
With application specific PKI, where 9 times out of 10 the transacting 
parties run special software (healthcare apps, conveyancing, trade 
documentation management, Skype etc etc), root key distribution is 
trivial.

Cheers,

Steve Wilson.

Managing Director
Lockstep Technologies

Phone +61 (0)414 488 851

www.lockstep.com.au/technologies
-------------------
  * ABC TV 'The New Inventors' Nov 2008
  * Global Security Challenge Asia Top Five 2008
  * Australian Technology Showcase 2008
  * AusIndustry COMET Grant 2007
  * ICT Secrets of Innovation Finalist (Security) 2007
  * Anthill / PwC Cool Company Finalist (Innovation) 2007
-------------------
Lockstep Technologies develops unique new smart ID solutions to
safeguard identity and privacy. Lockstep Consulting provides
independent specialist advice and analysis on authentication, PKI
and smartcards.

Date: Thu, 20 Nov 2008 10:02:25 -0500
To: "Turner, Sean P." <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: AD comments for draft-ietf-pkix-ecc-subpubkeyinfo-09
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Sean & Pasi,

I am comfortable with these changes.

If anyone in the WG objects, say so now, else we will consider the 
previous WGLC to still be valid.

Steve

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: encoding an X.509 certificate
Cc: [email-masked]
Date: Thu, 20 Nov 2008 19:49:29 +1300
Sender: [email-masked]

Peter.

From: "Anders Rundgren" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Wed, 19 Nov 2008 23:09:48 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00BB_01C94A9B.EB774BA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Stefan,
You're right, I screw up the adoption year.

Regarding the motives behind this and that for e-invoices I'm not able =
to tell because it is simply not decodable based on for example the =
German "solution" depicted a few postings ago.

Is this political manifesto? Well, that depends on what you mean with =
political :-)

What does S/MIME bring me using Windows Mail except for a black screen =
telling that there is a security problem with this message, compared to =
unsigned messages encouraging me to download coolpicture.exe which is =
treated as secure mail?  Of course Microsoft can add =
yet-another-impossible-to-understand-by-ordinary-humans-security-setting,=
 but I don't think it will help much because S/MIME is based on an =
inferior security architecture (which in fact is the indirect reason to =
why I got the coolpicture.exe message as well).

Isn't somewhat funny that the scheme I described some 10 years ago =
(server-signed assertions), which roughly 100% of the PKIX list slammed =
as a bad idea, actually is one of the corner-stones of Microsoft's =
brilliant CardSpace technology?

Both of these things are in turn is highly related to the undisputed =
fact that the US government doesn't have a documented architecture for =
secure messaging between agencies of the kind that is slowly but surely =
becoming standard in the EU.

Is there something for PKIX to cater for here?  It seems that most PKIX =
folks prefer dealing with rather esoteric stuff
http://www.ietf.org/proceedings/08nov/agenda/pkix.txt
than for example digging into the realities of large-scale =
consumer/citizen PKIs of the kind used in Europe.  I'm currently =
implementing the PKI for Web 2.0 framework in Google's Android because I =
think the route Microsoft selected for CardSpace (first code + =
preliminary specs, then standards) is a better mousetrap.

Regards
Anders Rundgren

  ----- Original Message -----=20
  From: Stefan Santesson=20
  To: Anders Rundgren ; [email-masked]=20
  Sent: Tuesday, November 18, 2008 23:41
  Subject: RE: The EU Signature Directive - A 15+15 Year Perspective

  Anders,

  =20

  On the factual side, the EU signature directive was adopted 1999, =
which is 9 years ago and not 15.

  Further, the primary function of the EU directive was to establish =
that no signature should be denied legal value solely because it was not =
based on a certain technology or met certain standards. The article 5 =
signature (often referred to as qualified signatures) are just a level =
of security that all member countries MUST accept as equivalent to =
hand-written signatures. I certainly agree that the content and =
intention of this directive has been highly misunderstood.

  =20

  The requirements on electronic invoicing comes from a totally separate =
directive.

  =20

  However, I lack any specific technical proposal for this working group =
to consider in your e-mail.=20

  In absence of such proposal, your mail appears to me more as a =
political manifesto.

  =20

  =20

  Stefan Santesson

  Senior Program Manager

  =20

  From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Anders Rundgren
  Sent: den 18 november 2008 04:38
  To: [email-masked]
  Subject: The EU Signature Directive - A 15+15 Year Perspective

  =20

  Some 15 years ago the EU launched a signature directive.  This posting =
tries to describe the consequences of this directive with respect to =
usage of PKI.

  =20

  Primary Motivation

  =20

  There are a number of processes needing a human-written signature in =
order to fulfill legal requirements.

  =20

  Some of these processes could without doubt be possible to carry out =
electronically and thus also remote over a network, if there was some =
kind of technology available that could serve as a replacement for a =
hand-written signature.

  =20

  The Solution

  =20

  Right or wrong, digital signatures using PKI were considered as a =
viable alternative.  To make PKI a credible solution, the EU signature =
directive added a number of requirements including characteristics of =
the signature creation device and policies for CAs.

  =20

  Current Deployment

  =20

  Apart from Qualified Certificates which (for reasons too diverse for =
describing in an email) have not become truly mainstream, the EU =
signature directive have indeed in local legislations made it possible =
to perform fairly qualified tasks remotely over the Internet.  I.e. the =
directive has functioned as an ENABLER.

  =20

  Then Something Went Wrong...

  =20

  Unfortunately, a few (but influential) people got a bit carried away =
and interpreted the signature directive in way that has severely =
hampered the use of PKI.  Essentially they began claiming that all =
messages in order to be trustworthy should be signed by a qualified =
signature or at least by a digital signature created under the direct =
control a human being.

  =20

  From a 50000 ft perspective this may sound like a great idea, but the =
fact is that decades before the signature directive was conceived; yes, =
even before PKI was invented, the concept of secure messaging actually =
existed.  Back in those days secure messaging was facilitated through =
the use of leased lines which allowed banks (and some early b2b =
networks), to securely exchange transaction messages in a completely =
automated fashion.

  =20

  An example:  If you want to wire-transfer money from your bank to =
another bank, the way the transfer is initiated (phone, paper, on-line, =
etc) has no impact on the transaction messaging because it is performed =
in a transaction network that neither the customers, nor most of the =
staff have direct access to.=20

  =20

  That such networks have proved to be secure, reliable, cost-efficient, =
and sometimes even globally scalable, apparently did not impress the =
bunch of hard-core signature experts who for example in Germany managed =
to make PKI a DISABLER by outlawing non-human digital signatures on =
invoices.  That German paper-invoices do not even require signatures =
makes this position a true mystery.

  =20

  One had hoped that this would be an exception to the rule but it is =
not; If you scan sites like NIST.GOV, CIO.GOV, and GSA.GOV you'll find =
literally thousands of security-related documents, indeed in a few =
places mentioning PKI, but mostly full of government regulation =
abbreviations like FISMA, giving little if any guidance on how to create =
secure messaging between agencies, not to mention between agencies and =
the private sector.

  =20

  I'm happy to see that the Nordic countries plus Estonia have realized =
that all signatures that can be securely bound to an entity (in =
practice) are legally binding, in the extremely rare case somebody would =
actually repudiate a signed invoice.   These governments have all (and =
independently of each other) created local variants of a scheme that I =
have described in:

  http://webpki.org/papers/web/gateway.pdf

  which could be characterized as a 21st century version of leased lines =
for multi-party automated secure messaging.

  It will probably take another 15 years for this concept to achieve =
general acceptance although it is really (if you look closely) very =
similar to the US e-Authentication scheme, they have just not connected =
the dots yet: A SAML assertion and an server-signed invoice from a =
specific entity are essentially only different in content, not in =
trustworthiness.

  =20

  Anders Rundgren

  http://WebPKI.org

  =20

  =20

------=_NextPart_000_00BB_01C94A9B.EB774BA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:x =3D=20
"urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20
"urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20
"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20
"urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b =
=3D=20
"urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20
"urn:schemas-microsoft-com:office:spreadsheet" xmlns:c =3D=20
"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc =3D=20
"urn:schemas-microsoft-com:office:odc" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20
"http://www.w3.org/TR/REC-html40" xmlns:q =3D=20
"http://schemas.xmlsoap.org/soap/envelope/" XMLNS:D =3D "DAV:" xmlns:x2 =
=3D=20
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois =3D=20
"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20
"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20
"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20
"http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20
"http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20
"http://www.w3.org/2001/XMLSchema" xmlns:sub =3D=20
"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec =
=3D=20
"http://www.w3.org/2001/04/xmlenc#" xmlns:sp =3D=20
"http://schemas.microsoft.com/sharepoint/" xmlns:sps =3D=20
"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20
"http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf =3D=20
"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf =3D=20
"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver =3D=20
"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m =
=3D=20
"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels =3D=20
"http://schemas.openxmlformats.org/package/2006/relationships" =
xmlns:ex12t =3D=20
"http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m =
=3D=20
"http://schemas.microsoft.com/exchange/services/2006/messages" XMLNS:Z =
=3D=20
"urn:schemas-microsoft-com:" xmlns:st =3D "=01"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.20927" name=3DGENERATOR>
<STYLE>@font-face {
	font-family: SimSun;
}
@font-face {
	font-family: Cambria Math;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @SimSun;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 70.85pt 70.85pt 70.85pt =
70.85pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.EmailStyle19 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: =
personal-reply
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DSV vLink=3Dpurple link=3Dblue bgColor=3Dwhite>
<DIV><FONT face=3DArial size=3D2>Hi Stefan,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>You're right, I screw up the adoption=20
year.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regarding the motives behind this and =
that for=20
e-invoices I'm not able to tell because it is simply not decodable based =
on for=20
example the German "solution" depicted a few postings ago.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Is this political manifesto? Well, that =
depends on=20
what you mean with political :-)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>What does S/MIME bring me using Windows =
Mail except=20
for a black screen telling that there is a security problem with this =
message,=20
compared to unsigned messages encouraging me to download <FONT=20
face=3D"Courier New">coolpicture.exe</FONT> which is treated =
as&nbsp;secure=20
mail?&nbsp; Of course Microsoft can add=20
yet-another-impossible-to-understand-by-ordinary-humans-security-setting,=
 but I=20
don't think it will help much because S/MIME is based on an inferior =
security=20
architecture (which in fact is the <EM>indirect</EM> reason to why I got =
the=20
<FONT face=3D"Courier New">coolpicture.exe</FONT> message as =
well).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Isn't somewhat funny that the scheme I =
described=20
some 10 years ago (server-signed assertions),&nbsp;which =
roughly&nbsp;100% of=20
the PKIX list slammed as a bad idea, actually&nbsp;is&nbsp;one of=20
the&nbsp;corner-stones of&nbsp;Microsoft's brilliant CardSpace=20
technology?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Both of these things are in turn =
is&nbsp;highly=20
related to the undisputed&nbsp;fact that the US government doesn't have =
a=20
documented architecture for secure messaging between agencies of the =
kind that=20
is slowly but surely becoming standard in the EU.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>Is there something for PKIX to cater for here?&nbsp; It seems=20
that&nbsp;most&nbsp;PKIX folks prefer dealing with rather esoteric =
stuff</DIV>
<DIV><A=20
href=3D"http://www.ietf.org/proceedings/08nov/agenda/pkix.txt">http://www=
.ietf.org/proceedings/08nov/agenda/pkix.txt</A></DIV>
<DIV>than for example digging into the realities of large-scale =
consumer/citizen=20
PKIs of the kind used in Europe.&nbsp; I'm currently implementing the =
PKI for=20
Web 2.0 framework in Google's Android because I think the route =
Microsoft=20
selected for CardSpace (first code + preliminary specs, then standards) =
is a=20
better mousetrap.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards</DIV>
<DIV>Anders Rundgren</DIV></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked] =
href=3D"mailto:[email-masked]">Stefan=20
  Santesson</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">Anders Rundgren</A> ; <A=20
  title=[email-masked] =
href=3D"mailto:[email-masked]">[email-masked]</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, November 18, =
2008=20
  23:41</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: The EU Signature =
Directive -=20
  A 15+15 Year Perspective</DIV>
  <DIV><BR></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><A name=3D_MailEndCompose><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Anders,<o:p></o:p></SPAN></A></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">On=20
  the factual side, the EU signature directive was adopted 1999, which =
is 9=20
  years ago and not 15.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Further,=20
  the primary function of the EU directive was to establish that no =
signature=20
  should be denied legal value solely because it was not based on a =
certain=20
  technology or met certain standards. The article 5 signature (often =
referred=20
  to as qualified signatures) are just a level of security that all =
member=20
  countries MUST accept as equivalent to hand-written signatures. I =
certainly=20
  agree that the content and intention of this directive has been highly =

  misunderstood.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">The=20
  requirements on electronic invoicing comes from a totally separate=20
  directive.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">However,=20
  I lack any specific technical proposal for this working group to =
consider in=20
  your e-mail. <o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">In=20
  absence of such proposal, your mail appears to me more as a political=20
  manifesto.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <DIV>
  <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Arial','sans-serif'">Stefan=20
  Santesson</SPAN></B><SPAN lang=3DEN-GB=20
  style=3D"COLOR: #1f497d"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Senior=20
  Program Manager</SPAN><SPAN lang=3DEN-GB=20
  style=3D"COLOR: navy"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Windows=20
  Security, Standards</SPAN></B><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p></o:p></SPAN></P></DIV>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue =
1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
  <DIV>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
#b5c4df 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: =
medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
  <P class=3DMsoNormal><B><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20
  lang=3DEN-US style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Anders Rundgren<BR><B>Sent:</B> den 18 november 2008=20
  04:38<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> The EU =
Signature=20
  Directive - A 15+15 Year Perspective<o:p></o:p></SPAN></P></DIV></DIV>
  <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Some 15 =
years ago=20
  the EU launched a signature directive.&nbsp; This posting tries to =
describe=20
  the consequences of this directive with respect to usage of=20
  PKI.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><STRONG><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'">Primary=20
  Motivation</SPAN></STRONG><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">There are =
a number=20
  of processes&nbsp;needing a human-written signature in order to =
fulfill legal=20
  requirements.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Some of =
these=20
  processes could without doubt be possible to carry out electronically =
and thus=20
  also remote over a network, if there was some kind of technology =
available=20
  that could serve as a replacement for a hand-written=20
  signature.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><STRONG><SPAN style=3D"FONT-FAMILY: =
'Arial','sans-serif'">The=20
  Solution</SPAN></STRONG><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Right or =
wrong,=20
  digital signatures using PKI were considered as&nbsp;a=20
  viable&nbsp;alternative.&nbsp; To make PKI a credible solution, the EU =

  signature directive added a number of requirements including =
characteristics=20
  of the signature creation device and policies for=20
  CAs.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><STRONG><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'">Current=20
  Deployment</SPAN></STRONG><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Apart =
from=20
  Qualified Certificates which (for reasons too diverse for describing =
in an=20
  email) have not become truly mainstream, the EU signature directive =
have=20
  indeed in local legislations made it possible to perform fairly =
qualified=20
  tasks remotely over the Internet.&nbsp; I.e. the directive has =
functioned as=20
  an <STRONG><SPAN=20
  style=3D"FONT-FAMILY: =
'Arial','sans-serif'">ENABLER</SPAN></STRONG>.<o:p></o:p></SPAN></P></DIV=
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><STRONG><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'">Then Something=20
  Went&nbsp;Wrong...</SPAN></STRONG><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">Unfortunately, a=20
  few (but&nbsp;influential) people got a bit carried away and =
interpreted the=20
  signature directive in way that has severely hampered the use of =
PKI.&nbsp;=20
  Essentially they began claiming that all messages in order to=20
  be&nbsp;trustworthy should be signed by a qualified signature or at =
least by a=20
  digital signature created&nbsp;under the direct control&nbsp;a human=20
  being.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">From a =
50000 ft=20
  perspective this may sound like a great idea, but the fact is that =
decades=20
  before the signature directive was conceived; yes, even before PKI was =

  invented, the concept of secure messaging actually =
existed.&nbsp;&nbsp;Back in=20
  those days&nbsp;secure messaging was facilitated through the use of =
leased=20
  lines which allowed banks (and some early b2b networks), to securely =
exchange=20
  transaction messages <EM><SPAN style=3D"FONT-FAMILY: =
'Arial','sans-serif'">in a=20
  completely automated fashion</SPAN></EM>.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">An =
example:&nbsp;=20
  If you want to wire-transfer money from your bank to another bank, the =
way the=20
  transfer is initiated (phone, paper,&nbsp;on-line, etc)&nbsp;has no =
impact on=20
  the transaction messaging because it is&nbsp;performed in a =
transaction=20
  network that neither the&nbsp;customers, nor&nbsp;most of the staff =
have=20
  direct access to.&nbsp;</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">That&nbsp;such=20
  networks have proved to be secure, reliable, cost-efficient, and =
sometimes=20
  even globally scalable, apparently did not impress the bunch of =
hard-core=20
  signature experts who for example in Germany managed to make PKI a=20
  <STRONG><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'">DISABLER</SPAN></STRONG> =
by=20
  outlawing non-human digital signatures on invoices.&nbsp; That German=20
  paper-invoices do not even require signatures&nbsp;makes this position =
a true=20
  mystery.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">One had =
hoped that=20
  this would be an exception to the rule but it is not; If you scan =
sites like=20
  NIST.GOV, CIO.GOV, and GSA.GOV you'll find literally thousands of=20
  security-related documents, indeed in a few places mentioning PKI, but =
mostly=20
  full of government regulation abbreviations like FISMA, giving little =
if any=20
  guidance on how to create secure messaging between agencies, not to =
mention=20
  between agencies and the private sector.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">I'm happy =
to=20
  see&nbsp;that the Nordic countries plus Estonia have realized that all =

  signatures that can be securely bound to an entity (in practice) are =
legally=20
  binding, in the extremely rare case somebody would actually repudiate =
a signed=20
  invoice.&nbsp;&nbsp; These governments have all (and independently of =
each=20
  other) created local variants of&nbsp;a scheme that I have described=20
  in:</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><A =
href=3D"http://webpki.org/papers/web/gateway.pdf"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">http://webpki.org/papers/web/gateway.pdf</SPAN></A>=
<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">which&nbsp;could be=20
  characterized as&nbsp;a 21st century version of leased lines for=20
  multi-party&nbsp;automated secure =
messaging.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">It will =
probably=20
  take another 15 years for this concept to achieve general acceptance =
although=20
  it is really (if you look closely) very similar&nbsp;to the US=20
  e-Authentication scheme, they have just not connected the dots =
yet:&nbsp;A=20
  SAML assertion and an server-signed&nbsp;invoice from a specific =
entity are=20
  essentially only different in content, not in=20
  trustworthiness.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Anders=20
  Rundgren</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"><A=20
  =
href=3D"http://WebPKI.org">http://WebPKI.org</A></SPAN><o:p></o:p></P></D=
IV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P=20
class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV></DIV></DIV></BLOCKQUOTE></B=
ODY></HTML>

------=_NextPart_000_00BB_01C94A9B.EB774BA0--

From: Stefan Santesson <[email-masked]>
To: Stephen Farrell <[email-masked]>, Eric Norman <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Wed, 19 Nov 2008 05:17:48 +0000
Subject: RE: encoding an X.509 certificate
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Correct me if I'm wrong, but the core of this issue seems to be a scenario =
where a certificate is stored in some system. This system is ASN.1 aware an=
d for some reason refuse to store the certificate as is as a chunk of arbit=
rary bytes, but choose to decode the ASN.1 and store the inner data element=
s instead together with the signature. Once retrieved again, the system rea=
ssembles the certificate using its knowledge about ASN.1 and X.509 certific=
ates for the process. Unfortunately it deploys illegal encoding (BER or XXX=
ER) and delivers back a certificate where the associated signature no longe=
r matches the encoded certificate.

But are there really any system with any significance around today that ope=
rates this way?
Somehow I have a hard time to believe there is.

Stefan Santesson
Senior Program Manager

> "SHOULD...gracefully" isn't  sufficiently clear.

From: Patrick Patterson <[email-masked]>
Reply-To: [email-masked]
Organization: Carillon Information Security Inc.
To: [email-masked]
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Tue, 18 Nov 2008 16:49:27 -0500
Sender: [email-masked]

On November 18, 2008 12:55:57 pm Anders Rundgren wrote:
> Hi Patrick,
>
> <snip>
>
> >As an aside, this is one of the reasons that in the Aerospace industry,
> > we're working on the concept of "Organisational" certificates (PKI analog
> > to the corporate seal).
>
> That's interesting and VERY GOOD news!  I thought the Aerospace industry
> spent their PKI money on [IMO] rather awkward Bridge CA stuff like
> http://certipath.com which I consider the opposite to Organizational
> certificates since Bridge CAs is typically rather about extending the reach
> of (existing) employee certificates.
>
Well, I'll let Santosh ring in on this if he wants, but the I can say that 
most of the companies with which I am familiar have had to implement or beef 
up their "existing" PKI infrastructures to comply with the much more rigorous 
and standardised requirements of joining the Bridge, thus facilitating, 
within the community at least, the establishment of Trust "more than a few 
blocks away from your own backyard" :)

> >It neatly side-steps the mental block that some people have regarding
> >"one person, one key", and allows anyone who is authorized to "sign
> >on behalf of the company" to use the PKI based corporate seal.
>
> Apart from possible mental blocks, there are other quite down-to-earth
> hurdles as well: 
> a.. Employees come and go => Your "digital handles" to 
> other companies easily get invalid 

That is why the Corporate Seal (you know - the one that is a physical piece of 
hardware, is kept in a safe, and is only let out by the corporate lawyers for 
defined and logged purposes) is a usefull concept to translate into the 
Digital Credential (read PKI) realm. Since the Certificate is issued to the 
corporate legal body, and not any particular physical person, it doesn't 
suffer from the same problems as "personal" certificates.

> b.. How do you automatically and 
> securely correlate a company identity as expressed in business messages
> with a PKI-based employee identity, and preferably make that scale a few
> blocks from of your own backyard? 

Is this is somewhat dependant on both the messaging format, and the trust and 
policy infrastructure that you place on the Organisational issuing practices? 

Not to get into any dogmatic debates, but by leveraging the Bridge within the 
community, we believe that this can allow the trust in the Org certs to be 
validated to quite a rigorous level.

> c.. That VeriSign's SSL PKI reaches out 
> over the entire globe, while employee PKIs (be it PIV or just your local
> stuff) typically is unknown at 99.99% of all places, indicates that the
> employee PKI model suffers from pretty serious trust establishment issues

Ok - now you're tickling one of my favourite points of discussion. The entire 
idea behind the PKI framework being worked on within the Aerospace industry 
is that it is meant to be only for within the industry. As I tell my clients, 
if you want a certificate for a web portal that is B2C focused (i.e.: for 
John Q. Public to access and interact with) then buy a Verisign (or 
equivalent) SSL certificate. If you want a certificate for 
inter-industry "closed community" collaboration (B2B within the closed 
community that is an aerospace program or project), then use a certificate 
from a CA that is cross-certified with CertiPath. Within the industry, we 
have worked out solutions for trust anchor establishment (although if more 
people did PDVAL correctly, it would make it even easier:), so we're not 
interested in propagating each individual companies CA Trust Anchor to 
millions of non-affiliated entities. In the ideal case (where the platforms 
that we work on do PDVAL correctly), each company would only propagate it's 
own trust anchor to its internal systems (trivial with such mechanisms as AD 
group policies), and let the pdval tools do their jobs when presented with 
a "external" certificate. If that external cert can "cross the bridge", then 
we're fine. If it can't, then don't trust it.

> d.. Privacy concerns.  Who (in the organization) actually orders goods is
> not necessarily something the seller needs to know.  In fact, employment is
> not public information Regarding who is authorized "to sign on behalf of
> the company", I believe that such certificates should only to be used for
> secure messaging which means that they are installed in gateway servers
> and/or information systems.  The purpose of such signatures is supporting
> authenticity and message integrity, while "consent" and "authorization" are
> things that typically stay inside of the company.  This is at least how
> bank transaction networks operate.
>

Ok - we've got a slightly different view on this point - the precise point of 
Org certs is to act as the digital equivalent of the corporate seal, which is 
the legacy mechanism for engaging the corporation in some sort of contract, 
liability, or promise - eg.: Signature.

The way that I see it, the EV SSL certs that are currently being espoused 
today are probably sufficient to convey the identity assurance that would be 
required for gateway messaging servers - for us to develop an industry 
specific solution that would compete with this would subject us to precisely 
the concerns that you had in b) and c).

> In addition, company certificates open the road for even more sophisticated
> security schemes which I have briefly covered on the last page of:
> http://webpki.org/papers/web/gateway.pdf
>
I've not read your paper yet, but I'll add it to my list :)

-- 
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca

Date: Wed, 19 Nov 2008 10:23:51 +1100
From: Steven Legg <[email-masked]>
To: Tom Gindin <[email-masked]>
CC: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

Tom,

Regards,
Steven

> encode the received cert into DER before checking.

From: Stefan Santesson <[email-masked]>
To: Mike <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 19 Nov 2008 00:45:50 +0000
Subject: RE: Robustness principle
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

I would say that it is impossible to successfully generalize what an approp=
riate behavior is.
What is reasonable in one situation and context is not reasonable in anothe=
r.

No matter what we say, implementers will do what best serves their customer=
s and their own business.

Stefan Santesson
Senior Program Manager

> On Behalf Of Mike
> Sent: den 18 november 2008 17:25
> To: [email-masked]
> Subject: Re: Robustness principle
>
>
> > If signature verification on "as is" fails, but succeeds for DER
> > encoded, what harm do you see in saving, using and relaying DER
> encoded?
>
> Saving and using the fixed version for your own purposes is fine, but
> you shouldn't pass it along.  If re-encoding the certificate renders
> it valid, then somewhere along the way somebody broke it.  That broken
> software needs to be fixed, so if you don't pass along the fixed
> version, discovering where the problem is will be much easier, and
> there will be more unhappy people to pressure them for a fix.  As an
> engineer I understand that it may be easier to just add a little code
> to work around a problem.  Then you end up with something like SSLv2
> with so many little workarounds that are not in any document which
> make it nearly impossible to implement (and interoperate).  Fortunately
> SSLv2 can now be considered historical.
>
> Mike
>

Date: Wed, 19 Nov 2008 00:39:21 +0000
From: Stephen Farrell <[email-masked]>
To: Eric Norman <[email-masked]>
CC: [email-masked]
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

Stephen.

Date: Wed, 19 Nov 2008 11:23:47 +1100
From: Stephen Wilson <[email-masked]>
Reply-To: [email-masked]
Organization: Lockstep
To: Anders Rundgren <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Sender: [email-masked]

Anders Rundgren wrote:
> 	... VeriSign's SSL PKI reaches out over the entire globe, while
>       employee PKIs (be it PIV or just your local stuff) typically is
>       unknown at 99.99% of all places, indicates that the employee PKI
>       model suffers from pretty serious trust establishment issues

This is another red herring.  It tells us nothing true or deep about the 
effectiveness of individual certificates.  The fact that employee PKIs 
don't have global reach is hardly surprising.  To begin with, global 
recognition of *employees* outside the enterprise is not usually 
important!  Look at the J&J corporate PKI; seems to be working great 
with 100,000+ individuals.

But more importantly, successful PKIs are always application specific. 
[BTW the application-specificity of SSL server certificates is really 
one of their most salient features, but almost always overlooked when 
people try to draw lessons form SSL's success!]  The reach problem that 
so concerns Anders is really only a matter of root key distribution. 
With application specific PKI, where 9 times out of 10 the transacting 
parties run special software (healthcare apps, conveyancing, trade 
documentation management, Skype etc etc), root key distribution is 
trivial.

Cheers,

Steve Wilson.

Managing Director
Lockstep Technologies

Phone +61 (0)414 488 851

www.lockstep.com.au/technologies
-------------------
  * ABC TV 'The New Inventors' Nov 2008
  * Global Security Challenge Asia Top Five 2008
  * Australian Technology Showcase 2008
  * AusIndustry COMET Grant 2007
  * ICT Secrets of Innovation Finalist (Security) 2007
  * Anthill / PwC Cool Company Finalist (Innovation) 2007
-------------------
Lockstep Technologies develops unique new smart ID solutions to
safeguard identity and privacy. Lockstep Consulting provides
independent specialist advice and analysis on authentication, PKI
and smartcards.

Date: Tue, 18 Nov 2008 17:53:08 -0600
From: Eric Norman <[email-masked]>
Subject: Re: encoding an X.509 certificate
To: [email-masked]
Sender: [email-masked]

Eric Norman

Date: Tue, 18 Nov 2008 15:25:26 -0800
From: Mike <[email-masked]>
To: [email-masked]
Subject: Re: Robustness principle
Sender: [email-masked]

> If signature verification on "as is" fails, but succeeds for DER
> encoded, what harm do you see in saving, using and relaying DER encoded?

Saving and using the fixed version for your own purposes is fine, but
you shouldn't pass it along.  If re-encoding the certificate renders
it valid, then somewhere along the way somebody broke it.  That broken
software needs to be fixed, so if you don't pass along the fixed
version, discovering where the problem is will be much easier, and
there will be more unhappy people to pressure them for a fix.  As an
engineer I understand that it may be easier to just add a little code
to work around a problem.  Then you end up with something like SSLv2
with so many little workarounds that are not in any document which
make it nearly impossible to implement (and interoperate).  Fortunately
SSLv2 can now be considered historical.

Mike

Date: Wed, 19 Nov 2008 10:23:51 +1100
From: Steven Legg <[email-masked]>
To: Tom Gindin <[email-masked]>
CC: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

Tom,

Regards,
Steven

> encode the received cert into DER before checking.

From: Stefan Santesson <[email-masked]>
To: Anders Rundgren <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 18 Nov 2008 22:41:47 +0000
Subject: RE: The EU Signature Directive - A 15+15 Year Perspective
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_000_9F11911AED01D24BAA1C2355723C3D321AB0CF72DCEAEXMSGC332eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Anders,

On the factual side, the EU signature directive was adopted 1999, which is =
9 years ago and not 15.
Further, the primary function of the EU directive was to establish that no =
signature should be denied legal value solely because it was not based on a=
 certain technology or met certain standards. The article 5 signature (ofte=
n referred to as qualified signatures) are just a level of security that al=
l member countries MUST accept as equivalent to hand-written signatures. I =
certainly agree that the content and intention of this directive has been h=
ighly misunderstood.

The requirements on electronic invoicing comes from a totally separate dire=
ctive.

However, I lack any specific technical proposal for this working group to c=
onsider in your e-mail.
In absence of such proposal, your mail appears to me more as a political ma=
nifesto.

Stefan Santesson
Senior Program Manager

From: [email-masked] [mailto:[email-masked]] On=
 Behalf Of Anders Rundgren
Sent: den 18 november 2008 04:38
To: [email-masked]
Subject: The EU Signature Directive - A 15+15 Year Perspective

Some 15 years ago the EU launched a signature directive.  This posting trie=
s to describe the consequences of this directive with respect to usage of P=
KI.

Primary Motivation

There are a number of processes needing a human-written signature in order =
to fulfill legal requirements.

Some of these processes could without doubt be possible to carry out electr=
onically and thus also remote over a network, if there was some kind of tec=
hnology available that could serve as a replacement for a hand-written sign=
ature.

The Solution

Right or wrong, digital signatures using PKI were considered as a viable al=
ternative.  To make PKI a credible solution, the EU signature directive add=
ed a number of requirements including characteristics of the signature crea=
tion device and policies for CAs.

Current Deployment

Apart from Qualified Certificates which (for reasons too diverse for descri=
bing in an email) have not become truly mainstream, the EU signature direct=
ive have indeed in local legislations made it possible to perform fairly qu=
alified tasks remotely over the Internet.  I.e. the directive has functione=
d as an ENABLER.

Then Something Went Wrong...

Unfortunately, a few (but influential) people got a bit carried away and in=
terpreted the signature directive in way that has severely hampered the use=
 of PKI.  Essentially they began claiming that all messages in order to be =
trustworthy should be signed by a qualified signature or at least by a digi=
tal signature created under the direct control a human being.

>From a 50000 ft perspective this may sound like a great idea, but the fact =
is that decades before the signature directive was conceived; yes, even bef=
ore PKI was invented, the concept of secure messaging actually existed.  Ba=
ck in those days secure messaging was facilitated through the use of leased=
 lines which allowed banks (and some early b2b networks), to securely excha=
nge transaction messages in a completely automated fashion.

An example:  If you want to wire-transfer money from your bank to another b=
ank, the way the transfer is initiated (phone, paper, on-line, etc) has no =
impact on the transaction messaging because it is performed in a transactio=
n network that neither the customers, nor most of the staff have direct acc=
ess to.

That such networks have proved to be secure, reliable, cost-efficient, and =
sometimes even globally scalable, apparently did not impress the bunch of h=
ard-core signature experts who for example in Germany managed to make PKI a=
 DISABLER by outlawing non-human digital signatures on invoices.  That Germ=
an paper-invoices do not even require signatures makes this position a true=
 mystery.

One had hoped that this would be an exception to the rule but it is not; If=
 you scan sites like NIST.GOV, CIO.GOV, and GSA.GOV you'll find literally t=
housands of security-related documents, indeed in a few places mentioning P=
KI, but mostly full of government regulation abbreviations like FISMA, givi=
ng little if any guidance on how to create secure messaging between agencie=
s, not to mention between agencies and the private sector.

I'm happy to see that the Nordic countries plus Estonia have realized that =
all signatures that can be securely bound to an entity (in practice) are le=
gally binding, in the extremely rare case somebody would actually repudiate=
 a signed invoice.   These governments have all (and independently of each =
other) created local variants of a scheme that I have described in:
http://webpki.org/papers/web/gateway.pdf
which could be characterized as a 21st century version of leased lines for =
multi-party automated secure messaging.
It will probably take another 15 years for this concept to achieve general =
acceptance although it is really (if you look closely) very similar to the =
US e-Authentication scheme, they have just not connected the dots yet: A SA=
ML assertion and an server-signed invoice from a specific entity are essent=
ially only different in content, not in trustworthiness.

Anders Rundgren
http://WebPKI.org

--_000_9F11911AED01D24BAA1C2355723C3D321AB0CF72DCEAEXMSGC332eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www=
.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoin=
t/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns=
:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile=
" xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns=
:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns=
:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http=
://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"ht=
tp://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z=3D"urn:s=
chemas-microsoft-com:" xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-=
html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span lang=3DEN-US style=
=3D'font-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Anders,<o:p></o:p>=
</span></a></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>On the factual side, the EU signature directive was adopted
1999, which is 9 years ago and not 15.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>Further, the primary function of the EU directive was to
establish that no signature should be denied legal value solely because it =
was
not based on a certain technology or met certain standards. The article 5
signature (often referred to as qualified signatures) are just a level of
security that all member countries MUST accept as equivalent to hand-writte=
n
signatures. I certainly agree that the content and intention of this direct=
ive
has been highly misunderstood.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>The requirements on electronic invoicing comes from a totall=
y
separate directive.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>However, I lack any specific technical proposal for this wor=
king
group to consider in your e-mail. <o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>In absence of such proposal, your mail appears to me more as=
 a
political manifesto.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'col=
or:navy'><o:p></o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> [email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Anders Rundgren<b=
r>
<b>Sent:</b> den 18 november 2008 04:38<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> The EU Signature Directive - A 15+15 Year Perspective<o:p><=
/o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>Some
15 years ago the EU launched a signature directive.&nbsp; This posting trie=
s to
describe the consequences of this directive with respect to usage of PKI.</=
span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><strong><span style=3D'font-family:"Arial","sans-serif=
"'>Primary
Motivation</span></strong><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>There
are a number of processes&nbsp;needing a human-written signature in order t=
o
fulfill legal requirements.</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>Some
of these processes could without doubt be possible to carry out electronica=
lly
and thus also remote over a network, if there was some kind of technology
available that could serve as a replacement for a hand-written signature.</=
span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><strong><span style=3D'font-family:"Arial","sans-serif=
"'>The
Solution</span></strong><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>Right
or wrong, digital signatures using PKI were considered as&nbsp;a
viable&nbsp;alternative.&nbsp; To make PKI a credible solution, the EU
signature directive added a number of requirements including characteristic=
s of
the signature creation device and policies for CAs.</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><strong><span style=3D'font-family:"Arial","sans-serif=
"'>Current
Deployment</span></strong><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>Apart
from Qualified Certificates which (for reasons too diverse for describing i=
n an
email) have not become truly mainstream, the EU signature directive have in=
deed
in local legislations made it possible to perform fairly qualified tasks
remotely over the Internet.&nbsp; I.e. the directive has functioned as an <=
strong><span
style=3D'font-family:"Arial","sans-serif"'>ENABLER</span></strong>.<o:p></o=
:p></span></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><strong><span style=3D'font-family:"Arial","sans-serif=
"'>Then
Something Went&nbsp;Wrong...</span></strong><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>Unfortunately,
a few (but&nbsp;influential) people got a bit carried away and interpreted =
the
signature directive in way that has severely hampered the use of PKI.&nbsp;
Essentially they began claiming that all messages in order to
be&nbsp;trustworthy should be signed by a qualified signature or at least b=
y a
digital signature created&nbsp;under the direct control&nbsp;a human being.=
</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>From
a 50000 ft perspective this may sound like a great idea, but the fact is th=
at
decades before the signature directive was conceived; yes, even before PKI =
was
invented, the concept of secure messaging actually existed.&nbsp;&nbsp;Back=
 in
those days&nbsp;secure messaging was facilitated through the use of leased
lines which allowed banks (and some early b2b networks), to securely exchan=
ge
transaction messages <em><span style=3D'font-family:"Arial","sans-serif"'>i=
n a
completely automated fashion</span></em>.</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>An
example:&nbsp; If you want to wire-transfer money from your bank to another
bank, the way the transfer is initiated (phone, paper,&nbsp;on-line,
etc)&nbsp;has no impact on the transaction messaging because it
is&nbsp;performed in a transaction network that neither the&nbsp;customers,
nor&nbsp;most of the staff have direct access to.&nbsp;</span><o:p></o:p></=
p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>That&nbsp;such
networks have proved to be secure, reliable, cost-efficient, and sometimes =
even
globally scalable, apparently did not impress the bunch of hard-core signat=
ure
experts who for example in Germany managed to make PKI a <strong><span
style=3D'font-family:"Arial","sans-serif"'>DISABLER</span></strong> by outl=
awing
non-human digital signatures on invoices.&nbsp; That German paper-invoices =
do
not even require signatures&nbsp;makes this position a true mystery.</span>=
<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>One
had hoped that this would be an exception to the rule but it is not; If you
scan sites like NIST.GOV, CIO.GOV, and GSA.GOV you'll find literally thousa=
nds
of security-related documents, indeed in a few places mentioning PKI, but
mostly full of government regulation abbreviations like FISMA, giving littl=
e if
any guidance on how to create secure messaging between agencies, not to men=
tion
between agencies and the private sector.</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>I'm
happy to see&nbsp;that the Nordic countries plus Estonia have realized that=
 all
signatures that can be securely bound to an entity (in practice) are legall=
y
binding, in the extremely rare case somebody would actually repudiate a sig=
ned
invoice.&nbsp;&nbsp; These governments have all (and independently of each
other) created local variants of&nbsp;a scheme that I have described in:</s=
pan><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><a href=3D"http://webpki.org/papers/web/gateway.pdf"><=
span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>http://webpki.o=
rg/papers/web/gateway.pdf</span></a><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>which&nbsp;could
be characterized as&nbsp;a 21st century version of leased lines for multi-p=
arty&nbsp;automated
secure messaging.</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>It
will probably take another 15 years for this concept to achieve general
acceptance although it is really (if you look closely) very similar&nbsp;to=
 the
US e-Authentication scheme, they have just not connected the dots yet:&nbsp=
;A
SAML assertion and an server-signed&nbsp;invoice from a specific entity are
essentially only different in content, not in trustworthiness.</span><o:p><=
/o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>Anders
Rundgren</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'><a
href=3D"http://WebPKI.org">http://WebPKI.org</a></span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D321AB0CF72DCEAEXMSGC332eu_--

Content-class: urn:content-classes:message
Subject: RE: Robustness principle
Date: Tue, 18 Nov 2008 16:59:09 -0500
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Stefan,

The purpose of my post was that while relaying payload is a good
principle, if I am going to use the certificate to create a new payload,
I should DER encode the certificate if the signature verifies on the DER
encoding.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]=20
Sent: Tuesday, November 18, 2008 4:50 PM
To: Santosh Chokhani; Mike; [email-masked]
Subject: RE: Robustness principle

I agree, but I'm not sure where this has applicability within the
context of standardization.

If you pass a certificate to me where the signature validates, I will be
able to use it and trust it regardless of whether you "fixed" it.

The situation is quite different when we talk about signed objects. For
this case there is only one single representation of the signed data
that will match the signature. The Relying Party is safe as long as the
signature validates and the signed data can be decoded.

Stefan Santesson
Senior Program Manager

> From: [email-masked]
[mailto:[email-masked]]
> Sent: den 18 november 2008 15:05
> To: Mike; [email-masked]
> Subject: RE: Robustness principle
>
>
> Mike,
>
> If signature verification on "as is" fails, but succeeds for DER
> encoded, what harm do you see in saving, using and relaying DER
encoded?
>
> One harm I see is that the payload that contained the certificate
> itself, may be signed and that signature will break.
>
[mailto:[email-masked]]
> On Behalf Of Mike
> Sent: Tuesday, November 18, 2008 3:50 PM
> To: [email-masked]
> Subject: Robustness principle
>
>
> The robustness principle is not necessarily bad when it is
> applied as it was originally intended.  It has two parts:
>
>     1 - be liberal in what you accept
>     2 - be conservative in what you send
>
> The problem is that some people incorrectly interpret the
> second part to mean, "if you accepted something non-standard
> (that would otherwise have been rejected), *attempt to fix
> it* before passing it along, so what you send is standard-
> compliant."
>
> W.R.T. a non-DER-encoded certificate, I think the best thing
> you can do as an RP is to first attempt to validate it as is,
> and if that fails, optionally attempt to re-encode it as DER
> and validate it a second time.  That is being liberal in
> what you accept.
>
> However, DO NOT pass your "fixed" version on to anyone else;
> always give them the original.  That is being conservative
> in what you send.  It may seem like you should help your
> neighbor, but perhaps they wield the kind of power that can
> cause the originator to actually fix their broken software,
> making the situation better for everyone.
>
> I have a lot of experience in email server software design
> where in the 90's it was considered a good thing to fix email
> messages that didn't have proper CR-LF line endings.  This
> "helpful" behavior causes too many problems, so it is no
> longer recommended.  It, too, was done in the name of the
> robustness principle, but the principle does not actually
> advocate modifying relayed objects.
>
> Mike
>

From: Stefan Santesson <[email-masked]>
To: Santosh Chokhani <[email-masked]>, Mike <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 18 Nov 2008 21:50:09 +0000
Subject: RE: Robustness principle
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

I agree, but I'm not sure where this has applicability within the context o=
f standardization.

If you pass a certificate to me where the signature validates, I will be ab=
le to use it and trust it regardless of whether you "fixed" it.

The situation is quite different when we talk about signed objects. For thi=
s case there is only one single representation of the signed data that will=
 match the signature. The Relying Party is safe as long as the signature va=
lidates and the signed data can be decoded.

Stefan Santesson
Senior Program Manager

> Sent: den 18 november 2008 15:05
> To: Mike; [email-masked]
> Subject: RE: Robustness principle
>
>
> Mike,
>
> If signature verification on "as is" fails, but succeeds for DER
> encoded, what harm do you see in saving, using and relaying DER encoded?
>
> One harm I see is that the payload that contained the certificate
> itself, may be signed and that signature will break.
>
> On Behalf Of Mike
> Sent: Tuesday, November 18, 2008 3:50 PM
> To: [email-masked]
> Subject: Robustness principle
>
>
> The robustness principle is not necessarily bad when it is
> applied as it was originally intended.  It has two parts:
>
>     1 - be liberal in what you accept
>     2 - be conservative in what you send
>
> The problem is that some people incorrectly interpret the
> second part to mean, "if you accepted something non-standard
> (that would otherwise have been rejected), *attempt to fix
> it* before passing it along, so what you send is standard-
> compliant."
>
> W.R.T. a non-DER-encoded certificate, I think the best thing
> you can do as an RP is to first attempt to validate it as is,
> and if that fails, optionally attempt to re-encode it as DER
> and validate it a second time.  That is being liberal in
> what you accept.
>
> However, DO NOT pass your "fixed" version on to anyone else;
> always give them the original.  That is being conservative
> in what you send.  It may seem like you should help your
> neighbor, but perhaps they wield the kind of power that can
> cause the originator to actually fix their broken software,
> making the situation better for everyone.
>
> I have a lot of experience in email server software design
> where in the 90's it was considered a good thing to fix email
> messages that didn't have proper CR-LF line endings.  This
> "helpful" behavior causes too many problems, so it is no
> longer recommended.  It, too, was done in the name of the
> robustness principle, but the principle does not actually
> advocate modifying relayed objects.
>
> Mike
>

From: Patrick Patterson <[email-masked]>
Reply-To: [email-masked]
Organization: Carillon Information Security Inc.
To: [email-masked]
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Tue, 18 Nov 2008 16:49:27 -0500
Sender: [email-masked]

On November 18, 2008 12:55:57 pm Anders Rundgren wrote:
> Hi Patrick,
>
> <snip>
>
> >As an aside, this is one of the reasons that in the Aerospace industry,
> > we're working on the concept of "Organisational" certificates (PKI analog
> > to the corporate seal).
>
> That's interesting and VERY GOOD news!  I thought the Aerospace industry
> spent their PKI money on [IMO] rather awkward Bridge CA stuff like
> http://certipath.com which I consider the opposite to Organizational
> certificates since Bridge CAs is typically rather about extending the reach
> of (existing) employee certificates.
>
Well, I'll let Santosh ring in on this if he wants, but the I can say that 
most of the companies with which I am familiar have had to implement or beef 
up their "existing" PKI infrastructures to comply with the much more rigorous 
and standardised requirements of joining the Bridge, thus facilitating, 
within the community at least, the establishment of Trust "more than a few 
blocks away from your own backyard" :)

> >It neatly side-steps the mental block that some people have regarding
> >"one person, one key", and allows anyone who is authorized to "sign
> >on behalf of the company" to use the PKI based corporate seal.
>
> Apart from possible mental blocks, there are other quite down-to-earth
> hurdles as well: 
> a.. Employees come and go => Your "digital handles" to 
> other companies easily get invalid 

That is why the Corporate Seal (you know - the one that is a physical piece of 
hardware, is kept in a safe, and is only let out by the corporate lawyers for 
defined and logged purposes) is a usefull concept to translate into the 
Digital Credential (read PKI) realm. Since the Certificate is issued to the 
corporate legal body, and not any particular physical person, it doesn't 
suffer from the same problems as "personal" certificates.

> b.. How do you automatically and 
> securely correlate a company identity as expressed in business messages
> with a PKI-based employee identity, and preferably make that scale a few
> blocks from of your own backyard? 

Is this is somewhat dependant on both the messaging format, and the trust and 
policy infrastructure that you place on the Organisational issuing practices? 

Not to get into any dogmatic debates, but by leveraging the Bridge within the 
community, we believe that this can allow the trust in the Org certs to be 
validated to quite a rigorous level.

> c.. That VeriSign's SSL PKI reaches out 
> over the entire globe, while employee PKIs (be it PIV or just your local
> stuff) typically is unknown at 99.99% of all places, indicates that the
> employee PKI model suffers from pretty serious trust establishment issues

Ok - now you're tickling one of my favourite points of discussion. The entire 
idea behind the PKI framework being worked on within the Aerospace industry 
is that it is meant to be only for within the industry. As I tell my clients, 
if you want a certificate for a web portal that is B2C focused (i.e.: for 
John Q. Public to access and interact with) then buy a Verisign (or 
equivalent) SSL certificate. If you want a certificate for 
inter-industry "closed community" collaboration (B2B within the closed 
community that is an aerospace program or project), then use a certificate 
from a CA that is cross-certified with CertiPath. Within the industry, we 
have worked out solutions for trust anchor establishment (although if more 
people did PDVAL correctly, it would make it even easier:), so we're not 
interested in propagating each individual companies CA Trust Anchor to 
millions of non-affiliated entities. In the ideal case (where the platforms 
that we work on do PDVAL correctly), each company would only propagate it's 
own trust anchor to its internal systems (trivial with such mechanisms as AD 
group policies), and let the pdval tools do their jobs when presented with 
a "external" certificate. If that external cert can "cross the bridge", then 
we're fine. If it can't, then don't trust it.

> d.. Privacy concerns.  Who (in the organization) actually orders goods is
> not necessarily something the seller needs to know.  In fact, employment is
> not public information Regarding who is authorized "to sign on behalf of
> the company", I believe that such certificates should only to be used for
> secure messaging which means that they are installed in gateway servers
> and/or information systems.  The purpose of such signatures is supporting
> authenticity and message integrity, while "consent" and "authorization" are
> things that typically stay inside of the company.  This is at least how
> bank transaction networks operate.
>

Ok - we've got a slightly different view on this point - the precise point of 
Org certs is to act as the digital equivalent of the corporate seal, which is 
the legacy mechanism for engaging the corporation in some sort of contract, 
liability, or promise - eg.: Signature.

The way that I see it, the EV SSL certs that are currently being espoused 
today are probably sufficient to convey the identity assurance that would be 
required for gateway messaging servers - for us to develop an industry 
specific solution that would compete with this would subject us to precisely 
the concerns that you had in b) and c).

> In addition, company certificates open the road for even more sophisticated
> security schemes which I have briefly covered on the last page of:
> http://webpki.org/papers/web/gateway.pdf
>
I've not read your paper yet, but I'll add it to my list :)

-- 
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca

From: Stefan Santesson <[email-masked]>
To: pkix <[email-masked]>
Date: Tue, 18 Nov 2008 21:08:49 +0000
Subject: PKIX meeting slides
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_000_9F11911AED01D24BAA1C2355723C3D321AB0CF72ADEAEXMSGC332eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All of you who are presenting at the PKIX meeting on Thursday, please send =
me your slides prior to the meeting so I can make them available on the mee=
ting materials page.
https://datatracker.ietf.org/meeting/73/materials.html

Stefan Santesson
Senior Program Manager

--_000_9F11911AED01D24BAA1C2355723C3D321AB0CF72ADEAEXMSGC332eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www=
.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoin=
t/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns=
:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile=
" xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns=
:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns=
:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http=
://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"ht=
tp://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z=3D"urn:s=
chemas-microsoft-com:" xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-=
html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN-US>All of you who are presenting at th=
e PKIX
meeting on Thursday, please send me your slides prior to the meeting so I c=
an
make them available on the meeting materials page.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><a
href=3D"https://datatracker.ietf.org/meeting/73/materials.html">https://dat=
atracker.ietf.org/meeting/73/materials.html</a><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D321AB0CF72ADEAEXMSGC332eu_--

Content-class: urn:content-classes:message
Subject: RE: Robustness principle
Date: Tue, 18 Nov 2008 16:05:12 -0500
From: "Santosh Chokhani" <[email-masked]>
To: "Mike" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Mike,

If signature verification on "as is" fails, but succeeds for DER
encoded, what harm do you see in saving, using and relaying DER encoded?

One harm I see is that the payload that contained the certificate
itself, may be signed and that signature will break.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Mike
Sent: Tuesday, November 18, 2008 3:50 PM
To: [email-masked]
Subject: Robustness principle

The robustness principle is not necessarily bad when it is
applied as it was originally intended.  It has two parts:

    1 - be liberal in what you accept
    2 - be conservative in what you send

The problem is that some people incorrectly interpret the
second part to mean, "if you accepted something non-standard
(that would otherwise have been rejected), *attempt to fix
it* before passing it along, so what you send is standard-
compliant."

W.R.T. a non-DER-encoded certificate, I think the best thing
you can do as an RP is to first attempt to validate it as is,
and if that fails, optionally attempt to re-encode it as DER
and validate it a second time.  That is being liberal in
what you accept.

However, DO NOT pass your "fixed" version on to anyone else;
always give them the original.  That is being conservative
in what you send.  It may seem like you should help your
neighbor, but perhaps they wield the kind of power that can
cause the originator to actually fix their broken software,
making the situation better for everyone.

I have a lot of experience in email server software design
where in the 90's it was considered a good thing to fix email
messages that didn't have proper CR-LF line endings.  This
"helpful" behavior causes too many problems, so it is no
longer recommended.  It, too, was done in the name of the
robustness principle, but the principle does not actually
advocate modifying relayed objects.

Mike

Date: Tue, 18 Nov 2008 12:50:04 -0800
From: Mike <[email-masked]>
To: [email-masked]
Subject: Robustness principle
Sender: [email-masked]

The robustness principle is not necessarily bad when it is
applied as it was originally intended.  It has two parts:

    1 - be liberal in what you accept
    2 - be conservative in what you send

The problem is that some people incorrectly interpret the
second part to mean, "if you accepted something non-standard
(that would otherwise have been rejected), *attempt to fix
it* before passing it along, so what you send is standard-
compliant."

W.R.T. a non-DER-encoded certificate, I think the best thing
you can do as an RP is to first attempt to validate it as is,
and if that fails, optionally attempt to re-encode it as DER
and validate it a second time.  That is being liberal in
what you accept.

However, DO NOT pass your "fixed" version on to anyone else;
always give them the original.  That is being conservative
in what you send.  It may seem like you should help your
neighbor, but perhaps they wield the kind of power that can
cause the originator to actually fix their broken software,
making the situation better for everyone.

I have a lot of experience in email server software design
where in the 90's it was considered a good thing to fix email
messages that didn't have proper CR-LF line endings.  This
"helpful" behavior causes too many problems, so it is no
longer recommended.  It, too, was done in the name of the
robustness principle, but the principle does not actually
advocate modifying relayed objects.

Mike

Date: Tue, 18 Nov 2008 14:54:15 -0500
To: "David A. Cooper" <[email-masked]>, Julien Stern <[email-masked]>
From: Michael StJohns <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: [email-masked]
Sender: [email-masked]

--=====================_594740406==.ALT
Content-Type: text/plain; charset="us-ascii"

Mike

>>as a side note, while it may already implicitly be the case, a strongly worded statement by PKIX that implementations should reject all these "bogus" certificates (in BER, with negative serials, wi…

--=====================_594740406==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
X509 actually - in a backwards way - requires one extension to be marked
critical.&nbsp; The text in X509 is
&quot;<font face="Times New Roman, Times" size=2>If this extension field
is present and is flagged critical, the </font><font size=1><b>subject
</b></font><font face="Times New Roman, Times" size=2>field of the
certificate may contain a null name (e.g., a sequence of zero relative
distinguished names) in which case the subject is identified only by the
name or names in this extension. &quot;&nbsp; - note 2 under
8.3.2.1<br><br>
</font>This refers to the SubjectAltName extension.&nbsp; Another way of
stating it (and this is how 5280 states it) - if the subject field has a
null name, there MUST be a subjectAltName and it MUST be
critical.<br><br>
Mike<br><br>
<br><br>
At 02:29 PM 11/18/2008, David A. Cooper wrote:<br><br>
<blockquote type=cite class=cite cite="">We need to be careful to
distinguish between &quot;bogus&quot; certificates and certificates that
were not issued in conformance with RFC 5280.&nbsp; While RFC 5280
requires conforming CAs to use positive serial numbers, there is no such
requirement in X.509.&nbsp; Similarly, while X.509 requires that some
public key certificate extensions be marked non-critical, X.509 does not
require that any public key certificate extensions be marked
critical.&nbsp; There are, however, a few CRL and CRL entry extensions
that X.509 says must be marked critical.<br><br>
Dave<br><br>
Julien Stern wrote:<br>
<blockquote type=cite class=cite cite="">Steve,<br><br>
as a side note, while it may already implicitly be the case, a strongly
worded statement by PKIX that implementations should reject all these
&quot;bogus&quot; certificates (in BER, with negative serials, without
critical extensions when they have to be, etc) would certainly help
smaller vendors to &quot;plead their cause&quot; when they are told that
their software &quot;do not work&quot; (well, if there is indeed a
consensus on this statement, of course).<br><br>
Regards,<br><br>
-- <br>
Julien<br>
</blockquote></blockquote></body>
<br>
</html>

--=====================_594740406==.ALT--

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: AD comments for draft-ietf-pkix-ecc-subpubkeyinfo-09
Date: Tue, 18 Nov 2008 13:41:54 -0600
Organization: IECA, Inc.
Sender: [email-masked]

>From: [email-masked] [mailto:[email-masked]] 
>
>Sean,
>
>Thanks for a quick reply!
>
>> To answer your questions:
>> 
>> 1) Using parameter inheritance would mean that the EE certificate 
>> would not contain all of the necessary information that would be 
>> required for relying party to process a certificate.  The relying 
>> party might luck in to guessing the curve because there are only so 
>> many "well known" curves for a given key size, but to be sure the 
>> relying party would need to get the curve either from an issuer's 
>> certificate or through some other means.  The last paragraph of
>> 2.1.1 address these options.
>
>Hmm -- guessing the curve sounds like it could be dangerous?
>(But I haven't really thought what the attacks could be..)
>
>> 2) The rationale for retaining parameter inheritance is that many 
>> people that support DSA already deal with parameter inheritance in 
>> that context.  So, it may not be a burden to keep this capability in 
>> the specification.
>
>With DSA, inheritance saves hundreds of bytes, so this 
>optimization makes more sense there. Also, I think ECDSA could 
>get more widely used than DSA has been (and in more open and 
>non-homogeneous environments), so there are more opportunities 
>for problems to arise. (But opinions from other WG members 
>would be welcome, too.)

I talked to the one advocate (i.e., Russ H.) and he said he was fine taking
it out.  Nobody else has posted anything suggesting that they were
interested in this choice.  I'll comment it out, add some text to the ASN.1
note (the '88 ASN.1 below), and modify the bullet:

ECParameters ::= CHOICE {
  namedCurve         OBJECT IDENTIFIER
  -- implicitCurve   NULL
  -- specifiedCurve  SpecifiedECDomain
}
  -- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
  -- Details for SpecifiedECDomain can be found in [X9.62].
  -- Any future additions to this CHOICE should be coordinated
  -- with ANSI X.9.

o implicitCurve allows the elliptic curve parameters to be inherited.  This
choice MUST NOT be used.

>> It's PKIX so we generally assume people are doing path validation ;)
>
>Well, that's not always what other IETF WGs are doing :) 
>
>> >Topic #2: scope of Appendix A
>> >
>> >For a document that specifies how to carry ECC public keys in 
>> >SubjectPublicKeyInfo, I was sort of expecting ASN.1 module(s) to do 
>> >so.  When I got to Appendix A, I was very surprised to find ASN.1 
>> >modules that contain mostly other things (not related to 
>ECC at all, 
>> >or not related to SubjectPublicKeyInfo) -- nothing in the main 
>> >document (abstract and Sections 1..8) hinted that this would be 
>> >coming. Could you briefly explain why ASN.1 about RSA, DSA, 
>MD5, etc. 
>> >belongs in this document?
>> 
>> One of early comments was that since we're updating RFC 
>3279, we'd end 
>> up with a Chinese menu for implementers if we didn't update 
>the entire 
>> RFC 3279 module.  RFC 3279 includes more than ECC "stuff" so if we 
>> update the RFC 3279 module have baggage.
>
>Sounds like a reasonable explanation. Could you add a sentence 
>or two to the document abstract and introduction explaining this?

Yes.

><snip>
>> The reference to draft-ietf-pkix-new-asn1 is an informative 
>reference.  
>> I wish the reference could be normative, but we'd be blocked on it.  
>> We could 1) pull the appendix out of the document (we'd have 
>some text 
>> tweaking to do) and put the appendix in a) separate document 
>b) put it 
>> in draft-ietf-pkix-new-asn1 2) leave it in the document and 
>produce an 
>> update after draft-ietf-pkix-asn1 gets published that says the 
>> appendices are now normative 3) indicate that it does not form a 
>> normative part of the document (not sure what we'd do with the 
>> reference).  I am willing to be guided on the best way forward.
>
>I guess this depends how soon draft-ietf-pkix-new-asn1 is 
>going to be ready. If we want to publish ecc-subpubkeyinfo 
>first, I would suggest moving Appendix A.4 to draft-ietf-pkix-new-asn1.

The time frame we're looking to meet for IEEE is RFC status before they go
to ballot.  I think that time frame is sometime in Jan so to do that I think
it might be best to rip out the '02 ASN.1 module.  Turns out they don't care
which version of the ASN.1 we use.  I talked with Jim and Paul and they're
happy to put the '02 module in their document so the information won't get
lost.  They're looking at going to WG LC in January so it wouldn't be to far
on the heals of draft-ietf-pkix-ecc-subpubkeyinfo.  There's some from matter
text tweaking that will need to be done to remove the '02 syntax but it
shouldn't take too long.  We'll also revert back to one ASN.1 module because
we're not duplicating the OIDs in multiple places in this document.

spt

Date: Tue, 18 Nov 2008 13:29:05 -0600
From: "David A. Cooper" <[email-masked]>
To: Julien Stern <[email-masked]>
CC: [email-masked]
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

Dave

> software "do not work" (well, if there is indeed a consensus on this 

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Tue, 18 Nov 2008 18:55:57 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0361_01C949AF.4A8F4EA0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Patrick,

<snip>

>As an aside, this is one of the reasons that in the Aerospace industry, =
we're=20
>working on the concept of "Organisational" certificates (PKI analog to =
the=20
>corporate seal).

That's interesting and VERY GOOD news!  I thought the Aerospace industry =
spent their PKI money on [IMO] rather awkward Bridge CA stuff like =
http://certipath.com which I consider the opposite to Organizational =
certificates since Bridge CAs is typically rather about extending the =
reach of (existing) employee certificates.

>It neatly side-steps the mental block that some people have regarding =20
>"one person, one key", and allows anyone who is authorized to "sign=20
>on behalf of the company" to use the PKI based corporate seal.

Apart from possible mental blocks, there are other quite down-to-earth =
hurdles as well:
  a.. Employees come and go =3D> Your "digital handles" to other =
companies easily get invalid
  b.. How do you automatically and securely correlate a company identity =
as expressed in business messages with a PKI-based employee identity, =
and preferably make that scale a few blocks from of your own backyard?
  c.. That VeriSign's SSL PKI reaches out over the entire globe, while =
employee PKIs (be it PIV or just your local stuff) typically is unknown =
at 99.99% of all places, indicates that the employee PKI model suffers =
from pretty serious trust establishment issues
  d.. Privacy concerns.  Who (in the organization) actually orders goods =
is not necessarily something the seller needs to know.  In fact, =
employment is not public information
Regarding who is authorized "to sign on behalf of the company", I =
believe that such certificates should only to be used for secure =
messaging which means that they are installed in gateway servers and/or =
information systems.  The purpose of such signatures is supporting =
authenticity and message integrity, while "consent" and "authorization" =
are things that typically stay inside of the company.  This is at least =
how bank transaction networks operate.

In addition, company certificates open the road for even more =
sophisticated security schemes which I have briefly covered on the last =
page of:
http://webpki.org/papers/web/gateway.pdf

Regards
Anders Rundgren
http://WebPKI.org

------=_NextPart_000_0361_01C949AF.4A8F4EA0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<META content=3D"MSHTML 6.00.6000.20927" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>Hi Patrick,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&lt;snip&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT><BR><FONT face=3DArial =
size=3D2>&gt;As an aside,=20
this is one of the reasons that in the Aerospace industry, we're =
<BR>&gt;working=20
on the concept of "Organisational" certificates (PKI analog to the=20
<BR>&gt;corporate seal).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>That's interesting and VERY GOOD news! =
&nbsp;I=20
thought the Aerospace industry spent their PKI money </FONT><FONT =
face=3DArial=20
size=3D2>on [IMO]&nbsp;rather awkward Bridge CA stuff like </FONT><FONT =
face=3DArial=20
size=3D2><A =
href=3D"http://certipath.com">http://certipath.com</A>&nbsp;</FONT><FONT =

face=3DArial size=3D2>which I consider the opposite to Organizational =
certificates=20
since Bridge&nbsp;CAs is typically rather about extending the reach of=20
(existing) employee certificates.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&gt;It neatly side-steps the mental =
block that some=20
people have&nbsp;regarding&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&gt;"one person, one key", and allows =
anyone who is=20
authorized to "sign <BR>&gt;on behalf of the company" to use the PKI =
based=20
corporate seal.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Apart from possible mental blocks, =
there are other=20
quite down-to-earth hurdles as well:</FONT></DIV>
<UL>
  <LI><FONT face=3DArial size=3D2>Employees come and go =3D&gt; Your =
"digital handles"=20
  to&nbsp;other companies easily get invalid</FONT></LI>
  <LI><FONT face=3DArial size=3D2>How do you automatically and securely=20
  correlate&nbsp;a company identity as expressed</FONT><FONT =
face=3DArial size=3D2>=20
  in business messages&nbsp;with&nbsp;a PKI-based&nbsp;employee =
identity, and=20
  preferably&nbsp;make that</FONT><FONT face=3DArial =
size=3D2>&nbsp;scale a=20
  few&nbsp;blocks from of your own backyard?</FONT></LI>
  <LI><FONT face=3DArial size=3D2>That VeriSign's SSL PKI reaches out =
over the=20
  entire globe, while employee PKIs</FONT><FONT face=3DArial size=3D2> =
(be it PIV or=20
  just your local stuff) typically is unknown at 99.99% of all=20
  places,</FONT><FONT face=3DArial size=3D2> indicates that the employee =
PKI model=20
  suffers from pretty serious trust establishment issues</FONT></LI>
  <LI><FONT face=3DArial size=3D2>Privacy concerns.&nbsp; Who (in the=20
  organization)&nbsp;actually orders goods is not necessarily something =
the=20
  seller needs to know.&nbsp; In fact, employment is not public=20
  information</FONT></LI></UL>
<DIV><FONT face=3DArial size=3D2>Regarding who is authorized "to sign on =
behalf of=20
the company", I believe that such certificates&nbsp;should only to be =
used for=20
secure messaging which means that they are installed in gateway servers =
and/or=20
information systems.&nbsp; The purpose of such signatures is supporting=20
authenticity and message integrity, while "consent" and =
"authorization"&nbsp;are=20
things that typically&nbsp;stay inside of the company.&nbsp; This is at =
least=20
how bank transaction&nbsp;networks operate.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In addition, company certificates open =
the road for=20
even more sophisticated security schemes which I have briefly covered on =
the=20
last page of:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://webpki.org/papers/web/gateway.pdf"><FONT face=3DArial=20
size=3D2>http://webpki.org/papers/web/gateway.pdf</FONT></A></FONT></DIV>=

<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards</FONT></DIV><FONT face=3DArial =
size=3D2>
<DIV>Anders Rundgren</DIV>
<DIV><A href=3D"http://WebPKI.org">http://WebPKI.org</A></DIV>
<DIV><BR>&nbsp;</DIV></FONT></BODY></HTML>

------=_NextPart_000_0361_01C949AF.4A8F4EA0--

Date: Tue, 18 Nov 2008 17:50:13 +0100
From: Julien Stern <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

Steve,

Regards,

--
Julien

Date: Tue, 18 Nov 2008 11:29:50 -0500
To: Julien Stern <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: [email-masked]
Sender: [email-masked]

Steve

From: "Sood, Kapil" <[email-masked]>
To: Stephen Kent <[email-masked]>, "Timothy J. Miller" <[email-masked]>
CC: Eric Norman <[email-masked]>, "[email-masked]" <[email-masked]>, "Bar-Or, Sagi" <[email-masked]>
Date: Tue, 18 Nov 2008 08:26:40 -0800
Subject: RE: encoding an X.509 certificate
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

A testing (inter-op, certification) along these lines will be of immense va=
lue to numerous organizations that deploy PKI components...

Best Regards,
=20
Kapil.
971.506.1700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On=
 Behalf Of Stephen Kent
Sent: Tuesday, November 18, 2008 7:24 AM
To: Timothy J. Miller
Cc: Eric Norman; [email-masked]
Subject: Re: encoding an X.509 certificate

Steve

Date: Tue, 18 Nov 2008 17:01:16 +0100
From: Julien Stern <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

Regards,

--
Julien

Date: Tue, 18 Nov 2008 10:28:42 -0500
To: Julien Stern <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: [email-masked]
Sender: [email-masked]

Julien,

Steve

Date: Tue, 18 Nov 2008 10:24:17 -0500
To: "Timothy J. Miller" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: Eric Norman <[email-masked]>, [email-masked]
Sender: [email-masked]

Steve

Date: Tue, 18 Nov 2008 10:24:43 -0500
To: Tom Gindin <[email-masked]>, Stephen Kent <[email-masked]>
From: "Charles W. Gardiner" <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: [email-masked]
Sender: [email-masked]

Charlie Gardiner

>encode the received cert into DER before checking.

Date: Tue, 18 Nov 2008 10:12:52 -0500
To: Eric Norman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: [email-masked]
Sender: [email-masked]

Steve

Date: Tue, 18 Nov 2008 10:14:26 -0500
To: Eric Norman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: [email-masked]
Sender: [email-masked]

Steve

Date: Tue, 18 Nov 2008 08:49:26 -0600
From: "Timothy J. Miller" <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: Eric Norman <[email-masked]>, [email-masked]
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

--------------ms030800020400050902020303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

-- Tim

--------------ms030800020400050902020303
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms030800020400050902020303--

From: Patrick Patterson <[email-masked]>
Reply-To: [email-masked]
Organization: Carillon Information Security Inc.
To: [email-masked]
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Tue, 18 Nov 2008 09:27:22 -0500
Sender: [email-masked]

Hi Anders:

On November 18, 2008 08:35:24 am Anders Rundgren wrote:
> Hi Juergen,
>
> Should I interpret your response like following?  In Germany you can buy
> special equipment or services in which a company official (CFO?) puts
> another instance of his/her smart card, and then this card is used to
> automatically sign outgoing invoices that this card-owner typically has
> neither seen nor have direct control of, including when he or she is at
> home sleeping?
>
Just how is this different from the signature printers that are used on all 
cheques issued by larger companies? Or the signature stamp that has been in 
use by accounting departments for at least a century?

> This is sometimes referred to as the "hostage" PKI solution and must be one
> of the most flagrant examples of "pushing the envelope" ever heard of,
> since this scheme obviously was not the intent with the EU signature
> directive.
>
No, this is business reality - one needs an "officer of the company" to sign 
documents (be they cheques, invoices, purchase orders, etc.), and no company 
over a couple of hundred employees is going to make their CFO and COO sit 
down and spend their days signing documents. They will use either the printed 
(or stamped) equivalent of their handwritten signature, or the PKI 
alternative.

As long as the use of these signatures is controlled by policy, and is 
accountable, then just because it isn't a "pure" implementation, doesn't mean 
that it isn't valid.

As an aside, this is one of the reasons that in the Aerospace industry, we're 
working on the concept of "Organisational" certificates (PKI analog to the 
corporate seal). It neatly side-steps the mental block that some people have 
regarding "one person, one key", and allows anyone who is authorised to "sign 
on behalf of the company" to use the PKI based corporate seal.

-- 
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca

From: "Anders Rundgren" <[email-masked]>
To: "Juergen Brauckmann" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Date: Tue, 18 Nov 2008 14:35:24 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_01AE_01C9498A.E444D300
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Juergen,

Should I interpret your response like following?  In Germany you can buy =
special equipment or services in which a company official (CFO?) puts =
another instance of his/her smart card, and then this card is used to =
automatically sign outgoing invoices that this card-owner typically has =
neither seen nor have direct control of, including when he or she is at =
home sleeping?

This is sometimes referred to as the "hostage" PKI solution and must be =
one of the most flagrant examples of "pushing the envelope" ever heard =
of, since this scheme obviously was not the intent with the EU signature =
directive.

Anders Rundgren

----- Original Message -----=20
From: "Juergen Brauckmann" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, November 18, 2008 12:56
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective

Anders Rundgren wrote:
> hard-core signature experts who for example in Germany managed=20
> to make PKI a *DISABLER* by outlawing non-human digital signatures on=20
> invoices.  That German paper-invoices do not even require=20
> signatures makes this position a true mystery.

It is my understanding that requiring qualified digital signature on=20
invoices is targeted against VAT refund fraud.

Actually there are several products and services that you can buy to=20
automate qualified signature creation; google shows you some of them if=20
you ask for "signature server".

J=FCrgen

------=_NextPart_000_01AE_01C9498A.E444D300
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.20927" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>Hi Juergen,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Should I interpret&nbsp;your =
response&nbsp;like=20
following?&nbsp; In Germany you can buy special equipment or services in =
which a=20
company official (CFO?)&nbsp;puts another instance of his/her smart =
card, and=20
then this card is used to <EM>automatically sign outgoing invoices</EM> =
that=20
this card-owner typically has neither seen nor have direct control of, =
including=20
when he or she is at home sleeping?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>This is sometimes referred =
to&nbsp;as&nbsp;the=20
"hostage" PKI solution and must be</FONT><FONT face=3DArial size=3D2> =
one of the=20
most flagrant examples of "pushing the envelope" ever heard of, since =
this=20
scheme&nbsp;obviously was not the intent with&nbsp;the EU signature=20
directive.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders Rundgren</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>----- Original Message ----- </FONT>
<DIV><FONT face=3DArial size=3D2>From: "Juergen Brauckmann" =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DArial=20
size=3D2>[email-masked]</FONT></A><FONT face=3DArial=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>To: "Anders Rundgren" &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DArial=20
size=3D2>[email-masked]</FONT></A><FONT face=3DArial=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Cc: &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DArial=20
size=3D2>[email-masked]</FONT></A><FONT face=3DArial =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Sent: Tuesday, November 18, 2008 =
12:56</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Subject: Re: The EU Signature Directive =
- A 15+15=20
Year Perspective</FONT></DIV></DIV>
<DIV><FONT face=3DArial><BR><FONT size=3D2></FONT></FONT></DIV><FONT =
face=3DArial=20
size=3D2>Anders Rundgren wrote:<BR>&gt; hard-core signature experts who =
for=20
example in Germany managed <BR>&gt; to make PKI a *DISABLER* by =
outlawing=20
non-human digital signatures on <BR>&gt; invoices.&nbsp; That German=20
paper-invoices do not even require <BR>&gt; signatures makes this =
position a=20
true mystery.<BR><BR>It is my understanding that requiring qualified =
digital=20
signature on <BR>invoices is targeted against VAT refund =
fraud.<BR><BR>Actually=20
there are several products and services that you can buy to <BR>automate =

qualified signature creation; google shows you some of them if <BR>you =
ask for=20
"signature server".<BR><BR>J=FCrgen<BR></FONT></BODY></HTML>

------=_NextPart_000_01AE_01C9498A.E444D300--

Date: Tue, 18 Nov 2008 12:56:01 +0100
From: Juergen Brauckmann <[email-masked]>
Organization: DFN-CERT Services GmbH
To: Anders Rundgren <[email-masked]>
CC: [email-masked]
Subject: Re: The EU Signature Directive - A 15+15 Year Perspective
Sender: [email-masked]

Anders Rundgren wrote:
> hard-core signature experts who for example in Germany managed=20
> to make PKI a *DISABLER* by outlawing non-human digital signatures on=20
> invoices.  That German paper-invoices do not even require=20
> signatures makes this position a true mystery.

It is my understanding that requiring qualified digital signature on=20
invoices is targeted against VAT refund fraud.

Actually there are several products and services that you can buy to=20
automate qualified signature creation; google shows you some of them if=20
you ask for "signature server".

J=FCrgen

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: The EU Signature Directive - A 15+15 Year Perspective
Date: Tue, 18 Nov 2008 11:37:39 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0104_01C94972.0F669410
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Some 15 years ago the EU launched a signature directive.  This posting =
tries to describe the consequences of this directive with respect to =
usage of PKI.

Primary Motivation

There are a number of processes needing a human-written signature in =
order to fulfill legal requirements.

Some of these processes could without doubt be possible to carry out =
electronically and thus also remote over a network, if there was some =
kind of technology available that could serve as a replacement for a =
hand-written signature.

The Solution

Right or wrong, digital signatures using PKI were considered as a viable =
alternative.  To make PKI a credible solution, the EU signature =
directive added a number of requirements including characteristics of =
the signature creation device and policies for CAs.

Current Deployment

Apart from Qualified Certificates which (for reasons too diverse for =
describing in an email) have not become truly mainstream, the EU =
signature directive have indeed in local legislations made it possible =
to perform fairly qualified tasks remotely over the Internet.  I.e. the =
directive has functioned as an ENABLER.

Then Something Went Wrong...

Unfortunately, a few (but influential) people got a bit carried away and =
interpreted the signature directive in way that has severely hampered =
the use of PKI.  Essentially they began claiming that all messages in =
order to be trustworthy should be signed by a qualified signature or at =
least by a digital signature created under the direct control a human =
being.

>From a 50000 ft perspective this may sound like a great idea, but the =
fact is that decades before the signature directive was conceived; yes, =
even before PKI was invented, the concept of secure messaging actually =
existed.  Back in those days secure messaging was facilitated through =
the use of leased lines which allowed banks (and some early b2b =
networks), to securely exchange transaction messages in a completely =
automated fashion.

An example:  If you want to wire-transfer money from your bank to =
another bank, the way the transfer is initiated (phone, paper, on-line, =
etc) has no impact on the transaction messaging because it is performed =
in a transaction network that neither the customers, nor most of the =
staff have direct access to.=20

That such networks have proved to be secure, reliable, cost-efficient, =
and sometimes even globally scalable, apparently did not impress the =
bunch of hard-core signature experts who for example in Germany managed =
to make PKI a DISABLER by outlawing non-human digital signatures on =
invoices.  That German paper-invoices do not even require signatures =
makes this position a true mystery.

One had hoped that this would be an exception to the rule but it is not; =
If you scan sites like NIST.GOV, CIO.GOV, and GSA.GOV you'll find =
literally thousands of security-related documents, indeed in a few =
places mentioning PKI, but mostly full of government regulation =
abbreviations like FISMA, giving little if any guidance on how to create =
secure messaging between agencies, not to mention between agencies and =
the private sector.

I'm happy to see that the Nordic countries plus Estonia have realized =
that all signatures that can be securely bound to an entity (in =
practice) are legally binding, in the extremely rare case somebody would =
actually repudiate a signed invoice.   These governments have all (and =
independently of each other) created local variants of a scheme that I =
have described in:
http://webpki.org/papers/web/gateway.pdf
which could be characterized as a 21st century version of leased lines =
for multi-party automated secure messaging.

It will probably take another 15 years for this concept to achieve =
general acceptance although it is really (if you look closely) very =
similar to the US e-Authentication scheme, they have just not connected =
the dots yet: A SAML assertion and an server-signed invoice from a =
specific entity are essentially only different in content, not in =
trustworthiness.

Anders Rundgren
http://WebPKI.org

------=_NextPart_000_0104_01C94972.0F669410
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.20927" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Some 15 years ago the EU launched a =
signature=20
directive.&nbsp; This posting tries to describe the consequences of this =

directive with respect to usage of PKI.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><STRONG>Primary Motivation</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>There are a number of =
processes&nbsp;needing a=20
human-written signature in order to fulfill legal =
requirements.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Some of these processes could without =
doubt be=20
possible to carry out electronically and thus also remote over a =
network, if=20
there was some kind of technology available that could serve as a =
replacement=20
for a hand-written signature.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><STRONG>The Solution</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Right or wrong, digital signatures =
using PKI were=20
considered as&nbsp;a viable&nbsp;alternative.&nbsp; To make PKI a =
credible=20
solution, the EU signature directive added a number of requirements =
including=20
characteristics of the signature creation device and policies for=20
CAs.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><STRONG>Current Deployment</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>Apart from =
Qualified=20
Certificates which (for reasons too diverse for describing in an email) =
have not=20
become truly mainstream, the EU signature directive have indeed in local =

legislations made it possible to perform fairly qualified tasks remotely =
over=20
the Internet.&nbsp; I.e. the directive has functioned as an=20
<STRONG>ENABLER</STRONG>.</FONT></DIV>
<DIV></FONT><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><STRONG>Then Something=20
Went&nbsp;Wrong...</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Unfortunately, a few =
(but&nbsp;influential) people=20
got a bit carried away and interpreted the signature directive in way =
that has=20
severely hampered the use of PKI.&nbsp; Essentially they began claiming =
that all=20
messages in order to be&nbsp;trustworthy should be signed by a qualified =

signature or at least by a digital signature created&nbsp;under the =
direct=20
control&nbsp;a human being.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>From a 50000 ft perspective this may =
sound like a=20
great idea, but the fact is that decades before the signature directive =
was=20
conceived; yes, even before PKI was invented, the concept of secure =
messaging=20
actually existed.&nbsp;&nbsp;Back in those days&nbsp;secure messaging =
was=20
facilitated through the use of leased lines which allowed banks (and =
some early=20
b2b networks), to securely exchange transaction messages <EM>in a =
completely=20
automated fashion</EM>.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>An example:&nbsp; If you want to =
wire-transfer=20
money from your bank to another bank, the way the transfer is initiated =
(phone,=20
paper,&nbsp;on-line, etc)&nbsp;has no impact on the transaction =
messaging=20
because it is&nbsp;performed in a transaction network that neither=20
the&nbsp;customers, nor&nbsp;most of the staff have direct access=20
to.&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>That&nbsp;such networks have proved to =
be secure,=20
reliable, cost-efficient, and sometimes even globally scalable, =
apparently did=20
not impress the bunch of hard-core signature experts who for example in =
Germany=20
managed to make PKI a <STRONG>DISABLER</STRONG> by outlawing non-human =
digital=20
signatures on invoices.&nbsp; That German paper-invoices do not even =
require=20
signatures&nbsp;makes this position a true mystery.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>One had hoped that this would be an =
exception to=20
the rule but it is not; If you scan sites like NIST.GOV, CIO.GOV, and =
GSA.GOV=20
you'll find literally thousands of security-related documents, indeed in =
a few=20
places mentioning PKI, but mostly full of government regulation =
abbreviations=20
like FISMA, giving little if any guidance on how to create secure =
messaging=20
between agencies, not to mention between agencies and the private=20
sector.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I'm happy to see&nbsp;that the Nordic =
countries=20
plus Estonia have realized that all signatures that can be securely =
bound to an=20
entity (in practice) are legally binding, in the extremely rare case =
somebody=20
would actually repudiate a signed invoice.&nbsp;&nbsp; These governments =
have=20
all (and independently of each other) created local variants of&nbsp;a =
scheme=20
that I have described in:</FONT></DIV>
<DIV><A href=3D"http://webpki.org/papers/web/gateway.pdf"><FONT =
face=3DArial=20
size=3D2>http://webpki.org/papers/web/gateway.pdf</FONT></A></DIV>
<DIV><FONT face=3DArial size=3D2>which&nbsp;could be characterized =
as&nbsp;a 21st=20
century version of leased lines for multi-party&nbsp;automated secure=20
messaging.</FONT><BR></DIV>
<DIV><FONT face=3DArial size=3D2>It will probably take another 15 years =
for this=20
concept to achieve general acceptance although it is really (if you look =

closely) very similar&nbsp;to the US e-Authentication scheme, they have =
just not=20
connected the dots yet:&nbsp;A SAML assertion and an =
server-signed&nbsp;invoice=20
from a specific entity are essentially only different in content, not in =

trustworthiness.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders Rundgren</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://WebPKI.org">http://WebPKI.org</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0104_01C94972.0F669410--

Date: Mon, 17 Nov 2008 23:05:50 -0500
To: Eric Norman <[email-masked]>, [email-masked]
From: Michael StJohns <[email-masked]>
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

Mike

>Why shouldn't the robustness principle apply in this case?

To: Stephen Kent <[email-masked]>
Cc: [email-masked], [email-masked], Peter Gutmann <[email-masked]>, "Timothy J. Miller" <[email-masked]>
Subject: Re: encoding an X.509 certificate
From: Tom Gindin <[email-masked]>
Date: Mon, 17 Nov 2008 20:41:29 -0500
Sender: [email-masked]

        Steve:

                Tom Gindin

To

Tom,

Steve

Date: Mon, 17 Nov 2008 15:12:51 -0600
From: Eric Norman <[email-masked]>
Subject: Re: encoding an X.509 certificate
To: [email-masked]
Sender: [email-masked]

To be clear.

Eric Norman

Date: Mon, 17 Nov 2008 15:08:46 -0600
From: Eric Norman <[email-masked]>
Subject: Re: encoding an X.509 certificate
To: [email-masked]
Sender: [email-masked]

OK.

Eric Norman

Date: Mon, 17 Nov 2008 15:51:16 -0500
To: "Timothy J. Miller" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: Eric Norman <[email-masked]>, [email-masked]
Sender: [email-masked]

agreed.

agreed.

Steve

Date: Mon, 17 Nov 2008 14:31:01 -0600
From: "Timothy J. Miller" <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: Eric Norman <[email-masked]>, [email-masked]
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

--------------ms020006050004060602030603
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

-- Tim

--------------ms020006050004060602030603
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020006050004060602030603--

Date: Mon, 17 Nov 2008 12:03:59 -0800
From: Arshad Noor <[email-masked]>
Organization: StrongAuth, Inc.
To: [email-masked]
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

Arshad Noor
StrongAuth, Inc.

> powerful entity than yours :)

Date: Mon, 17 Nov 2008 13:50:09 -0500
To: Eric Norman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: [email-masked]
Sender: [email-masked]

Steve

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt (second part)
Date: Mon, 17 Nov 2008 13:25:25 -0500
From: "Carl Wallace" <[email-masked]>
To: "ietf-pkix" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C948E1.DC68836A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

inline...

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Denis Pinkas
	Sent: Thursday, November 06, 2008 5:27 AM
	To: ietf-pkix
	Subject: Re: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt
(second part)
=09
=09
	In order to keep the message short, two answers are given on
this document.
	=20

	Comments on draft-ietf-pkix-ta-mgmt-reqs-02

	=20

	Topic: Clarifications needed about associated data, purpose and=20

	constraints.

	=20

	For most web browsers and Java machines, the current situation
is the=20

	following:

	=20

	   - self-signed certificates are used for all purposes, e.g.
TLS server,

	     TLS client, sending e-mails, receiving e-mails, applets'
signatures,

	     and

	=20

	   - it is unknown whether revocation conditions are checked and
how.

	=20

	Suppose (for the time being) that we want to move from the
current=20

	situation where self-signed certificates are placed in the same
storage and=20

	hence used for all purposes to a situation where self-signed
certificates=20

	are no more used for any purpose, e.g. used for sending e-mails
or used for=20

	receiving e-mails.

	=20

	There are two possible approaches:

	=20

	   a) consider a given a *purpose*, e.g. applets' signatures,
and then=20

	      list all self-signed certificates that can be used for
such a

	      purpose, or

	=20

	   b) consider each self-signed certificate and tell for which
purpose=20

	      that self-signed certificate may be used.

	=20

	If we take into consideration the "need-to-know" requirement,
some=20

	applications need to know which self-signed certificates shall
be used for=20

	a given purpose and do not need to know if they are also used
for a=20

	different purpose.=20

	=20

=09

	The approach a) fulfils this requirement, but not the approach
b).

	=20

	When a path validation must be done for a given purpose, case a)
is rather=20

	straightforward: all the information is under the purpose.

	=20

	With case b), this would be more difficult, since the
application would=20

	need to scan every "Trust Anchor" store (?) and look if the
given purpose=20

	is mentioned under a "Trust Anchor".

	=20

	Case a) allows a clear and clean separation of information.
However, it=20

	seems that the document has implicitly chosen case b). :-(=20

	=20

	[CRW] This document does not choose a) or b).  You are
describing implementation details for how a trust anchor store is
queried.  We're not defining an API for interacting with a trust anchor
store.

	=20

	It is unclear in the current document what is the relationship
between the=20

	purpose of use of a self-signed certificate that would be placed
in TA, the=20

	"Trust Anchor" itself or the "Trust Anchor Store".

	=20

	Is one Trust anchor Store usable for some specific purpose(s)?=20

	=20

	Hence is the "purpose" part of the Trust Anchor Store rather
than=20
	the Trust Anchor itself?=20

	=20

	All this needs to be clarified. Once this will be clarified,=20

	it will be possible to address the kind of operations that
should be=20

	possible on the various objects.=20

	=20

	[CRW] The document does not discuss purpose in terms of a trust
anchor store.  One could create and manage a trust anchor store such
that the trust anchor store served a specific purpose.  One could define
an purpose-centric API for interacting with a trust anchor store that
served multiple purposes. =20

	=20

=09

=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D

	=20

	In the abstract the text states:

	=20

	   The public key is used to verify digital

	   signatures and the *associated data is used to constrain* the
types of

	   information for which the trust anchor is authoritative.

	=20

	This sentence is confusing since the word "constrain" is kept
vague and=20

	thus does not make the difference between:

	=20

	   1) the intended purpose,

	   2) the constraints that are set by the CA and apply for all
purposes,

	   3) the constraints that are set by the RP.

	=20

	Let us now illustrate case 2): the constraints are included into
the self-

	signed certificate. The constraints are set by the CA and apply
to all=20

	usages of that self-signed certificate, i.e. all "purposes".

	=20

	Let us now illustrate cases 3): the constraints are external to
the self-

	signed certificate. The constraints come in addition to those
included=20

	inside the self-signed certificate and are tailored to the
specific=20

	purpose.

	=20

	Case 2) and case 3) may co-exist.=20

	=20

	However, the current draft does not make the distinction between
case 2)=20

	and case 3). This is rather fundamental, since a "TA manager"
cannot change=20

	the constraints that are included in a self-signed certificate.=20

	=20

	[CRW] A "TA manager" cannot change what's included in a
self-signed certificate but it can define additional restrictions or
further restrict the constraints contained in a self-signed certificate.
This is addressed in the subordination processing rules in the TAMP
draft.=20

	=20

=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D

	=20

	The document defines a Trust Anchor as : "A trust anchor
represents an=20

	authoritative entity via a public key and associated data". This
sentence=20

	is confusing since the wording "associated data" means
everything and thus=20

	nothing.=20

	=20

	This definition is not coherent with RFC 5280 which states on
page 76:

	=20

	   " The trust anchor information includes:

	=20

	      (1)  the trusted issuer name,

	      (2)  the trusted public key algorithm,

	      (3)  the trusted public key, and

	      (4)  optionally, the trusted public key parameters
associated

	           with the public key.

	=20

	The issuer name shall always be present in a trust anchor".

	=20

	The definition of a TA should also make the difference between:

	=20

	   a) the constraints that are set by the CA and apply for all
purposes,

	   b) the constraints that are set by the RP.

	=20

	Only the later, can be managed when self-signed certificates are
used.=20

	=20

	[CRW] I think the definition of a trust anchor has been
sufficiently discussed and don't see anything here that warrants a
change.  I recognize the difference with 5280, but TAs have broader use
than just 5280, as noted in the draft.=20

	=20

=09

=09

	Denis
	=20

------_=_NextPart_001_01C948E1.DC68836A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D =
"urn:schemas-microsoft-com:office:office"><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16735" name=3DGENERATOR></HEAD>
<BODY style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=3D5 =
topMargin=3D5=20
#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D948152103-14112008>inline...</SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>Denis=20
  Pinkas<BR><B>Sent:</B> Thursday, November 06, 2008 5:27 =
AM<BR><B>To:</B>=20
  ietf-pkix<BR><B>Subject:</B> Re: I-D=20
  Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt (second part)<BR><BR></DIV>
  <DIV></DIV>
  <DIV>In order to keep the message short, two answers are given on this =

  document.</DIV>
  <DIV><SPAN lang=3DEN-GB style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></DIV>
  <DIV>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Comments =
on=20
  draft-ietf-pkix-ta-mgmt-reqs-02<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Topic:=20
  Clarifications needed about associated data, purpose and=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New">constraints.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">For most =
web=20
  browsers and Java machines, the current situation is the=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New">following:<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>- self-signed =
certificates are=20
  used for all purposes, e.g. TLS server,<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>TLS =
client, sending=20
  e-mails, receiving e-mails, applets' =
signatures,<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>and<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>- it is unknown =
whether=20
  revocation conditions are checked and =
how.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Suppose =
(for the=20
  time being) that we want to move from the current=20
<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">situation where=20
  self-signed certificates are placed in the same storage and=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">hence =
used for all=20
  purposes to a situation where self-signed certificates=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">are no =
more used for=20
  any purpose, e.g. used for sending e-mails or used for=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">receiving=20
  e-mails.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">There =
are two=20
  possible approaches:<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>a) consider a given a =
*purpose*,=20
  e.g. applets' signatures, and then <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>list =
all=20
  self-signed certificates that can be used for such=20
  a<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>purpose,=20
  or<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>b) consider each =
self-signed=20
  certificate and tell for which purpose <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>that =

  self-signed certificate may be used.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">If we =
take into=20
  consideration the "need-to-know" requirement, some=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">applications need to=20
  know which self-signed certificates shall be used for=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">a given =
purpose and=20
  do not need to know if they are also used for a =
<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">different=20
  purpose.</FONT><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New"></FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
approach a)=20
  fulfils this requirement, but not the approach=20
b).<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">When a =
path=20
  validation must be done for a given purpose, case a) is rather=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">straightforward: all=20
  the information is under the purpose.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">With =
case b), this=20
  would be more difficult, since the application would=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">need to =
scan every=20
  "Trust Anchor" store (?) and look if the given purpose=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">is =
mentioned under a=20
  "Trust Anchor".<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Case a) =
allows a=20
  clear and clean separation of information. However, it=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">seems =
that the=20
  document has implicitly chosen case b). :-(</FONT><FONT =
face=3DTahoma><SPAN=20
  class=3D948152103-14112008>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008></SPAN></FONT></SPAN>&nbsp;</P><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008><FONT face=3D"Courier New">[CRW]&nbsp;This =
document=20
  does not choose a) or b).&nbsp; You&nbsp;are describing implementation =
details=20
  for&nbsp;how a trust anchor store is queried.&nbsp; We're not defining =
an API=20
  for interacting with a trust anchor=20
  store.</FONT></SPAN></FONT></SPAN></SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">It is =
unclear in the=20
  current document what is the relationship between the=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">purpose =
of use of a=20
  self-signed certificate that would be placed in TA, the=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">"Trust =
Anchor"=20
  itself or the "Trust Anchor Store&#8221;.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Is one =
Trust anchor=20
  Store usable for some specific purpose(s)? </FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New"></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Hence is =

  </FONT></SPAN><SPAN lang=3DEN-GB style=3D"mso-ansi-language: =
EN-GB"><FONT=20
  face=3D"Courier New">the "purpose" part of the Trust Anchor Store =
rather than=20
  <BR>the Trust A</FONT></SPAN><SPAN lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">nchor =
itself?=20
  </FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New"></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">All this =
needs to be=20
  clarified. Once this will be clarified, <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">it will =
be possible=20
  to address the kind of operations that should be =
<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">possible =
on the=20
  various objects.</FONT><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  class=3D948152103-14112008></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  class=3D948152103-14112008>[CRW] The document does not discuss purpose =
in terms=20
  of a trust anchor store.&nbsp; One could create and manage a trust =
anchor=20
  store such that the trust anchor store served a specific =
purpose.&nbsp; One=20
  could define an purpose-centric API for interacting with a trust =
anchor store=20
  that served multiple purposes.&nbsp; </SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New"></FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier =
New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">In the =
abstract the=20
  text states:<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The public key is used =
to verify=20
  digital<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>signatures and the =
*associated=20
  data is used to constrain* the types of<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>information for which =
the trust=20
  anchor is authoritative.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">This =
sentence is=20
  confusing since the word "constrain" is kept vague and=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">thus =
does not make=20
  the difference between:<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>1) the intended=20
  purpose,<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>2) the constraints =
that are set=20
  by the CA and apply for all purposes,<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>3) the constraints =
that are set=20
  by the RP.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Let us =
now=20
  illustrate case 2): the constraints are included into the=20
  self-<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">signed =
certificate.=20
  The constraints are set by the CA and apply to all=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">usages =
of that=20
  self-signed certificate, i.e. all =
"purposes".<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Let us =
now=20
  illustrate cases 3): the constraints are external to the=20
  self-<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">signed =
certificate.=20
  The constraints come in addition to those included=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">inside =
the=20
  self-signed certificate and are tailored to the specific=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New">purpose.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Case 2) =
and case 3)=20
  may co-exist. <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">However, =
the current=20
  draft does not make the distinction between case 2)=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">and case =
3). This is=20
  rather fundamental, since a "TA manager" cannot change=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">the =
constraints that=20
  are included in a self-signed certificate.</FONT><FONT =
face=3DTahoma><SPAN=20
  class=3D948152103-14112008>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008><FONT face=3D"Courier New">[CRW] A "TA =
manager" cannot=20
  change what's included in a self-signed certificate but it can define=20
  additional restrictions or further restrict the constraints contained =
in a=20
  self-signed certificate.&nbsp; This is addressed&nbsp;in the =
subordination=20
  processing rules in&nbsp;the TAMP=20
  draft.</FONT>&nbsp;</SPAN><o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier =
New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
document defines=20
  a Trust Anchor as : "A trust anchor represents an=20
<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">authoritative entity=20
  via a public key and associated data". This sentence=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">is =
confusing since=20
  the wording "associated data" means everything and thus=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">nothing. =

  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">This =
definition is=20
  not coherent with RFC 5280 which states on page=20
  76:<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; " </SPAN>The trust anchor =
information=20
  includes:<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>(1)<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>the trusted issuer=20
  name,<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;</SPAN><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;</SPAN>(2)<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>the trusted public key=20
  algorithm,<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>(3)<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>the trusted public key,=20
  and<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>(4)<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>optionally, the trusted =
public key=20
  parameters associated<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>with the public key.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
issuer name=20
  shall always be present in a trust =
anchor".<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
definition of a=20
  TA should also make the difference =
between:<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>a) the constraints =
that are set=20
  by the CA and apply for all purposes,<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>b) the constraints =
that are set=20
  by the RP.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Only the =
later, can=20
  be managed when self-signed certificates are used.</FONT><FONT=20
  face=3DTahoma><SPAN =
class=3D948152103-14112008>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008><FONT face=3D"Courier New">[CRW] I think =
the definition=20
  of a trust anchor has been sufficiently discussed and don't see =
anything here=20
  that warrants a change.&nbsp; I recognize the difference with 5280, =
but TAs=20
  have broader use than just&nbsp;5280, as noted in the=20
  draft.</FONT>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D948152103-14112008></SPAN><o:p></o:p></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New"></FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"></SPAN></P></DIV>
  <DIV></DIV>
  <DIV><!--AID_FROMNAME_BEGIN-->Denis</DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C948E1.DC68836A--

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt
Date: Mon, 17 Nov 2008 13:25:23 -0500
From: "Carl Wallace" <[email-masked]>
To: "ietf-pkix" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C948E1.DB11330A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

inline...

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Denis Pinkas
	Sent: Thursday, November 06, 2008 5:25 AM
	To: ietf-pkix
	Subject: Re: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt
=09
=09
	In order to keep the message short, two answers are given on
this document.
	=20

	Comments on draft-ietf-pkix-ta-mgmt-reqs-02

	=20

	Topic: automatic root key rollover only using trust anchors
initially=20

	installed.

	=20

	The document states on page 7:

	=20

	   Ideally, only the initial set of trust anchors are installed
in=20

	   a particular trust anchor store should require out-of-band=20

	   verification, particularly when the costs of performing
out-of-band=20

	   checks commensurate with the security requirements of
applications=20

	   using the trust anchor store are high.

	=20

	It implicitly means that once an initial set of trust anchors is
installed,=20

	the renewal should happen automatically.=20

	=20

	Unfortunately, this text is only a *statement* within section 2
"Problem=20

	Statement" rather than a *requirement* within section 3
"Requirements". It=20

	should be transformed into a requirement with section 3.=20

	=20

	In practice, we are very close to reach this goal.

	=20

	The CMP protocol allows RPs to pull the information and to
automatically=20

	update trust anchors using the old-by-new self-signed
certificate and the=20

	new-by-new self-signed certificate. There are only two
additional questions=20

	to be answered:=20

	=20

	   a) where to fetch these self-signed-certificates ?

	   b) when to fetch these self-signed-certificates ?=20

	=20

	The answer to the first question is:=20

	=20

	   1) add an LDAP address or an HTTP address, or

	   2) use an Authority Information Access extension=20

	      within the self-signed certificate.

	=20

	The answer to the second question is:=20

	=20

	   1) add a time period for root key renewal, or

	   2) use a private key usage extension within the self-signed
certificate.

	=20

	 ... and then we are done when CA issue self-signed
certificates, which is=20

	what *all* CAs are doing today.

	=20

	It does not matter where self-signed certificates are stored,
e.g. in=20

	validation policies or in TA anchors stores (whatever this last
term may=20

	mean).

	=20

	It means that the use of self-signed certificates allows
automatic root key=20

	rollover and to reach the ideal situation mentioned above.

	=20

	A major advantage of this approach is the use of a pull model:
the process=20

	is initiated from the inside of a company and the number of
applications=20

	using that self-signed certificate may be hidden to the outside.
Denial of=20

	service is easier to handle since the first exchange comes from
the inside.=20

	=20

	These considerations should be taken into consideration in the
draft.=20

	=20

	[CRW] A mechanism based solely on self-signed certificates and
newWithOld/oldWithNew will fail to meet several of the requirements.
Given that auto-renewal could be implemented in terms of existing
requirements, I don't see a need to add it as a separate requirement.  I
don't think we need to enumerate all extensions/associated data in this
draft.

	=20

=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

	=20

	The document states in section 3.1.: Transport independence

	=20

	   "It MUST work in both session-oriented

	   and store-and-forward communications environments as well as
in both

	   push and pull distribution models".

	=20

	CMP only works in a pull model. With such sentence CMP would be
ruled out=20

	whereas it is already a standard track protocol.=20

	=20

=09

	The document states in section 3.1.: Transport independence

	=20

	   "connectionless integrity and data origin

	   authentication for TA transactions MUST be provided at the

	   application layer".

	=20

	With CMP, the security is obtained directly by the self-signed=20

	certificates, i.e. the data itself which is self-protected. With
such=20

	sentence CMP would be ruled out, whereas it is already a
standard track=20

	protocol.

	=20

	[CRW] CMP fails to meet several of the requirements. =20

	=20

	The document cannot say on one side that the pull model is
allowed and on=20

	the other side include requirements which rule out the use of
CMP (which is=20

	based on a pull model).

	=20

	Denis

	=20

------_=_NextPart_001_01C948E1.DB11330A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D =
"urn:schemas-microsoft-com:office:office"><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16735" name=3DGENERATOR></HEAD>
<BODY style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=3D5 =
topMargin=3D5=20
#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D358121203-14112008>inline...</SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>Denis=20
  Pinkas<BR><B>Sent:</B> Thursday, November 06, 2008 5:25 =
AM<BR><B>To:</B>=20
  ietf-pkix<BR><B>Subject:</B> Re: I-D=20
  Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt<BR><BR></DIV>
  <DIV></DIV>
  <DIV>In order to keep the message short, two answers are given on this =

  document.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Comments =
on=20
  draft-ietf-pkix-ta-mgmt-reqs-02<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Topic: =
automatic=20
  root key rollover only using trust anchors initially=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New">installed.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
document states=20
  on page 7:<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>Ideally, only the =
initial set of=20
  trust anchors are installed in <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>a particular trust =
anchor store=20
  should require out-of-band <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>verification, =
particularly when=20
  the costs of performing out-of-band <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>checks commensurate =
with the=20
  security requirements of applications <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>using the trust anchor =
store are=20
  high.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">It =
implicitly means=20
  that once an initial set of trust anchors is installed,=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">the =
renewal should=20
  happen automatically.</FONT><FONT face=3DTahoma><SPAN=20
  class=3D358121203-14112008>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D358121203-14112008><FONT=20
  face=3D"Courier New"></FONT></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">Unfortunately, this=20
  text is only a *statement* within section 2 "Problem=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">Statement" rather=20
  than a *requirement* within section 3 "Requirements". It=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">should =
be=20
  transformed into a requirement with section 3.</FONT><FONT =
face=3DTahoma><SPAN=20
  class=3D358121203-14112008>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  class=3D358121203-14112008></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">In =
practice, we are=20
  very close to reach this goal.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The CMP =
protocol=20
  allows RPs to pull the information and to automatically=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">update =
trust anchors=20
  using the old-by-new self-signed certificate and the=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">new-by-new=20
  self-signed certificate. There are only two additional questions=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">to be =
answered:=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">&nbsp;&nbsp; a)=20
  where to fetch these self-signed-certificates =
?<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">&nbsp; =
b) when to=20
  fetch these self-signed-certificates ? <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
answer to the=20
  first question is: <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>1) add an LDAP address =
or an=20
  HTTP address, or<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>2) use an Authority =
Information=20
  Access extension <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>within the=20
  self-signed certificate.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
answer to the=20
  second question is: <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>1) add a time period =
for root=20
  key renewal, or<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>2) use a private key =
usage=20
  extension within the self-signed =
certificate.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;</SPAN>... and then we are done when =
CA issue=20
  self-signed certificates, which is <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">what =
*all* CAs are=20
  doing today.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">It does =
not matter=20
  where self-signed certificates are stored, e.g. in=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">validation policies=20
  or in TA anchors stores (whatever this last term may=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New">mean).<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">It means =
that the=20
  use of self-signed certificates allows automatic root key=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">rollover =
and to=20
  reach the ideal situation mentioned =
above.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">A major =
advantage of=20
  this approach is the use of a pull model: the process=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">is =
initiated from=20
  the inside of a company and the number of applications=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">using =
that=20
  self-signed certificate may be hidden to the outside. Denial of=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">service =
is easier to=20
  handle since the first exchange comes from the inside.=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">These =
considerations=20
  should be taken into consideration in the draft.</FONT><FONT =
face=3DTahoma><SPAN=20
  class=3D358121203-14112008>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D358121203-14112008></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D358121203-14112008><FONT face=3D"Courier New">[CRW] =
</FONT><FONT=20
  face=3D"Courier New">A mechanism based solely on self-signed =
certificates and=20
  newWithOld/oldWithNew&nbsp;will fail to meet several of the=20
  requirements.&nbsp; Given that auto-renewal could be implemented in =
terms of=20
  existing requirements, I don't see a need to add it as a separate=20
  requirement.&nbsp; I don't think we need to enumerate all=20
  extensions/associated data in this =
draft.</FONT></SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier =
New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p=
></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
document states=20
  in section 3.1.: Transport independence<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>"It MUST work in both=20
  session-oriented<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>and store-and-forward=20
  communications environments as well as in =
both<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>push and pull =
distribution=20
  models".<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">CMP only =
works in a=20
  pull model. With such sentence CMP would be ruled out=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">whereas =
it is=20
  already a standard track protocol.</FONT><FONT face=3DTahoma><SPAN=20
  class=3D358121203-14112008>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D358121203-14112008></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New"></FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
document states=20
  in section 3.1.: Transport independence<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>"connectionless =
integrity and=20
  data origin<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>authentication for TA=20
  transactions MUST be provided at the<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>application=20
  layer".<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">With =
CMP, the=20
  security is obtained directly by the self-signed =
<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier =
New">certificates, i.e.=20
  the data itself which is self-protected. With such=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">sentence =
CMP would=20
  be ruled out, whereas it is already a standard track=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New">protocol.<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
  face=3D"Courier New"></FONT></o:p></SPAN>&nbsp;</P><SPAN lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3DTahoma><SPAN=20
  class=3D358121203-14112008><FONT face=3D"Courier New">[CRW] CMP fails =
to meet=20
  several of the requirements.</FONT>&nbsp;<FONT face=3D"Courier New">=20
  </FONT></SPAN></FONT></SPAN></P></o:p></SPAN>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The =
document cannot=20
  say on one side that the pull model is allowed and on=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">the =
other side=20
  include requirements which rule out the use of CMP (which is=20
  <o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">based on =
a pull=20
  model).</FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New"></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-GB=20
  style=3D"mso-ansi-language: EN-GB"><FONT=20
  face=3D"Courier New">Denis</FONT></SPAN></P>
  <P class=3DMsoPlainText=20
style=3D"MARGIN: 0cm 0cm =
0pt">&nbsp;</P></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C948E1.DB11330A--

Date: Mon, 17 Nov 2008 19:03:41 +0100
From: Julien Stern <[email-masked]>
To: [email-masked]
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

Oh well, why not ?

Regards,

--
Julien

Date: Mon, 17 Nov 2008 11:24:12 -0600
From: Eric Norman <[email-masked]>
Subject: Re: encoding an X.509 certificate
To: [email-masked]
Sender: [email-masked]

Eric Norman

Date: Mon, 17 Nov 2008 11:40:25 -0500
To: Tom Gindin <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: "Timothy J. Miller" <[email-masked]>, [email-masked], [email-masked], Peter Gutmann <[email-masked]>
Sender: [email-masked]

Tom,

Steve

Content-class: urn:content-classes:message
Subject: RE: AD comments for draft-ietf-pkix-ecc-subpubkeyinfo-09
Date: Mon, 17 Nov 2008 18:02:38 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Sean,

Thanks for a quick reply!

> To answer your questions:
>=20
> 1) Using parameter inheritance would mean that the EE certificate
> would not contain all of the necessary information that would be
> required for relying party to process a certificate.  The relying
> party might luck in to guessing the curve because there are only so
> many "well known" curves for a given key size, but to be sure the
> relying party would need to get the curve either from an issuer's
> certificate or through some other means.  The last paragraph of
> 2.1.1 address these options.

Hmm -- guessing the curve sounds like it could be dangerous?
(But I haven't really thought what the attacks could be..)

> 2) The rationale for retaining parameter inheritance is that many
> people that support DSA already deal with parameter inheritance in
> that context.  So, it may not be a burden to keep this capability in
> the specification.

With DSA, inheritance saves hundreds of bytes, so this optimization
makes more sense there. Also, I think ECDSA could get more widely used
than DSA has been (and in more open and non-homogeneous environments),
so there are more opportunities for problems to arise. (But opinions
from other WG members would be welcome, too.)

> It's PKIX so we generally assume people are doing path validation ;)

Well, that's not always what other IETF WGs are doing :)=20

> >Topic #2: scope of Appendix A
> >
> >For a document that specifies how to carry ECC public keys in
> >SubjectPublicKeyInfo, I was sort of expecting ASN.1 module(s) to do
> >so.  When I got to Appendix A, I was very surprised to find ASN.1
> >modules that contain mostly other things (not related to ECC at all,
> >or not related to SubjectPublicKeyInfo) -- nothing in the main
> >document (abstract and Sections 1..8) hinted that this would be
> >coming. Could you briefly explain why ASN.1 about RSA, DSA, MD5,=20
> >etc. belongs in this document?
>=20
> One of early comments was that since we're updating RFC 3279, we'd
> end up with a Chinese menu for implementers if we didn't update the
> entire RFC 3279 module.  RFC 3279 includes more than ECC "stuff" so
> if we update the RFC 3279 module have baggage.

Sounds like a reasonable explanation. Could you add a sentence or two
to the document abstract and introduction explaining this?

<snip>
> The reference to draft-ietf-pkix-new-asn1 is an informative
> reference.  I wish the reference could be normative, but we'd be
> blocked on it.  We could 1) pull the appendix out of the document
> (we'd have some text tweaking to do) and put the appendix in a)
> separate document b) put it in draft-ietf-pkix-new-asn1 2) leave it
> in the document and produce an update after draft-ietf-pkix-asn1
> gets published that says the appendices are now normative 3)
> indicate that it does not form a normative part of the document (not
> sure what we'd do with the reference).  I am willing to be guided on
> the best way forward.

I guess this depends how soon draft-ietf-pkix-new-asn1 is going
to be ready. If we want to publish ecc-subpubkeyinfo first,=20
I would suggest moving Appendix A.4 to draft-ietf-pkix-new-asn1.

> >The remaining comments are basically questions or suggestions
> >for minor clarifications:
> >
> >- Section 2.2: ANSI X9.62 specifies a third point form (that isn't=20
> >in [SEC1]); should this text say "the hybrid form MUST NOT be used"?
> >Or is the intent something else?
>=20
> I do not remember discussing the hybrid form and I don't remember
> back to the RFC 3279 discussion wrt to the hybrid form.  I would
> propose we add a new second sentence to the seconds paragraph "The
> hybrid form from [X9.62] MUST NOT be used."

Ok with me.

> >- I'm trying to understand how this ASN.1 fragment (and several
> >other similar cases) can actually compile:
> >
> >   sa-rsaWithMD2 SIGNATURE-ALGORITHM ::=3D {=20
> >     IDENTIFIER md2WithRSAEncryption=20
> >     PARAMS TYPE NULL ARE present=20
> >     HASHES { mda-md2 }=20
> >     PUBLIC KEYS { pk-rsa }=20
> >   }=20
> >
> >I'm puzzled because the string "present" is not one of the values
> >enumerated in ParamOptions -- but perhaps it's an ASN.1 keyword or
> >something?  (I have to admit that while I could usually read the old
> >1988 ASN.1 syntax, I don't really understand how this CLASS stuff
> >works...)
>=20
> "present" needs to be replaced by "required" (in 3 places).  I had=20
> a module that I was compiling and I forgot to copy over these=20
> changes :(

Ok (the spelling of "prefered" vs. "preferred" also needs to be=20
checked).

<snip>
> NEW:
>=20
> Two "restricted" algorithms are defined for key agreement
> algorithms: the Elliptic Curve Diffie-Hellman (ECDH) key agreement
> scheme and the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key
> agreement scheme. Both algorithms are identified by an object
> identifier and have parameters.  The object identifier varies based
> on the algorithm but the parameters are always ECParameters and they
> MUST always be present (see Section 2.1.1).

Works for me.

Best regards,
Pasi

Content-class: urn:content-classes:message
Subject: RE: Signing and Encrypting with the same key?
Date: Mon, 17 Nov 2008 09:06:35 -0500
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

From: Alan Sill <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: Attribute Authorities
Date: Sun, 16 Nov 2008 21:36:45 -0600
Sender: [email-masked]

Attribute authorities are features of virtual or real organizations,  
not CAs in general.  A give VO can have multiple CAs associated with  
it or accepted by its relying parties, none of which may be uniquely  
authoritative to assert that the AA itself is authentic.  In large- 
scale VOs that want to make such an assertion, a certificate from one  
of those CAs may be used to identify the AA service.  An example is  
the certificate checking built into some, but not all, of the relying  
party software that uses VOMS extended attribute certificates.  The  
responsibility to check the credentials of the AA belongs to the  
relying party, not to the CA.  They can do so by checking the  
credentials of the service that adds the extensions.

Alan

On Nov 15, 2008, at 3:53 AM, Massimiliano Pala wrote:

> I was wondering if there is a way to actually identify an AA based  
> on the
> contents of its certificate (eg., extendedKeyUsage, an extension, an
> OID,... ) ?
>
> How can a third party know that an Identity has been identified by a  
> CA
> as a valid AA ? I know that the problem of Identity and Authorization
> should not be tied together - but it would be easier for an  
> application
> to know that an identity can sign attribute certificates. Is there  
> anything
> of the sort ? And if not, has anybody thought about it ?

Alan Sill, Ph.D
Senior Scientist, High Performance Computing Center
Adjunct Professor of Physics
TTU

====================================================================
:  Alan Sill, Texas Tech University  Office: Admin 233, MS 4-1167  :
:  e-mail: [email-masked]   ph. 806-742-4350  fax 806-742-4358  :
====================================================================

From: Alan Sill <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: Attribute Authorities
Date: Sun, 16 Nov 2008 15:26:51 -0600
Sender: [email-masked]

Attribute authorities are features of virtual or real organizations,  
not CAs in general.  A give VO can have multiple CAs associated with  
it or accepted by its relying parties, none of which may be uniquely  
authoritative to assert that the AA itself is authentic.  In large- 
scale VOs that want to make such an assertion, a certificate from one  
of those CAs may be used to identify the AA service.  An example is  
the certificate checking built into some, but not all, of the relying  
party software that uses VOMS extended attribute certificates.  The  
responsibility to check the credentials of the AA belongs to the  
relying party, not to the CA.  They can do so by checking the  
credentials of the service that adds the extensions.

Alan

On Nov 15, 2008, at 3:53 AM, Massimiliano Pala wrote:

> I was wondering if there is a way to actually identify an AA based  
> on the
> contents of its certificate (eg., extendedKeyUsage, an extension, an
> OID,... ) ?
>
> How can a third party know that an Identity has been identified by a  
> CA
> as a valid AA ? I know that the problem of Identity and Authorization
> should not be tied together - but it would be easier for an  
> application
> to know that an identity can sign attribute certificates. Is there  
> anything
> of the sort ? And if not, has anybody thought about it ?

Alan Sill, Ph.D
Senior Scientist, High Performance Computing Center
Adjunct Professor of Physics
TTU

====================================================================
:  Alan Sill, Texas Tech University  Office: Admin 233, MS 4-1167  :
:  e-mail: [email-masked]   ph. 806-742-4350  fax 806-742-4358  :
====================================================================

From: "Anders Rundgren" <[email-masked]>
To: "Massimiliano Pala" <[email-masked]>
Cc: "pkix" <[email-masked]>
Subject: Re: Attribute Authorities
Date: Sun, 16 Nov 2008 18:56:00 +0100
Sender: [email-masked]

Hi Max,
I have taken the liberty (?) of studying the AC use-case in the business world, including 
e-governments.

I came up with a solution that I consider a viable alternative to X509 ACs although the method can 
be used with such as well.
The basic concept is that the AA publishes signed XML "ACs" using high-entropy URLs (can't be 
guessed) and the client only forwards this URL like the following example:
http://webpki.org/attributecertificates/A.2006.10.0452/9j2g637gdHu3erh8udvh5ddyugdRd9Gw30fdu0pwetfkotgoi4218hfcsKeherufu.xml
It also makes revocation a simple thing, the AA just removes the AC or replaces its contents with a 
revoke notice.

ACs can also be created for human consumption:
http://webpki.org/attributecertificates/A.2006.10.0452/9j2g637gdHu3erh8udvh5ddyugdRd9Gw30fdu0pwetfkotgoi4218hfcsKeherufu.pdf

IMHO, core PKI does not need much additional innovation, it is rather the application of PKI that is 
problem.  There is an over-belief in complexity as the solution.

In case you  *really* want to make PKI more useful you should tell these guys
http://www.mel.nist.gov/msid/b2btestbed
how they should dress their scheme in PKI because their buddies at the computer security department 
obviously haven't a clue!
BTW, I would be happy to see the design as well...

Anders

----- Original Message ----- 
From: "Massimiliano Pala" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sent: Sunday, November 16, 2008 06:01
Subject: Re: Attribute Authorities

Hi Anders,

my question was different and it was related to how to identify an AA - which is
basically answered in rfc3281 in 7.4 (thanks Santosh).

Talking about attribute authorities, the AC has been researched extensively (an
example being the work from Chadwick and the current work within the OGF). It is
true, although, that client software implementations are not widely deployed
outside certain communities. I do hope this will change as soon as we will
improve the usability of PKIs :D

Later,
Max

Anders Rundgren wrote:
> I thought that an X509 AC is supposed to contain a binding to a PKC (or identity) and
> that you need to trust both CAs in order to get something useful out of this concept.
> To me that sounds like that there already is a solution.
>
> Talking about attribute authorities; what do you think about the Microsoft-originated
> Information Card scheme? http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=imi
>  IMO it will do what ACs never did because it addresses real-world use-cases and is
> already supported by Vista, XP and Firefox platforms while the AC use-case(?) is poorly
> researched and client-side implementations are scarce to say the least.
>
> Anders Rundgren

Date: Sun, 16 Nov 2008 11:31:11 +0630
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: Anders Rundgren <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Attribute Authorities
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms090500010709050801030504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Anders,

my question was different and it was related to how to identify an AA - which is
basically answered in rfc3281 in 7.4 (thanks Santosh).

Talking about attribute authorities, the AC has been researched extensively (an
example being the work from Chadwick and the current work within the OGF). It is
true, although, that client software implementations are not widely deployed
outside certain communities. I do hope this will change as soon as we will
improve the usability of PKIs :D

Later,
Max

Anders Rundgren wrote:
> I thought that an X509 AC is supposed to contain a binding to a PKC (or identity) and
> that you need to trust both CAs in order to get something useful out of this concept.
> To me that sounds like that there already is a solution.
> 
> Talking about attribute authorities; what do you think about the Microsoft-originated
> Information Card scheme? http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=imi
>  IMO it will do what ACs never did because it addresses real-world use-cases and is
> already supported by Vista, XP and Firefox platforms while the AC use-case(?) is poorly
> researched and client-side implementations are scarce to say the least.
> 
> Anders Rundgren

--------------ms090500010709050801030504
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms090500010709050801030504--

From: "Anders Rundgren" <[email-masked]>
To: "Massimiliano Pala" <[email-masked]>, "pkix" <[email-masked]>
Subject: Re: Attribute Authorities
Date: Sun, 16 Nov 2008 09:42:47 +0100
Sender: [email-masked]

I thought that an X509 AC is supposed to contain a binding to a PKC (or identity) and that you need 
to trust both CAs in order to get something useful out of this concept.  To me that sounds like that 
there already is a solution.

Talking about attribute authorities; what do you think about the Microsoft-originated Information 
Card scheme?
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=imi
IMO it will do what ACs never did because it addresses real-world use-cases and is already supported 
by Vista, XP and Firefox platforms while the AC use-case(?) is poorly researched and client-side 
implementations are scarce to say the least.

Anders Rundgren

----- Original Message ----- 
From: "Massimiliano Pala" <[email-masked]>
To: "pkix" <[email-masked]>
Sent: Saturday, November 15, 2008 10:53
Subject: Attribute Authorities

Hi all,

I was wondering if there is a way to actually identify an AA based on the
contents of its certificate (eg., extendedKeyUsage, an extension, an
OID,... ) ?

How can a third party know that an Identity has been identified by a CA
as a valid AA ? I know that the problem of Identity and Authorization
should not be tied together - but it would be easier for an application
to know that an identity can sign attribute certificates. Is there anything
of the sort ? And if not, has anybody thought about it ?

Later,
Max

-- 

Best Regards,

Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]  [email-masked]
                                                    [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

People who think they know everything are a great annoyance to those of us
who do.
   -- Isaac Asimov

Date: Sat, 15 Nov 2008 16:23:18 +0630
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: pkix <[email-masked]>
Subject: Attribute Authorities
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms080809060906030406020105
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

I was wondering if there is a way to actually identify an AA based on the
contents of its certificate (eg., extendedKeyUsage, an extension, an
OID,... ) ?

How can a third party know that an Identity has been identified by a CA
as a valid AA ? I know that the problem of Identity and Authorization
should not be tied together - but it would be easier for an application
to know that an identity can sign attribute certificates. Is there anything
of the sort ? And if not, has anybody thought about it ?

Later,
Max

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]  [email-masked]
                                                    [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

--------------ms080809060906030406020105
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms080809060906030406020105--

Content-class: urn:content-classes:message
Subject: RE: Signing and Encrypting with the same key?
Date: Sat, 15 Nov 2008 15:51:06 -0500
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

One benefit of setting both bits for a TLS Server for RSA algorithm is
that when the Server is acting as a Server, the key is used to encrypt
and when the Server acts as a client, the same key can be used to
perform client authentication using digital signature.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Wilson
Sent: Saturday, November 15, 2008 9:34 AM
To: [email-masked]
Subject: Re: Signing and Encrypting with the same key?

And a short reiteration of what I thought was the answer:

Using the same key pair for signing and encryption (key exchange) is not

cryptanalytically a bad idea.  Rather, it is merely convention dating=20
back to the idea that backing up (or escrowing) keys used for encryption

dilutes their value for authentication, because of the possibility that=20
the extra copies might be used for signing things without the owner's=20
permission.

So, if TLS uses the same key pair, it's not breaking any rules.

Cheers,

Steve Wilson.

PS. I actually always thought the argument for key separation was=20
massively over-stated.  "Non repudiation" is one the greatest red=20
herrings in the history of cryptography.  If someone uses my signing key

without my permission, then I shouldn't be held accountable for that, if

it can be shown that the usage was illicit.  Some jurisdictions grant an

extra degree of 'attribution' when qualified digital signature devices=20
are used, but as far as I know, the attribution is still not absolute.=20
Rather, it's just a matter of onus of proof; if I can show that my=20
private key was used by someone else, without my consent, then I can=20
repudiate the transaction.  It's just another form of identity fraud;=20
investigating fraud entails working who really did what to whom.  It's=20
exactly the same with any authenticator -- a password, PKI private key,=20
biometric or whatever.  The idea that someone cannot in principle ever=20
repudiate a digitally signed transaction is plain silly, and to my=20
knowledge, has no actual legal foundation.  I'd like to know the precise

history of the NR bit in X.509.  Who actually thought of it, were they=20
an engineer or a lawyer, and what if any debate went on at the time?

Stephen Wilson
Managing Director
Lockstep Technologies

Phone +61 (0)414 488 851

www.lockstep.com.au/technologies
-------------------
  * ABC TV 'The New Inventors' Nov 2008
  * Global Security Challenge Asia Top Five 2008
  * Australian Technology Showcase 2008
  * AusIndustry COMET Grant 2007
  * ICT Secrets of Innovation Finalist (Security) 2007
  * Anthill / PwC Cool Company Finalist (Innovation) 2007
-------------------
Lockstep Technologies develops unique new smart ID solutions to
safeguard identity and privacy. Lockstep Consulting provides
independent specialist advice and analysis on authentication, PKI
and smartcards.

Anders Rundgren wrote:
> Just a short iteration of this question:
>=20
> If using a single key for authentication and encryption is a bad idea,
how come that TLS after all=20
> these years still only relies on a single key-pair for authenticating
the server as well as=20
> encrypting the channel?
>=20
>=20
>=20

Date: Sun, 16 Nov 2008 01:34:05 +1100
From: Stephen Wilson <[email-masked]>
Reply-To: [email-masked]
Organization: Lockstep
To: [email-masked]
Subject: Re: Signing and Encrypting with the same key?
Sender: [email-masked]

And a short reiteration of what I thought was the answer:

Using the same key pair for signing and encryption (key exchange) is not 
cryptanalytically a bad idea.  Rather, it is merely convention dating 
back to the idea that backing up (or escrowing) keys used for encryption 
dilutes their value for authentication, because of the possibility that 
the extra copies might be used for signing things without the owner's 
permission.

So, if TLS uses the same key pair, it's not breaking any rules.

Cheers,

Steve Wilson.

PS. I actually always thought the argument for key separation was 
massively over-stated.  "Non repudiation" is one the greatest red 
herrings in the history of cryptography.  If someone uses my signing key 
without my permission, then I shouldn't be held accountable for that, if 
it can be shown that the usage was illicit.  Some jurisdictions grant an 
extra degree of 'attribution' when qualified digital signature devices 
are used, but as far as I know, the attribution is still not absolute. 
Rather, it's just a matter of onus of proof; if I can show that my 
private key was used by someone else, without my consent, then I can 
repudiate the transaction.  It's just another form of identity fraud; 
investigating fraud entails working who really did what to whom.  It's 
exactly the same with any authenticator -- a password, PKI private key, 
biometric or whatever.  The idea that someone cannot in principle ever 
repudiate a digitally signed transaction is plain silly, and to my 
knowledge, has no actual legal foundation.  I'd like to know the precise 
history of the NR bit in X.509.  Who actually thought of it, were they 
an engineer or a lawyer, and what if any debate went on at the time?

Stephen Wilson
Managing Director
Lockstep Technologies

Phone +61 (0)414 488 851

www.lockstep.com.au/technologies
-------------------
  * ABC TV 'The New Inventors' Nov 2008
  * Global Security Challenge Asia Top Five 2008
  * Australian Technology Showcase 2008
  * AusIndustry COMET Grant 2007
  * ICT Secrets of Innovation Finalist (Security) 2007
  * Anthill / PwC Cool Company Finalist (Innovation) 2007
-------------------
Lockstep Technologies develops unique new smart ID solutions to
safeguard identity and privacy. Lockstep Consulting provides
independent specialist advice and analysis on authentication, PKI
and smartcards.

Anders Rundgren wrote:
> Just a short iteration of this question:
> 
> If using a single key for authentication and encryption is a bad idea, how come that TLS after all 
> these years still only relies on a single key-pair for authenticating the server as well as 
> encrypting the channel?
> 
> Anders
> 
> 

Date: Sat, 15 Nov 2008 06:10:14 -0800
From: Mike <[email-masked]>
To: [email-masked]
Subject: Re: Signing and Encrypting with the same key?
Sender: [email-masked]

In a particular TLS cipher suite, a key is used for only one purpose,
either signing or encrypting, not both.  In the case of an RSA key
exchange, the act of encrypting the channel has the side effect of
authenticating the server, since the server can only decrypt the
secret if it has the private key.  In other exchanges, an RSA or DSA
key is used to sign some Diffie-Hellman parameters.  The signature
provides the authentication of the server, but the Diffie-Hellman
exchange encrypts the channel.

The issue you raise is whether you use the same RSA key for both
types of cipher suites; in pure RSA exchanges, the key is used for
encryption, and in Diffie-Hellman exchanges it is used for signing.
This is an implementation/configuration issue, not a problem with TLS.
It is possible for a server to use two different keys, but it is
easier (and cheaper) to just use one, so that's what lots of people
do.

Mike

Anders Rundgren wrote:
> Just a short iteration of this question:
> 
> If using a single key for authentication and encryption is a bad idea, how come that TLS after all 
> these years still only relies on a single key-pair for authenticating the server as well as 
> encrypting the channel?
> 
> Anders

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Re: Signing and Encrypting with the same key?
Date: Sat, 15 Nov 2008 12:34:13 +0100
Sender: [email-masked]

Just a short iteration of this question:

If using a single key for authentication and encryption is a bad idea, how come that TLS after all 
these years still only relies on a single key-pair for authenticating the server as well as 
encrypting the channel?

Anders

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: AD comments for draft-ietf-pkix-ecc-subpubkeyinfo-09
Date: Thu, 13 Nov 2008 15:24:21 -0500
Organization: IECA, Inc.
Sender: [email-masked]

Pasi,

Thanks for your comments.  Responses inline.

spt

>From: [email-masked]
>Sent: Thursday, November 13, 2008 8:11 AM
>To: [email-masked]
>Subject: AD comments for draft-ietf-pkix-ecc-subpubkeyinfo-09
>
>
>I'm now doing the AD review for draft-ietf-pkix-ecc-subpubkeyinfo-09.
>My situation is slightly unusual, since I've never read the 
>draft before -- usually the AD has followed the draft for some 
>time, and is at least somewhat familiar with the WG 
>discussions that lead to making the decisions that were made. 
>So, I might be asking questions that were discussed already earlier...
>
>In general, the document looks quite good. I've identified 
>couple of topics that I'd like to discuss with the WG (plus some minor
>clarifications/comments):
>
>
>Topic #1: implicitCurve
>
>I'd like to better understand the motivation behind this option.
>It certainly saves ~10 bytes (one OID) in the certificate, but doesn't
>it also mean the end-entity certificate does not any longer contain 
>the whole public key? (since the ECPoint value alone is not useful 
>without knowing the curve)
>
>If that's the case, it would significantly complicate using the
>certificate to "carry public keys" in situations where the recipient
>does not necessarily do path validation (and may not have the issuer's
>public key).
>
>This situation is of course very common in web browsing (browser asks
>you whether you want to accept the certificate anyway), but occurs
>also in e.g. DTLS-SRTP and RFC 4572 (where the party receiving the
>certificate might do real path validation, or might just check that it
>matches the fingerprint received in SIP/SDP), and Syslog-over-TLS
>(where small implementations might use fingerprints instead of path
>validation, even if the certificate isn't self-signed). And I'm pretty
>sure more uses like this will be specified in the future.
>
>Would the spec be missing important functionality if it just said
>"implicitCurve MUST NOT be used" (like it says for specifiedCurve)?

To answer your questions:

1) Using parameter inheritance would mean that the EE certificate would not
contain all of the necessary information that would be required for relying
party to process a certificate.  The relying party might luck in to guessing
the curve because there are only so many "well known" curves for a given key
size, but to be sure the relying party would need to get the curve either
from an issuer's certificate or through some other means.  The last
paragraph of 2.1.1 address these options.

2) The rationale for retaining parameter inheritance is that many people
that support DSA already deal with parameter inheritance in that context.
So, it  may not be a burden to keep this capability in the specification.

It's PKIX so we generally assume people are doing path validation ;)

>Topic #2: scope of Appendix A
>
>For a document that specifies how to carry ECC public keys in
>SubjectPublicKeyInfo, I was sort of expecting ASN.1 module(s) to do
>so.  When I got to Appendix A, I was very surprised to find ASN.1
>modules that contain mostly other things (not related to ECC at all,
>or not related to SubjectPublicKeyInfo) -- nothing in the main
>document (abstract and Sections 1..8) hinted that this would be
>coming. Could you briefly explain why ASN.1 about RSA, DSA, MD5, 
>etc. belongs in this document?

One of early comments was that since we're updating RFC 3279, we'd end up
with a Chinese menu for implementers if we didn't update the entire RFC 3279
module.  RFC 3279 includes more than ECC "stuff" so if we update the RFC
3279 module have baggage.

>Topic #3: "informative" ASN.1
>
>I'm wondering whether calling a section consisting solely of formal
>language "informative" makes sense, and if just adding that one word
>avoids a normative reference to draft-ietf-pkix-new-asn1 (due to
>"IMPORTS" -- a case which is mentioned explicitly in RFC 3967).
>
>It looks like stuff implementors would use, and perhaps more
>importantly, something writers of future IETF specifications might
>want to use. Can we simultaneously claim it's not really part of the
>specification (and thus the reference to new-asn1 is not normative)
>and allow future documents to import from it (with a normative
>reference)?

The reference to draft-ietf-pkix-new-asn1 is an informative reference.  I
wish the reference could be normative, but we'd be blocked on it.  We could
1) pull the appendix out of the document (we'd have some text tweaking to
do) and put the appendix in a) separate document b) put it in
draft-ietf-pkix-new-asn1 2) leave it in the document and produce an update
after draft-ietf-pkix-asn1 gets published that says the appendices are now
normative 3) indicate that it does not form a normative part of the document
(not sure what we'd do with the reference).  I am willing to be guided on
the best way forward.

>The remaining comments are basically questions or suggestions
>for minor clarifications:
>
>- Section 2.2: ANSI X9.62 specifies a third point form (that isn't 
>in [SEC1]); should this text say "the hybrid form MUST NOT be used"?
>Or is the intent something else?

I do not remember discussing the hybrid form and I don't remember back to
the RFC 3279 discussion wrt to the hybrid form.   I would propose we add a
new second sentence to the seconds paragraph "The hybrid form from [X9.62]
MUST NOT be used."

>- I'm trying to understand how this ASN.1 fragment (and several
>other similar cases) can actually compile:
>
>   sa-rsaWithMD2 SIGNATURE-ALGORITHM ::= { 
>     IDENTIFIER md2WithRSAEncryption 
>     PARAMS TYPE NULL ARE present 
>     HASHES { mda-md2 } 
>     PUBLIC KEYS { pk-rsa } 
>   } 
>
>I'm puzzled because the string "present" is not one of the values
>enumerated in ParamOptions -- but perhaps it's an ASN.1 keyword or
>something?  (I have to admit that while I could usually read the old
>1988 ASN.1 syntax, I don't really understand how this CLASS stuff
>works...)

"present" needs to be replaced by "required" (in 3 places).  I had a module
that I was compiling and I forgot to copy over these changes :(

>- A question: for some AlgorithmIdentifiers it's occasionally been
>unclear whether the parameters must be NULL, must be omitted, or if
>either is allowed. This document looks quite clear about this topic --
>but is it 100% consistent with e.g. RFC 3279, PKCS#1 and other
>relevant documents? If it's not, it would be important to explicitly
>point out the differences.

I believe we're consistent.

>- Section 2.1.2 says "Algorithms used with elliptic curve cryptography
>fall in two different categories: signature and key agreement
>algorithms." Do you consider encryption schemes such as ECIES
>(specified in IEEE 1363) to be "key agreement"? (it certainly has
>similarities to ECDH). This question is also relevant for Section 3,
>where keyEncipherment bit is never mentioned.  Or perhaps the text's
>intent is that other uses of elliptic curves than ECDSA/ECDH/ECMQV
>are beyond the scope?

I definitely wasn't (not sure about the other authors) thinking about ECIES
when working on this ID.  That sentence was meant to be more of an
introductory sentence to explain why we've got three OIDs.  We could do the
following for 2.1.2 (but does this address your comment?):

OLD:

Algorithms used with elliptic curve cryptography fall in two different
categories: signature and key agreement algorithms.  ECDSA uses the pk-ec
identifier described in 2.1.1. Two sets of key agreement algorithms are
identified herein: the Elliptic Curve Diffie-Hellman (ECDH) key agreement
scheme and the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement
scheme. All algorithms are identified by an object identifier and have
parameters.  The object identifier varies based on the algorithm but the
parameters are always ECParameters and they MUST always be present (see
Section 2.1.1).

NEW:

Two "restricted" algorithms are defined for key agreement algorithms: the
Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme and the Elliptic
Curve Menezes-Qu-Vanstone (ECMQV) key agreement scheme. Both algorithms are
identified by an object identifier and have parameters.  The object
identifier varies based on the algorithm but the parameters are always
ECParameters and they MUST always be present (see Section 2.1.1).

>- The ASN.1 modules in Appendix A have a number of "TBA" values -- 
>it would be a good idea to have an explicit note (in the document) 
>saying who will fill them and at what point. Also, it's slightly 
>difficult to tell which TBAs refer to the same value, and which 
>to different values -- using something like "TBA1", "TBA2", etc., 
>might help.

I'll add a note in Appendix A to indicate that all the TBAs are going to
filled in during AUTH48.

>- Typos:
>Section 2.1.1 "ASNI" 
>Appendix A.3, should "FROM PKIXCurves" be "FROM PKIXCurves-2008"?
>Appendix A.4, "id-mod-algorithInformation" 

I'll fix these.

Content-class: urn:content-classes:message
Subject: AD comments for draft-ietf-pkix-ecc-subpubkeyinfo-09
Date: Thu, 13 Nov 2008 15:10:32 +0200
From: <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I'm now doing the AD review for draft-ietf-pkix-ecc-subpubkeyinfo-09.
My situation is slightly unusual, since I've never read the draft
before -- usually the AD has followed the draft for some time, and is
at least somewhat familiar with the WG discussions that lead to making
the decisions that were made. So, I might be asking questions that
were discussed already earlier...

In general, the document looks quite good. I've identified couple=20
of topics that I'd like to discuss with the WG (plus some minor
clarifications/comments):

Topic #1: implicitCurve

I'd like to better understand the motivation behind this option.
It certainly saves ~10 bytes (one OID) in the certificate, but doesn't
it also mean the end-entity certificate does not any longer contain=20
the whole public key? (since the ECPoint value alone is not useful=20
without knowing the curve)

If that's the case, it would significantly complicate using the
certificate to "carry public keys" in situations where the recipient
does not necessarily do path validation (and may not have the issuer's
public key).

This situation is of course very common in web browsing (browser asks
you whether you want to accept the certificate anyway), but occurs
also in e.g. DTLS-SRTP and RFC 4572 (where the party receiving the
certificate might do real path validation, or might just check that it
matches the fingerprint received in SIP/SDP), and Syslog-over-TLS
(where small implementations might use fingerprints instead of path
validation, even if the certificate isn't self-signed). And I'm pretty
sure more uses like this will be specified in the future.

Would the spec be missing important functionality if it just said
"implicitCurve MUST NOT be used" (like it says for specifiedCurve)?

Topic #2: scope of Appendix A

For a document that specifies how to carry ECC public keys in
SubjectPublicKeyInfo, I was sort of expecting ASN.1 module(s) to do
so.  When I got to Appendix A, I was very surprised to find ASN.1
modules that contain mostly other things (not related to ECC at all,
or not related to SubjectPublicKeyInfo) -- nothing in the main
document (abstract and Sections 1..8) hinted that this would be
coming. Could you briefly explain why ASN.1 about RSA, DSA, MD5,=20
etc. belongs in this document?

Topic #3: "informative" ASN.1

I'm wondering whether calling a section consisting solely of formal
language "informative" makes sense, and if just adding that one word
avoids a normative reference to draft-ietf-pkix-new-asn1 (due to
"IMPORTS" -- a case which is mentioned explicitly in RFC 3967).

It looks like stuff implementors would use, and perhaps more
importantly, something writers of future IETF specifications might
want to use. Can we simultaneously claim it's not really part of the
specification (and thus the reference to new-asn1 is not normative)
and allow future documents to import from it (with a normative
reference)?

The remaining comments are basically questions or suggestions
for minor clarifications:

- Section 2.2: ANSI X9.62 specifies a third point form (that isn't=20
in [SEC1]); should this text say "the hybrid form MUST NOT be used"?
Or is the intent something else?

- I'm trying to understand how this ASN.1 fragment (and several
other similar cases) can actually compile:

   sa-rsaWithMD2 SIGNATURE-ALGORITHM ::=3D {=20
     IDENTIFIER md2WithRSAEncryption=20
     PARAMS TYPE NULL ARE present=20
     HASHES { mda-md2 }=20
     PUBLIC KEYS { pk-rsa }=20
   }=20

I'm puzzled because the string "present" is not one of the values
enumerated in ParamOptions -- but perhaps it's an ASN.1 keyword or
something?  (I have to admit that while I could usually read the old
1988 ASN.1 syntax, I don't really understand how this CLASS stuff
works...)

- A question: for some AlgorithmIdentifiers it's occasionally been
unclear whether the parameters must be NULL, must be omitted, or if
either is allowed. This document looks quite clear about this topic --
but is it 100% consistent with e.g. RFC 3279, PKCS#1 and other
relevant documents? If it's not, it would be important to explicitly
point out the differences.

- Section 2.1.2 says "Algorithms used with elliptic curve cryptography
fall in two different categories: signature and key agreement
algorithms." Do you consider encryption schemes such as ECIES
(specified in IEEE 1363) to be "key agreement"? (it certainly has
similarities to ECDH). This question is also relevant for Section 3,
where keyEncipherment bit is never mentioned.  Or perhaps the text's
intent is that other uses of elliptic curves than ECDSA/ECDH/ECMQV
are beyond the scope?

- The ASN.1 modules in Appendix A have a number of "TBA" values --=20
it would be a good idea to have an explicit note (in the document)=20
saying who will fill them and at what point. Also, it's slightly=20
difficult to tell which TBAs refer to the same value, and which=20
to different values -- using something like "TBA1", "TBA2", etc.,=20
might help.

- Typos:
Section 2.1.1 "ASNI"=20
Appendix A.3, should "FROM PKIXCurves" be "FROM PKIXCurves-2008"?
Appendix A.4, "id-mod-algorithInformation"=20

Best regards,
Pasi

To: "Timothy J. Miller" <[email-masked]>
Cc: [email-masked], [email-masked], Peter Gutmann <[email-masked]>
Subject: Re: encoding an X.509 certificate
From: Tom Gindin <[email-masked]>
Date: Wed, 12 Nov 2008 20:22:48 -0500
Sender: [email-masked]

                Tom Gindin

To

Postel's Law, anyone?  :)

-- Tim

Date: Wed, 12 Nov 2008 10:10:47 -0600
From: "Timothy J. Miller" <[email-masked]>
To: Paul Hoffman <[email-masked]>
CC: Anders Rundgren <[email-masked]>, pkix <[email-masked]>
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

--------------ms020704000502090603090300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

By itself?  Not much.

-- Tim

--------------ms020704000502090603090300
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020704000502090603090300--

Date: Wed, 12 Nov 2008 09:31:26 -0600
From: "Timothy J. Miller" <[email-masked]>
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

--------------ms090108050000070706030009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Postel's Law, anyone?  :)

-- Tim

--------------ms090108050000070706030009
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms090108050000070706030009--

From: Stefan Santesson <[email-masked]>
To: pkix <[email-masked]>
Date: Wed, 12 Nov 2008 14:20:41 +0000
Subject: Agenda uploaded
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_000_9F11911AED01D24BAA1C2355723C3D321AB0B0B015EAEXMSGC332eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The preliminary agenda for the PKIX meeting next week is uploaded and can b=
e viewed at:
http://www.ietf.org/proceedings/08nov/agenda/pkix.txt

Stefan Santesson
Senior Program Manager

--_000_9F11911AED01D24BAA1C2355723C3D321AB0B0B015EAEXMSGC332eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www=
.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoin=
t/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns=
:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile=
" xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns=
:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns=
:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http=
://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"ht=
tp://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z=3D"urn:s=
chemas-microsoft-com:" xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-=
html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN-US>The preliminary agenda for the PKIX=
 meeting
next week is uploaded and can be viewed at:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><a
href=3D"http://www.ietf.org/proceedings/08nov/agenda/pkix.txt">http://www.i=
etf.org/proceedings/08nov/agenda/pkix.txt</a><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D321AB0B0B015EAEXMSGC332eu_--

Content-class: urn:content-classes:message
Subject: RE: encoding an X.509 certificate
Date: Mon, 10 Nov 2008 10:13:48 -0500
From: "Kemp, David P." <[email-masked]>
To: "pkix" <[email-masked]>
Sender: [email-masked]

Dave

-----Original Message-----

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: encoding an X.509 certificate
Date: Mon, 10 Nov 2008 09:02:18 -0500
From: "Kemp, David P." <[email-masked]>
To: "pkix" <[email-masked]>
Sender: [email-masked]

-----Original Message-----

--Paul Hoffman, Director
--VPN Consortium

From: "Anders Rundgren" <[email-masked]>
To: "Russ Housley" <[email-masked]>, "Paul Hoffman" <[email-masked]>
Cc: "pkix" <[email-masked]>
Subject: Re: encoding an X.509 certificate
Date: Mon, 10 Nov 2008 10:42:19 +0100
Sender: [email-masked]

Anders

----- Original Message ----- 
From: "Paul Hoffman" <[email-masked]>
To: "Russ Housley" <[email-masked]>; "Anders Rundgren" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sent: Sunday, November 09, 2008 23:41
Subject: Re: encoding an X.509 certificate

--Paul Hoffman, Director
--VPN Consortium

Date: Sun, 9 Nov 2008 14:41:10 -0800
To: Russ Housley <[email-masked]>, "Anders Rundgren" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

--Paul Hoffman, Director
--VPN Consortium

Date: Sun, 09 Nov 2008 16:13:31 -0500
To: "Anders Rundgren" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

Russ 

Date: Sat, 8 Nov 2008 18:19:01 -0500
From: "Tom Scavo" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: "Ben Laurie" <[email-masked]>, pkix <[email-masked]>
Sender: [email-masked]

Can you say why?

Tom

Date: Sat, 8 Nov 2008 14:37:11 -0800
To: "Anders Rundgren" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

--Paul Hoffman, Director
--VPN Consortium

From: "Anders Rundgren" <[email-masked]>
To: "Tom Scavo" <[email-masked]>, "Ben Laurie" <[email-masked]>
Cc: "pkix" <[email-masked]>
Subject: Re: encoding an X.509 certificate
Date: Sat, 8 Nov 2008 22:17:38 +0100
Sender: [email-masked]

Anders

----- Original Message ----- 
From: "Tom Scavo" <[email-masked]>
To: "Ben Laurie" <[email-masked]>
Cc: "Anders Rundgren" <[email-masked]>; "pkix" <[email-masked]>
Sent: Saturday, November 08, 2008 20:49
Subject: Re: encoding an X.509 certificate

Hi Ben,

Cheers,
Tom 

Date: Sat, 8 Nov 2008 14:49:47 -0500
From: "Tom Scavo" <[email-masked]>
To: "Ben Laurie" <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: "Anders Rundgren" <[email-masked]>, pkix <[email-masked]>
Sender: [email-masked]

Hi Ben,

Cheers,
Tom

Content-class: urn:content-classes:message
Subject: RE: encoding an X.509 certificate
Date: Sat, 8 Nov 2008 11:24:42 -0500
From: "Santosh Chokhani" <[email-masked]>
To: "Kemp, David P." <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Dave,

-----Original Message-----

Peter,

-----Original Message-----
From: pgut001 [mailto:[email-masked]]=20
Sent: Friday, November 07, 2008 11:03 AM
To: [email-masked]; [email-masked]; Santosh Chokhani;
[email-masked]

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: encoding an X.509 certificate
Date: Sat, 08 Nov 2008 20:34:30 +1300
Sender: [email-masked]

"Kemp, David P." <[email-masked]> writes:

>"X.509 dogma" is just for anal people who want 100% reliability.

Actually this one is just too good to let go, can I use it as a siq quote?

Peter :-).

--
"X.509 dogma" is just for anal people who want 100% reliability - David P.Kemp.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: encoding an X.509 certificate
Date: Sat, 08 Nov 2008 20:22:31 +1300
Sender: [email-masked]

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: encoding an X.509 certificate
Date: Sat, 08 Nov 2008 20:21:07 +1300
Sender: [email-masked]

Peter.

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-authorityclearanceconstraints-00.txt 
Date: Fri,  7 Nov 2008 10:00:01 -0800 (PST)
Sender: [email-masked]

--NextPart

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		: Clearance Attribute and Authority Clearance Constraints 
Certificate Extension
	Author(s)	: S. Chokhani, S. Turner
	Filename	: draft-ietf-pkix-authorityclearanceconstraints-00.txt
	Pages		: 19
	Date		: 2008-10-31
	
   This document defines the syntax and semantics for the Clearance 
   attribute and the Authority Clearance Constraints extension in X.509 
   certificates.  The Clearance attribute is used to indicate the 
   clearance held by the subject.  The Clearance attribute may appear in    the subject directory attributes extension of a public key 
   certificate or in the attributes field of an attribute certificate.  
   The Authority Clearance Constraints certificate extension values in a 
   Trust Anchor (TA), CA public key certificates, and an Attribute 
   Authority (AA) public key certificate in a public key certification 
   path constrain the effective Clearance of the subject. 

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-pkix-authorityclearanceconstraints-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: encoding an X.509 certificate
Date: Fri, 7 Nov 2008 12:45:30 -0500
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

-----Original Message-----

Peter,

-----Original Message-----
From: pgut001 [mailto:[email-masked]]=20
Sent: Friday, November 07, 2008 11:03 AM
To: [email-masked]; [email-masked]; Santosh Chokhani;
[email-masked]

Peter.

Content-class: urn:content-classes:message
Subject: RE: encoding an X.509 certificate
Date: Fri, 7 Nov 2008 11:55:09 -0500
From: "Santosh Chokhani" <[email-masked]>
To: "pgut001" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Peter,

-----Original Message-----
From: pgut001 [mailto:[email-masked]]=20
Sent: Friday, November 07, 2008 11:03 AM
To: [email-masked]; [email-masked]; Santosh Chokhani;
[email-masked]

Peter.

From: "Anders Rundgren" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: encoding an X.509 certificate
Date: Fri, 7 Nov 2008 17:50:51 +0100
Sender: [email-masked]

Peter,

Anders

----- Original Message ----- 
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, November 07, 2008 16:35
Subject: RE: encoding an X.509 certificate

with the corollary:

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: encoding an X.509 certificate
Date: Sat, 08 Nov 2008 05:02:38 +1300
Sender: [email-masked]

Peter.

Content-class: urn:content-classes:message
Subject: RE: encoding an X.509 certificate
Date: Fri, 7 Nov 2008 10:39:57 -0500
From: "Santosh Chokhani" <[email-masked]>
To: "pgut001" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Peter,

"The X.509 v3 certificate basic syntax is as follows.  For signature
calculation, the data that is to be signed is encoded using the ASN.1
   distinguished encoding rules (DER) [X.690]. =20

-----Original Message-----
From: pgut001 [mailto:[email-masked]]=20
Sent: Friday, November 07, 2008 10:36 AM
To: [email-masked]; Santosh Chokhani; [email-masked]
Subject: RE: encoding an X.509 certificate

with the corollary:

since the

the

since the

there's

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: encoding an X.509 certificate
Date: Sat, 08 Nov 2008 04:35:43 +1300
Sender: [email-masked]

with the corollary:

Peter.

Date: Fri, 07 Nov 2008 15:54:18 +0100
From: Peter Sylvester <[email-masked]>
To: Tomas Gustavsson <[email-masked]>
Cc: Juan Gonzalez <[email-masked]>, "Kemp, David P." <[email-masked]>, Tom Scavo <[email-masked]>, pkix <[email-masked]>
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms000500010203070601080500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Tomas Gustavsson wrote:
>    calculation, the data that is to be signed is encoded using the ASN.=
1
>    distinguished encoding rules (DER) [X.690].  ASN.1 DER encoding is a=

>
> Cheers,
> Tomas
>
>
> Peter Sylvester wrote:
>> Juan Gonzalez wrote:
>>> Tom:
>>> =20
>>> From my pont of view, the X.509 standard assumes DER encoding for=20
>>> certificates.
>> IMO it does not do that at all. A certficate is an ASN.1 data structur=
e
>> which is independant from a transfer syntax. X.509 does not even=20
>> indicate
>> that one must encode it in DER when it is transfered or stored. I=20
>> vaguely

--=20

<http://www.edelweb.fr>
*Edel/W/eb* 	Peter SYLVESTER
Consultant S=E9curit=E9 des Syst=E8mes d'Information
-----------------------------------------------------------
EdelWeb - Groupe ON-X
15, quai de Dion-Bouton
F-92816 Puteaux Cedex
Tel : +33.1.40.99.14.14 / Fax : +33.1.40.99.99.58
www.edelweb.fr <http://www.edelweb.fr> / www.on-x.com <http://www.on-x.co=
m>
-----------------------------------------------------------
To verify the message signature, see edelpki.edelweb.fr=20
<http://edelpki.edelweb.fr/>
Cela vous permet de charger le certificat de l'autorit=E9 de racine=20
<http://edelpki.edelweb.fr/cacerts/EdelPKI-ca.der>;
die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.

--------------ms000500010203070601080500
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms000500010203070601080500--

Date: Fri, 07 Nov 2008 09:45:37 -0500
To: Steven Legg <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: [email-masked]
Sender: [email-masked]

Russ 

Date: Fri, 7 Nov 2008 08:05:24 -0600
From: "Timothy J. Miller" <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: Peter Sylvester <[email-masked]>, Juan Gonzalez <[email-masked]>, "Kemp, David P." <[email-masked]>, Tom Scavo <[email-masked]>, pkix <[email-masked]>
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

--------------ms070605060508090503030904
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

-- Tim

--------------ms070605060508090503030904
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms070605060508090503030904--

From: "Anders Rundgren" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, "Juan Gonzalez" <[email-masked]>
Cc: "Kemp, David P." <[email-masked]>, "Tom Scavo" <[email-masked]>, "pkix" <[email-masked]>
Subject: Re: encoding an X.509 certificate
Date: Fri, 7 Nov 2008 12:42:31 +0100
Sender: [email-masked]

Everybody is right :-)

Anders

----- Original Message ----- 
From: "Peter Sylvester" <[email-masked]>
To: "Juan Gonzalez" <[email-masked]>
Cc: "Kemp, David P." <[email-masked]>; "Tom Scavo" <[email-masked]>; "pkix" 
<[email-masked]>

Date: Fri, 07 Nov 2008 10:56:11 +0100
From: Peter Sylvester <[email-masked]>
To: Juan Gonzalez <[email-masked]>
Cc: "Kemp, David P." <[email-masked]>, Tom Scavo <[email-masked]>, pkix <[email-masked]>
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms040808030509030708000309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

--------------ms040808030509030708000309
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms040808030509030708000309--

Date: Fri, 07 Nov 2008 08:19:51 +0000
From: Ben Laurie <[email-masked]>
To: Tom Scavo <[email-masked]>
CC: Anders Rundgren <[email-masked]>, pkix <[email-masked]>
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

Date: Fri, 07 Nov 2008 10:37:00 +1100
From: Steven Legg <[email-masked]>
To: Russ Housley <[email-masked]>
CC: Tom Scavo <[email-masked]>, [email-masked]
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

Russ,

Regards,
Steven

>> Thanks for shedding some light on this issue.

Date: Fri, 07 Nov 2008 10:01:42 +1100
From: Steven Legg <[email-masked]>
To: Tom Scavo <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

Tom,

Regards,
Steven

> see that may not be possible.

Date: Thu, 06 Nov 2008 17:18:23 -0500
To: "Tom Scavo" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: [email-masked]
Sender: [email-masked]

Russ

>Thanks for shedding some light on this issue.

From: "Anders Rundgren" <[email-masked]>
To: "Tom Scavo" <[email-masked]>, "Ben Laurie" <[email-masked]>
Cc: "pkix" <[email-masked]>
Subject: Re: encoding an X.509 certificate
Date: Thu, 6 Nov 2008 23:04:45 +0100
Sender: [email-masked]

Tom,

Anders

----- Original Message ----- 
From: "Tom Scavo" <[email-masked]>
To: "Ben Laurie" <[email-masked]>
Cc: "Anders Rundgren" <[email-masked]>; "pkix" <[email-masked]>
Sent: Thursday, November 06, 2008 22:38
Subject: Re: encoding an X.509 certificate

Thanks,
Tom 

Date: Thu, 6 Nov 2008 16:38:13 -0500
From: "Tom Scavo" <[email-masked]>
To: "Ben Laurie" <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: "Anders Rundgren" <[email-masked]>, pkix <[email-masked]>
Sender: [email-masked]

Thanks,
Tom

Content-class: urn:content-classes:message
Subject: RE: encoding an X.509 certificate
Date: Thu, 6 Nov 2008 15:19:33 -0600
From: "Juan Gonzalez" <[email-masked]>
To: "Kemp, David P." <[email-masked]>, "Tom Scavo" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C94055.5D53766F
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Tom:
=20
>From my pont of view, the X.509 standard assumes DER encoding for =
certificates.
=20
I'm not shure if it mandates DER, but the certificate concept is applied =
in other
standards such as ISO 9735 (EDIFACT), where a series of "segments" =
represent the serial number,
the issuer name, the validity period, the subject names, the public key =
and the signature
- including algorithms for digest and signature.
=20
In EDIFACT there are no attributes.  We have software that "converts" =
from DER encoding to
EDIFACT (using of course, aditional attributes that contain the EDIFACT =
signature and parameters)
=20
About how to distinguish a DER encoding from a Base64 encoding, you can =
analize the
first three bytes:
=20
1. If first byte is "0" (0x30) it is likely to be DER encoded (possibly =
BER/CER.  More analysis would be needed)
2. If first bytes are "MII" (0x4D, 0x49, 0x49) it is likely to be Base64 =
containing a DER/BER/CER encoded certificate
      More analysis would be needed to determine DER/BER/CER encoding
3. If first bytes are "USC" it is likely to be an EDIFACT Public Key =
(let's call it an "EDIFACT certificate")
4. If first byte were "<" (0x3c) it would be likely to be an XML encoded =
certificate (does it exist?, I don't know...)
=20
Juan
SeguriDATA

Dave

-----Original Message-----

<ds:KeyInfo xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#">
 <ds:X509Data>
   <ds:X509Certificate>
MII...
   </ds:X509Certificate>
 </ds:X509Data>
</ds:KeyInfo>

Tom Scavo
NCSA

------_=_NextPart_001_01C94055.5D53766F
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD><TITLE>RE: encoding an X.509 certificate</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6001.18148" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText32396 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2>Tom:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>From my pont of view, the =
X.509 standard assumes DER encoding for certificates</FONT><FONT =
face=3DArial size=3D2>.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I'm not shure if it mandates =
DER, but the certificate concept is applied in other</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>standards such as ISO 9735 =
(EDIFACT), where a series of&nbsp;"segments" represent the serial =
number,</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>the issuer name, the validity =
period, the subject names, the public key and the signature</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>- including algorithms for =
digest and signature.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>In EDIFACT there are no =
attributes.&nbsp; </FONT><FONT face=3DArial size=3D2>We have software =
that "converts" from DER encoding to</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>EDIFACT (using of =
course,&nbsp;aditional attributes that </FONT><FONT face=3DArial =
size=3D2>contain the EDIFACT signature and parameters)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>About how to distinguish a =
DER encoding from a Base64 encoding, you can analize the</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>first three =
bytes:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>1. If first byte is "0" =
(0x30) it is likely to be DER encoded (possibly BER/CER.&nbsp; More =
analysis would be needed)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>2. If first bytes are "MII" =
(0x4D, 0x49, 0x49) it is likely to be Base64 containing =
a&nbsp;DER/BER/CER encoded certificate</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; More analysis would be needed to =
determine DER/BER/CER encoding</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>3. If first bytes are "USC" =
it is likely to be an EDIFACT Public Key (let's call it an "EDIFACT =
certificate")</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>4. If first byte were "&lt;" =
(0x3c) it would be likely to be an XML encoded certificate (does it =
exist?, I don't know...)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2>Juan</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>SeguriDATA</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>De:</B> [email-masked] en =
nombre de Kemp, David P.<BR><B>Enviado el:</B> jue 06/11/2008 =
01:21<BR><B>Para:</B> Tom Scavo; pkix<BR><B>Asunto:</B> RE: encoding an =
X.509 certificate<BR></FONT><BR></DIV>=0A=
<DIV><BR>=0A=
<P><FONT size=3D2>There is no header ("magic bits") at the beginning of =
an encoded<BR>transfer string, so there is not a deterministic mechanism =
for<BR>determining an arbitrary encoding.&nbsp; However, heuristically =
it is trivial<BR>to examine a transfer string and determine that it is =
a) BER/DER/CER<BR>encoded, b) XER endoded, or c) PER encoded.&nbsp; In =
practice, if you were<BR>given an X.509 certificate of unknown encoding, =
there is only one<BR>encoding that it could possibly be (DER) because no =
other encoding is<BR>ever used.&nbsp; Because the signature is computed =
over the DER-encoded<BR>transfer string, a certificate in any other =
format would need to be<BR>re-encoded into DER before validating the =
signature, and that's too much<BR>effort for most =
applications.<BR><BR>Dave<BR><BR><BR>-----Original Message-----<BR>From: =
[email-masked] [<A =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]<BR>On Behalf Of Tom Scavo<BR>Sent: Thursday, November 06, =
2008 12:49 PM<BR>To: pkix<BR>Subject: encoding an X.509 =
certificate<BR><BR><BR>I've asked the following question in a number of =
forums with no luck.<BR>I'm hoping someone with intimate knowledge of =
ASN.1 encodings can help<BR>me out here.&nbsp; Many thanks in =
advance.<BR><BR>Currently there are three profiles before the OASIS =
Security Services<BR>Technical Committee (SSTC) that rely on XML =
elements of the form:<BR><BR>&lt;ds:KeyInfo xmlns:ds=3D"<A =
href=3D"http://www.w3.org/2000/09/xmldsig">http://www.w3.org/2000/09/xmld=
sig</A>#"&gt;<BR>&nbsp;&lt;ds:X509Data&gt;<BR>&nbsp;&nbsp; =
&lt;ds:X509Certificate&gt;<BR>MII...<BR>&nbsp;&nbsp; =
&lt;/ds:X509Certificate&gt;<BR>&nbsp;&lt;/ds:X509Data&gt;<BR>&lt;/ds:KeyI=
nfo&gt;<BR><BR>Interestingly, the above element has sparked a vigorous =
debate within<BR>the SSTC, which has since spread to the W3C XML =
Signature WG.&nbsp; The<BR>issue involves the ASN.1 encoding of the =
underlying certificate (which<BR>is base64 encoded in the XML).&nbsp; =
Specifically, should the certificate<BR>be DER-encoded or should the =
encoding be left unspecified?<BR><BR>So my question is:&nbsp; If you =
were given an X.509 certificate of unknown<BR>encoding, could you =
determine the encoding by simply inspecting the<BR>bytes?&nbsp; Does =
your favorite ASN.1 library support such a function?<BR><BR>Thanks for =
shedding some light on this issue.<BR><BR>Tom =
Scavo<BR>NCSA<BR><BR></FONT></P></DIV></BODY></HTML>
------_=_NextPart_001_01C94055.5D53766F--

Date: Thu, 6 Nov 2008 16:18:27 -0500
From: "Tom Scavo" <[email-masked]>
To: "Ben Laurie" <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: pkix <[email-masked]>
Sender: [email-masked]

Tom

Content-class: urn:content-classes:message
Subject: RE: encoding an X.509 certificate
Date: Thu, 6 Nov 2008 15:56:08 -0500
From: "Santosh Chokhani" <[email-masked]>
To: "pkix" <[email-masked]>
Sender: [email-masked]

I stand corrected.

-----Original Message-----

Tom Scavo wrote:
>=20
>=20
> <ds:KeyInfo xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#">
>  <ds:X509Data>
>    <ds:X509Certificate>
> MII...
>    </ds:X509Certificate>
>  </ds:X509Data>
> </ds:KeyInfo>
>=20
>=20

Cheers,

Ben.

--=20

Date: Thu, 06 Nov 2008 20:36:23 +0000
From: Ben Laurie <[email-masked]>
To: Tom Scavo <[email-masked]>
CC: Anders Rundgren <[email-masked]>, pkix <[email-masked]>
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

Date: Thu, 06 Nov 2008 20:34:03 +0000
From: Ben Laurie <[email-masked]>
To: Tom Scavo <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: encoding an X.509 certificate
Sender: [email-masked]

Cheers,

Ben.

Content-class: urn:content-classes:message
Subject: RE: encoding an X.509 certificate
Date: Thu, 6 Nov 2008 14:35:03 -0500
From: "Santosh Chokhani" <[email-masked]>
To: "Tom Scavo" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

Tom,

DER

-----Original Message-----
From: Tom Scavo [mailto:[email-masked]]=20
Sent: Thursday, November 06, 2008 2:14 PM
To: Santosh Chokhani
Cc: pkix
Subject: Re: encoding an X.509 certificate

Thanks!

Tom

> From: [email-masked]
[mailto:[email-masked]]
> <ds:KeyInfo xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#">
>  <ds:X509Data>
>   <ds:X509Certificate>
> MII...
>   </ds:X509Certificate>
>  </ds:X509Data>
> </ds:KeyInfo>
>

Date: Thu, 6 Nov 2008 14:25:00 -0500
From: "Tom Scavo" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: pkix <[email-masked]>
Sender: [email-masked]

Good point.

Thanks,
Tom

Content-class: urn:content-classes:message
Subject: RE: encoding an X.509 certificate
Date: Thu, 6 Nov 2008 14:21:19 -0500
From: "Kemp, David P." <[email-masked]>
To: "Tom Scavo" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

Dave

-----Original Message-----

<ds:KeyInfo xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#">
 <ds:X509Data>
   <ds:X509Certificate>
MII...
   </ds:X509Certificate>
 </ds:X509Data>
</ds:KeyInfo>

Tom Scavo
NCSA

Date: Thu, 6 Nov 2008 14:13:58 -0500
From: "Tom Scavo" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>
Subject: Re: encoding an X.509 certificate
Cc: pkix <[email-masked]>
Sender: [email-masked]

Thanks!

Tom

> Thanks for shedding some light on this issue.

From: "Perez, Aram" <[email-masked]>
To: PKIX <[email-masked]>
Date: Thu, 6 Nov 2008 11:05:35 -0800
Subject: Re: encoding an X.509 certificate
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Hi Tom,

On 11/6/08 9:49 AM, you wrote:

>=20
>=20
> <ds:KeyInfo xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#">
>  <ds:X509Data>
>    <ds:X509Certificate>
> MII...
>    </ds:X509Certificate>
>  </ds:X509Data>
> </ds:KeyInfo>
>=20

> bytes?=20

Regards,
Aram Perez

From: "Anders Rundgren" <[email-masked]>
To: "Tom Scavo" <[email-masked]>, "pkix" <[email-masked]>
Subject: Re: encoding an X.509 certificate
Date: Thu, 6 Nov 2008 20:02:05 +0100
Sender: [email-masked]

Hi Tom,

Regards
Anders

----- Original Message ----- 
From: "Tom Scavo" <[email-masked]>
To: "pkix" <[email-masked]>
Sent: Thursday, November 06, 2008 18:49
Subject: encoding an X.509 certificate

Tom Scavo
NCSA

Content-class: urn:content-classes:message
Subject: RE: encoding an X.509 certificate
Date: Thu, 6 Nov 2008 13:52:46 -0500
From: "Santosh Chokhani" <[email-masked]>
To: "Tom Scavo" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

-----Original Message-----

<ds:KeyInfo xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#">
 <ds:X509Data>
   <ds:X509Certificate>
MII...
   </ds:X509Certificate>
 </ds:X509Data>
</ds:KeyInfo>

Tom Scavo
NCSA

Date: Thu, 6 Nov 2008 12:49:10 -0500
From: "Tom Scavo" <[email-masked]>
To: pkix <[email-masked]>
Subject: encoding an X.509 certificate
Sender: [email-masked]

Tom Scavo
NCSA

From: Stefan Santesson <[email-masked]>
To: Stefan Santesson <[email-masked]>, pkix <[email-masked]>
Date: Thu, 6 Nov 2008 11:04:57 +0000
Subject: RE: FINAL CALL: Call for agenda items, Minneapolis IETF
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_000_9F11911AED01D24BAA1C2355723C3D32195ACDA1F6EAEXMSGC332eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Yeah, we are going to Minneapolis...

No need for any more private e-mails to me pointing that out :)

Stefan Santesson
Senior Program Manager

From: [email-masked] [mailto:[email-masked]] On=
 Behalf Of Stefan Santesson
Sent: den 5 november 2008 17:52
To: pkix
Subject: FINAL CALL: Call for agenda items, Philadelphia IETF

I have timeslot requests for the following PKIX work items:

*         Trust Anchor Management

*         Other certs extension

*         Clearance attribute and CA clearance constraints

*         PKI resource query protocol

*         RFC3281 updates

I still lack information if any editor wants to address the following WG it=
ems:

*         ECC Subject public key info

*         RFC 4055 update

*         New ASN.1 modules for PKIX

*         Algorithm identifiers for SHA2

*         Traceable anonymous certificates

I have no requests for additional topics.

REQUIRED ACTIONS:
Can someone from each lacking WG item please let me know if you want any ti=
me slot.
We are also still open for other potential topics on the agenda.
But I need all requests by the end of this week.

Thank you.

Stefan Santesson
Senior Program Manager

From: [email-masked] [mailto:[email-masked]] On=
 Behalf Of Stefan Santesson
Sent: den 20 februari 2008 18:05
To: pkix
Subject: Call for agenda items, Philadelphia IETF

Time to set the agenda for the Philadelphia PKIX meeting.

Anyone wanting a slot should send me an e-mail as soon as possible, no late=
r than EOD Wednesday next week (Feb 27).
As usual I want the lead editor for every current pkix draft to tell me if =
they want a slot or not.

We are currently scheduled as a Monday morning session from 0900-1130, whic=
h means two things.
1) We have 2.5 hours available which should be plenty of time.
2) We need to have everything set, including presentations sent to me by Su=
nday night.

Stefan Santesson
Senior Program Manager

--_000_9F11911AED01D24BAA1C2355723C3D32195ACDA1F6EAEXMSGC332eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www=
.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoin=
t/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns=
:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile=
" xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns=
:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns=
:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http=
://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"ht=
tp://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z=3D"urn:s=
chemas-microsoft-com:" xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-=
html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1027682776;
	mso-list-type:hybrid;
	mso-list-template-ids:-1317393742 69009409 69009411 69009413 69009409 6900=
9411 69009413 69009409 69009411 69009413;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1
	{mso-list-id:1397900729;
	mso-list-type:hybrid;
	mso-list-template-ids:635612220 69009409 69009411 69009413 69009409 690094=
11 69009413 69009409 69009411 69009413;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l1:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span lang=3DEN-US style=
=3D'color:
#1F497D'>Yeah, we are going to Minneapolis&#8230;<o:p></o:p></span></a></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>No need for=
 any more
private e-mails to me pointing that out </span><span lang=3DEN-US
style=3D'font-family:Wingdings;color:#1F497D'>J</span><span lang=3DEN-US
style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> [email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Stefan Santesson<=
br>
<b>Sent:</b> den 5 november 2008 17:52<br>
<b>To:</b> pkix<br>
<b>Subject:</b> FINAL CALL: Call for agenda items, Philadelphia IETF<o:p></=
o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>I have time=
slot
requests for the following PKIX work items:<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>T=
rust
Anchor Management<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>O=
ther
certs extension<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>C=
learance
attribute and CA clearance constraints<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>P=
KI
resource query protocol<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>R=
FC3281 updates<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>I still lac=
k
information if any editor wants to address the following WG items:<o:p></o:=
p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo4'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>E=
CC
Subject public key info <o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo4'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>R=
FC 4055
update<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo4'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>N=
ew ASN.1
modules for PKIX<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo4'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>A=
lgorithm
identifiers for SHA2<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo4'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>T=
raceable
anonymous certificates<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>I have no r=
equests
for additional topics.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>REQUIRED AC=
TIONS:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Can someone=
 from each
lacking WG item please let me know if you want any time slot.<o:p></o:p></s=
pan></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>We are also=
 still
open for other potential topics on the agenda.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>But I need =
all
requests by the end of this week.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Thank you.<=
o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> [email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Stefan Santesson<=
br>
<b>Sent:</b> den 20 februari 2008 18:05<br>
<b>To:</b> pkix<br>
<b>Subject:</b> Call for agenda items, Philadelphia IETF<o:p></o:p></span><=
/p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US>Time to set the agenda for the Phil=
adelphia
PKIX meeting.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Anyone wanting a slot should send m=
e an
e-mail as soon as possible, no later than EOD Wednesday next week (Feb 27).=
<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>As usual I want the lead editor for=
 every
current pkix draft to tell me if they want a slot or not.<o:p></o:p></span>=
</p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>We are currently scheduled as a Mon=
day
morning session from 0900-1130, which means two things.<o:p></o:p></span></=
p>

<p class=3DMsoNormal><span lang=3DEN-US>1) We have 2.5 hours available whic=
h should
be plenty of time.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>2) We need to have everything set,
including presentations sent to me by Sunday night.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</div>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D32195ACDA1F6EAEXMSGC332eu_--

Reply-To: [email-masked]
From: "Denis Pinkas"<[email-masked]>
To: "ietf-pkix"<[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt (second part)
Date: Thu, 6 Nov 2008 11:26:53 +0100
Sender: [email-masked]

------=_NextPart_08110611265266872518641_002
Content-Type: text/plain; 
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

In order to keep the message short, two answers are given on this documen=
t.
=20
Comments on draft-ietf-pkix-ta-mgmt-reqs-02
=20
Topic: Clarifications needed about associated data, purpose and=20
constraints.
=20
For most web browsers and Java machines, the current situation is the=20
following:
=20
   - self-signed certificates are used for all purposes, e.g. TLS server,
     TLS client, sending e-mails, receiving e-mails, applets' signatures,
     and
=20
   - it is unknown whether revocation conditions are checked and how.
=20
Suppose (for the time being) that we want to move from the current=20
situation where self-signed certificates are placed in the same storage a=
nd=20
hence used for all purposes to a situation where self-signed certificates=
=20
are no more used for any purpose, e.g. used for sending e-mails or used f=
or=20
receiving e-mails.
=20
There are two possible approaches:
=20
   a) consider a given a *purpose*, e.g. applets' signatures, and then=20
      list all self-signed certificates that can be used for such a
      purpose, or
=20
   b) consider each self-signed certificate and tell for which purpose=20
      that self-signed certificate may be used.
=20
If we take into consideration the "need-to-know" requirement, some=20
applications need to know which self-signed certificates shall be used fo=
r=20
a given purpose and do not need to know if they are also used for a=20
different purpose.
=20
The approach a) fulfils this requirement, but not the approach b).
=20
When a path validation must be done for a given purpose, case a) is rathe=
r=20
straightforward: all the information is under the purpose.
=20
With case b), this would be more difficult, since the application would=20
need to scan every "Trust Anchor" store (?) and look if the given purpose=
=20
is mentioned under a "Trust Anchor".
=20
Case a) allows a clear and clean separation of information. However, it=20
seems that the document has implicitly chosen case b). :-(
=20
It is unclear in the current document what is the relationship between th=
e=20
purpose of use of a self-signed certificate that would be placed in TA, t=
he=20
"Trust Anchor" itself or the "Trust Anchor Store=94.
=20
Is one Trust anchor Store usable for some specific purpose(s)?=20

Hence is the "purpose" part of the Trust Anchor Store rather than=20
the Trust Anchor itself?=20

All this needs to be clarified. Once this will be clarified,=20
it will be possible to address the kind of operations that should be=20
possible on the various objects.
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
In the abstract the text states:
=20
   The public key is used to verify digital
   signatures and the *associated data is used to constrain* the types of
   information for which the trust anchor is authoritative.
=20
This sentence is confusing since the word "constrain" is kept vague and=20
thus does not make the difference between:
=20
   1) the intended purpose,
   2) the constraints that are set by the CA and apply for all purposes,
   3) the constraints that are set by the RP.
=20
Let us now illustrate case 2): the constraints are included into the self=
-
signed certificate. The constraints are set by the CA and apply to all=20
usages of that self-signed certificate, i.e. all "purposes".
=20
Let us now illustrate cases 3): the constraints are external to the self-
signed certificate. The constraints come in addition to those included=20
inside the self-signed certificate and are tailored to the specific=20
purpose.
=20
Case 2) and case 3) may co-exist.=20
=20
However, the current draft does not make the distinction between case 2)=20
and case 3). This is rather fundamental, since a "TA manager" cannot chan=
ge=20
the constraints that are included in a self-signed certificate.
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
=20
The document defines a Trust Anchor as : "A trust anchor represents an=20
authoritative entity via a public key and associated data". This sentence=
=20
is confusing since the wording "associated data" means everything and thu=
s=20
nothing.=20
=20
This definition is not coherent with RFC 5280 which states on page 76:
=20
   " The trust anchor information includes:
=20
      (1)  the trusted issuer name,
      (2)  the trusted public key algorithm,
      (3)  the trusted public key, and
      (4)  optionally, the trusted public key parameters associated
           with the public key.
=20
The issuer name shall always be present in a trust anchor".
=20
The definition of a TA should also make the difference between:
=20
   a) the constraints that are set by the CA and apply for all purposes,
   b) the constraints that are set by the RP.
=20
Only the later, can be managed when self-signed certificates are used.
Denis

----- Message re=E7u -----=20
De : owner-ietf-pkix=20
=C0 : i-d-announce=20
Date : 2008-10-30, 21:45:01
Sujet : I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt

Pi=E8ce(s) Jointe(s) au message original :
  (1). draft-ietf-pkix-ta-mgmt-reqs-02.txt

  Title : Trust Anchor Management Requirements
  Author(s) : R. Reddy, C. Wallace
  Filename : draft-ietf-pkix-ta-mgmt-reqs-02.txt
  Pages : 19
  Date : 2008-10-30

A trust anchor represents an authoritative entity via a public key
and associated data. The public key is used to verify digital
signatures and the associated data is used to constrain the types of
information for which the trust anchor is authoritative. A relying
party uses trust anchors to determine if a digitally signed object is
valid by verifying a digital signature using the trust anchor's
public key, and by enforcing the constraints expressed in the
associated data for the trust anchor. This document describes some
of the problems associated with the lack of a standard trust anchor
management mechanism and defines requirements for data formats and
protocols designed to address these problems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-reqs-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

------=_NextPart_08110611265266872518641_002
Content-Type: text/html; 
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD><TITLE></TITLE>
<META content=3D"KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, =A9 Kurt=
 Senfer"=20
name=3DGENERATOR>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-=
1"></HEAD>
<BODY style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=3D5 topMa=
rgin=3D5=20
#ffffff>
<DIV>In order to keep the message short, two answers are given on this=20
document.</DIV>
<DIV><SPAN lang=3DEN-GB style=3D"mso-ansi-language: EN-GB"><?xml:namespac=
e prefix =3D=20
o ns =3D "urn:schemas-microsoft-com:office:office" /><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></DIV>
<DIV>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Comments on=
=20
draft-ietf-pkix-ta-mgmt-reqs-02<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Topic: Clar=
ifications=20
needed about associated data, purpose and <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New">constraints.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">For most we=
b browsers=20
and Java machines, the current situation is the <o:p></o:p></FONT></SPAN>=
</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New">following:<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>- self-signed certificate=
s are=20
used for all purposes, e.g. TLS server,<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>TLS client, s=
ending=20
e-mails, receiving e-mails, applets' signatures,<o:p></o:p></FONT></SPAN>=
</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>and<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>- it is unknown whether r=
evocation=20
conditions are checked and how.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Suppose (fo=
r the time=20
being) that we want to move from the current <o:p></o:p></FONT></SPAN></P=
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">situation w=
here=20
self-signed certificates are placed in the same storage and=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">hence used =
for all=20
purposes to a situation where self-signed certificates=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">are no more=
 used for=20
any purpose, e.g. used for sending e-mails or used for=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">receiving=20
e-mails.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">There are t=
wo possible=20
approaches:<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>a) consider a given a *pu=
rpose*,=20
e.g. applets' signatures, and then <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>list al=
l=20
self-signed certificates that can be used for such=20
a<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>purpose=
,=20
or<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>b) consider each self-sig=
ned=20
certificate and tell for which purpose <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>that se=
lf-signed=20
certificate may be used.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">If we take =
into=20
consideration the "need-to-know" requirement, some <o:p></o:p></FONT></SP=
AN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">application=
s need to=20
know which self-signed certificates shall be used for=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">a given pur=
pose and do=20
not need to know if they are also used for a <o:p></o:p></FONT></SPAN></P=
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">different=20
purpose.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The approac=
h a)=20
fulfils this requirement, but not the approach b).<o:p></o:p></FONT></SPA=
N></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">When a path=
 validation=20
must be done for a given purpose, case a) is rather=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">straightfor=
ward: all=20
the information is under the purpose.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">With case b=
), this=20
would be more difficult, since the application would=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">need to sca=
n every=20
"Trust Anchor" store (?) and look if the given purpose=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">is mentione=
d under a=20
"Trust Anchor".<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Case a) all=
ows a clear=20
and clean separation of information. However, it <o:p></o:p></FONT></SPAN=
></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">seems that =
the=20
document has implicitly chosen case b). :-(<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">It is uncle=
ar in the=20
current document what is the relationship between the=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">purpose of =
use of a=20
self-signed certificate that would be placed in TA, the=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">"Trust Anch=
or" itself=20
or the "Trust Anchor Store=94.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Is one Trus=
t anchor=20
Store usable for some specific purpose(s)? </FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New"></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Hence is=20
</FONT></SPAN><SPAN lang=3DEN-GB style=3D"mso-ansi-language: EN-GB"><FONT=
=20
face=3D"Courier New">the "purpose" part of the Trust Anchor Store rather =
than=20
<BR>the Trust A</FONT></SPAN><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">nchor itsel=
f?=20
</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New"></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">All this ne=
eds to be=20
clarified. Once this will be clarified, <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">it will be =
possible to=20
address the kind of operations that should be <o:p></o:p></FONT></SPAN></=
P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">possible on=
 the=20
various objects.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">In the abst=
ract the=20
text states:<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The public key is used to=
 verify=20
digital<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>signatures and the *assoc=
iated=20
data is used to constrain* the types of<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>information for which the=
 trust=20
anchor is authoritative.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">This senten=
ce is=20
confusing since the word "constrain" is kept vague and=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">thus does n=
ot make the=20
difference between:<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>1) the intended=20
purpose,<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>2) the constraints that a=
re set by=20
the CA and apply for all purposes,<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>3) the constraints that a=
re set by=20
the RP.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Let us now =
illustrate=20
case 2): the constraints are included into the=20
self-<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">signed cert=
ificate.=20
The constraints are set by the CA and apply to all <o:p></o:p></FONT></SP=
AN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">usages of t=
hat=20
self-signed certificate, i.e. all "purposes".<o:p></o:p></FONT></SPAN></P=
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Let us now =
illustrate=20
cases 3): the constraints are external to the self-<o:p></o:p></FONT></SP=
AN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">signed cert=
ificate.=20
The constraints come in addition to those included <o:p></o:p></FONT></SP=
AN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">inside the =
self-signed=20
certificate and are tailored to the specific <o:p></o:p></FONT></SPAN></P=
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New">purpose.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Case 2) and=
 case 3)=20
may co-exist. <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">However, th=
e current=20
draft does not make the distinction between case 2)=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">and case 3)=
. This is=20
rather fundamental, since a "TA manager" cannot change=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">the constra=
ints that=20
are included in a self-signed certificate.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The documen=
t defines a=20
Trust Anchor as : "A trust anchor represents an <o:p></o:p></FONT></SPAN>=
</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">authoritati=
ve entity=20
via a public key and associated data". This sentence=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">is confusin=
g since the=20
wording "associated data" means everything and thus=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">nothing.=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">This defini=
tion is not=20
coherent with RFC 5280 which states on page 76:<o:p></o:p></FONT></SPAN><=
/P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; " </SPAN>The trust anchor inform=
ation=20
includes:<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>(1)<SPA=
N=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>the trusted issuer=20
name,<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;</SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;</SPAN>(2)<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>the trusted public key=20
algorithm,<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>(3)<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>the trusted public key,=20
and<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>(4)<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>optionally, the trusted public =
key=20
parameters associated<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;=20
</SPAN>with the public key.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The issuer =
name shall=20
always be present in a trust anchor".<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The definit=
ion of a TA=20
should also make the difference between:<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>a) the constraints that a=
re set by=20
the CA and apply for all purposes,<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>b) the constraints that a=
re set by=20
the RP.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Only the la=
ter, can be=20
managed when self-signed certificates are used.<o:p></o:p></FONT></SPAN><=
/P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New"></FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"></SPAN></P></DIV>
<DIV></DIV>
<DIV><!--AID_FROMNAME_BEGIN-->Denis</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-=
LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal">-----=20
  Message re=E7u ----- </DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE=
-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: bl=
ack"><B>De=20
  :</B> <A href=3D"mailto :[email-masked]">owner-ietf-pkix<=
/A>=20
</DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>=C0=20
  :</B> <A href=3D"mailto :[email-masked]">i-d-announce</A> </DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Date=20
  :</B> 2008-10-30, 21:45:01</DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Sujet=20
  :</B> I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV>
  <DIV><U><STRONG>Pi=E8ce(s) Jointe(s) au message original :</STRONG></U>=
</DIV>
  <DIV>&nbsp;&nbsp;(1).&nbsp;draft-ietf-pkix-ta-mgmt-reqs-02.txt</DIV><BR=
></DIV>
  <DIV>
  <DIV>&nbsp;&nbsp;Title : Trust Anchor Management=20
  Requirements<BR>&nbsp;&nbsp;Author(s) : R. Reddy, C.=20
  Wallace<BR>&nbsp;&nbsp;Filename :=20
  draft-ietf-pkix-ta-mgmt-reqs-02.txt<BR>&nbsp;&nbsp;Pages :=20
  19<BR>&nbsp;&nbsp;Date : 2008-10-30<BR><BR>A trust anchor represents an=
=20
  authoritative entity via a public key<BR>and associated data. The publi=
c key=20
  is used to verify digital<BR>signatures and the associated data is used=
 to=20
  constrain the types of<BR>information for which the trust anchor is=20
  authoritative. A relying<BR>party uses trust anchors to determine if a=20
  digitally signed object is<BR>valid by verifying a digital signature us=
ing the=20
  trust anchor's<BR>public key, and by enforcing the constraints expresse=
d in=20
  the<BR>associated data for the trust anchor. This document describes=20
  some<BR>of the problems associated with the lack of a standard trust=20
  anchor<BR>management mechanism and defines requirements for data format=
s=20
  and<BR>protocols designed to address these problems.<BR><BR>A URL for t=
his=20
  Internet-Draft is:<BR><A=20
  href=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-req=
s-02.txt">http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-req=
s-02.txt</A><BR><BR>Internet-Drafts=20
  are also available by anonymous FTP=20
  at:<BR>ftp://ftp.ietf.org/internet-drafts/<BR><BR>Below is the data whi=
ch will=20
  enable a MIME compliant mail reader<BR>implementation to automatically=20
  retrieve the ASCII version of=20
the<BR>Internet-Draft.<BR><BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08110611265266872518641_002--

Reply-To: [email-masked]
From: "Denis Pinkas"<[email-masked]>
To: "ietf-pkix"<[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt
Date: Thu, 6 Nov 2008 11:24:39 +0100
Sender: [email-masked]

------=_NextPart_08110611243926651453484_002
Content-Type: text/plain; 
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

In order to keep the message short, two answers are given on this documen=
t.

Comments on draft-ietf-pkix-ta-mgmt-reqs-02
=20
Topic: automatic root key rollover only using trust anchors initially=20
installed.
=20
The document states on page 7:
=20
   Ideally, only the initial set of trust anchors are installed in=20
   a particular trust anchor store should require out-of-band=20
   verification, particularly when the costs of performing out-of-band=20
   checks commensurate with the security requirements of applications=20
   using the trust anchor store are high.
=20
It implicitly means that once an initial set of trust anchors is installe=
d,=20
the renewal should happen automatically.
=20
Unfortunately, this text is only a *statement* within section 2 "Problem=20
Statement" rather than a *requirement* within section 3 "Requirements". I=
t=20
should be transformed into a requirement with section 3.
=20
In practice, we are very close to reach this goal.
=20
The CMP protocol allows RPs to pull the information and to automatically=20
update trust anchors using the old-by-new self-signed certificate and the=
=20
new-by-new self-signed certificate. There are only two additional questio=
ns=20
to be answered:=20
=20
   a) where to fetch these self-signed-certificates ?
   b) when to fetch these self-signed-certificates ?=20
=20
The answer to the first question is:=20
=20
   1) add an LDAP address or an HTTP address, or
   2) use an Authority Information Access extension=20
      within the self-signed certificate.
=20
The answer to the second question is:=20
=20
   1) add a time period for root key renewal, or
   2) use a private key usage extension within the self-signed certificat=
e.
=20
 ... and then we are done when CA issue self-signed certificates, which i=
s=20
what *all* CAs are doing today.
=20
It does not matter where self-signed certificates are stored, e.g. in=20
validation policies or in TA anchors stores (whatever this last term may=20
mean).
=20
It means that the use of self-signed certificates allows automatic root k=
ey=20
rollover and to reach the ideal situation mentioned above.
=20
A major advantage of this approach is the use of a pull model: the proces=
s=20
is initiated from the inside of a company and the number of applications=20
using that self-signed certificate may be hidden to the outside. Denial o=
f=20
service is easier to handle since the first exchange comes from the insid=
e.=20
=20
These considerations should be taken into consideration in the draft.
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
The document states in section 3.1.: Transport independence
=20
   "It MUST work in both session-oriented
   and store-and-forward communications environments as well as in both
   push and pull distribution models".
=20
CMP only works in a pull model. With such sentence CMP would be ruled out=
=20
whereas it is already a standard track protocol.
=20
The document states in section 3.1.: Transport independence
=20
   "connectionless integrity and data origin
   authentication for TA transactions MUST be provided at the
   application layer".
=20
With CMP, the security is obtained directly by the self-signed=20
certificates, i.e. the data itself which is self-protected. With such=20
sentence CMP would be ruled out, whereas it is already a standard track=20
protocol.
=20
The document cannot say on one side that the pull model is allowed and on=
=20
the other side include requirements which rule out the use of CMP (which =
is=20
based on a pull model).

Denis

----- Message re=E7u -----=20
De : owner-ietf-pkix=20
=C0 : i-d-announce=20
Date : 2008-10-30, 21:45:01
Sujet : I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt

Pi=E8ce(s) Jointe(s) au message original :
  (1). draft-ietf-pkix-ta-mgmt-reqs-02.txt

  Title : Trust Anchor Management Requirements
  Author(s) : R. Reddy, C. Wallace
  Filename : draft-ietf-pkix-ta-mgmt-reqs-02.txt
  Pages : 19
  Date : 2008-10-30

A trust anchor represents an authoritative entity via a public key
and associated data. The public key is used to verify digital
signatures and the associated data is used to constrain the types of
information for which the trust anchor is authoritative. A relying
party uses trust anchors to determine if a digitally signed object is
valid by verifying a digital signature using the trust anchor's
public key, and by enforcing the constraints expressed in the
associated data for the trust anchor. This document describes some
of the problems associated with the lack of a standard trust anchor
management mechanism and defines requirements for data formats and
protocols designed to address these problems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-reqs-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

------=_NextPart_08110611243926651453484_002
Content-Type: text/html; 
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD><TITLE></TITLE>
<META content=3D"KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, =A9 Kurt=
 Senfer"=20
name=3DGENERATOR>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-=
1"></HEAD>
<BODY style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=3D5 topMa=
rgin=3D5=20
#ffffff>
<DIV>In order to keep the message short, two answers are given on this=20
document.</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Comments on=
=20
draft-ietf-pkix-ta-mgmt-reqs-02<?xml:namespace prefix =3D o ns =3D=20
"urn:schemas-microsoft-com:office:office" /><o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Topic: auto=
matic root=20
key rollover only using trust anchors initially <o:p></o:p></FONT></SPAN>=
</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New">installed.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The documen=
t states on=20
page 7:<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>Ideally, only the initial=
 set of=20
trust anchors are installed in <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>a particular trust anchor=
 store=20
should require out-of-band <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>verification, particularl=
y when=20
the costs of performing out-of-band <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>checks commensurate with =
the=20
security requirements of applications <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>using the trust anchor st=
ore are=20
high.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">It implicit=
ly means=20
that once an initial set of trust anchors is installed,=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">the renewal=
 should=20
happen automatically.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Unfortunate=
ly, this=20
text is only a *statement* within section 2 "Problem=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">Statement" =
rather than=20
a *requirement* within section 3 "Requirements". It=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">should be t=
ransformed=20
into a requirement with section 3.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">In practice=
, we are=20
very close to reach this goal.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The CMP pro=
tocol=20
allows RPs to pull the information and to automatically=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">update trus=
t anchors=20
using the old-by-new self-signed certificate and the=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">new-by-new =
self-signed=20
certificate. There are only two additional questions=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">to be answe=
red:=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">&nbsp;&nbsp=
; a) where=20
to fetch these self-signed-certificates ?<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">&nbsp; b) w=
hen to=20
fetch these self-signed-certificates ? <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The answer =
to the=20
first question is: <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>1) add an LDAP address or=
 an HTTP=20
address, or<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>2) use an Authority Infor=
mation=20
Access extension <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>within =
the=20
self-signed certificate.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The answer =
to the=20
second question is: <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>1) add a time period for =
root key=20
renewal, or<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>2) use a private key usag=
e=20
extension within the self-signed certificate.<o:p></o:p></FONT></SPAN></P=
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN>... and then we are done when CA=
 issue=20
self-signed certificates, which is <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">what *all* =
CAs are=20
doing today.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">It does not=
 matter=20
where self-signed certificates are stored, e.g. in <o:p></o:p></FONT></SP=
AN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">validation =
policies or=20
in TA anchors stores (whatever this last term may <o:p></o:p></FONT></SPA=
N></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New">mean).<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">It means th=
at the use=20
of self-signed certificates allows automatic root key=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">rollover an=
d to reach=20
the ideal situation mentioned above.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">A major adv=
antage of=20
this approach is the use of a pull model: the process=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">is initiate=
d from the=20
inside of a company and the number of applications <o:p></o:p></FONT></SP=
AN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">using that =
self-signed=20
certificate may be hidden to the outside. Denial of=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">service is =
easier to=20
handle since the first exchange comes from the inside.=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">These consi=
derations=20
should be taken into consideration in the draft.<o:p></o:p></FONT></SPAN>=
</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The documen=
t states in=20
section 3.1.: Transport independence<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>"It MUST work in both=20
session-oriented<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>and store-and-forward=20
communications environments as well as in both<o:p></o:p></FONT></SPAN></=
P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>push and pull distributio=
n=20
models".<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">CMP only wo=
rks in a=20
pull model. With such sentence CMP would be ruled out=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">whereas it =
is already=20
a standard track protocol.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The documen=
t states in=20
section 3.1.: Transport independence<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>"connectionless integrity=
 and data=20
origin<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>authentication for TA tra=
nsactions=20
MUST be provided at the<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>application=20
layer".<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">With CMP, t=
he security=20
is obtained directly by the self-signed <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">certificate=
s, i.e. the=20
data itself which is self-protected. With such <o:p></o:p></FONT></SPAN><=
/P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">sentence CM=
P would be=20
ruled out, whereas it is already a standard track <o:p></o:p></FONT></SPA=
N></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New">protocol.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><o:p><FONT=20
face=3D"Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">The documen=
t cannot=20
say on one side that the pull model is allowed and on=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">the other s=
ide include=20
requirements which rule out the use of CMP (which is=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT face=3D"Courier New">based on a =
pull=20
model).</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New"></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New">Denis</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-GB=20
style=3D"mso-ansi-language: EN-GB"><FONT=20
face=3D"Courier New"></FONT></SPAN>&nbsp;</P></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-=
LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal">-----=20
  Message re=E7u ----- </DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE=
-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: bl=
ack"><B>De=20
  :</B> <A href=3D"mailto :[email-masked]">owner-ietf-pkix<=
/A>=20
</DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>=C0=20
  :</B> <A href=3D"mailto :[email-masked]">i-d-announce</A> </DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Date=20
  :</B> 2008-10-30, 21:45:01</DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Sujet=20
  :</B> I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV>
  <DIV><U><STRONG>Pi=E8ce(s) Jointe(s) au message original :</STRONG></U>=
</DIV>
  <DIV>&nbsp;&nbsp;(1).&nbsp;draft-ietf-pkix-ta-mgmt-reqs-02.txt</DIV><BR=
></DIV>
  <DIV>
  <DIV>&nbsp;&nbsp;Title : Trust Anchor Management=20
  Requirements<BR>&nbsp;&nbsp;Author(s) : R. Reddy, C.=20
  Wallace<BR>&nbsp;&nbsp;Filename :=20
  draft-ietf-pkix-ta-mgmt-reqs-02.txt<BR>&nbsp;&nbsp;Pages :=20
  19<BR>&nbsp;&nbsp;Date : 2008-10-30<BR><BR>A trust anchor represents an=
=20
  authoritative entity via a public key<BR>and associated data. The publi=
c key=20
  is used to verify digital<BR>signatures and the associated data is used=
 to=20
  constrain the types of<BR>information for which the trust anchor is=20
  authoritative. A relying<BR>party uses trust anchors to determine if a=20
  digitally signed object is<BR>valid by verifying a digital signature us=
ing the=20
  trust anchor's<BR>public key, and by enforcing the constraints expresse=
d in=20
  the<BR>associated data for the trust anchor. This document describes=20
  some<BR>of the problems associated with the lack of a standard trust=20
  anchor<BR>management mechanism and defines requirements for data format=
s=20
  and<BR>protocols designed to address these problems.<BR><BR>A URL for t=
his=20
  Internet-Draft is:<BR><A=20
  href=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-req=
s-02.txt">http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-req=
s-02.txt</A><BR><BR>Internet-Drafts=20
  are also available by anonymous FTP=20
  at:<BR>ftp://ftp.ietf.org/internet-drafts/<BR><BR>Below is the data whi=
ch will=20
  enable a MIME compliant mail reader<BR>implementation to automatically=20
  retrieve the ASCII version of=20
the<BR>Internet-Draft.<BR><BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08110611243926651453484_002--

Date: Wed, 05 Nov 2008 09:31:41 -0800
From: Arshad Noor <[email-masked]>
Organization: StrongAuth, Inc.
To: Anders Rundgren <[email-masked]>
CC: [email-masked], ekmi <[email-masked]>
Subject: Re: SKSML Was: Signing and Encrypting with the same key?
Sender: [email-masked]

To paraphrase the Public Review 02 specification (which should be
available on the OASIS site by the end of this week):

"..conforming implementations of the SKSML protocol MUST enclose all 
SKSML messages between participants in an SKMS, in the SOAP Body of a 
SOAP Envelope.  Additionally, the contents of the SOAP Body MUST be 
secured using digital signatures conforming to [XMLSignature] in the 
SOAP Header.  Specifically, the SOAP Header of the SOAP Envelope MUST 
enclose a Security element conforming to [WSS] with a ValueType 
attribute containing the value 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3."

Yes, all SKMS clients and servers are mandated to use a certain security
convention in SOAP, but the SKSML message is oblivious of its envelope. 
  Secondly, how the digital certificates are constructed, how the client
and server key-pairs are managed, how the PKI is setup, managed and
audited, is not in the SKSML protocol.

That is what I meant by "abstracting the security, implementation,
operations and audit" of an EKMI out of the protocol.

Arshad Noor
StrongAuth, Inc.

Anders Rundgren wrote:
> Arshad,
> 
> Pardon my ignorance but I do not see how you can "abstract out" security solutions in a concrete 
> SOAP specification, either it is there or it is not.  That is, with respect to the particular 
> question and the current draft, you have no real alternative except stating that client and servers 
> must be configured to support a common convention.  Which BTW may be exactly what you meant :-) 
> That KeyGen2 is a 6-pass protocol is for avoiding conventions since the entities involved typically 
> do not belong to the same "IT-domain".  E.g. a consumer with a mobile phone and his/her bank.
> 
> Regarding the separate key stuff, the current strategy is to support it in the protocol, but not in 
> the Open Source client-implementation since no compelling argument actually has been raised for 
> having multiple keys, while there is quite a bunch of arguments against such an arrangement.  How is 
> an SKSML server supposed to know what to encrypt with if you do not send the key in the request?  It 
> seems that an SKSML server must keep an encryption key database or be configured to use LDAP etc. 
> It seems like a more straightforward solution to transfer encryption keys explicitly and validate 
> them at receival in the same way as you do with signature and authentication keys.
> 
> I'm a bit puzzled regarding how you intend to bootstrap SKSML with PKI, if the figures with a myriad 
> of entirely different clients are still valid.  The reason I started the KeyGen2 effort is because 
> this is a veritable nightmare, particularly for mobile devices.  As a comparison I would like to 
> mention the fact that there are some 100M TPM chips out there in major laptops, but they are "mostly 
> of out work" because the bootstrapping issues haven't been fully addressed by the TPM designers.
> 
> Anders
> 
> From: "Arshad Noor" <[email-masked]>
> To: "Anders Rundgren" <[email-masked]>
> Cc: "Timothy J. Miller" <[email-masked]>; "Peter Gutmann" <[email-masked]>; 
> <[email-masked]>
> Sent: Tuesday, November 04, 2008 22:24
> Subject: Re: Signing and Encrypting with the same key?
> 
> 
> 
> Hi Anders,
> 
> The reason we haven't mentioned it yet is because the TC is going
> to begin the task of creating Implementation, Operations and Audit
> Guidelines for EKMI only in 2009.  It is within these guidelines
> where a recommendation for separating signing & encryption key-pairs
> would be made.
> 
> The SKSML protocol focuses on the minimum necessary syntax to send
> and receive messages related to symmetric-key management.  The
> security, implementation, operations and audit of such Enterprise
> Key Management Infrastructures must be capable of being abstracted
> out of the protocol, layered and managed independently.  Which is
> why there is no mention of separated key-pairs yet.  However, you
> can expect to see it in the Guidelines next year.
> 
> Arshad Noor
> StrongAuth, Inc.
> 
> 
> Anders Rundgren wrote:
>> Hi Arshad,
>> I just skimmed through the non-normative spec and example and from that I could not see any
>> mentioning of separate keys.
>>
>> I digged a bit further but could still not find such references in:
>> http://www.oasis-open.org/committees/download.php/28725/SKSML-1.0-Specification-Normative-DRAFT6.0.pdf
>>
>> I don't know what you have planned, but IMO you need additional elements in the protocol (like
>> giving the client a place to put its encryption key), as well as a standard for how encryption and
>> signature keys link together otherwise the server cannot be sure that it is encrypting for the
>> client that authenticated.  All this is the reason why I'm not overly enthusiastic of having
>> multiple entity-keys in a provisioning protocol, particularly since all attacks I have heard about
>> to date, have been based on flawed implementations, which is moderately interesting from a
>> *protocol-design* point-of-view:
>> http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html
>>
>> But it is possible that SKSML will run in more restricted environments than KeyGen2 and thus can
>> build on that the client and servers use "conventions", keeping the protocol smallish.   KeyGen2 
>> is
>> designed to cope with a fragmented world and thus sports a capability/policy negotiation facility.
>>
>> Anders
>>
>> From: "Arshad Noor" <[email-masked]>
>> To: "Anders Rundgren" <[email-masked]>
>> Cc: "Timothy J. Miller" <[email-masked]>; "Peter Gutmann" <[email-masked]>;
>> <[email-masked]>
>> Sent: Tuesday, November 04, 2008 21:11
>> Subject: Re: Signing and Encrypting with the same key?
>>
>>
>> Anders,
>>
>> Just to clarify, the SKSML protocol does not mandate how the
>> digital certificate of SKMS clients and servers should be
>> constructed, or what the keyUsage extension should look like
>> within such certificates.  We believe that that is an
>> implementation detail of the PKI that supports the SKMS.
>>
>> The SKMS only requires that every client and server have a
>> signing key and an encryption key.  They can be the same
>> key-pair or two different key-pairs, depending on the PKI
>> certificate policy of the implementation site.
>>
>> Within the open-source StrongKey software we have, we require
>> two digital certificates to be configured for SKMS clients and
>> servers, to separate signing and encryption uses.  The test
>> certs we bundle with the FOSS, combines signing & encryption
>> merely as a convenience for people "kicking the tires".
>>
>> As a conservative practice, we recommend that PKIs separate
>> the signing and encryption capability into different digital
>> certificates.
>>
>> Arshad Noor
>> StrongAuth, Inc.
>>
>> Anders Rundgren wrote:
>>> Another reference is OASIS EKMI:
>>> http://www.oasis-open.org/committees/download.php/28657/SKSML-1.0-Specification-Non-Normative-DRAFT6.pdf
>>> From what I can deduct they indeed authenticate the requesting client through a signature and 
>>> then
>>> return the key by wrapping it by the public signature key.
>>>
> 

From: Stefan Santesson <[email-masked]>
To: pkix <[email-masked]>
Date: Wed, 5 Nov 2008 16:51:48 +0000
Subject: FINAL CALL: Call for agenda items, Philadelphia IETF
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_000_9F11911AED01D24BAA1C2355723C3D32195AC47236EAEXMSGC332eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have timeslot requests for the following PKIX work items:

*         Trust Anchor Management

*         Other certs extension

*         Clearance attribute and CA clearance constraints

*         PKI resource query protocol

*         RFC3281 updates

I still lack information if any editor wants to address the following WG it=
ems:

*         ECC Subject public key info

*         RFC 4055 update

*         New ASN.1 modules for PKIX

*         Algorithm identifiers for SHA2

*         Traceable anonymous certificates

I have no requests for additional topics.

REQUIRED ACTIONS:
Can someone from each lacking WG item please let me know if you want any ti=
me slot.
We are also still open for other potential topics on the agenda.
But I need all requests by the end of this week.

Thank you.

Stefan Santesson
Senior Program Manager

From: [email-masked] [mailto:[email-masked]] On=
 Behalf Of Stefan Santesson
Sent: den 20 februari 2008 18:05
To: pkix
Subject: Call for agenda items, Philadelphia IETF

Time to set the agenda for the Philadelphia PKIX meeting.

Anyone wanting a slot should send me an e-mail as soon as possible, no late=
r than EOD Wednesday next week (Feb 27).
As usual I want the lead editor for every current pkix draft to tell me if =
they want a slot or not.

We are currently scheduled as a Monday morning session from 0900-1130, whic=
h means two things.
1) We have 2.5 hours available which should be plenty of time.
2) We need to have everything set, including presentations sent to me by Su=
nday night.

Stefan Santesson
Senior Program Manager

--_000_9F11911AED01D24BAA1C2355723C3D32195AC47236EAEXMSGC332eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www=
.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoin=
t/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns=
:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile=
" xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns=
:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns=
:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http=
://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"ht=
tp://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z=3D"urn:s=
chemas-microsoft-com:" xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-=
html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1027682776;
	mso-list-type:hybrid;
	mso-list-template-ids:-1317393742 69009409 69009411 69009413 69009409 6900=
9411 69009413 69009409 69009411 69009413;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l1
	{mso-list-id:1397900729;
	mso-list-type:hybrid;
	mso-list-template-ids:635612220 69009409 69009411 69009413 69009409 690094=
11 69009413 69009409 69009411 69009413;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span lang=3DEN-US style=
=3D'color:
#1F497D'>I have timeslot requests for the following PKIX work items:<o:p></=
o:p></span></a></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo1'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>T=
rust
Anchor Management<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo1'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>O=
ther
certs extension<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo1'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>C=
learance
attribute and CA clearance constraints<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo1'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>P=
KI
resource query protocol<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1=
 lfo1'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>R=
FC3281
updates<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>I still lac=
k
information if any editor wants to address the following WG items:<o:p></o:=
p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>E=
CC Subject
public key info <o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>R=
FC 4055 update<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>N=
ew ASN.1
modules for PKIX<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>A=
lgorithm
identifiers for SHA2<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo2'><![if !supportLists]><span
lang=3DEN-US style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-=
list:Ignore'>&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'color:#1F497D'>T=
raceable
anonymous certificates<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>I have no r=
equests
for additional topics.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>REQUIRED AC=
TIONS:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Can someone=
 from each
lacking WG item please let me know if you want any time slot.<o:p></o:p></s=
pan></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>We are also=
 still
open for other potential topics on the agenda.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>But I need =
all
requests by the end of this week.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Thank you.<=
o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> [email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Stefan Santesson<=
br>
<b>Sent:</b> den 20 februari 2008 18:05<br>
<b>To:</b> pkix<br>
<b>Subject:</b> Call for agenda items, Philadelphia IETF<o:p></o:p></span><=
/p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US>Time to set the agenda for the Phil=
adelphia
PKIX meeting.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Anyone wanting a slot should send m=
e an
e-mail as soon as possible, no later than EOD Wednesday next week (Feb 27).=
<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>As usual I want the lead editor for=
 every
current pkix draft to tell me if they want a slot or not.<o:p></o:p></span>=
</p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>We are currently scheduled as a Mon=
day morning
session from 0900-1130, which means two things.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>1) We have 2.5 hours available whic=
h should
be plenty of time.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>2) We need to have everything set,
including presentations sent to me by Sunday night.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D32195AC47236EAEXMSGC332eu_--

From: "Anders Rundgren" <[email-masked]>
To: "Arshad Noor" <[email-masked]>
Cc: <[email-masked]>
Subject: SKSML Was: Signing and Encrypting with the same key?
Date: Wed, 5 Nov 2008 09:54:30 +0100
Sender: [email-masked]

Arshad,

Pardon my ignorance but I do not see how you can "abstract out" security solutions in a concrete 
SOAP specification, either it is there or it is not.  That is, with respect to the particular 
question and the current draft, you have no real alternative except stating that client and servers 
must be configured to support a common convention.  Which BTW may be exactly what you meant :-) 
That KeyGen2 is a 6-pass protocol is for avoiding conventions since the entities involved typically 
do not belong to the same "IT-domain".  E.g. a consumer with a mobile phone and his/her bank.

Regarding the separate key stuff, the current strategy is to support it in the protocol, but not in 
the Open Source client-implementation since no compelling argument actually has been raised for 
having multiple keys, while there is quite a bunch of arguments against such an arrangement.  How is 
an SKSML server supposed to know what to encrypt with if you do not send the key in the request?  It 
seems that an SKSML server must keep an encryption key database or be configured to use LDAP etc. 
It seems like a more straightforward solution to transfer encryption keys explicitly and validate 
them at receival in the same way as you do with signature and authentication keys.

I'm a bit puzzled regarding how you intend to bootstrap SKSML with PKI, if the figures with a myriad 
of entirely different clients are still valid.  The reason I started the KeyGen2 effort is because 
this is a veritable nightmare, particularly for mobile devices.  As a comparison I would like to 
mention the fact that there are some 100M TPM chips out there in major laptops, but they are "mostly 
of out work" because the bootstrapping issues haven't been fully addressed by the TPM designers.

Anders

----- Original Message ----- 
From: "Arshad Noor" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: "Timothy J. Miller" <[email-masked]>; "Peter Gutmann" <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, November 04, 2008 22:24
Subject: Re: Signing and Encrypting with the same key?

Hi Anders,

The reason we haven't mentioned it yet is because the TC is going
to begin the task of creating Implementation, Operations and Audit
Guidelines for EKMI only in 2009.  It is within these guidelines
where a recommendation for separating signing & encryption key-pairs
would be made.

The SKSML protocol focuses on the minimum necessary syntax to send
and receive messages related to symmetric-key management.  The
security, implementation, operations and audit of such Enterprise
Key Management Infrastructures must be capable of being abstracted
out of the protocol, layered and managed independently.  Which is
why there is no mention of separated key-pairs yet.  However, you
can expect to see it in the Guidelines next year.

Arshad Noor
StrongAuth, Inc.

Anders Rundgren wrote:
> Hi Arshad,
> I just skimmed through the non-normative spec and example and from that I could not see any
> mentioning of separate keys.
>
> I digged a bit further but could still not find such references in:
> http://www.oasis-open.org/committees/download.php/28725/SKSML-1.0-Specification-Normative-DRAFT6.0.pdf
>
> I don't know what you have planned, but IMO you need additional elements in the protocol (like
> giving the client a place to put its encryption key), as well as a standard for how encryption and
> signature keys link together otherwise the server cannot be sure that it is encrypting for the
> client that authenticated.  All this is the reason why I'm not overly enthusiastic of having
> multiple entity-keys in a provisioning protocol, particularly since all attacks I have heard about
> to date, have been based on flawed implementations, which is moderately interesting from a
> *protocol-design* point-of-view:
> http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html
>
> But it is possible that SKSML will run in more restricted environments than KeyGen2 and thus can
> build on that the client and servers use "conventions", keeping the protocol smallish.   KeyGen2 
> is
> designed to cope with a fragmented world and thus sports a capability/policy negotiation facility.
>
> Anders
>
> From: "Arshad Noor" <[email-masked]>
> To: "Anders Rundgren" <[email-masked]>
> Cc: "Timothy J. Miller" <[email-masked]>; "Peter Gutmann" <[email-masked]>;
> <[email-masked]>
> Sent: Tuesday, November 04, 2008 21:11
> Subject: Re: Signing and Encrypting with the same key?
>
>
> Anders,
>
> Just to clarify, the SKSML protocol does not mandate how the
> digital certificate of SKMS clients and servers should be
> constructed, or what the keyUsage extension should look like
> within such certificates.  We believe that that is an
> implementation detail of the PKI that supports the SKMS.
>
> The SKMS only requires that every client and server have a
> signing key and an encryption key.  They can be the same
> key-pair or two different key-pairs, depending on the PKI
> certificate policy of the implementation site.
>
> Within the open-source StrongKey software we have, we require
> two digital certificates to be configured for SKMS clients and
> servers, to separate signing and encryption uses.  The test
> certs we bundle with the FOSS, combines signing & encryption
> merely as a convenience for people "kicking the tires".
>
> As a conservative practice, we recommend that PKIs separate
> the signing and encryption capability into different digital
> certificates.
>
> Arshad Noor
> StrongAuth, Inc.
>
> Anders Rundgren wrote:
>> Another reference is OASIS EKMI:
>> http://www.oasis-open.org/committees/download.php/28657/SKSML-1.0-Specification-Non-Normative-DRAFT6.pdf
>> From what I can deduct they indeed authenticate the requesting client through a signature and 
>> then
>> return the key by wrapping it by the public signature key.
>>
>

Date: Tue, 04 Nov 2008 13:24:28 -0800
From: Arshad Noor <[email-masked]>
Organization: StrongAuth, Inc.
To: Anders Rundgren <[email-masked]>
CC: "Timothy J. Miller" <[email-masked]>, Peter Gutmann <[email-masked]>, [email-masked]
Subject: Re: Signing and Encrypting with the same key?
Sender: [email-masked]

Hi Anders,

The reason we haven't mentioned it yet is because the TC is going
to begin the task of creating Implementation, Operations and Audit
Guidelines for EKMI only in 2009.  It is within these guidelines
where a recommendation for separating signing & encryption key-pairs
would be made.

The SKSML protocol focuses on the minimum necessary syntax to send
and receive messages related to symmetric-key management.  The
security, implementation, operations and audit of such Enterprise
Key Management Infrastructures must be capable of being abstracted
out of the protocol, layered and managed independently.  Which is
why there is no mention of separated key-pairs yet.  However, you
can expect to see it in the Guidelines next year.

Arshad Noor
StrongAuth, Inc.

Anders Rundgren wrote:
> Hi Arshad,
> I just skimmed through the non-normative spec and example and from that I could not see any
> mentioning of separate keys.
> 
> I digged a bit further but could still not find such references in:
> http://www.oasis-open.org/committees/download.php/28725/SKSML-1.0-Specification-Normative-DRAFT6.0.pdf
> 
> I don't know what you have planned, but IMO you need additional elements in the protocol (like 
> giving the client a place to put its encryption key), as well as a standard for how encryption and 
> signature keys link together otherwise the server cannot be sure that it is encrypting for the 
> client that authenticated.  All this is the reason why I'm not overly enthusiastic of having 
> multiple entity-keys in a provisioning protocol, particularly since all attacks I have heard about 
> to date, have been based on flawed implementations, which is moderately interesting from a 
> *protocol-design* point-of-view:
> http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html
> 
> But it is possible that SKSML will run in more restricted environments than KeyGen2 and thus can 
> build on that the client and servers use "conventions", keeping the protocol smallish.   KeyGen2 is 
> designed to cope with a fragmented world and thus sports a capability/policy negotiation facility.
> 
> Anders
> 
> From: "Arshad Noor" <[email-masked]>
> To: "Anders Rundgren" <[email-masked]>
> Cc: "Timothy J. Miller" <[email-masked]>; "Peter Gutmann" <[email-masked]>; 
> <[email-masked]>
> Sent: Tuesday, November 04, 2008 21:11
> Subject: Re: Signing and Encrypting with the same key?
> 
> 
> Anders,
> 
> Just to clarify, the SKSML protocol does not mandate how the
> digital certificate of SKMS clients and servers should be
> constructed, or what the keyUsage extension should look like
> within such certificates.  We believe that that is an
> implementation detail of the PKI that supports the SKMS.
> 
> The SKMS only requires that every client and server have a
> signing key and an encryption key.  They can be the same
> key-pair or two different key-pairs, depending on the PKI
> certificate policy of the implementation site.
> 
> Within the open-source StrongKey software we have, we require
> two digital certificates to be configured for SKMS clients and
> servers, to separate signing and encryption uses.  The test
> certs we bundle with the FOSS, combines signing & encryption
> merely as a convenience for people "kicking the tires".
> 
> As a conservative practice, we recommend that PKIs separate
> the signing and encryption capability into different digital
> certificates.
> 
> Arshad Noor
> StrongAuth, Inc.
> 
> Anders Rundgren wrote:
>> Another reference is OASIS EKMI:
>> http://www.oasis-open.org/committees/download.php/28657/SKSML-1.0-Specification-Non-Normative-DRAFT6.pdf
>> From what I can deduct they indeed authenticate the requesting client through a signature and then
>> return the key by wrapping it by the public signature key.
>>
> 

From: "Anders Rundgren" <[email-masked]>
To: "Arshad Noor" <[email-masked]>
Cc: "Timothy J. Miller" <[email-masked]>, "Peter Gutmann" <[email-masked]>, <[email-masked]>
Subject: Re: Signing and Encrypting with the same key?
Date: Tue, 4 Nov 2008 22:08:01 +0100
Sender: [email-masked]

Hi Arshad,
I just skimmed through the non-normative spec and example and from that I could not see any
mentioning of separate keys.

I digged a bit further but could still not find such references in:
http://www.oasis-open.org/committees/download.php/28725/SKSML-1.0-Specification-Normative-DRAFT6.0.pdf

I don't know what you have planned, but IMO you need additional elements in the protocol (like 
giving the client a place to put its encryption key), as well as a standard for how encryption and 
signature keys link together otherwise the server cannot be sure that it is encrypting for the 
client that authenticated.  All this is the reason why I'm not overly enthusiastic of having 
multiple entity-keys in a provisioning protocol, particularly since all attacks I have heard about 
to date, have been based on flawed implementations, which is moderately interesting from a 
*protocol-design* point-of-view:
http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html

But it is possible that SKSML will run in more restricted environments than KeyGen2 and thus can 
build on that the client and servers use "conventions", keeping the protocol smallish.   KeyGen2 is 
designed to cope with a fragmented world and thus sports a capability/policy negotiation facility.

Anders

----- Original Message ----- 
From: "Arshad Noor" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: "Timothy J. Miller" <[email-masked]>; "Peter Gutmann" <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, November 04, 2008 21:11
Subject: Re: Signing and Encrypting with the same key?

Anders,

Just to clarify, the SKSML protocol does not mandate how the
digital certificate of SKMS clients and servers should be
constructed, or what the keyUsage extension should look like
within such certificates.  We believe that that is an
implementation detail of the PKI that supports the SKMS.

The SKMS only requires that every client and server have a
signing key and an encryption key.  They can be the same
key-pair or two different key-pairs, depending on the PKI
certificate policy of the implementation site.

Within the open-source StrongKey software we have, we require
two digital certificates to be configured for SKMS clients and
servers, to separate signing and encryption uses.  The test
certs we bundle with the FOSS, combines signing & encryption
merely as a convenience for people "kicking the tires".

As a conservative practice, we recommend that PKIs separate
the signing and encryption capability into different digital
certificates.

Arshad Noor
StrongAuth, Inc.

Anders Rundgren wrote:
>
> Another reference is OASIS EKMI:
> http://www.oasis-open.org/committees/download.php/28657/SKSML-1.0-Specification-Non-Normative-DRAFT6.pdf
> From what I can deduct they indeed authenticate the requesting client through a signature and then
> return the key by wrapping it by the public signature key.
>

Date: Tue, 04 Nov 2008 12:11:37 -0800
From: Arshad Noor <[email-masked]>
Organization: StrongAuth, Inc.
To: Anders Rundgren <[email-masked]>
CC: "Timothy J. Miller" <[email-masked]>, Peter Gutmann <[email-masked]>, [email-masked]
Subject: Re: Signing and Encrypting with the same key?
Sender: [email-masked]

Anders,

Just to clarify, the SKSML protocol does not mandate how the
digital certificate of SKMS clients and servers should be
constructed, or what the keyUsage extension should look like
within such certificates.  We believe that that is an
implementation detail of the PKI that supports the SKMS.

The SKMS only requires that every client and server have a
signing key and an encryption key.  They can be the same
key-pair or two different key-pairs, depending on the PKI
certificate policy of the implementation site.

Within the open-source StrongKey software we have, we require
two digital certificates to be configured for SKMS clients and
servers, to separate signing and encryption uses.  The test
certs we bundle with the FOSS, combines signing & encryption
merely as a convenience for people "kicking the tires".

As a conservative practice, we recommend that PKIs separate
the signing and encryption capability into different digital
certificates.

Arshad Noor
StrongAuth, Inc.

Anders Rundgren wrote:
> 
> Another reference is OASIS EKMI:
> http://www.oasis-open.org/committees/download.php/28657/SKSML-1.0-Specification-Non-Normative-DRAFT6.pdf
> From what I can deduct they indeed authenticate the requesting client through a signature and then
> return the key by wrapping it by the public signature key.
> 

Content-class: urn:content-classes:message
Subject: RE: Comments on the TA requirements document
Date: Mon, 3 Nov 2008 17:39:13 -0500
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C93E04.FEA9D2D6
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Stefan,

=20

I can understand a distinction between "what must be done" and "how to
do it".  I can also draw a correlation between the XCCDF language that
specifies security configuration checklists and the OVAL language that
supports platform-dependent execution and reporting for checklist items
(http://scap.nist.gov).  What I don't understand is how:

=20

3.3.1.  Functional Requirements

=20

   A protocol for TA management must allow a TA management transaction

   to be directed to:

=20

      All TA stores for which the manager is responsible

      An enumerated list of one or more groups of trust anchor stores

      An individual trust anchor store

=20

would be considered to favor combined specification/execution over
separate specification of what to keys to trust and how to obtain them.
Would it help if it said "A protocol *suite* for TA management ..." to
encompass the possibility of multiple languages / stages of execution?

=20

(It may not be immediately obvious that PKIX is the correct WG to
develop a TAM suite if the end product would be implemented under SCAP,
but the TA-specific expertise is undeniably in this group.)

=20

Dave

=20

=20

From: Stefan Santesson [mailto:[email-masked]]=20
Sent: Friday, October 24, 2008 10:48 PM
To: Kemp, David P.; [email-masked]
Subject: RE: Comments on the TA requirements document

=20

Dave

=20

This is not a matter of transport protocol. This is a matter of how you
manage policies and what protocols you need to support both management
and execution of these policies.

=20

The current requirement document mix together policy management and
policy execution in one bucket for TA management.

=20

The policy management part deals with ensuring that all hosts knows what
keys they are allowed to trust.

The policy execution part deals with obtaining the keys and parameters
associated with managed policies and to put them in use in a compliant
manner.

=20

Policy management is always initiated and managed centrally and pushed
down to users/hosts, or at least enforced upon users/hosts in some way
or another. There are many ways to do this, but it always involves some
kind of central management. One way to do this that is very common in my
world, is to use a directory as the central mechanism to publish
policies combined with other functions (like system health checks) to
make sure hat policies has been downloaded and implemented. In these
common cases, there is no need for any new protocol.

=20

Policy execution is something that is carried out by the user/host,
based on the centrally distributed policy. One part of policy execution
in this case is to obtain/download the TAs that are considered
trustworthy by the distributed policy. Since the user/host is in control
and thus responsible for policy execution, they can also "pull" down any
key data associated with the TA policy. The only thing they would need
in order to do that, is a common data format for TA keys and their
parameters, signed by some kind of "master" TA policy management key.
That common data format for TA key information is all I currently need.

We may convince ourselves that we can make a central manager in control
of policy execution on behalf of users/hosts if we write a super smart
protocol (like PKIX TAM), but that would be an illusion. To some extent
we will always need to trust the user/host to carry out the policy in an
appropriate manner.

=20

This is the world I'm coming from when approaching this subject. When I
read the req document for TA management I do not recognize any protocol
that fit the needs of my environment.=20

This is why I have problems providing constructive feedback on it.

=20

=20

Stefan Santesson

Senior Program Manager

=20

------_=_NextPart_001_01C93E04.FEA9D2D6
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:st=3D"&#1;" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.h41
	{mso-style-name:h41;
	font-family:"Courier New";
	font-weight:bold;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle24
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle25
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Stefan,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>I can understand a =
distinction
between &#8220;what must be done&#8221; and &#8220;how to do =
it&#8221;.&nbsp; I can also draw a correlation
between the XCCDF language that specifies security configuration =
checklists and
the OVAL language that supports platform-dependent execution and =
reporting for
checklist items (http://scap.nist.gov).&nbsp; What I don&#8217;t =
understand is how:<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier New"'>3.3.1.&nbsp;
Functional Requirements</span></b><span lang=3DEN =
style=3D'font-size:12.0pt;
font-family:"Courier New"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
A protocol for TA management must allow a TA management =
transaction<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
to be directed to:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
All TA stores for which the manager is responsible<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
An enumerated list of one or more groups of trust anchor =
stores<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
An individual trust anchor store<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>would be considered =
to favor
combined specification/execution over separate specification of what to =
keys to
trust and how to obtain them.&nbsp; &nbsp;Would it help if it said =
&#8220;A protocol *<b>suite</b>*
for TA management &#8230;&#8221; to encompass the possibility of =
multiple languages /
stages of execution?<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>(It may not be =
immediately
obvious that PKIX is the correct WG to develop a TAM suite if the end =
product would
be implemented under SCAP, but the TA-specific expertise is undeniably =
in this
group.)<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Dave<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Stefan =
Santesson
[mailto:[email-masked]] <br>
<b>Sent:</b> Friday, October 24, 2008 10:48 PM<br>
<b>To:</b> Kemp, David P.; [email-masked]<br>
<b>Subject:</b> RE: Comments on the TA requirements =
document<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span =
style=3D'color:#1F497D'>Dave</span></a><span
style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>This is not a matter =
of
transport protocol. This is a matter of how you manage policies and what
protocols you need to support both management and execution of these =
policies.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The current =
requirement document
mix together policy management and policy execution in one bucket for TA
management.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The policy management =
part deals
with ensuring that all hosts knows what keys they are allowed to =
trust.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The policy execution =
part deals
with obtaining the keys and parameters associated with managed policies =
and to
put them in use in a compliant manner.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Policy management is =
always
initiated and managed centrally and pushed down to users/hosts, or at =
least
enforced upon users/hosts in some way or another. There are many ways to =
do
this, but it always involves some kind of central management. One way to =
do
this that is very common in my world, is to use a directory as the =
central
mechanism to publish policies combined with other functions (like system =
health
checks) to make sure hat policies has been downloaded and implemented. =
In these
common cases, there is no need for any new =
protocol.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Policy execution is =
something
that is carried out by the user/host, based on the centrally distributed
policy. One part of policy execution in this case is to obtain/download =
the TAs
that are considered trustworthy by the distributed policy. Since the =
user/host
is in control and thus responsible for policy execution, they can also =
&#8220;pull&#8221;
down any key data associated with the TA policy. The only thing they =
would need
in order to do that, is a common data format for TA keys and their =
parameters,
signed by some kind of &#8220;master&#8221; TA policy management key. =
That common data
format for TA key information is all I currently =
need.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>We may convince =
ourselves that
we can make a central manager in control of policy execution on behalf =
of
users/hosts if we write a super smart protocol (like PKIX TAM), but that =
would
be an illusion. To some extent we will always need to trust the =
user/host to
carry out the policy in an appropriate manner.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>This is the world =
I&#8217;m coming
from when approaching this subject. When I read the req document for TA
management I do not recognize any protocol that fit the needs of my
environment. <o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>This is why I have =
problems
providing constructive feedback on it.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif";color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:"Times New =
Roman","serif";color:navy'><o:p></o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif";color:#400040'>Windows Security, =
Standards</span></b><span
style=3D'color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

</div>

</body>

</html>

------_=_NextPart_001_01C93E04.FEA9D2D6--

Content-class: urn:content-classes:message
Subject: RE: Processing rules for non-critical extensions (Re: Rationales for CA clearance constraints)
Date: Mon, 3 Nov 2008 17:03:09 -0500
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

CAs and application developers look to X.509 to understand the meaning
of an extension.  If a hypothetical discussion resulted in consensus to
change X.509's treatment of name constraints to not depend on
criticality, then a [non-PKIX] CA's decision to mark name constraints
non-critical would be based on the behavior described in the new X.509.

My "assumption" is of course contrary to X.509, otherwise there would be
no basis for a proposed change.  From 5280:

   If a name constraints extension that is marked as critical
   imposes constraints on a particular name form, and an instance of
   that name form appears in the subject field or subjectAltName
   extension of a subsequent certificate, then the application MUST
   either process the constraint or reject the certificate.

This does not say that *any* unsupported constraint would reject the
certificate, only an unsupported constraint on any subject name form
used in the path.  An application that *uses* a name form (for example,
dNSName) must be able to understand that name form, and arguably should
be required to also support constraints on that name form (where
constraints can be defined).  For name forms that appear in the cert
path but are ignored by the application, constraints are trivially
"processed" and satisfied without any explicit action.

So the argument to the X.500 WG would be that for a critical or
non-critical nameConstraints, the "best" course of action would be
similar to (1) below: reject the certificate since it cannot process
every element of the extension that (a) applies to any subject of a
subsequent certificate that (b) is used by the application.
Why would any CA believe it worthwhile to specify constraints that
applications are permitted to selectively enforce?

Am I planning to propose such a change?  No.  But if a discussion of
criticality happened to occur, I would advocate the position of equal
treatment.

Dave

-----Original Message-----

> Thus a client that can process nameConstraints on some name forms but=20
> that encounters a non-critical nameConstraints extension with a name=20
> form that it cannot process must do one of the following: (1) reject
the=20
> certificate since it cannot process every element of the extension;
(2)=20
> ignore the extension entirely; or (3) process the extension to the=20
> degree possible and ignore the presence of the name forms that it
cannot=20
> process.  Option (3) is the one specified by X.509.  Isn't it also the

> option that most closely aligns with the CA's intention in marking the

> extension non-critical?

Date: Mon, 03 Nov 2008 15:04:02 -0500
From: "David A. Cooper" <[email-masked]>
To: "Kemp, David P." <[email-masked]>
CC: [email-masked]
Subject: Processing rules for non-critical extensions (Re: Rationales for CA clearance constraints)
Sender: [email-masked]

Kemp, David P. wrote:
> Dave C,
>
> I start with the assumption that an extension marked critical must be
> processed identically to an extension marked non-critical if it is
> processed at all, and that processing requirements that refer to
> criticality are therefore incorrect.  Name constraints has two such
> statements (here is one) ...
>   
David,

You may choose to start with this assumption, but as I noted in my 
previous email, this is contrary to X.509, which specifically allows 
(requires) clients to ignore some unknown elements in a non-critical 
extension but not in a critical extension:

  If unknown elements appear within the extension, and the extension
  is not marked critical, those unknown elements shall be ignored
  according to the rules of extensibility documented in 12.2.2 in
  ITU-T Rec. X.519 | ISO/IEC 9594-5.

I do not understand your logic below with respect to the nameConstraints 
extension.  You proposed the following text:
  
   A certificate-using system MUST reject the certificate if it
   encounters a critical extension that it cannot process.  If a
   certificate-using system encounters a non-critical extension,
   it MUST either process the extension as if it were marked
   critical or ignore the extension entirely.

As I interpret this, a client that encounters a non-critical 
nameConstraints extension that includes a name form that it cannot 
process MUST ignore the extension entirely since it cannot process the 
extension as if it were marked critical.   Below you seem to be 
proposing, for the nameConstraints extension, that clients should be 
required to process a non-critical nameConstraints extension as if it 
were critical.  This would mean that a client that can process name 
constraints for some name forms would be required to reject a 
certificate if it encountered a non-critical nameConstraints extension 
that included a name form that it could not process even though a client 
that did not recognize the OID for the nameConstraints extension at all 
would be permitted to accept the certificate.  Not only does this seem 
to be contrary to the idea behind allowing an extension to be marked 
non-critical, it directly contradicts X.509.  Unlike RFC 5280, X.509 
specifically allows for the nameConstraints extension to be marked 
non-critical and it includes the following text:

   Conformant implementations are not required to recognize
   all possible name forms. If the extension is flagged critical
   and a certificate-using implementation does not recognize
   a name form used in any base component, the certificate
   shall be handled as if an unrecognized critical extension
   had been encountered. If the extension is flagged
   non-critical and a certificate-using implementation does
   not recognize a name form used in any base component,
   then that subtree may be ignored.

>    If a name constraints extension that is marked as critical
>    imposes constraints on a particular name form, and an instance of
>    that name form appears in the subject field or subjectAltName
>    extension of a subsequent certificate, then the application MUST
>    either process the constraint or reject the certificate.
>
> ... and conforming CAs MUST mark name constraints as critical.  If an
> application finds a non-critical name constraints and a path contains
> SANs using dNSname form and the application cannot process that form,
> then it is better to reject the certificate than to constrain subject DN
> while allowing dNSname to pass unconstrained.  Under what circumstances
> would it ever be a good thing to process some name constraints while
> silently ignoring others?

Under what circumstances would it be a good thing to ignore all name 
constraints simply because some cannot be processed?  Remember that we 
are only considering the case in which the CA has chosen to mark the 
extension non-critical.  The fact that RFC 5280 states that conforming 
CAs must always mark the extension as critical is irrelevant as is any 
discussion of whether it ever makes sense for a CA to mark the extension 
non-critical.  If the CA has chosen to mark the extension non-critical, 
then it is indicating that it does not wish to require clients to reject 
the certificate simply because they that cannot process the extension.  
Thus a client that can process nameConstraints on some name forms but 
that encounters a non-critical nameConstraints extension with a name 
form that it cannot process must do one of the following: (1) reject the 
certificate since it cannot process every element of the extension; (2) 
ignore the extension entirely; or (3) process the extension to the 
degree possible and ignore the presence of the name forms that it cannot 
process.  Option (3) is the one specified by X.509.  Isn't it also the 
option that most closely aligns with the CA's intention in marking the 
extension non-critical?

> To answer your last question below, "no".  But the same behavior
> (processing what it can and ignoring the rest) should be required where
> appropriate (as with AIA and EKU) if the extension is marked critical.
> Name constraints should be fixed so that the appropriate behavior
> (constrain all present subject names or reject) is required even if the
> constraint is non-critical.
>   

Isn't this essentially saying that the profile should override the 
express wishes of the issuing CA since you believe the CA must have been 
mistaken in choosing the mark the extension non-critical?

Dave

From: "Anders Rundgren" <[email-masked]>
To: "Timothy J. Miller" <[email-masked]>
Cc: "Peter Gutmann" <[email-masked]>, <[email-masked]>
Subject: Re: Signing and Encrypting with the same key?
Date: Mon, 3 Nov 2008 16:31:14 +0100
Sender: [email-masked]

<snip>
>That depends on the *other* uses to which that key can be put, doesn't
>it?  If it's only used for bootstrapping, there's no escrow requirement.
>  But if the device API allows it to be accessed for other uses...?

Tim,
I believe we are practically on the same page now :-)

The intention with the described scheme is that the device encryption key (be it specific or 
"universal") should not be exposed in the general pool of keys, but be limited to key-provisioning.

That it might be hard to thwart misuse in some operating systems is true, but for the primary target 
mobile phones, I don't expect any real problems since these systems anyway must support a more 
granular way of identifying software and capabilities, due to the lack of the concept User, Guest or 
Administrator when operating in the consumer space.  In practical terms that means that a software 
that wants to provision keys must be declared with that capability which in turn will require that 
it is signed by an external clearing house (or device vendor) rather than by a developer.

An app that "only" wants to use user-keys, probably will not need external signing, unless it wants 
to use keys in "silent mode", something that the key-provisioning system also can deal with on a 
per-key basis.

Oops, I slided off the core subject a bit, but you get the point; this is a [rather small but 
crucial] piece of a huge and quite interesting puzzle that a large number of people is working with, 
and mostly in a completely unsynchronized way...

Regards
Anders 

Date: Mon, 3 Nov 2008 08:55:54 -0600
From: "Timothy J. Miller" <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: Peter Gutmann <[email-masked]>, [email-masked]
Subject: Re: Signing and Encrypting with the same key?
Sender: [email-masked]

--------------ms050203050809050700000408
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Anders Rundgren wrote:

> The reason for having key escrow is to recover lost data.

Correct.

> If you feel that key-import (bootstrapping) keys also should be escrowable, I encourage you to 
> interact with these guys:

That depends on the *other* uses to which that key can be put, doesn't 
it?  If it's only used for bootstrapping, there's no escrow requirement. 
  But if the device API allows it to be accessed for other uses...?

-- Tim

--------------ms050203050809050700000408
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms050203050809050700000408--

From: "Anders Rundgren" <[email-masked]>
To: "Timothy J. Miller" <[email-masked]>
Cc: "Peter Gutmann" <[email-masked]>, <[email-masked]>
Subject: Re: Signing and Encrypting with the same key?
Date: Mon, 3 Nov 2008 15:43:46 +0100
Sender: [email-masked]

Tim,
The reason for having key escrow is to recover lost data.

If you feel that key-import (bootstrapping) keys also should be escrowable, I encourage you to 
interact with these guys:
https://www.trustedcomputinggroup.org/specs/TPM
Since they need a whopping 700 pages just for describing the API, they should be able to cope *any* 
requirement.

Another reference is OASIS EKMI:
http://www.oasis-open.org/committees/download.php/28657/SKSML-1.0-Specification-Non-Normative-DRAFT6.pdf
>From what I can deduct they indeed authenticate the requesting client through a signature and then
return the key by wrapping it by the public signature key.

Anders

----- Original Message ----- 
From: "Timothy J. Miller" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: "Peter Gutmann" <[email-masked]>; <[email-masked]>
Sent: Monday, November 03, 2008 15:08
Subject: Re: Signing and Encrypting with the same key?

Anders Rundgren wrote:

> There appears to be three possibilities for this position.

> 2. Encryption keys may be backed-up while signature keys may not

This is the NIST rationale, as I've understood it from 800-57's authors.

> Point #2 don't apply to device-keys.

That's an unwarranted assumption.  If the device key is used for
encryption, then there's very likely a compelling enterprise need to
escrow that key.

-- Tim

Content-class: urn:content-classes:message
Subject: RE: Signing and Encrypting with the same key?
Date: Mon, 3 Nov 2008 09:32:07 -0500
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

There are several reasons due to which device keys are generally not
escrowed.

They are used in real-time communications which need not be recovered
(unlike e-mail).

The same key is used for both signing and encrypting.

The key may be used in cryptographic protocols that provide perfect
forward secrecy, rendering the escrow of the device key useless.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Timothy J. Miller
Sent: Monday, November 03, 2008 9:08 AM
To: Anders Rundgren
Cc: Peter Gutmann; [email-masked]
Subject: Re: Signing and Encrypting with the same key?

Anders Rundgren wrote:

> There appears to be three possibilities for this position.

> 2. Encryption keys may be backed-up while signature keys may not

This is the NIST rationale, as I've understood it from 800-57's authors.

> Point #2 don't apply to device-keys.

That's an unwarranted assumption.  If the device key is used for=20
encryption, then there's very likely a compelling enterprise need to=20
escrow that key.

-- Tim

Date: Mon, 3 Nov 2008 08:08:28 -0600
From: "Timothy J. Miller" <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: Peter Gutmann <[email-masked]>, [email-masked]
Subject: Re: Signing and Encrypting with the same key?
Sender: [email-masked]

--------------ms000704010900040405060202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Anders Rundgren wrote:

> There appears to be three possibilities for this position.

> 2. Encryption keys may be backed-up while signature keys may not

This is the NIST rationale, as I've understood it from 800-57's authors.

> Point #2 don't apply to device-keys.

That's an unwarranted assumption.  If the device key is used for 
encryption, then there's very likely a compelling enterprise need to 
escrow that key.

-- Tim

--------------ms000704010900040405060202
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms000704010900040405060202--

From: "Erik Andersen" <[email-masked]>
To: <[email-masked]>
Subject: RE: Edition 6 of X.500, including X.509
Date: Mon, 3 Nov 2008 13:30:39 +0100
Importance: Normal
Sender: [email-masked]

Hi Peter,

Do not confuse versions with editions. You still write X.509v3 when
referring to Version 3 of certs. A new edition may change or a lot of =
things
without touching the structure of a certificate, e.g.; add new =
extensions.

Regards,

Erik Andersen
Andersen's L-Service
Elsevej 48, DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
email: [email-masked]
www.x500.eu
www.x500standard.com
=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] =
On
Behalf Of Peter Gutmann
Sent: 2. november 2008 04:18
To: [email-masked]; [email-masked]
Subject: Re: Edition 6 of X.500, including X.509

"Erik Andersen" <[email-masked]> writes:

>This is just to make you aware that the sixth edition of X.509 is =
competed
>from the editor's hand. X.509 now includes federated PMI and several
>corrections as documented in two corrigenda to the fifth edition.

A slightly off-topic question, but how does one refer to this?  X.509
version=20
6?  X.509v3 revision 6?  X.509v3.6?

Peter.

From: "Anders Rundgren" <[email-masked]>
To: "Manger, James H" <[email-masked]>, <[email-masked]>
Subject: Re: Signing and Encrypting with the same key?
Date: Mon, 3 Nov 2008 09:38:51 +0100
Sender: [email-masked]

James,
Thank you for the MMA references!

Although I'm not an expert in cryptography (which is the reason I asked for assistance from the 
crypto collective), I have based on published reports found that the mentioned algorithm still is 
used by most TLS implementations because the MMA attacks were enabled by somewhat "unsuspicious" 
server code which subsequently has been corrected, right?

In the use-case I have described (which is very different to TLS), there is as I have pointed out, 
no persistent data whatsoever to encrypt or sign, which (in my maybe overly naive world), should 
make a difference.

In addition, the key in question would during its life-time seldom or never exceed a few thousand 
uses because there is a limit to how many web-sites a user finds worth signing up to.  Yes, this 
piece (of junk?) is the first serious stab at retiring passwords as the primary authentication 
mechanism on the web by hosting all your credentials (except for a few specials like PIV)  in an 
NFC/WLAN-connected mobile phone.  I.e. it is a de-facto standard in early preparation, intended to 
be rolled-out in the same way as Microsoft has done with their brilliant Information Card 
initiative.  The scheme is of course fully compliant with Information Cards as well since fighting 
Microsoft is neither fun, nor possible.  That Microsoft is also experimenting with supporting 
virtual credit-cards doesn't make things less interesting.

The reason why I raised this open question is that multiple keys for user-key bootstrapping would 
effectively require standardization of associated certificates as well in order to regardless of 
operation, uniquely identify the crypto device.  Although indeed quite feasible, a multi-key 
approach greatly complicates the scheme and based on hands-on experience with Internet standards 
since 1995, I see that complexity is a major source to failure.  Less actually seems to be more :-)

Anders Rundgren

----- Original Message ----- 
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 03, 2008 00:48
Subject: RE: Signing and Encrypting with the same key?

Anders,

Daniel Bleichenbacher's "million message attack" showed how RSA encryption according to PKCS#1 v1.5 
block-type 2 padding could be attacked by sending about a million chosen ciphertexts to a TLS (eg 
HTTPS) server. The result was recovery of one encrypted session key.

A variation on the attack allows a signature to be forged. An attacker chooses the message they want 
signed, sends about a million ciphertexts to a TLS server, and by watching the responses can forge 
the signature.

This attack showed that a weakness in an encryption algorithm can lead to exploits against a 
signature algorithm (that was otherwise "safe") if the same key is used with both.

James Manger

See RFC 3218 "Preventing the Million Message Attack on CMS" -- though it does not discuss the 
signature-forging aspect.

From: "Eduard Formanek" <[email-masked]>
To: <[email-masked]>
Subject: serialNumber in Subject
Date: Mon, 3 Nov 2008 09:15:39 +0100
Sender: [email-masked]

Toto je zprava s vmce hastmi ve formatu MIME.

------=_NextPart_000_000D_01C93D94.BD256B10
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello,

It is possible to have the multiple appearance of the atribut serialNumber
in issuer/subject names (RFC5280,  Section 4.1.2.4) ?

Thank you very much for your answer.

Eda

------=_NextPart_000_000D_01C93D94.BD256B10
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.StylE-mailovZprvy17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DCS link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>Hello,<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>It is possible to have the multiple appearance of =
the atribut
serialNumber in issuer/subject names <span lang=3DEN-US>(RFC5280, =
&nbsp;</span>Section
4.1.2.4<span lang=3DEN-US>)</span><span lang=3DEN-US> =
</span>?<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Thank you very much for your answer.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Eda<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

 <BR><BR>__________ Informace od ESET NOD32 Antivirus, verze databaze =
3576 (20081102) __________<BR><BR>Tuto zpravu proveril ESET NOD32 =
Antivirus.<BR><BR><A =
HREF=3D"http://www.eset.cz">http://www.eset.cz</A><BR> </body>

</html>

------=_NextPart_000_000D_01C93D94.BD256B10--

From: "Manger, James H" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 3 Nov 2008 10:48:01 +1100
Subject: RE: Signing and Encrypting with the same key?
Accept-Language: en-US, en-AU
acceptlanguage: en-US, en-AU
Sender: [email-masked]

From: "Anders Rundgren" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>
Subject: Re: Signing and Encrypting with the same key?
Date: Sun, 2 Nov 2008 10:11:04 +0100
Sender: [email-masked]

Peter,
If we put implementation errors aside and only look on the mathematical side of things, could you
please comment on the following?

First the use-case:  This discussion is about the possible (mis) use of a single embedded (device)
private key in a cryptographic container along the lines shown in this document:
http://keycenter.webpki.org/javadoc/keystore/phone/keystore/crypto/VirtualSE.html
http://webpki.org/papers/keygen2/keygen-all-protocol-steps.html

Thesis: "You shouldn't use a signing key for encryption" which is (with other wording) stated in
NIST's SP 800-57.

There appears to be three possibilities for this position.
1. Signatures could be forged and/or private keys could be revealed
2. Encryption keys may be backed-up while signature keys may not
3. Encrypted data could be exposed in clear

We can safely drop #1 since there is no way you can prevent somebody from encrypting arbitrary data
with a public signature key.  If there actually is a problem here, we might as well quit using PKI
altogether!

Point #2 don't apply to device-keys.

So the remaining issue must be that encrypted data could be exposed in some way by "correlating"
encrypted data with signed data, right?

Why I am not that worried?  Well,

C1.  Signed and encrypted input data in KeyGen2 is always padded with PKCS 1 which means that the
raw decryption and encryption algorithms never operate on the same data even when the original data
actually is identical (see C2 and C3)

C2.  There is no correlation whatsoever between signed and encrypted input data in KeyGen2

C3.  Signed and encrypted input data in KeyGen2 requires crypto-level entropy making any kind of
correlation infeasible for practical purposes.  In fact, if the entropy is low, the integrity of the
whole scheme is jeopardized irrespective of other issues

P1.  Although a slightly lamer argument, in most (if not all) cases communications would take place
over HTTPS further reducing "leakage" and attack space

P2.  That many existing PKIs rely on universal keys, including VeriSign's e-mail PKI, is maybe not a
strong technical argument, but shows that commercial PKI vendors as well as enterprises are
concerned about the additional "fuzz" multiple keys introduce.

C = Crypto, P = Practice

Comments are welcome!  I don't claim to have all the answers, but quite a few questions...

Regards
Anders R
----- Original Message ----- 
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Sunday, November 02, 2008 04:14
Subject: Re: Signing and Encrypting with the same key?

Julien Stern <[email-masked]> writes:

>As far as I remember, there are no known attacks, but there aren't any
>proofs that it does not weaken security (actually, I believe someone
>published a paper with some hints that there may be a theoretical
>weakness, but that was really long time ago, maybe someone else would know).

There are a pile of fault attacks (that's including inadvertent memory
corruption in the category of "attacks", so it's something that can happen
without any overt attack) that will leak the private key on signing but not on
decrypt, so technically there are known attacks that'll exploit the same key
being used for signing and decryption.

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Edition 6 of X.500, including X.509
Date: Sun, 02 Nov 2008 16:18:25 +1300
Sender: [email-masked]

"Erik Andersen" <[email-masked]> writes:

>This is just to make you aware that the sixth edition of X.509 is competed
>from the editor's hand. X.509 now includes federated PMI and several
>corrections as documented in two corrigenda to the fifth edition.

A slightly off-topic question, but how does one refer to this?  X.509 version 
6?  X.509v3 revision 6?  X.509v3.6?

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Signing and Encrypting with the same key?
Date: Sun, 02 Nov 2008 16:14:40 +1300
Sender: [email-masked]

Julien Stern <[email-masked]> writes:

>As far as I remember, there are no known attacks, but there aren't any 
>proofs that it does not weaken security (actually, I believe someone 
>published a paper with some hints that there may be a theoretical 
>weakness, but that was really long time ago, maybe someone else would know).

There are a pile of fault attacks (that's including inadvertent memory 
corruption in the category of "attacks", so it's something that can happen 
without any overt attack) that will leak the private key on signing but not on 
decrypt, so technically there are known attacks that'll exploit the same key 
being used for signing and decryption.

Peter.