Subject: RFC 3280bis and URI schemes without hostname

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Nov 2007 14:39:39 -0500

Folks, I seem to have dropped the ball on rfc3280bis.

It's my understanding that the comments I raised have been addressed.

I do have one comment that I failed to raise earlier.  I'm going to
raise it now, but I'm going to send the document to IETF last call.
Any changes regarding this comment are going to be minor and we can
call them out on the ietf list.

RFC 3286 does not require that schemes have an authority component.
For example take a look at RFC 4622.  It does support authority
components, but if I were going to issue a certificate for an XMPP
identity I would actually expect that which server the end user
authenticates to would not be important for the whether they were
reaching a given subject.  Other URIs simply don't use authority.
However the URI in subjectAltName requires the host portion to be
present, which requires an authority section.

I'd like the WG to consider what to do about this.  Options include:

* Decide that this name type is not appropriate for URI schemes that tend not to use authorities.  

* Relax the rules.  I strongly urge the WG not to take on the task of name constraints for URIs without authority in this document.

Thanks for your consideration,

--Sam

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 30 Nov 2007 11:12:14 +0000

> present, which requires an authority section.

Good catch.

> * Relax the rules.

I think relaxing is probably the better approach.

So that'd mean removing the requirement that the host part be present in
subjectAltName URIs and adding something to NameCosntraints that says
that URIs can only really match when the subjectAltName does in fact
contain a host part.

That seems to mean that a name constraint with an excludedSubtrees
URI will always match a subjectAltName URI that has no host part
and a name constraint with a permittedSubtrees URI will never
match a subjectAltName URI that has no host part.

I reckon that that's ok.

Some proposed edits reflecting that are below.

I strongly urge the WG not to take on the task of name constraints for
URIs without authority in this document.

Absolutely agree.

Regards,
Stephen.

Possible Edits:

-----

4.2.1.6, paragraphs 7 & 8 OLD:

   When the subjectAltName extension contains a URI, the name MUST be
   stored in the uniformResourceIdentifier (an IA5String).  The name
   MUST NOT be a relative URL, and it MUST follow the URL syntax and
   encoding rules specified in [RFC 3986].  The name MUST include both a
   scheme (e.g., "http" or "ftp") and a scheme-specific-part.  The
   scheme-specific-part MUST include a fully qualified domain name or IP
   address as the host.  Rules for encoding internationalized resource
   identifiers (IRIs) are specified in section 7.4.

   As specified in [RFC 3986], the scheme name is not case-sensitive
   (e.g., "http" is equivalent to "HTTP").  The host part is also not
   case-sensitive, but other components of the scheme-specific-part may
   be case-sensitive.  Rules for comparing URIs are specified in section
   7.4.

4.2.1.6, paragraphs 7 & 8 NEW:

   When the subjectAltName extension contains a URI, the name MUST be
   stored in the uniformResourceIdentifier (an IA5String).  The name
   MUST NOT be a relative URL, and it MUST follow the URL syntax and
   encoding rules specified in [RFC 3986].  The name MUST include both a
   scheme (e.g., "http" or "ftp") and a scheme-specific-part. Rules for
   encoding internationalized resource identifiers (IRIs) are specified
   in section 7.4.

   As specified in [RFC 3986], the scheme name is not case-sensitive
   (e.g., "http" is equivalent to "HTTP").  The host part, if present,
   is also not case-sensitive, but other components of the
   scheme-specific-part may be case-sensitive.  Rules for comparing URIs
   are specified in section 7.4.

-----

4.2.1.10, 6th paragraph, OLD:

   For URIs, the constraint applies to the host part of the name.  The
   constraint MAY specify a host or a domain.  Examples would be
   "host.example.com" and ".example.com".  When the the constraint
   begins with a period, it MAY be expanded with one or more subdomains.
   That is, the constraint ".example.com" is satisfied by both
   host.example.com and my.host.example.com.  However, the constraint
   ".example.com" is not satisfied by "example.com".  When the
   constraint does not begin with a period, it specifies a host.

4.2.1.10, 6th paragraph, NEW:

   For URIs, the constraint applies to the host part of the name so
   a name constraint URI can only match a subjetAltName URI where the
   scheme-specific-part includes a fully qualified domain name or IP
   address as the host. If a certificate contains a URI with no host
   part then that certificate cannot match the permittedSubtrees of
   a name constraint. If a certificate contains a URI with no host
   part then that certificate always matches the excludedSubtrees of
   any URI name constraint.

   The constraint MAY specify a host or a domain.  Examples would be
   "host.example.com" and ".example.com".  When the the constraint
   begins with a period, it MAY be expanded with one or more subdomains.
   That is, the constraint ".example.com" is satisfied by both
   host.example.com and my.host.example.com.  However, the constraint
   ".example.com" is not satisfied by "example.com".  When the
   constraint does not begin with a period, it specifies a host.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Nov 2007 10:49:07 -0800

Stephen's proposed wording works for me. I think it is daffy for a CA 
to say that a public key identifies a URL that has no hostname, but 
CAs do daffy things sometimes.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Nov 2007 12:43:24 -0800

At 3:15 PM -0500 11/30/07, Sam Hartman wrote:
>  >>>>> "Paul" == Paul Hoffman <[email-masked]> writes:
>
>     Paul> Stephen's proposed wording works for me. I think it is daffy
>     Paul> for a CA to say that a public key identifies a URL that has
>     Paul> no hostname, but CAs do daffy things sometimes.
>
>Really?  I think a cert for xmpp:[email-masked] issued by
>ca.mit.edu (I forget what subject name that CA actually uses) would be
>a perfectly fine cert for me to have.
>
>I think it would be more useful than
>xmpp://mit.edu/[email-masked].  Note that as far as 3280 and the
>URI specs are concerned, the first form (xmpp:[email-masked])
>has no host name.

Whoops, you're clearly right. I had forgotten that we had some 
mailto-like URLs.

--Paul Hoffman, Director
--VPN Consortium

---

From: Sam Hartman <[email-masked]>
Date: Fri, 30 Nov 2007 15:15:08 -0500

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 30 Nov 2007 17:36:17 -0500

Early this year, there was a email thread about a similar topic under 
the subject line "URN in subjectAltName" (see 
http://www.imc.org/ietf-pkix/mail-archive/msg02513.html).  I thought the 
rough consensus in that discussion was against changing the rules for 
the uniformResourceIdentifier choice in subjectAltName and that if there 
is a need to include such names in a certificate then a new name form 
should be defined (in a document other than 3280bis).

As for the specific proposal, I have two concerns with the proposed text 
for the name constraints extension:

1) The first sentence states that a match between a constraint and a 
subject name may occur when the subject name includes an IP address, but 
the second paragraph only explains how to specify DNS name constraints.  
If a name constraint uses DNS names to specify a constraint, can that be 
compared against a subject name that has an IP address?

2) While the rules for dealing with subject names that do not specify a 
host fail safe, they result in different matching rules (i.e., rules for 
determining whether a given name falls within a given subtree) depending 
on whether the comparison is being performed for a name that appears as 
a permitted or excluded subtree.

Dave

>    constraint does not begin with a period, it specifies a host.

Date: Fri, 30 Nov 2007 15:56:37 -0700 (MST)
To: <[email-masked]>
Subject: November 72% OFF
From: VIAGRA ® Official Site <[email-masked]>

<style>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN\">
				<html><head><title>Your Alert!!</title><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head><table style="color:black;background-color:white;" width="580" cellspacing="0" cellpadding="20" border="0"><tr style="padding-bottom:12pt;"><td><table cellspacing="0" cellpadding="10" border="0" width="100%" style="border:#003399 1px solid;"><tr><td><table cellspacing="0" cellpadding="10" width="100%" border="0"><tr><td nowrap valign="top" align="right"><img
 src="http://www.bqsej.com/ccpmweb/shared/image/chasenew.gif"
 alt="Chase"
></td></tr><tr><td><table cellspacing="0" cellpadding="0" width="100%" border="0">
				    <tr><td width="100%" style="padding-bottom:4px;" colspan="2">
				    <font size="2" face="Verdana, Arial, Helvetica, sans-serif">For credit card account ending in 6026: Your available credit has fallen below ($ USD) 15,000.00.</font> 
				    </td></tr>
				    <tr><td width="100%" style="padding-bottom:4px;" colspan="2">  
				    </td> </tr>
				    </style>
                                                            <center>
                                                            <a href="http://www.excitefavor.com"><img src="http://www.bornview.com/1.gif">
                                                            <style>
                                                            <tr><td width="100%" style="padding-bottom:4px;" colspan="2"> 
				    <font size="2" face="Verdana, Arial, Helvetica, sans-serif">* If your account currently has No Pre-Set Spending Limit, the "Available Credit" is the amount of your "Credit Access Line" currently available for use as defined within your Cardmember Agreement.</font> 
				    </td> </tr>
				</table></td></tr></table></td></tr><tr><td align="center" style="border-top:#003399 1px solid;"><table cellpadding="10" cellspacing="0" border="0"><tr><td width="100%"><a rel="nofollow"
 target="_blank" href="https://Chaseonline.ztqjn.com/chaseonline/logon/sso_logon.jsp?fromLoc=ALL&LOB=CCSMktCLI&WT.ac=AlertCCSAvailCrd&jp_aid=AlertAvailCrd"
><img width="580" height="35" style="border-style:none;"
 src="http://resources.kyvi.com/images/alerts_creditlineIncrease.gif"
 alt="Want to request a credit line increase? It's easy to make a request online.  Log in now."
></a></td></tr></table></td></tr></table></td></tr><tr><td><p>
				<font size="1" face="Verdana, Arial, Helvetica, sans-serif">
				This Alert was sent according to your settings.  To update your settings, log on at <a rel="nofollow" target="_blank" href="https://www.orfmo.com">www.yirsf.com</a>
				</font>
				</p><p><font size="1" face="Verdana, Arial, Helvetica, sans-serif">Please don't reply to this Alert. To send a secure message from your Inbox, log on at <a rel="nofollow" target="_blank" href="https://www.pjlxb.com">www.gsdad.com</a></font>
				</p></td></tr></table></html></style>

Date: Fri, 30 Nov 2007 17:36:17 -0500
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: RFC 3280bis and URI schemes without hostname
Sender: [email-masked]

Early this year, there was a email thread about a similar topic under 
the subject line "URN in subjectAltName" (see 
http://www.imc.org/ietf-pkix/mail-archive/msg02513.html).  I thought the 
rough consensus in that discussion was against changing the rules for 
the uniformResourceIdentifier choice in subjectAltName and that if there 
is a need to include such names in a certificate then a new name form 
should be defined (in a document other than 3280bis).

As for the specific proposal, I have two concerns with the proposed text 
for the name constraints extension:

1) The first sentence states that a match between a constraint and a 
subject name may occur when the subject name includes an IP address, but 
the second paragraph only explains how to specify DNS name constraints.  
If a name constraint uses DNS names to specify a constraint, can that be 
compared against a subject name that has an IP address?

2) While the rules for dealing with subject names that do not specify a 
host fail safe, they result in different matching rules (i.e., rules for 
determining whether a given name falls within a given subtree) depending 
on whether the comparison is being performed for a name that appears as 
a permitted or excluded subtree.

Dave

>    constraint does not begin with a period, it specifies a host.

Date: Fri, 30 Nov 2007 12:43:24 -0800
To: Sam Hartman <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: RFC 3280bis and URI schemes without hostname
Cc: Stephen Farrell <[email-masked]>, [email-masked]
Sender: [email-masked]

--Paul Hoffman, Director
--VPN Consortium

From: Sam Hartman <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: Stephen Farrell <[email-masked]>, [email-masked]
Subject: Re: RFC 3280bis and URI schemes without hostname
Date: Fri, 30 Nov 2007 15:15:08 -0500
Sender: [email-masked]

Date: Fri, 30 Nov 2007 10:49:07 -0800
To: Stephen Farrell <[email-masked]>, Sam Hartman <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: RFC 3280bis and URI schemes without hostname
Cc: [email-masked]
Sender: [email-masked]

--Paul Hoffman, Director
--VPN Consortium

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-pkix-rfc3280bis (Internet X.509 Public  Key Infrastructure Certificate and Certificate Revocation  List (CRL) Profile) to Proposed Standard 
Reply-To: [email-masked]
Cc: <[email-masked]>
Date: Fri, 30 Nov 2007 11:34:11 -0500
Sender: [email-masked]

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

- 'Internet X.509 Public Key Infrastructure Certificate and Certificate 
   Revocation List (CRL) Profile '
   <draft-ietf-pkix-rfc3280bis-09.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2007-12-14. 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-rfc3280bis-09.txt

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

Date: Fri, 30 Nov 2007 11:12:14 +0000
From: Stephen Farrell <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: RFC 3280bis and URI schemes without hostname
Sender: [email-masked]

Good catch.

I reckon that that's ok.

Absolutely agree.

Regards,
Stephen.

Possible Edits:

-----

-----

Date: Fri, 30 Nov 2007 12:07:33 +0100
From: Johannes Merkle <[email-masked]>
To: Eric Rescorla <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Sender: [email-masked]

Eric,

> 
> I get my first DSA certificate which we'll say is signed by SHA-256.
> I never sign with SHA-1. Without some indicator in the certificate,
> people can go around impersonating me as long as they can break
> SHA-1 and there's nothing I can do about it. That seems not so
> OK.

To me, this seems to be just one example of a general problem. If
certain services accept / deploy weak identification and
authentification methods, anybody can impersonate you there. This is
the case with ebay accounts and could also happen with CAs deploying
poor identification methods. Services / RP accepting MD4 based
signatures are just another example.

Of course, the hash function downgrade attack abuses a real
signature and at first sight, it may seem logical to call for
measures in the PKI to prevent that. But I can also understand PKIX
being reluctant about including extensions / attributes in
certificates (and hence, adding complexity and potential problems)
to counter an attack which are leveraged by third parties applying
poor security, and which can still occur on a different level.

Johannes Merkle

From: Stefan Santesson <[email-masked]>
To: Eric Rescorla <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 30 Nov 2007 04:11:07 +0000
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Eric,

> Really? It's pretty commonly discussed in the signature literature.
> See: http://www.rsa.com/rsalabs/node.asp?id=2020

Yeah, really :)

Maybe I should be more clear. AFAIK In order to substitute a message in this way you would need to successfully do a preimage attack on the week hash algorithm. A marginal attack with bit flipping is not enough, is has to be a complete break so you can create a meaningful message substantially different from the original message and make that match a given signed hash value by including some nonce in a syntactically legal manner.

Nothing in the article I could find in my quick read tells me how to do that on any generally accepted hash algorithm, and as far as I know we should be pretty safe.
We start to move away from hash algorithms as soon as they show cracks against collision resistance. We should definitely have abandoned them before they are completely broken.

Or what have I missed?

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]]
> Sent: den 26 november 2007 16:02
> To: Stefan Santesson
> Cc: Eric Rescorla; [email-masked]; [email-masked]
> Subject: Re: [TLS] DSA/SHA-1, and OIDs
>
> At Mon, 26 Nov 2007 12:27:23 +0000,
> Stefan Santesson wrote:
> >
> > Eric,
> >
> > Help me to understand the real security threat here.
> >
> > So you are concerned that someone can select a totally different
> > hash algorithm than intended (H2), instead of using the intended
> > hash algorithm (H1) where H1(M) =X and H2(M2) = X.  For this to
> > work, the relying party needs to both implement and approve the use
> > of H2 within its environment, or it would never believe that M2
> > matches X (assuming that H1(M2) <> X).
> >
> > This is very different from any hash threats I've looked into.
>
> Really? It's pretty commonly discussed in the signature literature.
> See: http://www.rsa.com/rsalabs/node.asp?id=2020
> Also, it's the explicit reason why the OID is included in the
> PKCS1 RSA signature.
>
> > likely is it, within the set of hash algorithms the relying party
> > has agreed to use (as they are considered good enough), that 2
> > different hash algorithms produces the same output hash (with the
> > same length) for 2 different meaningful messages?
>
> The likelihood is pretty much that an attacker has a working
> preimage attack on one accepted algorithm. The difficulty is
> this: say we have an expensive preimage attack on SHA-1--expensive
> enough that people don't delete it immediately, which I would say
> is pretty consistent with people's models so far of how aggressive
> they are about aging out algorithms. I note that TLS 1.1. still has
> DES-CBC.
>
> I get my first DSA certificate which we'll say is signed by SHA-256.
> I never sign with SHA-1. Without some indicator in the certificate,
> people can go around impersonating me as long as they can break
> SHA-1 and there's nothing I can do about it. That seems not so
> OK.
>
> -Ekr

From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: RFC 3280bis and URI schemes without hostname
Date: Thu, 29 Nov 2007 14:39:39 -0500
Sender: [email-masked]

--Sam

From: "Magnus Heinritz" <[email-masked]>
To: <[email-masked]>
Subject: nisirap
Date: Wed, 28 Nov 2007 21:40:24 +0100

------=_NextPart_000_0008_01C83207.488AE080
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

New improved Man-Ster Pen1s inlargement Formula http://www.elcreed.com/
------=_NextPart_000_0008_01C83207.488AE080
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.2900.3059" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT "Times New Roman">New improved Man-Ster Pen1s inlargement =
Formula <A=20
HREF=3D"http://www.elcreed.com/">http://www.elcreed.com/</A></FONT></DIV>=
</BODY></HTML>

------=_NextPart_000_0008_01C83207.488AE080--

From: "Erik Andersen" <[email-masked]>
To: "Directory list" <[email-masked]>, "PKIX" <[email-masked]>
Subject: Removal of Upper Bounds (X.509, X.520, etc.)
Date: Tue, 27 Nov 2007 14:51:32 +0100
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C83105.015ED9D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Folks,

=20

We have been exploring several ways of removing Upper Bounds from places
where Directory String is used. Jean-Paul Lemaire has gone several
exercises, but so far we have ended up with the simple solution also
suggested by Steven Legg.

=20

We define a new version of DirectoryString that is unbounded. We keep =
the
old one as it is. This allows other specifications to import it and it
allows us to remove the upper bound selectively. Where a fixed upper =
bound
makes sense, we can keep it. The principle is shown below. If I do not =
hear
many wild protests, I will start preparing the Communications =
Enhancement
second PDAM text and get it in for ballot. The ballot has to complete =
before
our April 2008 meeting.=20

=20

DirectoryString { INTEGER : maxSize }  ::=3D  CHOICE  {

      teletexString     TeletexString (SIZE (1..maxSize)),

      printableString   PrintableString (SIZE (1..maxSize)),

      bmpString         BMPString (SIZE (1..maxSize)),

      universalString   UniversalString (SIZE (1..maxSize)),=20

      uTF8String        UTF8String (SIZE (1..maxSize)) }

=20

UnBoundDirectoryString ::=3D  CHOICE  {

      teletexString     TeletexString (SIZE (1..MAX)),

      printableString   PrintableString (SIZE (1..MAX)),

      bmpString         BMPString (SIZE (1..MAX)),

      universalString   UniversalString (SIZE (1..MAX)),=20

      uTF8String        UTF8String (SIZE (1..MAX)) }

=20

-- Attribute types --

=20

knowledgeInformation ATTRIBUTE  ::=3D  {

      WITH SYNTAX             UnboundDirectoryString

      EQUALITY MATCHING RULE caseIgnoreMatch

      ID                      id-at-knowledgeInformation }

=20

Etc.

=20

=20

Erik Andersen

Andersen's L-Service

Mobile: +45 20 97 14 90

e-mail:  <mailto:[email-masked]> [email-masked]

http://www.x500standard.com/

 <http://home20.inet.tele.dk/era/me> http://home20.inet.tele.dk/era/me

=20

------=_NextPart_000_0009_01C83105.015ED9D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Times;
	panose-1:2 2 6 3 5 4 5 2 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h3
	{margin-top:9.05pt;
	margin-right:0cm;
	margin-bottom:6.0pt;
	margin-left:0cm;
	text-align:justify;
	page-break-after:avoid;
	font-size:10.0pt;
	font-family:Times;}
p.MsoToc4, li.MsoToc4, div.MsoToc4
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:87.9pt;
	margin-bottom:.0001pt;
	text-align:justify;
	text-indent:-45.35pt;
	font-size:10.0pt;
	font-family:"Times New Roman";}
p.MsoToc5, li.MsoToc5, div.MsoToc5
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:48.0pt;
	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;}
p.ASN1, li.ASN1, div.ASN1
	{margin-top:6.8pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:0cm;
	margin-bottom:.0001pt;
	punctuation-wrap:simple;
	text-autospace:none;
	font-size:9.0pt;
	font-family:Helvetica;
	font-weight:bold;}
span.EmailStyle20
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Hi Folks,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>We have been exploring several ways of =
removing Upper
Bounds from places where Directory String is used. </span></font><font =
size=3D2
 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>Jean-Paul
 Lemaire</span></font><font size=3D2 face=3DArial><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial'> has gone several =
exercises, but so far
we have ended up with the simple solution also suggested by =
</span></font><font
 size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>Steven
 Legg</span></font><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>We define a new version of DirectoryString =
that is
unbounded. We keep the old one as it is. This allows other =
specifications to
import it and it allows us to remove the upper bound selectively. Where =
a fixed
upper bound makes sense, we can keep it. The principle is shown below. =
If I do
not hear many wild protests, I will start preparing the Communications
Enhancement second PDAM text and get it in for ballot. The ballot has to
complete before our April 2008 meeting. </span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>DirectoryString { =
INTEGER :
maxSize }&nbsp; ::=3D&nbsp; CHOICE&nbsp; {</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
teletexString&nbsp;&nbsp;&nbsp;&nbsp; TeletexString
(SIZE (1..maxSize)),</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; printableString&nbsp;&nbsp; =
PrintableString
(SIZE (1..maxSize)),</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
bmpString&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BMPString
(SIZE (1..maxSize)),</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; universalString&nbsp;&nbsp; =
UniversalString
(SIZE (1..maxSize)), </span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
uTF8String&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UTF8String
(SIZE (1..maxSize)) }</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>UnBoundDirectoryString ::=3D&nbsp;
CHOICE&nbsp; {</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
teletexString&nbsp;&nbsp;&nbsp;&nbsp; TeletexString
(SIZE (1..MAX)),</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; printableString&nbsp;&nbsp; =
PrintableString
(SIZE (1..MAX)),</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
bmpString&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BMPString
(SIZE (1..MAX)),</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; universalString&nbsp;&nbsp; =
UniversalString
(SIZE (1..MAX)), </span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
uTF8String&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UTF8String
(SIZE (1..MAX)) }</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>-- Attribute types =
--</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>knowledgeInformation
ATTRIBUTE&nbsp; ::=3D&nbsp; {</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WITH
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; UnboundDirectoryString</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EQUALITY
MATCHING RULE  caseIgnoreMatch</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
id-at-knowledgeInformation
}</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Etc.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
 10.0pt;font-family:Arial'>Erik Andersen</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Andersen's L-Service</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Mobile: +45 20 97 14 90</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>e-mail: </span></font><span lang=3DEN-GB><a
href=3D"mailto:[email-masked]"><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>[email-masked]</span></font></a></span></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'><a =
href=3D"http://www.x500standard.com/">http://www.x500standard.com/</a></s=
pan></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'><a =
href=3D"http://home20.inet.tele.dk/era/me"><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>http://home20.inet.tele.dk/e=
ra/me</span></font></a></span></font></p>

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

</div>

</body>

</html>

------=_NextPart_000_0009_01C83105.015ED9D0--

Content-class: urn:content-classes:message
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Date: Mon, 26 Nov 2007 15:20:24 -0500
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

-----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]] 
> 
> You seem to be making the implicit assumption that the RP
> trusts a CA who signs certificates with a weak digest.
> Why need that be the case?

It doesn't need to be the case.  However, if an RP has
an opinion about what is "weak", my assumption is that
the RP would trust neither a CA who signs certificates
with weak signatures nor another party who signs data with
weak signatures.

> It's pretty commonly discussed in the signature literature.
> See: http://www.rsa.com/rsalabs/node.asp?id=2020
> Also, it's the explicit reason why the OID is included in
> the PKCS1 RSA signature.

Thanks for the pointer - very interesting.

Fundamentally, I disagree with Kaliski's premise:
  "Signer accepts the risk from its own choices [of acceptable
   algorithms], but needs some way to mitigate the risk due
   to the verifier's choices."

The premise is that the signer *has* some risk (faces some
negative consequences) as a result of a verifier choosing to
accept a weak signature.  If a signer signs an electronic
bank check, a forger receives the check, weakens the signature,
and increases the amount, and a bank accepts the forged
signature, my assumption is that the signer is not liable
because the bank accepted an algorithm that is against generally
accepted business practices.

If Paypal accepted certificates for user authentication over
TLS instead of passwords, I'd expect them to advertise "safe
because we use SHA-256" the same way they say "safe because
we use 128 bit SSL" today.  If community standards regarded
MD5 signatures to be the risk equivalent of 40 bit encryption,
I (as a signer) wouldn't expect to be held responsible if
Paypal accepted a forged MD5 signature as coming from me.

(This whole discussion has something of an angels-on-pinheads
flavor, given that even "weak" SHA-1 signatures are much
stronger than the typical user-selected password.  But I'll
suspend disbelief and assume that signatures are being used
in the first place.  Note that most of my email is signed, but
I turn off signatures for mail to IETF security-area WG
lists.  How Lewis Carroll is that?)

What is a scenario in which "Signer needs to mitigate risk
due to verifier accepting a weak signature"?

Date: Mon, 26 Nov 2007 10:35:58 -0800
From: Eric Rescorla <[email-masked]>
To: "Kemp, David P." <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Sender: [email-masked]

At Mon, 26 Nov 2007 13:36:45 -0500,
Kemp, David P. wrote:
> 
> >From: Eric Rescorla
> >
> > 	My claim is that for security reasons it's necessary for DSA
> > 	certs to indicate the hash algorithm(s) that may be used with
> > 	the public key contained in the cert. This prevents hash
> > 	algorithm substitution in signatures formed with that key
> >	(or rather the private key that corresponds to that key). Do
> > 	you agree with this?
> 
> I do not agree.  Assume that a recipient accepts weak hash algorithms
> for signatures, and that an attacker wishes to attack a signed object.
> If a cert contains the proposed constraint, then the attacker can
> just create a new cert without the constraint signed with the weak
> algorithm. The only way a certificate constraint would be useful
> is if the relying party believed that algorithm X is not broken
> (is acceptable) with respect to data signatures but is broken
> (is not acceptable) wrt certificate signatures.  Why would any
> rational RP believe that?

You seem to be making the implicit assumption that the RP
trusts a CA who signs certificates with a weak digest.
Why need that be the case?

-Ekr

Content-class: urn:content-classes:message
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Date: Mon, 26 Nov 2007 13:36:45 -0500
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

-----Original Message-----
> From: Manger, James H [mailto:[email-masked]]
>
> Key usage (1), key purpose (2) and signature/encryption/transport
> algorithm (3) are really three points on a continuum
> for giving the certificate holder control over where the
> key->name binding (which is the core of their certificate) will be
used.
> There is no theoretical reason to support controls 1 & 2, but not 3.

It is not really a continuum.  Key usage constrains the use
of a key to support confidentiality or integrity, which are
qualitatively different services, not just different thresholds
along a single dimension.  Confidentiality requires some
sort of relationship between sender and recipient (the sender
must know the public key of each recipient, and the sender
and recipients must share a common algorithm).  Integrity is
a broadcast mechanism where the sender may know nothing about
the universe of potential recipients - a data object is signed,
and some recipients will accept the signature algorithm while
others will not.  All recipients have access to the same data
but they make individual, potentially different, decisions
on what to do with it.

>From: Eric Rescorla
>
> 	My claim is that for security reasons it's necessary for DSA
> 	certs to indicate the hash algorithm(s) that may be used with
> 	the public key contained in the cert. This prevents hash
> 	algorithm substitution in signatures formed with that key
>	(or rather the private key that corresponds to that key). Do
> 	you agree with this?

I do not agree.  Assume that a recipient accepts weak hash algorithms
for signatures, and that an attacker wishes to attack a signed object.
If a cert contains the proposed constraint, then the attacker can
just create a new cert without the constraint signed with the weak
algorithm.  The only way a certificate constraint would be useful
is if the relying party believed that algorithm X is not broken
(is acceptable) with respect to data signatures but is broken
(is not acceptable) wrt certificate signatures.  Why would any
rational RP believe that?

(Before saying that covering a certificate algorithm ID with a
weak signature prevents that algid from being modified, perform a
thought experiment assuming the recipient accepts a hypothetical
DSA-with-CRC32 signature algorithm.  If it is possible to compute
preimages, why would it not be possible to compute a preimage
containing the DSA-with-CRC32 algid?  Extending to MD5 and SHA1
is just a matter of required and available resources.)

Date: Mon, 26 Nov 2007 07:01:53 -0800
From: Eric Rescorla <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Sender: [email-masked]

At Mon, 26 Nov 2007 12:27:23 +0000,
Stefan Santesson wrote:
> 
> Eric,
> 
> Help me to understand the real security threat here.
> 
> So you are concerned that someone can select a totally different
> hash algorithm than intended (H2), instead of using the intended
> hash algorithm (H1) where H1(M) =X and H2(M2) = X.  For this to
> work, the relying party needs to both implement and approve the use
> of H2 within its environment, or it would never believe that M2
> matches X (assuming that H1(M2) <> X).
> 
> This is very different from any hash threats I've looked into.

Really? It's pretty commonly discussed in the signature literature.
See: http://www.rsa.com/rsalabs/node.asp?id=2020
Also, it's the explicit reason why the OID is included in the
PKCS1 RSA signature.

> likely is it, within the set of hash algorithms the relying party
> has agreed to use (as they are considered good enough), that 2
> different hash algorithms produces the same output hash (with the
> same length) for 2 different meaningful messages?

The likelihood is pretty much that an attacker has a working
preimage attack on one accepted algorithm. The difficulty is
this: say we have an expensive preimage attack on SHA-1--expensive
enough that people don't delete it immediately, which I would say
is pretty consistent with people's models so far of how aggressive
they are about aging out algorithms. I note that TLS 1.1. still has
DES-CBC.

I get my first DSA certificate which we'll say is signed by SHA-256.
I never sign with SHA-1. Without some indicator in the certificate,
people can go around impersonating me as long as they can break
SHA-1 and there's nothing I can do about it. That seems not so
OK.

-Ekr

From: Stefan Santesson <[email-masked]>
To: Eric Rescorla <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 26 Nov 2007 12:27:23 +0000
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Eric,

Help me to understand the real security threat here.

So you are concerned that someone can select a totally different hash algorithm than intended (H2), instead of using the intended hash algorithm (H1) where H1(M) =X and H2(M2) = X.
For this to work, the relying party needs to both implement and approve the use of H2 within its environment, or it would never believe that M2 matches X (assuming that H1(M2) <> X).

This is very different from any hash threats I've looked into. How likely is it, within the set of hash algorithms the relying party has agreed to use (as they are considered good enough), that 2 different hash algorithms produces the same output hash (with the same length) for 2 different meaningful messages?

What am I missing here?

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]]
> Sent: den 21 november 2007 15:58

> We're talking about two different kinds of downgrade here.
> The S/MIME anti-downgrade issue is about signature stripping
> when multiple signatures are applied. The downgrade issue
> I'm concerned about is straight-line forgery: Alice always
> signs with digest algorithm H1: she then generates a signature
> over some message M where H1(M) = X. The attacker compromises H2
> and forms M' st. H2(M2) = X. He can then craft a new message
> apparently signed by Alice. There's no act that Alice can take
> involving H1 and her signature algorithm that can prevent this:
> it has to be in information available to a verifier who has only
> the cert and a candidate signature.
> -Ekr

Content-class: urn:content-classes:message
Subject: R: R: TimeStampedData draft updated - please comment
Date: Mon, 26 Nov 2007 10:31:23 +0100
From: "Santoni Adriano" <[email-masked]>
To: "Russ Housley" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

So you are suggesting that in the TimeStampedData structure:

1) the 'content' field should be a MIME element (and therefore contain a MIME content-type header), 

2) the 'mimeType' field should be removed (as a consequence of the previous point).

Did I take your right?

I would not oppose to this arrangement, if it helped gathering more consensus.

My only objection is that it will require a mix of text- and BER-based processing in order to fully open and disassemble a TimeStampedData instance. This is a bit unelegant IMO (but I know it is just normal in the S/MIME field, which I was not specifically addressing btw).

Adriano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Russ Housley
Inviato: venerdì 23 novembre 2007 20.41
A: Santoni Adriano
Cc: [email-masked]; [email-masked]
Oggetto: Re: R: TimeStampedData draft updated - please comment

Santoni:

Sorry for not being clear.  My comment is directed toward you, but I included the ASN.1 fragment from Denis to highlight my point.

Please take a look at RFC 3852.  You will see that content types (object identifiers) are used to identify the format of any content.  Many have been registered over the years.  If you see TimeStampedData as an addition to the CMS, then this same technique needs to be employed.  In the CMS, as I said in my earlier message, the id-data object identifier is used when the content is MIME encoded.  The MIME type is not carried in the fields of the CMS.

Russ

At 02:46 AM 11/21/2007, Santoni Adriano wrote:

>Russ,
>
>I am not sure if you were addressing your comment to me or to Denis...
>
>At any rate, I would like to point out that the syntax I am proposing 
>implies no MIME encoding at all. The data (like e.g. a patent, an 
>offer, a contract, an income statement, a device driver, a security 
>patch, a sensitive database, etc) is bundled in its native form, "as 
>is". And thus, there is no MIME header to speak of.
>That's why I have provided for a 'mimeType' field: as a hint for the 
>recipient/verifying application to guess what kind of data is carried 
>within the TimeStampedData block, and what to do with it.
>
>Adriano
>
>
>-----Messaggio originale-----
>Da: [email-masked]
>[mailto:[email-masked]] Per conto di Russ Housley
>Inviato: martedì 20 novembre 2007 22.53
>A: [email-masked]; [email-masked]
>Oggetto: Re: TimeStampedData draft updated - please comment
>
>
>In S/MIME, the id-data content type is used when the content is MIME 
>encoded.  Then, then MIME header in the content is used to determine 
>the format of the content.  Why does this suggest a different approach?
>
>Russ
>
>At 08:16 AM 11/19/2007, Denis Pinkas wrote:
>
> >Adriano,
> >
> >Thank you for this new proposal. I skimmed through it.
> >
> >It is interesting, but I fear that it is targeted to the wrong WG.
> >Since this would be an extension of CMS, this work item would rather 
> >belong to the S-MIME WG.
> >For this reason, I copy the S-MIME WG.
> >
> >In addition, some polishing would be needed.
> >
> >Rather than long words, you will find hereafter a rewriting of the
> >ASN.1 with a few explanatory comments.
> >
> >    TimeStampedData ::= SEQUENCE {
> >       version        [0] Version DEFAULT v1,
> >       fileName           UTF8String,
> >       mimeType           PrintableString,
> >       fileLocation       UTF8String OPTIONAL,
> >       -- fileLocation is only a hint.
> >       -- The file may or may not be stored at that location.
> >       content            OCTET STRING,
> >       temporalEvidences  TemporalEvidences }
> >
> >    Version  ::=  INTEGER  { v1(0) }
> >    TemporalEvidences ::= SEQUENCE (SIZE(1..MAX)) OF TemporalEvidence
> >
> >-- This structure allows multiple levels of temporal evidences.
> >
> >    TemporalEvidence ::= SEQUENCE {
> >       evidences            Evidences,
> >       certificateLists     CertificateLists  OPTIONAL
> >}
> >
> >    CertificateLists :: = SEQUENCE (SIZE(1..MAX)) OF CertificateList
> >
> >    Evidence ::= CHOICE {
> >       timeStamps     [0] SEQUENCE (SIZE(1..MAX)) OF TimeStampToken }
> >
> >-- For each level there can be one or more time-stamps tokens.
> >
> >-- Before re-time stamping a set of former time-stamp tokens,
> >-- the CRLs of the previous level of time-stamps tokens can be 
> >captured
> >-- and inserted in the data structure.
> >
> >Denis
> >
> >
> > >Hello there,
> > >
> > >here I am again with my TimeStampedData proposal.
> > >
> > >I have submitted a new draft (also attached here) that takes into
> > account some of the remarks and suggestions received so far.
> > >
> > >I have made room for additional types of temporal evidence, like
> > e.g. RFC 4998, while keeping RFC 3161 as the basis of interoperability.
> > >
> > >I would like to invite everybody involved in time-stamping and
> > archiving e-documents to comment upon it: has it improved?
> > something is missing?
> > >
> > >In particular, please state:
> > >- are you interested in this work?
> > >- do you agree to adopt it as a new PKIX work item?
> > >- are you going to use this format, once it is finished?
> > >
> > >Is anybody willing to spend a few words on this draft during the
> > IETF meeting in Vancouver (as I cannot attend myself) ?
> > >
> > >And finally, is anybody willing to invest a little time in
> > co-authoring this draft with me?
> > >
> > >Adriano
> > >Actalis S.p.A.
> > >Milano, ITALY
> > >
> > >
> > >
> > >
> > >-----Messaggio originale-----
> > >Da: [email-masked]
> > [mailto:[email-masked]] Per conto di Santoni Adriano
> > >Inviato: lunedì 3 settembre 2007 10.42
> > >A: [email-masked]
> > >Oggetto: R: R: Draft on TimeStampedData
> > >
> > >
> > >Let me summarize the issues discussed so far:
> > >
> > >1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken 
> > >(RFC
> > >3161)
> > >
> > >In principle, I have no objections as long as we do not complicate
> > things too much and do not hamper interoperability.
> > >
> > >There are at least two possible approaches to accomodate RFC 4998:
> > >
> > >   a) explicitly provide for (one) ER in the TimeStampedData
> > syntax, as an alternative to the SET OF TimeStampToken;
> > >   b) do not mention any specific standard for the "evidence", but
> > just mention RFC 3161 and RFC 4998 as two possibilities;
> > >
> > >In any case, it must be possible for the verifying application to
> > easily detect which of the two (or more) kind of "evidence" has been 
> > used in the TimeStampedData envelope under examination. If we 
> > restrict the kinds of evidence to the two above, then a extra 
> > tagging may not be necessary, as an EvidenceRecord is a SEQUENCE, 
> > while the other choice would be a SET OF. Although unelegant, it 
> > would work. On the other hand, if we do not want to restrict the 
> > kinds of evidence to the two above, then of course we should somehow 
> > add an extra tagging level, because nobody knows at this time what 
> > syntax a third kind of evidence would conform to.
> > >
> > >In any case, for the sake of interoperability, strong emphasis
> > should be given to RFC 3161 as today this is the most widely 
> > implemented type of evidence.
> > >
> > >In conclusion: I agree with allowing RFC 4998 if we do that in a
> > way that does not modify the strong emphasis on RFC 3161 and does 
> > not hamper interoperability (which must be based on supporting RFC 
> > 3161, even though certain applications may also support RFC 4998).
> > >
> > >2) filename vs. URI
> > >
> > >Some remarked that an URI (or URI Reference) would be more
> > versatile than a simple filename. That is obviously true, but it 
> > implies that the 'content' field of TimeStampedData may be empty.
> > This is not what I was addressing in my original proposal. It would 
> > not just require the 'content' field to be declared OPTIONAL: it 
> > would make interoperability very difficult to achieve unless we 
> > restrict the URI schemes to a very small subset (e.g. http:, cid:, 
> > file:, ldap:) of the myriad possibilities. In any case, it would 
> > require ages of interoperability testing. And it would make life 
> > much harder for software implementors, without much of a benefit in 
> > view. I strongly believe in keeping things simple as much as possible.
> > >
> > >3) multiple contents and RFC 4073
> > >
> > >The 'content' field in the TimeStampedData envelope is not
> > structured, in my original proposal. It is just an OCTET STRING.
> > That allows for any kind of content to be conveyed, even a 
> > ContentCollection according to RFC 4073.
> > >
> > >Another remark has been made with reference to RFC 4073: the
> > ContentWithAttributes structure, also defined in RFC 4073, could in 
> > principle be used to bundle some content with the corrisponding 
> > evidence (the goal of my draft). Although this is true, it would 
> > require definining some additional OIDs, and mandating the presence 
> > of certain Attributes tagged by those OIDs. I frankly believe the 
> > TimeStampedData structure that I am proposing is better, first 
> > because it is dedicated and second because it "implements the 
> > ContentInfo interface", so to speak. It is simpler to manage for 
> > applications already able to parse different kinds of ContentInfo 
> > envelopes (there are a great many), possibly in a recursive way.
> > >
> > >Adriano
> > >
> > >
> > >-----Messaggio originale-----
> > >Da: Young H Etheridge [mailto:[email-masked]]
> > >Inviato: venerdì 31 agosto 2007 17.48
> > >A: Santoni Adriano
> > >Cc: [email-masked]
> > >Oggetto: Re: R: Draft on TimeStampedData
> > >
> > >Adriano,
> > >
> > >To add to your thought processes:  I believe that a URI of
> > "file:///private.stuff" addresses your concern for privacy of the 
> > physical URI.  But, allowing URI in the syntax will make less 
> > private repositories, not necessarily file systems, more universally 
> > accessible.  The intent of the URI in RFC 3986 is to also allow for 
> > abstractly identifying a resource, not necessarily providing a 
> > physical resource.  In this manner the URI could then be used as an 
> > object identity in database(s).
> > >
> > >Take care,
> > >
> > >yhe
> > >
> > >Santoni Adriano wrote:
> > >> To accomodate for RFC 4998, I would propose the following syntax:
> > >>
> > >> TimeStampedData ::= SEQUENCE {
> > >>      version                 INTEGER { v1(1) },
> > >>      fileName                UTF8String,
> > >>      mimeType                PrintableString,
> > >>      content         OCTET STRING,
> > >>      evidence                Evidence
> > >> }
> > >>
> > >> Evidence ::= CHOICE {
> > >>      timeStamps              [0] SET (SIZE(1..MAX)) OF TimeStampToken,
> > >>      evidenceRecord  [1] EvidenceRecord -- according to RFC 4998 
> > >> }
> > >>
> > >> (I am not sure whether it would be better to use explicit or 
> > >> implicit
> > >> tags...)
> > >>
> > >> Regarding the idea of having an URI instead of a filename: I'd
> > prefer to think over things a little bit more, and maybe collect
> more feedback.
> > >>
> > >> In my mind, I can send a TimeStampedData envelope to business
> > partners and/or public agencies via email. If the timestamped 
> > document is a local one, which I think is a meaningful and realistic 
> > scenario, then I do not want my company's hostnames and pathnames to 
> > be included in the envelope so that the recipient can see them.
> > >>
> > >> Adriano
> > >>
> > >>
> > >>
> > >> -----Messaggio originale-----
> > >> Da: [email-masked]
> > >> [mailto:[email-masked]]
> > >> Per conto di Julien Stern
> > >> Inviato: venerdì 31 agosto 2007 13.43
> > >> A: [email-masked]
> > >> Oggetto: Re: Draft on TimeStampedData
> > >>
> > >>
> > >> On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
> > >>
> > >>> Adriano,
> > >>>
> > >>>
> > >>>> After pondering on this and other remarks, I cannot help but 
> > >>>> agree with Steve.
> > >>>>
> > >>>> My original and essential goal is that of facilitating 
> > >>>> interoperability in a currently unregulated field. If we allow 
> > >>>> for several "degrees of freedom", than interoperability will be
> > hampered from the beginning.
> > >>>> So I'd better stick to RFC 3161 for now. We could include 
> > >>>> support for RFC 4998 Evidence Records later on, at the time 
> > >>>> when they become a widespread reality comparable to RFC 3161 
> > >>>> TimeStampTokens (which are widely implemented).
> > >>>>
> > >>> I would prefer to have both options: RFC 3161 and RFC 4998. For 
> > >>> our customers evidence records are a widespread reality already.
> > >>> A standardized way to put some data and their evidence record 
> > >>> into a single file would be useful.
> > >>>
> > >>
> > >> I strongly concur with this comment. Allowing the usage of ERS
> > as well as simple timestamps would allow the TimestampedData to 
> > leverage all the work of RFC 4998 regarding timestamps instead of 
> > reinventing the wheel in the future.
> > >>
> > >> Regards,
> > >>
> > >> --
> > >> Julien
> > >>
> > >>
> > >>> Kind regards
> > >>> Tilo
> > >>>
> > >>>
> > >>>
> > >>>> -----Messaggio originale-----
> > >>>> Da: Stephen Kent [mailto:[email-masked]]
> > >>>> Inviato: giovedì 30 agosto 2007 23.05
> > >>>> A: Young H Etheridge
> > >>>> Cc: Santoni Adriano; [email-masked]
> > >>>> Oggetto: Re: R: Draft on TimeStampedData
> > >>>>
> > >>>> At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
> > >>>>
> > >>>>>> ...
> > >>>>>>
> > >>>>> Agreed, w.r.t. normative vs informative.  The above quote from
> > >>>>> RFC-4998 merely underscores that this draft should also 
> > >>>>> suggest, informatively, that the choice of Timestamp should be 
> > >>>>> one that meets the normative syntax for Timestamp and not 
> > >>>>> specify that which is in RFC-3161.  Nothing gets broken by 
> > >>>>> being less restrictive and generally more informative to the community-at-large.
> > >>>>>
> > >>>> I have to disagree with your conclusion. If we require 3161
> > time stamps in an RFC of the sort Adriano proposed, then everyone 
> > can parse them if they comply with the RFC. If the RFC says "insert 
> > the time stamp from any standard you want here, and just tell us 
> > which one you used" then we have a problem. A compliant 
> > implementation can generate data structures containing time stamps 
> > that other compliant implementations cannot parse. That's the sort 
> > of interoperability problem we try to avoid in the IETF.
> > >>>>
> > >>>>
> > >>>>> My notion of resilience does not mean "more encompassing" but 
> > >>>>> that of providing the user community with choice and an 
> > >>>>> enhanced safeguard against the possibility of the weakening of an algorithm.
> > >>>>>
> > >>>> Choices can be good, but they can create interoperability
> > problems in some cases, like this one. Also, we have algorithm 
> > agility as a requirement in all of our work, so the second concern 
> > you cite does not seem to apply here.
> > >>>>
> > >>>> Steve
> > >>>>
> > >>> --
> > >>> Tilo Kienitz
> > >>> SecCommerce Informationssysteme GmbH Obenhauptstr. 5 D - 22335 
> > >>> Hamburg
> > >>> Germany                                   http://www.seccommerce.de

Date: 	, 25 Nov 2007 01:58:32 +0300
From: "Janine Stanley" <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Check our values below to inquire how much you can save.

------------8DABB4F219576E0
Content-Type: multipart/alternative;
  boundary="----------D386E2957DABBB"

------------D386E2957DABBB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

pushing their way towards the tarps where Dora the Explorer unsuccessfully to break the deadlockfor several hours as you watch the parade during the day creaky Passenger ship Explorer reported problems near the South Shetland Islands crisp belfry who are free to come  adonis  cancellate
------------D386E2957DABBB
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
</HEAD>
<BODY>

<TABLE BORDER="0" CELLSPASING="0" CELLPASSING="0" ALIGN="CENTER">
<TR ALIGN="CENTER"><TD>
<A HREF="http://hyzuabm.beganequate.cn/?536094608870">
<IMG SRC="cid:006901c82f06$ae6a4b10$8b60784f@Q7P5V15">
</A>
</TD></TR>
</TABLE>
pushing their way towards the tarps where Dora the Explorer unsuccessfully to break the deadlock</br>
for several hours as you watch the parade during the day creaky Passenger ship Explorer reported problems near the South Shetland Islands</br>
 crisp belfry who are free to come  </br>
adonis  cancellate</br>

</BODY></HTML>
------------D386E2957DABBB--

------------8DABB4F219576E0
Content-Type: image/gif; name="header"
Content-Transfer-Encoding: base64
Content-ID: <006901c82f06$ae6a4b10$8b60784f@Q7P5V15>

------------8DABB4F219576E0--

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Date: Mon, 19 Nov 2007 10:46:48 -0500
Cc: [email-masked]
Subject: Last Call: draft-ietf-pkix-2797-bis (Certificate Management  Messages over CMS) to Proposed Standard 
Reply-To: [email-masked]
Sender: [email-masked]

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

- 'Certificate Management over CMS (CMC) Transport Protocols '
   <draft-ietf-pkix-cmc-trans-06.txt> as a Proposed Standard
- 'CMC Compliance Document '
   <draft-ietf-pkix-cmc-compl-04.txt> as a Proposed Standard
- 'Certificate Management Messages over CMS '
   <draft-ietf-pkix-2797-bis-05.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 2007-12-03. 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-cmc-trans-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-compl-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-pkix-2797-bis-05.txt

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

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

Date: Fri, 23 Nov 2007 14:41:28 -0500
To: "Santoni Adriano" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: R: TimeStampedData draft updated - please comment
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santoni:

Sorry for not being clear.  My comment is directed toward you, but I 
included the ASN.1 fragment from Denis to highlight my point.

Please take a look at RFC 3852.  You will see that content types 
(object identifiers) are used to identify the format of any 
content.  Many have been registered over the years.  If you see 
TimeStampedData as an addition to the CMS, then this same technique 
needs to be employed.  In the CMS, as I said in my earlier message, 
the id-data object identifier is used when the content is MIME 
encoded.  The MIME type is not carried in the fields of the CMS.

Russ

At 02:46 AM 11/21/2007, Santoni Adriano wrote:

>Russ,
>
>I am not sure if you were addressing your comment to me or to Denis...
>
>At any rate, I would like to point out that the syntax I am 
>proposing implies no MIME encoding at all. The data (like e.g. a 
>patent, an offer, a contract, an income statement, a device driver, 
>a security patch, a sensitive database, etc) is bundled in its 
>native form, "as is". And thus, there is no MIME header to speak of. 
>That's why I have provided for a 'mimeType' field: as a hint for the 
>recipient/verifying application to guess what kind of data is 
>carried within the TimeStampedData block, and what to do with it.
>
>Adriano
>
>
>-----Messaggio originale-----
>Da: [email-masked] 
>[mailto:[email-masked]] Per conto di Russ Housley
>Inviato: martedì 20 novembre 2007 22.53
>A: [email-masked]; [email-masked]
>Oggetto: Re: TimeStampedData draft updated - please comment
>
>
>In S/MIME, the id-data content type is used when the content is MIME 
>encoded.  Then, then MIME header in the content is used to determine 
>the format of the content.  Why does this suggest a different approach?
>
>Russ
>
>At 08:16 AM 11/19/2007, Denis Pinkas wrote:
>
> >Adriano,
> >
> >Thank you for this new proposal. I skimmed through it.
> >
> >It is interesting, but I fear that it is targeted to the wrong WG.
> >Since this would be an extension of CMS, this work item would rather
> >belong to the S-MIME WG.
> >For this reason, I copy the S-MIME WG.
> >
> >In addition, some polishing would be needed.
> >
> >Rather than long words, you will find hereafter a rewriting of the
> >ASN.1 with a few explanatory comments.
> >
> >    TimeStampedData ::= SEQUENCE {
> >       version        [0] Version DEFAULT v1,
> >       fileName           UTF8String,
> >       mimeType           PrintableString,
> >       fileLocation       UTF8String OPTIONAL,
> >       -- fileLocation is only a hint.
> >       -- The file may or may not be stored at that location.
> >       content            OCTET STRING,
> >       temporalEvidences  TemporalEvidences }
> >
> >    Version  ::=  INTEGER  { v1(0) }
> >    TemporalEvidences ::= SEQUENCE (SIZE(1..MAX)) OF TemporalEvidence
> >
> >-- This structure allows multiple levels of temporal evidences.
> >
> >    TemporalEvidence ::= SEQUENCE {
> >       evidences            Evidences,
> >       certificateLists     CertificateLists  OPTIONAL
> >}
> >
> >    CertificateLists :: = SEQUENCE (SIZE(1..MAX)) OF CertificateList
> >
> >    Evidence ::= CHOICE {
> >       timeStamps     [0] SEQUENCE (SIZE(1..MAX)) OF TimeStampToken }
> >
> >-- For each level there can be one or more time-stamps tokens.
> >
> >-- Before re-time stamping a set of former time-stamp tokens,
> >-- the CRLs of the previous level of time-stamps tokens can be captured
> >-- and inserted in the data structure.
> >
> >Denis
> >
> >
> > >Hello there,
> > >
> > >here I am again with my TimeStampedData proposal.
> > >
> > >I have submitted a new draft (also attached here) that takes into
> > account some of the remarks and suggestions received so far.
> > >
> > >I have made room for additional types of temporal evidence, like
> > e.g. RFC 4998, while keeping RFC 3161 as the basis of interoperability.
> > >
> > >I would like to invite everybody involved in time-stamping and
> > archiving e-documents to comment upon it: has it improved?
> > something is missing?
> > >
> > >In particular, please state:
> > >- are you interested in this work?
> > >- do you agree to adopt it as a new PKIX work item?
> > >- are you going to use this format, once it is finished?
> > >
> > >Is anybody willing to spend a few words on this draft during the
> > IETF meeting in Vancouver (as I cannot attend myself) ?
> > >
> > >And finally, is anybody willing to invest a little time in
> > co-authoring this draft with me?
> > >
> > >Adriano
> > >Actalis S.p.A.
> > >Milano, ITALY
> > >
> > >
> > >
> > >
> > >-----Messaggio originale-----
> > >Da: [email-masked]
> > [mailto:[email-masked]] Per conto di Santoni Adriano
> > >Inviato: lunedì 3 settembre 2007 10.42
> > >A: [email-masked]
> > >Oggetto: R: R: Draft on TimeStampedData
> > >
> > >
> > >Let me summarize the issues discussed so far:
> > >
> > >1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken (RFC
> > >3161)
> > >
> > >In principle, I have no objections as long as we do not complicate
> > things too much and do not hamper interoperability.
> > >
> > >There are at least two possible approaches to accomodate RFC 4998:
> > >
> > >   a) explicitly provide for (one) ER in the TimeStampedData
> > syntax, as an alternative to the SET OF TimeStampToken;
> > >   b) do not mention any specific standard for the "evidence", but
> > just mention RFC 3161 and RFC 4998 as two possibilities;
> > >
> > >In any case, it must be possible for the verifying application to
> > easily detect which of the two (or more) kind of "evidence" has been
> > used in the TimeStampedData envelope under examination. If we restrict
> > the kinds of evidence to the two above, then a extra tagging may not
> > be necessary, as an EvidenceRecord is a SEQUENCE, while the other
> > choice would be a SET OF. Although unelegant, it would work. On the
> > other hand, if we do not want to restrict the kinds of evidence to the
> > two above, then of course we should somehow add an extra tagging
> > level, because nobody knows at this time what syntax a third kind of
> > evidence would conform to.
> > >
> > >In any case, for the sake of interoperability, strong emphasis
> > should be given to RFC 3161 as today this is the most widely
> > implemented type of evidence.
> > >
> > >In conclusion: I agree with allowing RFC 4998 if we do that in a
> > way that does not modify the strong emphasis on RFC 3161 and does not
> > hamper interoperability (which must be based on supporting RFC 3161,
> > even though certain applications may also support RFC 4998).
> > >
> > >2) filename vs. URI
> > >
> > >Some remarked that an URI (or URI Reference) would be more
> > versatile than a simple filename. That is obviously true, but it
> > implies that the 'content' field of TimeStampedData may be empty.
> > This is not what I was addressing in my original proposal. It would
> > not just require the 'content' field to be declared OPTIONAL: it would
> > make interoperability very difficult to achieve unless we restrict the
> > URI schemes to a very small subset (e.g. http:, cid:, file:, ldap:) of
> > the myriad possibilities. In any case, it would require ages of
> > interoperability testing. And it would make life much harder for
> > software implementors, without much of a benefit in view. I strongly
> > believe in keeping things simple as much as possible.
> > >
> > >3) multiple contents and RFC 4073
> > >
> > >The 'content' field in the TimeStampedData envelope is not
> > structured, in my original proposal. It is just an OCTET STRING.
> > That allows for any kind of content to be conveyed, even a
> > ContentCollection according to RFC 4073.
> > >
> > >Another remark has been made with reference to RFC 4073: the
> > ContentWithAttributes structure, also defined in RFC 4073, could in
> > principle be used to bundle some content with the corrisponding
> > evidence (the goal of my draft). Although this is true, it would
> > require definining some additional OIDs, and mandating the presence of
> > certain Attributes tagged by those OIDs. I frankly believe the
> > TimeStampedData structure that I am proposing is better, first because
> > it is dedicated and second because it "implements the ContentInfo
> > interface", so to speak. It is simpler to manage for applications
> > already able to parse different kinds of ContentInfo envelopes (there
> > are a great many), possibly in a recursive way.
> > >
> > >Adriano
> > >
> > >
> > >-----Messaggio originale-----
> > >Da: Young H Etheridge [mailto:[email-masked]]
> > >Inviato: venerdì 31 agosto 2007 17.48
> > >A: Santoni Adriano
> > >Cc: [email-masked]
> > >Oggetto: Re: R: Draft on TimeStampedData
> > >
> > >Adriano,
> > >
> > >To add to your thought processes:  I believe that a URI of
> > "file:///private.stuff" addresses your concern for privacy of the
> > physical URI.  But, allowing URI in the syntax will make less private
> > repositories, not necessarily file systems, more universally
> > accessible.  The intent of the URI in RFC 3986 is to also allow for
> > abstractly identifying a resource, not necessarily providing a
> > physical resource.  In this manner the URI could then be used as an
> > object identity in database(s).
> > >
> > >Take care,
> > >
> > >yhe
> > >
> > >Santoni Adriano wrote:
> > >> To accomodate for RFC 4998, I would propose the following syntax:
> > >>
> > >> TimeStampedData ::= SEQUENCE {
> > >>      version                 INTEGER { v1(1) },
> > >>      fileName                UTF8String,
> > >>      mimeType                PrintableString,
> > >>      content         OCTET STRING,
> > >>      evidence                Evidence
> > >> }
> > >>
> > >> Evidence ::= CHOICE {
> > >>      timeStamps              [0] SET (SIZE(1..MAX)) OF TimeStampToken,
> > >>      evidenceRecord  [1] EvidenceRecord -- according to RFC 4998 }
> > >>
> > >> (I am not sure whether it would be better to use explicit or
> > >> implicit
> > >> tags...)
> > >>
> > >> Regarding the idea of having an URI instead of a filename: I'd
> > prefer to think over things a little bit more, and maybe collect 
> more feedback.
> > >>
> > >> In my mind, I can send a TimeStampedData envelope to business
> > partners and/or public agencies via email. If the timestamped document
> > is a local one, which I think is a meaningful and realistic scenario,
> > then I do not want my company's hostnames and pathnames to be included
> > in the envelope so that the recipient can see them.
> > >>
> > >> Adriano
> > >>
> > >>
> > >>
> > >> -----Messaggio originale-----
> > >> Da: [email-masked]
> > >> [mailto:[email-masked]]
> > >> Per conto di Julien Stern
> > >> Inviato: venerdì 31 agosto 2007 13.43
> > >> A: [email-masked]
> > >> Oggetto: Re: Draft on TimeStampedData
> > >>
> > >>
> > >> On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
> > >>
> > >>> Adriano,
> > >>>
> > >>>
> > >>>> After pondering on this and other remarks, I cannot help but
> > >>>> agree with Steve.
> > >>>>
> > >>>> My original and essential goal is that of facilitating
> > >>>> interoperability in a currently unregulated field. If we allow
> > >>>> for several "degrees of freedom", than interoperability will be
> > hampered from the beginning.
> > >>>> So I'd better stick to RFC 3161 for now. We could include support
> > >>>> for RFC 4998 Evidence Records later on, at the time when they
> > >>>> become a widespread reality comparable to RFC 3161
> > >>>> TimeStampTokens (which are widely implemented).
> > >>>>
> > >>> I would prefer to have both options: RFC 3161 and RFC 4998. For
> > >>> our customers evidence records are a widespread reality already.
> > >>> A standardized way to put some data and their evidence record into
> > >>> a single file would be useful.
> > >>>
> > >>
> > >> I strongly concur with this comment. Allowing the usage of ERS
> > as well as simple timestamps would allow the TimestampedData to
> > leverage all the work of RFC 4998 regarding timestamps instead of
> > reinventing the wheel in the future.
> > >>
> > >> Regards,
> > >>
> > >> --
> > >> Julien
> > >>
> > >>
> > >>> Kind regards
> > >>> Tilo
> > >>>
> > >>>
> > >>>
> > >>>> -----Messaggio originale-----
> > >>>> Da: Stephen Kent [mailto:[email-masked]]
> > >>>> Inviato: giovedì 30 agosto 2007 23.05
> > >>>> A: Young H Etheridge
> > >>>> Cc: Santoni Adriano; [email-masked]
> > >>>> Oggetto: Re: R: Draft on TimeStampedData
> > >>>>
> > >>>> At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
> > >>>>
> > >>>>>> ...
> > >>>>>>
> > >>>>> Agreed, w.r.t. normative vs informative.  The above quote from
> > >>>>> RFC-4998 merely underscores that this draft should also suggest,
> > >>>>> informatively, that the choice of Timestamp should be one that
> > >>>>> meets the normative syntax for Timestamp and not specify that
> > >>>>> which is in RFC-3161.  Nothing gets broken by being less
> > >>>>> restrictive and generally more informative to the community-at-large.
> > >>>>>
> > >>>> I have to disagree with your conclusion. If we require 3161
> > time stamps in an RFC of the sort Adriano proposed, then everyone can
> > parse them if they comply with the RFC. If the RFC says "insert the
> > time stamp from any standard you want here, and just tell us which one
> > you used" then we have a problem. A compliant implementation can
> > generate data structures containing time stamps that other compliant
> > implementations cannot parse. That's the sort of interoperability
> > problem we try to avoid in the IETF.
> > >>>>
> > >>>>
> > >>>>> My notion of resilience does not mean "more encompassing" but
> > >>>>> that of providing the user community with choice and an enhanced
> > >>>>> safeguard against the possibility of the weakening of an algorithm.
> > >>>>>
> > >>>> Choices can be good, but they can create interoperability
> > problems in some cases, like this one. Also, we have algorithm agility
> > as a requirement in all of our work, so the second concern you cite
> > does not seem to apply here.
> > >>>>
> > >>>> Steve
> > >>>>
> > >>> --
> > >>> Tilo Kienitz
> > >>> SecCommerce Informationssysteme GmbH Obenhauptstr. 5 D - 22335
> > >>> Hamburg
> > >>> Germany                                   http://www.seccommerce.de

Date: Fri, 23 Nov 2007 19:53:30 +0100
From: Bodo Moeller <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Eric Rescorla <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Mail-Followup-To: Bodo Moeller <[email-masked]>, Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Eric Rescorla <[email-masked]>
Sender: [email-masked]

On Fri, Nov 23, 2007 at 07:20:46AM -0800, Paul Hoffman wrote:
> At 12:53 PM +0100 11/22/07, Bodo Moeller wrote:
>>On Wed, Nov 21, 2007 at 11:26:53AM -0600, max pritikin wrote:

>>> Placing usage instructions in the certificate does not enforce the 
>>> verifying parties behavior any more than protocol handshakes would.  

>> It does provide authenticated usage information to the verifying
>> parties, though.

> Um, so? It is "authenticated" to be from a party that is not the 
> signer. In most situations, my CA doesn't have the slightest idea 
> what I am doing, or want to be doing, with my public key.

Only if you haven't told the CA what you want to do, by using
ExtensionReq and the like.

Of course, if you can't trust a CA to achieve a sufficiently close
approximation of what you want it do to, then that CA is pretty much
worthless.  If a CA starts to put other people's keys in certificates
naming you as the subject, say, that's pretty bad; if it does not
follow your requests regarding relevant certificate options, then
that's pretty bad too.

>> Consider the following scenario.  The SHA-3 competition is now open.
>> So one interesting business idea is to take the signature from any
>> certificate signed by some high-profile ECDSA or DSA root certificate
>> that is far away from expiring, and then to engineer a new hash
>> algorithm that appears sound and secure, except that it happens to
>> have a particularly interesting pre-image for the hash value from said
>> non-root certificate's signature: namely, a preimage that would
>> provide you with a certificate of your own with generous
>> basicConstraints, simply by reusing the previous signature coming from
>> the CA.  So you submit this hash function to the SHA-3 competition,
>> provide a reference implementation and hope that it ends up in relying
>> parties' software.  If this plan works out, suddenly you have become a
>> high-profile CA yourself -- even though in this particular example
>> none of the cryptographic algorithms involved would have to be
>> insecure in itself.

> Even if there were any "high-profile ECDSA or DSA root certificates", 
> they would contain the signature algorithm, which includes the hash 
> used, ecdsa-with-SHA1 or id-dsa-with-sha1, and that is covered by the 
> signature itself. This is no different than RSA.

Actually, it is different from RSA signatures.  PKCS #1 v1.5
RSA signatures do contain the hash used in unhashed form
(i.e. as a literal part of what you get when computing x^e mod n,
where x is the signature in question and e, n are the components
of the public key).  DSA and ECDSA signatures in a certificate, in
contrast, involve the algorithm identifer determining the hash
function only *as part of the hashed input*.  The literal
algorithm identifier does not affect the signature verification
calculation beyond providing part of the input to the hash function.

Bodo

Date: Fri, 23 Nov 2007 17:51:37 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Draft response to the liaison from ITU-T SG 17 to IETF on the resolution of DR320
Sender: [email-masked]

This is a multi-part message in MIME format.

--=====003_Dragon157875718364_=====
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="iso-8859-1"

Stephan,

Thank you for posting the agenda.

I noticed that 3.1 is about DR 320 : 
      Liaison statements received from ITU-T SG17 - 10 min
      Stefan Santesson (WG co-chair)
      https://datatracker.ietf.org/liaison/375/

I have prepared below a draft response to the liaison statement:

Draft response to the liaison from ITU-T SG 17 to IETF on the resolution of DR320 
 
See: https://datatracker.ietf.org/liaison/375/
 
Neither DNs of entities, nor DNs of CAs, can be unambiguous.
 
Within RFC 3280, every subject DN (whether it is an entity DN or a CA DN) 
is only unique for the CA that has picked that name. A CA is thus free to choose any DN 
for naming an entity without the need to find out if that name has already been used by 
some other CA in the world. 
There is currently no mechanism in place to prevent conflict, e.g. a list of existing CA names that deployers of new CAs could check for naming conflicts. There is no need to consider putting mechanisms in place to prevent conflict, e.g. a list of existing CA names that deployers of new CAs could check for naming conflicts.
The single requirement is the following: within a validation policy or within a signature policy 
there shall not be two different root CAs (trust anchors) with the same DN. 
 
This means that within RFC 3280 an ambiguous name is composed of a sequence of DNs, 
starting with the DN of a root CA and ending with the DN (or the Subject Alternate Name, 
if the DN is empty) of the entity.
 
This also means that a DN alone associated with a certificate serial number is unable to uniquely identify 
a public key certificate. 
 
However, if the DN is the DN from a certificate issuer whose certificate has been verified under a given 
validation policy or signature policy, then that DN can be characterized by a chain of upper CA names and 
then becomes unique under that validation or signature policy.
 
The liaison statement states: "Things break if two entities identify themselves using the same name". 
No evidence has been provided by ITU-T SG 17 to demonstrate that this statement is true. 
If it were, amendments to X.509 would need to be provided to deal with name collisions 
which are indeed possible, either intentionally or by accident. 

Denis

I have updated what I believe to be the final agenda for Vancouver.
We have now an almost full 2 hour program.
 http://www3.ietf.org/proceedings/07dec/agenda/pkix.txt
 Stefan Santesson
Senior Program Manager
Windows Security, Standards

--=====003_Dragon157875718364_=====
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1601" name=GENERATOR></HEAD>
<BODY>
<DIV>Stephan,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thank you for posting the agenda.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I noticed that 3.1 is about DR 320 :&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;Liaison statements received from ITU-T SG17 
- 10 min<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stefan Santesson (WG 
co-chair)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A 
href="https://datatracker.ietf.org/liaison/375/">https://datatracker.ietf.org/liaison/375/</A><BR></DIV>
<DIV>I have prepared below a draft response to the liaison statement:</DIV>
<DIV><B><SPAN style="FONT-SIZE: 13.5pt"></SPAN></B>&nbsp;</DIV>
<DIV><B><SPAN style="FONT-SIZE: 13.5pt">Draft response to the liaison from ITU-T 
SG 17 to IETF on the resolution of DR320 <o:p></o:p></SPAN></B></DIV>
<DIV>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US">See: 
https://datatracker.ietf.org/liaison/375/<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US">Neither DNs of entities, nor DNs of CAs, can be 
unambiguous.<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US">Within&nbsp;RFC 3280, every subject DN (whether 
it is an entity DN or a CA DN) </SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US">is only unique for the CA that has picked that 
name. A CA is thus free to choose any DN </SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US">for naming an entity without the need to find 
out if that name has already been used by </SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US">some other CA in the world. 
<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p></o:p></SPAN></P><PRE><SPAN lang=EN-US style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-US">There is currently no mechanism in place to prevent conflict, e.g. a list of existing CA names <BR>that deployers of new CAs could check for naming conflicts. There is no need to consider <BR>putting mechanisms in place to prevent conflict, e.g. a list of existing CA names that deployers <BR>of new CAs could check for naming conflicts.<o:p></o:p></SPAN></PRE>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US">The single requirement is the following: within 
a validation policy or within a signature policy <BR>there shall not be two 
different root CAs (trust anchors) with the same DN. <o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US">This means that within&nbsp;RFC 3280 an 
ambiguous name is composed of a sequence of DNs, <BR>starting with the DN of a 
root CA and ending with the DN (or the Subject Alternate Name, </SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US">if the DN is empty) of the 
entity.<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US">This also means that a DN alone associated with 
a certificate serial number is unable to uniquely identify <BR>a public key 
certificate. <o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US">However, if the DN is the DN from a certificate 
issuer whose certificate has been verified under a given <BR>validation policy 
or signature policy, then that DN can be characterized by a chain of upper CA 
names and <BR>then becomes unique under that validation or signature 
policy.<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p></o:p></SPAN><SPAN lang=EN-US 
style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-US">The 
liaison statement states: "Things break if two entities identify themselves 
using the same name". <BR>No evidence has been provided by ITU-T SG 17 to 
demonstrate that this statement is true. <BR>If it were, amendments to 
X.509&nbsp;would need to be provided to deal with name collisions <BR>which are 
indeed possible, either intentionally or by accident. <o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p></o:p></SPAN>&nbsp;</P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p>Denis</o:p></SPAN></P></DIV>
<DIV>&nbsp;</DIV>
<DIV>
<HR>
</DIV>
<DIV class=Section1>
<P class=MsoNormal><SPAN lang=EN-US>I have updated what I believe to be the 
final agenda for Vancouver.<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-US>We have now an almost full 2 hour 
program.<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-US><o:p>&nbsp;</o:p></SPAN><SPAN lang=EN-US><A 
href="http://www3.ietf.org/proceedings/07dec/agenda/pkix.txt">http://www3.ietf.org/proceedings/07dec/agenda/pkix.txt</A><o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-US><o:p>&nbsp;</o:p></SPAN><B><SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Arial','sans-serif'">Stefan 
Santesson</SPAN></B><SPAN lang=EN-GB 
style="FONT-SIZE: 12pt; COLOR: #1f497d; FONT-FAMILY: 'Times New Roman','serif'"><o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Senior 
Program Manager</SPAN><SPAN lang=EN-GB 
style="FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: 'Times New Roman','serif'"><o:p></o:p></SPAN></P>
<P class=MsoNormal><B><SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Windows 
Security, Standards</SPAN></B><SPAN lang=EN-US 
style="COLOR: #1f497d"><o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-US><o:p></o:p></SPAN></P></DIV>
<HR>
</BODY></HTML>

--=====003_Dragon157875718364_=====--

From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 23 Nov 2007 15:24:32 +0000
Subject: Agenda posted
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

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

I have updated what I believe to be the final agenda for Vancouver.
We have now an almost full 2 hour program.

http://www3.ietf.org/proceedings/07dec/agenda/pkix.txt

Stefan Santesson
Senior Program Manager
Windows Security, Standards

--_000_9F11911AED01D24BAA1C2355723C3D32032E20ADCAEAEXMSGC332eu_
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=
:oa=3D"urn:schemas-microsoft-com:office:activation" xmlns:html=3D"http://ww=
w.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/2=
003/xml" xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xm=
lns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:d=
s=3D"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.micros=
oft.com/sharepoint/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc"=
 xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" xmlns:sps=3D"http://schemas=
.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSch=
ema-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"htt=
p://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"http=
://schemas.microsoft.com/exchange/services/2006/messages" xmlns=3D"http://w=
ww.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:"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.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>I have updated what I believe to be=
 the
final agenda for Vancouver.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>We have now an almost full 2 hour p=
rogram.<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><a
href=3D"http://www3.ietf.org/proceedings/07dec/agenda/pkix.txt">http://www3=
.ietf.org/proceedings/07dec/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><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_9F11911AED01D24BAA1C2355723C3D32032E20ADCAEAEXMSGC332eu_--

Date: Fri, 23 Nov 2007 07:20:46 -0800
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Cc: Eric Rescorla <[email-masked]>
Sender: [email-masked]

At 12:53 PM +0100 11/22/07, Bodo Moeller wrote:
>On Wed, Nov 21, 2007 at 11:26:53AM -0600, max pritikin wrote:
>
>>  Placing usage instructions in the certificate does not enforce the 
>>  verifying parties behavior any more than protocol handshakes would.  
>
>It does provide authenticated usage information to the verifying
>parties, though.

Um, so? It is "authenticated" to be from a party that is not the 
signer. In most situations, my CA doesn't have the slightest idea 
what I am doing, or want to be doing, with my public key.

>Without such information, verifying parties cannot
>tell if the observed usage in any given handshake should be considered
>suspicious (and thus rejected) or is benign.

And with such information from my CA, they still have no idea.

>Consider the following scenario.  The SHA-3 competition is now open.
>So one interesting business idea is to take the signature from any
>certificate signed by some high-profile ECDSA or DSA root certificate
>that is far away from expiring, and then to engineer a new hash
>algorithm that appears sound and secure, except that it happens to
>have a particularly interesting pre-image for the hash value from said
>non-root certificate's signature: namely, a preimage that would
>provide you with a certificate of your own with generous
>basicConstraints, simply by reusing the previous signature coming from
>the CA.  So you submit this hash function to the SHA-3 competition,
>provide a reference implementation and hope that it ends up in relying
>parties' software.  If this plan works out, suddenly you have become a
>high-profile CA yourself -- even though in this particular example
>none of the cryptographic algorithms involved would have to be
>insecure in itself.

Even if there were any "high-profile ECDSA or DSA root certificates", 
they would contain the signature algorithm, which includes the hash 
used, ecdsa-with-SHA1 or id-dsa-with-sha1, and that is covered by the 
signature itself. This is no different than RSA.

--Paul Hoffman, Director
--VPN Consortium

Date: Thu, 22 Nov 2007 12:53:33 +0100
From: Bodo Moeller <[email-masked]>
To: max pritikin <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Mail-Followup-To: Bodo Moeller <[email-masked]>, max pritikin <[email-masked]>, Eric Rescorla <[email-masked]>, "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

On Wed, Nov 21, 2007 at 11:26:53AM -0600, max pritikin wrote:

> Placing usage instructions in the certificate does not enforce the  
> verifying parties behavior any more than protocol handshakes would.   

It does provide authenticated usage information to the verifying
parties, though.  Without such information, verifying parties cannot
tell if the observed usage in any given handshake should be considered
suspicious (and thus rejected) or is benign.

> Also it maybe more difficult if the certificate verification  
> operations are distinct from the protocol hashing operations. Paul's  
> example of key usage seems to be very topical.
> 
> Long lived device certificates would suffer from this approach. The  
> certificates on these devices (cable modems, wimax, IEEE 802.1AR, etc  
> etc etc) are profiled and baked well in advance. Attempting to expand  
> those profiles to limit the use of the credentials to particular hash  
> algorithms would be problematic.

One the one hand, you wouldn't *have* to use such hash algorithm
constraints in long-lived certificates for which you consider it
problematic.

On the other hand, this is where it is particularly important to
specify such constraints.  (You don't really need hash constraints to
prevent SHA-1 use of your (EC)DSA key that is only meant to be used
with SHA-256: Except with tiny probability, none of the signatures
that you ever generate using SHA-256 could be interpreted as a
SHA-1-based signature, unless the (EC)DSA subgroup you are using is
too small.)

Consider the following scenario.  The SHA-3 competition is now open.
So one interesting business idea is to take the signature from any
certificate signed by some high-profile ECDSA or DSA root certificate
that is far away from expiring, and then to engineer a new hash
algorithm that appears sound and secure, except that it happens to
have a particularly interesting pre-image for the hash value from said
non-root certificate's signature: namely, a preimage that would
provide you with a certificate of your own with generous
basicConstraints, simply by reusing the previous signature coming from
the CA.  So you submit this hash function to the SHA-3 competition,
provide a reference implementation and hope that it ends up in relying
parties' software.  If this plan works out, suddenly you have become a
high-profile CA yourself -- even though in this particular example
none of the cryptographic algorithms involved would have to be
insecure in itself.

If your are ambitious about security, then to avoid hash algorithm
substitution attacks of any kind, generally you'd want to limit the
use of any given key beforehand if at all possible.  I don't agree
that long-lived certificates are a severe obstacle to this.  If you
want algorithm flexibility for everyday use, then you can introduce an
intermediate CA whose certificate is updated sufficiently often,
always specifying the appropriate algorithm to use, while the root CA
would continue to use the initially chosen hash algorithms for the few
certificates that it signs.  If there is ever a time where you want
to completely exchange the set of allowed algorithms, why not take the
extra step and exchange the long-lived certificate as well?

Bodo

Content-class: urn:content-classes:message
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Date: Thu, 22 Nov 2007 12:21:53 +1100
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I agree with Ekr.
RFC 4055 â€œAdditional RSA Algorithms and Identifiersâ€
Â§8 â€œSecurity Considerationsâ€ describes the reasons for binding
a public key to a signature algorithm. It talks about RSA keys,
but the logic also applies to DSA keys -- in fact to any crypto key.

â€œGenerally, good cryptographic practice employs a given RSA key pair
in only one scheme.  This practice avoids the risk that vulnerability
in one scheme may compromise the security of the other, and may be
essential to maintain provable security.  While PKCS #1 Version 1.5
[P1v1.5] has been employed for both key transport and digital
signature without any known bad interactions, such a combined use of
an RSA key pair is not recommended in the future.  Therefore, an RSA
key pair used for RSASSA-PSS signature generation should not be used
for other purposes.  For similar reasons, one RSA key pair should
always be used with the same RSASSA-PSS parameters (except possibly
for the salt length).  Likewise, an RSA key pair used for RSAES-OAEP
key transport should not be used for other purposes.  For similar
reasons, one RSA key pair should always be used with the same RSAES-
OAEP parameters.â€

There actually have been â€œknown bad interactionsâ€ with PKCS #1 v1.5.
The â€œmillion-message attackâ€ against PKCS #1 v1.5 block-type 2 encryption
in SSL can be used to create a PKCS #1 v1.5 block-type 1 signature.
A certificate binding the SSL serverâ€™s public encryption key to a
specific encryption algorithm would prevent the forged signature from
being accepted.
In this case, a (critical) key usage extension would also suffice.

In practise, the benefits of being able to use a single key (for
signing and decrypting email, for acting as a TLS server and client,
for signing XML and authenticating in TLS) often far outweigh the
risk of bad interactions. That is, the risk that an operation in one
context being misinterpreted as an operation in a different context.
â€œOftenâ€ â€œin practiseâ€ is not â€œalwaysâ€ â€œfor all usersâ€ â€œin all circumstancesâ€.

Key usage (1), key purpose (2) and signature/encryption/transport
algorithm (3) are really three points on a continuum
for giving the certificate holder control over where the
key->name binding (which is the core of their certificate) will be used.
There is no theoretical reason to support controls 1 & 2, but not 3.

So we come down to practical objections:
* control 3 (eg over signature hash) will be used less than
  controls 1 & 2 (key usage & purpose) -- perhaps infrequently
  enough that it doesnâ€™t warrant inclusion in a standard
  for Internet use;
* key usage has been a disaster (according to Paul Hoffman),
  implying that deprecating the existing controls would be
  better than adding another (though such deprecation would
  cause too big a storm to contemplate);
* messy/painful/awkward to implement given the common divide
  between crypto libraries, cert processing libraries and
  application logic (this area is not my forte, but that is
  the impression I remember from Stefan Santesson --
  though it may only concern the placement of the control
  in subjectPublicKeyInfo vs in an extension);
* existing public CAs donâ€™t (that I have seen) allow certificate
  holders to arbitrarily specify the key usage or purposes they want
  (other than choosing a server or code signing cert) so
  they are unlikely to allow algorithms to be specified,
  which means any extension has little hope of widespread deployment;
* interoperability issues where a certificate holder wants
  one algorithm, but a relying party wants another
  (this is a clash of deliberate crypto choices (policy),
  not syntax details -- but the resulting frustration is similar).

My gut feel is that a new extension holding â€œalgorithm identifier
matching rulesâ€ should be defined.
List hash:SHA-1 in the extension, mark it critical,
and pray that the other end understands.

----------
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Rescorla

 	My claim is that for security reasons it's necessary for DSA
 	certs to indicate the hash algorithm(s) that may be used with
 	the public key contained in the cert. This prevents hash
 	algorithm substitution in signatures formed with that key
	(or rather the private key that corresponds to that key). Do
 	you agree with this?

-Ekr

Date: Wed, 21 Nov 2007 14:53:49 -0500
To: Eric Rescorla <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Cc: Stefan Santesson <[email-masked]>, Eric Rescorla <[email-masked]>, "Manger, James H" <[email-masked]>, "[email-masked]"	<[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

At 6:57 AM -0800 11/21/07, Eric Rescorla wrote:

>...
>  > Is there any studies out there showing that this is a real security
>>  issue (has any realistic chance of being exploited) or are we simply
>>  chasing a ghost far away from the scene of real internet crime?
>
>Is this the current PKIX standard for work items?
>
>-Ekr

Two observations:

PKIX does take into account the viability of attacks when deciding 
how to address newly discovered vulnerabilities.  So, for example, we 
noted that a CA could assign non-predictable cert serial numbers as a 
countermeasure to the first published hash attacks, which rely on the 
attacker being able to know/control the prefix of a signed object 
such as a cert submitted in a cert request.

Several of the recent messages refer to problem of using the right 
hash algorithm with a given signature algorithm and key size.  PKIX 
will certainly address this problem in the context of our data 
objects, e.g., certs. It is less clear whether PKIX should advocate 
carriage of additional data in certs to assist other protocols in 
this area. One could define suitable conventions for hash alg and 
signature alg/key size in the context of each protocol, for example.

That doesn't mean we ought not consider an extension for carrying 
this info, but as several there  folks have pointed out, this 
approach has problems too:

	- a CA may not want to assume liability for putting this info 
into a cert

	- a cert lifetime many not match the time frame for 
expressing new algorithm pairing info

	- an application/protocol or a CAPI may not have ready access 
to a private extension used  to convey this info

We have to proceed cautiously here. I am not (yet) ruling out an 
extension to carry such info, if these issue can be addressed.

Steve

Date: Wed, 21 Nov 2007 10:03:59 -0800
From: Eric Rescorla <[email-masked]>
To: max pritikin <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, Paul Hoffman <[email-masked]>, Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Sender: [email-masked]

At Wed, 21 Nov 2007 11:26:53 -0600,
max pritikin wrote:
> Placing usage instructions in the certificate does not enforce the  
> verifying parties behavior any more than protocol handshakes would.   

It's not a matter of enforcement than information.
Again, there's no way to do this in the protocol handshake
because it needs to be authenticated by a separate mechanism.

> Paul's  
> example of key usage seems to be very topical.
> 
> Long lived device certificates would suffer from this approach. The  
> certificates on these devices (cable modems, wimax, IEEE 802.1AR, etc  
> etc etc) are profiled and baked well in advance. Attempting to expand  
> those profiles to limit the use of the credentials to particular hash  
> algorithms would be problematic.

No more than limiting them to particular signature algorithms,
which is baked into the certificate right now. In fact, I'd
observe that current DSA certificates are effectively
restricted to SHA-1 right now in that there is no DSS for 
DSA with other digests.

-Ekr

Cc: Paul Hoffman <[email-masked]>, Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
From: max pritikin <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Date: Wed, 21 Nov 2007 11:26:53 -0600
To: Eric Rescorla <[email-masked]>
Sender: [email-masked]

Placing usage instructions in the certificate does not enforce the  
verifying parties behavior any more than protocol handshakes would.   
Also it maybe more difficult if the certificate verification  
operations are distinct from the protocol hashing operations. Paul's  
example of key usage seems to be very topical.

Long lived device certificates would suffer from this approach. The  
certificates on these devices (cable modems, wimax, IEEE 802.1AR, etc  
etc etc) are profiled and baked well in advance. Attempting to expand  
those profiles to limit the use of the credentials to particular hash  
algorithms would be problematic.

- max

On Nov 21, 2007, at 10:52 AM, Eric Rescorla wrote:

>
> At Wed, 21 Nov 2007 08:50:33 -0800,
> Paul Hoffman wrote:
>>
>> At 6:57 AM -0800 11/21/07, Eric Rescorla wrote:
>>> We're talking about two different kinds of downgrade here.
>>> The S/MIME anti-downgrade issue is about signature stripping
>>> when multiple signatures are applied. The downgrade issue
>>> I'm concerned about is straight-line forgery: Alice always
>>> signs with digest algorithm H1: she then generates a signature
>>> over some message M where H1(M) = X. The attacker compromises H2
>>> and forms M' st. H2(M2) = X. He can then craft a new message
>>> apparently signed by Alice. There's no act that Alice can take
>>> involving H1 and her signature algorithm that can prevent this:
>>> it has to be in information available to a verifier who has only
>>> the cert and a candidate signature.
>>
>> The proposed solution of an extension that says which hash functions
>> can be used with the public key in a cert has a few flaws. First, it
>> means that all CAs must understand the safety of all the hash
>> algorithms out there to know to not list H2.
>
> Not really, no. As I said, I think this is pretty much an issue
> of matching SHA variant to DSA key size. I agree that this is
> imperfect, but the situation is imperfect.
>
>
>> In some sense, they must
>> all predict the future as well, because they might list H2 today and
>> then next year find out that some set of Mallorys have compromised
>> it. Further, this puts CAs into the position of saying what can and
>> cannot be done with a public key; "key usage" has proven this to be a
>> disaster.
>
> This strikes me as a pretty different case.
>
>
>> Instead, we have to assume that all relying parties need to know
>> which of the hash algorithms that they know how to use are
>> trustworthy, and which aren't. Hopefully, for any that are not, the
>> relying party simply forgets how to use it, or marks it as poisoned.
>
> This seems highly undesirable from the perspective of the
> verifying party, who has opinions about what digests he
> will use, but who needs the relying party to enforce it.
>
> -Ekr

Date: Wed, 21 Nov 2007 08:52:57 -0800
From: Eric Rescorla <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Sender: [email-masked]

At Wed, 21 Nov 2007 08:50:33 -0800,
Paul Hoffman wrote:
> 
> At 6:57 AM -0800 11/21/07, Eric Rescorla wrote:
> >We're talking about two different kinds of downgrade here.
> >The S/MIME anti-downgrade issue is about signature stripping
> >when multiple signatures are applied. The downgrade issue
> >I'm concerned about is straight-line forgery: Alice always
> >signs with digest algorithm H1: she then generates a signature
> >over some message M where H1(M) = X. The attacker compromises H2
> >and forms M' st. H2(M2) = X. He can then craft a new message
> >apparently signed by Alice. There's no act that Alice can take
> >involving H1 and her signature algorithm that can prevent this:
> >it has to be in information available to a verifier who has only
> >the cert and a candidate signature.
> 
> The proposed solution of an extension that says which hash functions 
> can be used with the public key in a cert has a few flaws. First, it 
> means that all CAs must understand the safety of all the hash 
> algorithms out there to know to not list H2.

Not really, no. As I said, I think this is pretty much an issue
of matching SHA variant to DSA key size. I agree that this is
imperfect, but the situation is imperfect.

> In some sense, they must 
> all predict the future as well, because they might list H2 today and 
> then next year find out that some set of Mallorys have compromised 
> it. Further, this puts CAs into the position of saying what can and 
> cannot be done with a public key; "key usage" has proven this to be a 
> disaster.

This strikes me as a pretty different case.

> Instead, we have to assume that all relying parties need to know 
> which of the hash algorithms that they know how to use are 
> trustworthy, and which aren't. Hopefully, for any that are not, the 
> relying party simply forgets how to use it, or marks it as poisoned.

This seems highly undesirable from the perspective of the
verifying party, who has opinions about what digests he
will use, but who needs the relying party to enforce it.

-Ekr

Date: Wed, 21 Nov 2007 08:50:33 -0800
To: Eric Rescorla <[email-masked]>, Stefan Santesson <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

At 6:57 AM -0800 11/21/07, Eric Rescorla wrote:
>We're talking about two different kinds of downgrade here.
>The S/MIME anti-downgrade issue is about signature stripping
>when multiple signatures are applied. The downgrade issue
>I'm concerned about is straight-line forgery: Alice always
>signs with digest algorithm H1: she then generates a signature
>over some message M where H1(M) = X. The attacker compromises H2
>and forms M' st. H2(M2) = X. He can then craft a new message
>apparently signed by Alice. There's no act that Alice can take
>involving H1 and her signature algorithm that can prevent this:
>it has to be in information available to a verifier who has only
>the cert and a candidate signature.

The proposed solution of an extension that says which hash functions 
can be used with the public key in a cert has a few flaws. First, it 
means that all CAs must understand the safety of all the hash 
algorithms out there to know to not list H2. In some sense, they must 
all predict the future as well, because they might list H2 today and 
then next year find out that some set of Mallorys have compromised 
it. Further, this puts CAs into the position of saying what can and 
cannot be done with a public key; "key usage" has proven this to be a 
disaster.

Instead, we have to assume that all relying parties need to know 
which of the hash algorithms that they know how to use are 
trustworthy, and which aren't. Hopefully, for any that are not, the 
relying party simply forgets how to use it, or marks it as poisoned.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 21 Nov 2007 06:57:49 -0800
From: Eric Rescorla <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, "Manger, James H" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Sender: [email-masked]

At Wed, 21 Nov 2007 12:47:58 +0000,
Stefan Santesson wrote:
> 
> This is not the place to request it, but I really think we should
> bring this up in a common meeting like the saag, because it is a
> general problem that is relevant cross protocols.
> 
> Trying to solve downgrade problems by stuffing hash limitations in
> the certificate worries me, feels like the easy way out for the
> protocol designers and principally wrong.

I don't know what you mean by "the easy way out". TLS, for
instance, has extensive anti-downgrade provisions. But this
particular one cannot go in the protocol, because it's
fundamentally tied to the signing key. [The exception here
is to make an explicit tie to key length, i.e., keys of 
length X need SHA-1. I'll note that this is what FIPS 186-3
already does but it's notmandatory.]

> As pointed out, it makes management of hash selection a lot harder
> and a slow moving target as it requires certificate issuance to
> match the hash policy.

I don't see this. What I would expect would simply be that
certificates would be issued with digest algorithms that
match the FIPS 186-3 recommendations. 

> As a basic principle I think the major effort to transition to
> better hashes is to upgrade the capability of communicating hosts
> before the lowest grade of hash used becomes a realistic security
> issue.

This isn't about turning on new hashes, it's about allowing
old ones to be used once the new ones are turned on during
the transition period.

> As a secondary solution protocols could be amended to protect
> against downgrading, as with S/MIME and as a last resort enhance the
> certificates.

We're talking about two different kinds of downgrade here.
The S/MIME anti-downgrade issue is about signature stripping
when multiple signatures are applied. The downgrade issue
I'm concerned about is straight-line forgery: Alice always
signs with digest algorithm H1: she then generates a signature
over some message M where H1(M) = X. The attacker compromises H2
and forms M' st. H2(M2) = X. He can then craft a new message
apparently signed by Alice. There's no act that Alice can take
involving H1 and her signature algorithm that can prevent this:
it has to be in information available to a verifier who has only
the cert and a candidate signature.

> Is there any studies out there showing that this is a real security
> issue (has any realistic chance of being exploited) or are we simply
> chasing a ghost far away from the scene of real internet crime?

Is this the current PKIX standard for work items?

-Ekr

Cc: Eric Rescorla <[email-masked]>, "Manger, James H" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
From: max pritikin <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Date: Wed, 21 Nov 2007 08:34:19 -0600
To: Stefan Santesson <[email-masked]>
Sender: [email-masked]

I too feel that placing protocol hints in the certificate is a bad  
way to go.

	- max

On Nov 21, 2007, at 6:47 AM, Stefan Santesson wrote:

>
> This is not the place to request it, but I really think we should  
> bring this up in a common meeting like the saag, because it is a  
> general problem that is relevant cross protocols.
>
> Trying to solve downgrade problems by stuffing  hash limitations in  
> the certificate worries me, feels like the easy way out for the  
> protocol designers and principally wrong.
> As pointed out, it makes management of hash selection a lot harder  
> and a slow moving target as it requires certificate issuance to  
> match the hash policy.
>
> As a basic principle I think the major effort to transition to  
> better hashes is to upgrade the capability of communicating hosts  
> before the lowest grade of hash used becomes a realistic security  
> issue. As a secondary solution protocols could be amended to  
> protect against downgrading, as with S/MIME and as a last resort  
> enhance the certificates.
>
> Is there any studies out there showing that this is a real security  
> issue (has any realistic chance of being exploited) or are we  
> simply chasing a ghost far away from the scene of real internet crime?
>
>
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
>
>> -----Original Message-----
>> From: Eric Rescorla [mailto:[email-masked]]
>> Sent: den 20 november 2007 18:34
>> To: Stefan Santesson
>> Cc: Manger, James H; [email-masked]; [email-masked]
>> Subject: Re: [TLS] DSA/SHA-1, and OIDs
>>
>> At Tue, 20 Nov 2007 16:19:40 +0000,
>> Stefan Santesson wrote:
>>>
>>> [1  <text/plain; utf-8 (base64)>]
>>> James,
>>>
>>> The design team has met again and will talk about it at the PKIX
>> meeting.
>>> However, this has never extended beyond the public key algorithm
>> itself.
>>> No one has seriously requested a full signature algorithm with hash
>> algorithm to be specified in this field.
>>
>> Please take this message as a request from me that it be so, at
>> least for DSA/ECSDA.
>>
>> -Ekr

From: Stefan Santesson <[email-masked]>
To: Eric Rescorla <[email-masked]>
CC: "Manger, James H" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 21 Nov 2007 12:47:58 +0000
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

This is not the place to request it, but I really think we should bring this up in a common meeting like the saag, because it is a general problem that is relevant cross protocols.

Trying to solve downgrade problems by stuffing  hash limitations in the certificate worries me, feels like the easy way out for the protocol designers and principally wrong.
As pointed out, it makes management of hash selection a lot harder and a slow moving target as it requires certificate issuance to match the hash policy.

As a basic principle I think the major effort to transition to better hashes is to upgrade the capability of communicating hosts before the lowest grade of hash used becomes a realistic security issue. As a secondary solution protocols could be amended to protect against downgrading, as with S/MIME and as a last resort enhance the certificates.

Is there any studies out there showing that this is a real security issue (has any realistic chance of being exploited) or are we simply chasing a ghost far away from the scene of real internet crime?

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]]
> Sent: den 20 november 2007 18:34
> To: Stefan Santesson
> Cc: Manger, James H; [email-masked]; [email-masked]
> Subject: Re: [TLS] DSA/SHA-1, and OIDs
>
> At Tue, 20 Nov 2007 16:19:40 +0000,
> Stefan Santesson wrote:
> >
> > [1  <text/plain; utf-8 (base64)>]
> > James,
> >
> > The design team has met again and will talk about it at the PKIX
> meeting.
> > However, this has never extended beyond the public key algorithm
> itself.
> > No one has seriously requested a full signature algorithm with hash
> algorithm to be specified in this field.
>
> Please take this message as a request from me that it be so, at
> least for DSA/ECSDA.
>
> -Ekr

Content-class: urn:content-classes:message
Subject: R: TimeStampedData draft updated - please comment
Date: Wed, 21 Nov 2007 08:46:18 +0100
From: "Santoni Adriano" <[email-masked]>
To: "Russ Housley" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Russ,

I am not sure if you were addressing your comment to me or to Denis...

At any rate, I would like to point out that the syntax I am proposing implies no MIME encoding at all. The data (like e.g. a patent, an offer, a contract, an income statement, a device driver, a security patch, a sensitive database, etc) is bundled in its native form, "as is". And thus, there is no MIME header to speak of. That's why I have provided for a 'mimeType' field: as a hint for the recipient/verifying application to guess what kind of data is carried within the TimeStampedData block, and what to do with it.

Adriano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Russ Housley
Inviato: martedì 20 novembre 2007 22.53
A: [email-masked]; [email-masked]
Oggetto: Re: TimeStampedData draft updated - please comment

In S/MIME, the id-data content type is used when the content is MIME encoded.  Then, then MIME header in the content is used to determine the format of the content.  Why does this suggest a different approach?

Russ

At 08:16 AM 11/19/2007, Denis Pinkas wrote:

>Adriano,
>
>Thank you for this new proposal. I skimmed through it.
>
>It is interesting, but I fear that it is targeted to the wrong WG.
>Since this would be an extension of CMS, this work item would rather 
>belong to the S-MIME WG.
>For this reason, I copy the S-MIME WG.
>
>In addition, some polishing would be needed.
>
>Rather than long words, you will find hereafter a rewriting of the 
>ASN.1 with a few explanatory comments.
>
>    TimeStampedData ::= SEQUENCE {
>       version        [0] Version DEFAULT v1,
>       fileName           UTF8String,
>       mimeType           PrintableString,
>       fileLocation       UTF8String OPTIONAL,
>       -- fileLocation is only a hint.
>       -- The file may or may not be stored at that location.
>       content            OCTET STRING,
>       temporalEvidences  TemporalEvidences }
>
>    Version  ::=  INTEGER  { v1(0) }
>    TemporalEvidences ::= SEQUENCE (SIZE(1..MAX)) OF TemporalEvidence
>
>-- This structure allows multiple levels of temporal evidences.
>
>    TemporalEvidence ::= SEQUENCE {
>       evidences            Evidences,
>       certificateLists     CertificateLists  OPTIONAL
>}
>
>    CertificateLists :: = SEQUENCE (SIZE(1..MAX)) OF CertificateList
>
>    Evidence ::= CHOICE {
>       timeStamps     [0] SEQUENCE (SIZE(1..MAX)) OF TimeStampToken }
>
>-- For each level there can be one or more time-stamps tokens.
>
>-- Before re-time stamping a set of former time-stamp tokens,
>-- the CRLs of the previous level of time-stamps tokens can be captured
>-- and inserted in the data structure.
>
>Denis
>
>
> >Hello there,
> >
> >here I am again with my TimeStampedData proposal.
> >
> >I have submitted a new draft (also attached here) that takes into
> account some of the remarks and suggestions received so far.
> >
> >I have made room for additional types of temporal evidence, like
> e.g. RFC 4998, while keeping RFC 3161 as the basis of interoperability.
> >
> >I would like to invite everybody involved in time-stamping and
> archiving e-documents to comment upon it: has it improved? 
> something is missing?
> >
> >In particular, please state:
> >- are you interested in this work?
> >- do you agree to adopt it as a new PKIX work item?
> >- are you going to use this format, once it is finished?
> >
> >Is anybody willing to spend a few words on this draft during the
> IETF meeting in Vancouver (as I cannot attend myself) ?
> >
> >And finally, is anybody willing to invest a little time in
> co-authoring this draft with me?
> >
> >Adriano
> >Actalis S.p.A.
> >Milano, ITALY
> >
> >
> >
> >
> >-----Messaggio originale-----
> >Da: [email-masked]
> [mailto:[email-masked]] Per conto di Santoni Adriano
> >Inviato: lunedì 3 settembre 2007 10.42
> >A: [email-masked]
> >Oggetto: R: R: Draft on TimeStampedData
> >
> >
> >Let me summarize the issues discussed so far:
> >
> >1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken (RFC 
> >3161)
> >
> >In principle, I have no objections as long as we do not complicate
> things too much and do not hamper interoperability.
> >
> >There are at least two possible approaches to accomodate RFC 4998:
> >
> >   a) explicitly provide for (one) ER in the TimeStampedData
> syntax, as an alternative to the SET OF TimeStampToken;
> >   b) do not mention any specific standard for the "evidence", but
> just mention RFC 3161 and RFC 4998 as two possibilities;
> >
> >In any case, it must be possible for the verifying application to
> easily detect which of the two (or more) kind of "evidence" has been 
> used in the TimeStampedData envelope under examination. If we restrict 
> the kinds of evidence to the two above, then a extra tagging may not 
> be necessary, as an EvidenceRecord is a SEQUENCE, while the other 
> choice would be a SET OF. Although unelegant, it would work. On the 
> other hand, if we do not want to restrict the kinds of evidence to the 
> two above, then of course we should somehow add an extra tagging 
> level, because nobody knows at this time what syntax a third kind of 
> evidence would conform to.
> >
> >In any case, for the sake of interoperability, strong emphasis
> should be given to RFC 3161 as today this is the most widely 
> implemented type of evidence.
> >
> >In conclusion: I agree with allowing RFC 4998 if we do that in a
> way that does not modify the strong emphasis on RFC 3161 and does not 
> hamper interoperability (which must be based on supporting RFC 3161, 
> even though certain applications may also support RFC 4998).
> >
> >2) filename vs. URI
> >
> >Some remarked that an URI (or URI Reference) would be more
> versatile than a simple filename. That is obviously true, but it 
> implies that the 'content' field of TimeStampedData may be empty.
> This is not what I was addressing in my original proposal. It would 
> not just require the 'content' field to be declared OPTIONAL: it would 
> make interoperability very difficult to achieve unless we restrict the 
> URI schemes to a very small subset (e.g. http:, cid:, file:, ldap:) of 
> the myriad possibilities. In any case, it would require ages of 
> interoperability testing. And it would make life much harder for 
> software implementors, without much of a benefit in view. I strongly 
> believe in keeping things simple as much as possible.
> >
> >3) multiple contents and RFC 4073
> >
> >The 'content' field in the TimeStampedData envelope is not
> structured, in my original proposal. It is just an OCTET STRING. 
> That allows for any kind of content to be conveyed, even a 
> ContentCollection according to RFC 4073.
> >
> >Another remark has been made with reference to RFC 4073: the
> ContentWithAttributes structure, also defined in RFC 4073, could in 
> principle be used to bundle some content with the corrisponding 
> evidence (the goal of my draft). Although this is true, it would 
> require definining some additional OIDs, and mandating the presence of 
> certain Attributes tagged by those OIDs. I frankly believe the 
> TimeStampedData structure that I am proposing is better, first because 
> it is dedicated and second because it "implements the ContentInfo 
> interface", so to speak. It is simpler to manage for applications 
> already able to parse different kinds of ContentInfo envelopes (there 
> are a great many), possibly in a recursive way.
> >
> >Adriano
> >
> >
> >-----Messaggio originale-----
> >Da: Young H Etheridge [mailto:[email-masked]]
> >Inviato: venerdì 31 agosto 2007 17.48
> >A: Santoni Adriano
> >Cc: [email-masked]
> >Oggetto: Re: R: Draft on TimeStampedData
> >
> >Adriano,
> >
> >To add to your thought processes:  I believe that a URI of
> "file:///private.stuff" addresses your concern for privacy of the 
> physical URI.  But, allowing URI in the syntax will make less private 
> repositories, not necessarily file systems, more universally 
> accessible.  The intent of the URI in RFC 3986 is to also allow for 
> abstractly identifying a resource, not necessarily providing a 
> physical resource.  In this manner the URI could then be used as an 
> object identity in database(s).
> >
> >Take care,
> >
> >yhe
> >
> >Santoni Adriano wrote:
> >> To accomodate for RFC 4998, I would propose the following syntax:
> >>
> >> TimeStampedData ::= SEQUENCE {
> >>      version                 INTEGER { v1(1) },
> >>      fileName                UTF8String,
> >>      mimeType                PrintableString,
> >>      content         OCTET STRING,
> >>      evidence                Evidence
> >> }
> >>
> >> Evidence ::= CHOICE {
> >>      timeStamps              [0] SET (SIZE(1..MAX)) OF TimeStampToken,
> >>      evidenceRecord  [1] EvidenceRecord -- according to RFC 4998 }
> >>
> >> (I am not sure whether it would be better to use explicit or 
> >> implicit
> >> tags...)
> >>
> >> Regarding the idea of having an URI instead of a filename: I'd
> prefer to think over things a little bit more, and maybe collect more feedback.
> >>
> >> In my mind, I can send a TimeStampedData envelope to business
> partners and/or public agencies via email. If the timestamped document 
> is a local one, which I think is a meaningful and realistic scenario, 
> then I do not want my company's hostnames and pathnames to be included 
> in the envelope so that the recipient can see them.
> >>
> >> Adriano
> >>
> >>
> >>
> >> -----Messaggio originale-----
> >> Da: [email-masked] 
> >> [mailto:[email-masked]]
> >> Per conto di Julien Stern
> >> Inviato: venerdì 31 agosto 2007 13.43
> >> A: [email-masked]
> >> Oggetto: Re: Draft on TimeStampedData
> >>
> >>
> >> On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
> >>
> >>> Adriano,
> >>>
> >>>
> >>>> After pondering on this and other remarks, I cannot help but 
> >>>> agree with Steve.
> >>>>
> >>>> My original and essential goal is that of facilitating 
> >>>> interoperability in a currently unregulated field. If we allow 
> >>>> for several "degrees of freedom", than interoperability will be
> hampered from the beginning.
> >>>> So I'd better stick to RFC 3161 for now. We could include support 
> >>>> for RFC 4998 Evidence Records later on, at the time when they 
> >>>> become a widespread reality comparable to RFC 3161 
> >>>> TimeStampTokens (which are widely implemented).
> >>>>
> >>> I would prefer to have both options: RFC 3161 and RFC 4998. For 
> >>> our customers evidence records are a widespread reality already.
> >>> A standardized way to put some data and their evidence record into 
> >>> a single file would be useful.
> >>>
> >>
> >> I strongly concur with this comment. Allowing the usage of ERS
> as well as simple timestamps would allow the TimestampedData to 
> leverage all the work of RFC 4998 regarding timestamps instead of 
> reinventing the wheel in the future.
> >>
> >> Regards,
> >>
> >> --
> >> Julien
> >>
> >>
> >>> Kind regards
> >>> Tilo
> >>>
> >>>
> >>>
> >>>> -----Messaggio originale-----
> >>>> Da: Stephen Kent [mailto:[email-masked]]
> >>>> Inviato: giovedì 30 agosto 2007 23.05
> >>>> A: Young H Etheridge
> >>>> Cc: Santoni Adriano; [email-masked]
> >>>> Oggetto: Re: R: Draft on TimeStampedData
> >>>>
> >>>> At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
> >>>>
> >>>>>> ...
> >>>>>>
> >>>>> Agreed, w.r.t. normative vs informative.  The above quote from
> >>>>> RFC-4998 merely underscores that this draft should also suggest, 
> >>>>> informatively, that the choice of Timestamp should be one that 
> >>>>> meets the normative syntax for Timestamp and not specify that 
> >>>>> which is in RFC-3161.  Nothing gets broken by being less 
> >>>>> restrictive and generally more informative to the community-at-large.
> >>>>>
> >>>> I have to disagree with your conclusion. If we require 3161
> time stamps in an RFC of the sort Adriano proposed, then everyone can 
> parse them if they comply with the RFC. If the RFC says "insert the 
> time stamp from any standard you want here, and just tell us which one 
> you used" then we have a problem. A compliant implementation can 
> generate data structures containing time stamps that other compliant 
> implementations cannot parse. That's the sort of interoperability 
> problem we try to avoid in the IETF.
> >>>>
> >>>>
> >>>>> My notion of resilience does not mean "more encompassing" but 
> >>>>> that of providing the user community with choice and an enhanced 
> >>>>> safeguard against the possibility of the weakening of an algorithm.
> >>>>>
> >>>> Choices can be good, but they can create interoperability
> problems in some cases, like this one. Also, we have algorithm agility 
> as a requirement in all of our work, so the second concern you cite 
> does not seem to apply here.
> >>>>
> >>>> Steve
> >>>>
> >>> --
> >>> Tilo Kienitz
> >>> SecCommerce Informationssysteme GmbH Obenhauptstr. 5 D - 22335 
> >>> Hamburg
> >>> Germany                                   http://www.seccommerce.de

Date: 21 Nov 2007 02:39:07 -0000
From: "Rodrigo Botafogo" <[email-masked]>
To: "Ietf-Pkix" <[email-masked]>
Subject: Your Contact Info
Sender: [email-masked]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html><head><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Your Contact Info</title>
</head>

<body bgcolor="#6897cf">
<div align="center">
      <div align="center">
        <table width="580" border="0" cellspacing="0" cellpadding="0" height="20">
          <tr height="20">
            <td valign="top" width="100" height="20"></td>
          </tr>
        </table>
      </div>
      <table width="580" border="0" cellspacing="0" cellpadding="0" align="center" bgcolor="#ffffff" height="72">
        <tr align="left" valign="top">
          <td align="left" valign="top">
            <div align="left">
              <img src="http://www.plaxo.com/images/server/email/share_connect/corner_white1.gif" alt="" width="4" height="4" border="0" /></div>
          </td>
          <td colspan="2">
            <div align="right">
              <img src="http://www.plaxo.com/images/server/email/share_connect/plaxo_logo2.gif" alt="Plaxo | Your address book for life" width="274" height="59" border="0" /></div>
          </td>
        </tr>
      </table>
      <table width="580" border="0" cellspacing="0" cellpadding="0" align="center" bgcolor="#ffffff">
        <tr align="left" valign="top" height="45">
          <td width="60" height="45"></td>
          
          <td align="right" valign="bottom" height="45">
            <div align="left">
              <font size="-1" color="#0071bb" face="Arial"><strong>A Plaxo member would like to connect with you<br />
                </strong></font><font size="-1" color="#666666" face="Arial">From: Rodrigo Botafogo, Diretor de Tecnologia, CertiSign Certificadora Digital S.A
                 
                 </font></div>
          </td>
        </tr>
      </table>
      <table width="580" border="0" cellspacing="0" cellpadding="0" bgcolor="white" height="30">
        <tr valign="top">
          <td valign="bottom"><img src="http://www.plaxo.com/images/server/email/share_connect/blue_ramp.gif" alt="" width="100%" height="20" border="0" /></td>
        </tr>
      </table>
      <table width="580" border="0" cellspacing="0" cellpadding="0" align="center" bgcolor="#ffffff" height="250">
        <tr align="left" valign="top" height="120">
          <td rowspan="2" align="left" valign="top" width="60" height="250">
            <div align="left"></div>
          </td>
          <td rowspan="2" colspan="2" align="left" valign="middle" height="250">

           <table height="250"><tr><td  height="100%"  valign="center">

           <font size="-1" color="#666666" face="Arial">
           <br />
           
            Estou usando o Plaxo para manter minha agenda de contatos atualizada. Por que você não me envia suas informações de contato mais atuais? Se você fizer parte do Plaxo, sempre teremos as informações de contato mais atuais um do outro nas nossas agendas.<br><br>Obrigado!<br><br>
           
            <br />
            </font>

           </td></tr>

           </table>
          </td>
          <td rowspan="2" align="right" valign="top" width="60" height="250"></td>
        </tr>
        <tr align="left" valign="top" height="130"></tr>
      </table>
      <table width="580" border="0" cellspacing="0" cellpadding="0" align="center" bgcolor="#fffacc" height="105">
        <tr align="center" valign="top" height="40">
          <td rowspan="3" align="left" valign="bottom" width="60">
            <div align="left">
              <img src="http://www.plaxo.com/images/server/email/share_connect/corner_yellow3.gif" alt="" width="2" height="2" border="0" /></div>
          </td>
          <td colspan="2" valign="bottom" height="40">

          </td>
          <td rowspan="3" align="right" valign="bottom" width="60"><img src="http://www.plaxo.com/images/server/email/share_connect/corner_yellow4.gif" alt="" width="2" height="2" border="0" /></td>
        </tr>
        <tr align="center">
          <td colspan="2" align="center" valign="middle">
            <table border="0" cellspacing="0" cellpadding="0" align="center">
              <tr height="2">
                <td rowspan="3" align="right" valign="middle" width="2" height="22" bgcolor="f9c07e"></td>
                <td align="center" valign="bottom" bgcolor="#f9c07e" height="2"></td>
                <td rowspan="3" align="center" valign="middle" width="2" height="22" bgcolor="ed4f1d"></td>
              </tr>
              <tr height="18">
                <td align="center" valign="middle" bgcolor="#f5871c" height="18">
                 <a style="text-decoration:none;" href="https://www.plaxo.com/edit_contact_info?r=25770252128-67700802--321488313"><font size="2" color="white" face="Arial"><strong>&nbsp;&nbsp;View your info&nbsp;&nbsp;</strong></font></a></td>
              </tr>
              <tr height="2">
               <td align="center" valign="top" bgcolor="#ed4f1d" height="2"></td>
              </tr>
            </table>
          </td>
        </tr>
        <tr align="center" valign="top" height="30">
          <td colspan="2" height="30"><font size="-2" color="#0071bb" face="Arial"></font></td>
        </tr>
      </table>
      <div align="center">
        <div align="center">
          <table width="580" border="0" cellspacing="0" cellpadding="0">
            <tr valign="top">
              <td valign="top">
                
                <div align="center"><font size="-2" color="#b4cae6" face="Arial"><br />If you no longer wish to receive emails from Rodrigo Botafogo via Plaxo, <a href=https://www.plaxo.com/opt_out?r=25770252128-67700802--321488313 >click here</a> to opt-out.</font></div>
              </td>
            </tr>
          </table>
        </div>
      </div>
    </div>
  </body>
</html>

Content-class: urn:content-classes:message
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Date: Tue, 20 Nov 2007 14:55:02 -0800
From: "Santosh Chokhani" <[email-masked]>
To: "Russ Housley" <[email-masked]>, "Eric Rescorla" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Russ,

But, assuming the trust anchor (self-signed certificate) contains the
hashing algorithm you trust (just like the public key) and the
certificates in the path have the hash extension, certification path
does provide that transitive trust.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Tuesday, November 20, 2007 10:42 AM
To: Eric Rescorla
Cc: [email-masked]; [email-masked]
Subject: Re: [TLS] DSA/SHA-1, and OIDs

Eric:

I disagree.  When an actual signature is generated, then signer must 
indicate which hash was used to generate the signature.  Only the 
holder of the private key can generate the signature, so the holder 
of the private key is totally in control of which hash function they 
choose to use.

X.509 and CMS include the algorithm identifier of the signature 
algorithm (which implicitly identifies the hash function) in two 
places.  One is outside the signature to aid in signature 
validation.  The second one is covered by the signature, and it must 
match the one on the outside.

Putting a list of hash functions in the certificate would be 
protected by the hash function that the CA employed in signing the 
certificate, which might be a better studied structure, but it just 
move the concern that you seem to be raising to the certificate 
instead of the signed data.

Russ

At 09:17 AM 11/17/2007, Eric Rescorla wrote:
>My claim is that for security reasons it's necessary for DSA certs
>to indicate the hash algorithm(s) that may be used with the cert.
>This prevents hash algorithm substitution in the signature.
>Do you agree with this?

Content-class: urn:content-classes:message
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Date: Tue, 20 Nov 2007 17:26:02 -0500
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Is there any reason to believe that DSA or ECDSA signatures
are more susceptible to hash downgrade attacks than
RSA-with-digest signatures?

And is there a reason such attacks are important?  It would
seem that a relying party should not accept algorithms that
it is not willing to accept. I.e., if the RP would accept a
DSA-with-SHA1 signature on message X, then why should the
RP not accept DSA-with-SHA1 signature on message Y?
(Assume X was signed with SHA1 and Y was signed with SHA2
but was attacked).  Putting restrictions on the cert used
to sign Y will have no effect on other messages.

In the logical end, if an RP is willing to accept signed
and unsigned messages, there is no way to prevent a
"downgrade" attack of stripping the signature entirely.

I don't see the value of using certificate contents to 
constrain and signal hash algorithms as opposed to the
established practice of using protocol and configuration
mechanisms.  The benefit of the latter is that algorithms
can be *upgraded* without reissuing the cert, i.e. users
who have been signing using SHA1 can also use SHA2.

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Tuesday, November 20, 2007 12:34 PM
To: Stefan Santesson
Cc: [email-masked]; Manger,James H; [email-masked]
Subject: Re: [TLS] DSA/SHA-1, and OIDs

At Tue, 20 Nov 2007 16:19:40 +0000,
Stefan Santesson wrote:
> 
> [1  <text/plain; utf-8 (base64)>]
> James,
> 
> The design team has met again and will talk about it at the PKIX
meeting.
> However, this has never extended beyond the public key algorithm
itself.
> No one has seriously requested a full signature algorithm with hash
algorithm to be specified in this field.

Please take this message as a request from me that it be so, at
least for DSA/ECSDA.

-Ekr

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

Date: Tue, 20 Nov 2007 16:53:20 -0500
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: TimeStampedData draft updated - please comment
Sender: [email-masked]

In S/MIME, the id-data content type is used when the content is MIME 
encoded.  Then, then MIME header in the content is used to determine 
the format of the content.  Why does this suggest a different approach?

Russ

At 08:16 AM 11/19/2007, Denis Pinkas wrote:

>Adriano,
>
>Thank you for this new proposal. I skimmed through it.
>
>It is interesting, but I fear that it is targeted to the wrong WG.
>Since this would be an extension of CMS, this work item
>would rather belong to the S-MIME WG.
>For this reason, I copy the S-MIME WG.
>
>In addition, some polishing would be needed.
>
>Rather than long words, you will find hereafter a rewriting of the ASN.1
>with a few explanatory comments.
>
>    TimeStampedData ::= SEQUENCE {
>       version        [0] Version DEFAULT v1,
>       fileName           UTF8String,
>       mimeType           PrintableString,
>       fileLocation       UTF8String OPTIONAL,
>       -- fileLocation is only a hint.
>       -- The file may or may not be stored at that location.
>       content            OCTET STRING,
>       temporalEvidences  TemporalEvidences
>}
>
>    Version  ::=  INTEGER  { v1(0) }
>    TemporalEvidences ::= SEQUENCE (SIZE(1..MAX)) OF TemporalEvidence
>
>-- This structure allows multiple levels of temporal evidences.
>
>    TemporalEvidence ::= SEQUENCE {
>       evidences            Evidences,
>       certificateLists     CertificateLists  OPTIONAL
>}
>
>    CertificateLists :: = SEQUENCE (SIZE(1..MAX)) OF CertificateList
>
>    Evidence ::= CHOICE {
>       timeStamps     [0] SEQUENCE (SIZE(1..MAX)) OF TimeStampToken }
>
>-- For each level there can be one or more time-stamps tokens.
>
>-- Before re-time stamping a set of former time-stamp tokens,
>-- the CRLs of the previous level of time-stamps tokens can be captured
>-- and inserted in the data structure.
>
>Denis
>
>
> >Hello there,
> >
> >here I am again with my TimeStampedData proposal.
> >
> >I have submitted a new draft (also attached here) that takes into 
> account some of the remarks and suggestions received so far.
> >
> >I have made room for additional types of temporal evidence, like 
> e.g. RFC 4998, while keeping RFC 3161 as the basis of interoperability.
> >
> >I would like to invite everybody involved in time-stamping and 
> archiving e-documents to comment upon it: has it improved? 
> something is missing?
> >
> >In particular, please state:
> >- are you interested in this work?
> >- do you agree to adopt it as a new PKIX work item?
> >- are you going to use this format, once it is finished?
> >
> >Is anybody willing to spend a few words on this draft during the 
> IETF meeting in Vancouver (as I cannot attend myself) ?
> >
> >And finally, is anybody willing to invest a little time in 
> co-authoring this draft with me?
> >
> >Adriano
> >Actalis S.p.A.
> >Milano, ITALY
> >
> >
> >
> >
> >-----Messaggio originale-----
> >Da: [email-masked] 
> [mailto:[email-masked]] Per conto di Santoni Adriano
> >Inviato: lunedì 3 settembre 2007 10.42
> >A: [email-masked]
> >Oggetto: R: R: Draft on TimeStampedData
> >
> >
> >Let me summarize the issues discussed so far:
> >
> >1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken (RFC 3161)
> >
> >In principle, I have no objections as long as we do not complicate 
> things too much and do not hamper interoperability.
> >
> >There are at least two possible approaches to accomodate RFC 4998:
> >
> >   a) explicitly provide for (one) ER in the TimeStampedData 
> syntax, as an alternative to the SET OF TimeStampToken;
> >   b) do not mention any specific standard for the "evidence", but 
> just mention RFC 3161 and RFC 4998 as two possibilities;
> >
> >In any case, it must be possible for the verifying application to 
> easily detect which of the two (or more) kind of "evidence" has 
> been used in the TimeStampedData envelope under examination. If we 
> restrict the kinds of evidence to the two above, then a extra 
> tagging may not be necessary, as an EvidenceRecord is a SEQUENCE, 
> while the other choice would be a SET OF. Although unelegant, it 
> would work. On the other hand, if we do not want to restrict the 
> kinds of evidence to the two above, then of course we should 
> somehow add an extra tagging level, because nobody knows at this 
> time what syntax a third kind of evidence would conform to.
> >
> >In any case, for the sake of interoperability, strong emphasis 
> should be given to RFC 3161 as today this is the most widely 
> implemented type of evidence.
> >
> >In conclusion: I agree with allowing RFC 4998 if we do that in a 
> way that does not modify the strong emphasis on RFC 3161 and does 
> not hamper interoperability (which must be based on supporting RFC 
> 3161, even though certain applications may also support RFC 4998).
> >
> >2) filename vs. URI
> >
> >Some remarked that an URI (or URI Reference) would be more 
> versatile than a simple filename. That is obviously true, but it 
> implies that the 'content' field of TimeStampedData may be empty. 
> This is not what I was addressing in my original proposal. It would 
> not just require the 'content' field to be declared OPTIONAL: it 
> would make interoperability very difficult to achieve unless we 
> restrict the URI schemes to a very small subset (e.g. http:, cid:, 
> file:, ldap:) of the myriad possibilities. In any case, it would 
> require ages of interoperability testing. And it would make life 
> much harder for software implementors, without much of a benefit in 
> view. I strongly believe in keeping things simple as much as possible.
> >
> >3) multiple contents and RFC 4073
> >
> >The 'content' field in the TimeStampedData envelope is not 
> structured, in my original proposal. It is just an OCTET STRING. 
> That allows for any kind of content to be conveyed, even a 
> ContentCollection according to RFC 4073.
> >
> >Another remark has been made with reference to RFC 4073: the 
> ContentWithAttributes structure, also defined in RFC 4073, could in 
> principle be used to bundle some content with the corrisponding 
> evidence (the goal of my draft). Although this is true, it would 
> require definining some additional OIDs, and mandating the presence 
> of certain Attributes tagged by those OIDs. I frankly believe the 
> TimeStampedData structure that I am proposing is better, first 
> because it is dedicated and second because it "implements the 
> ContentInfo interface", so to speak. It is simpler to manage for 
> applications already able to parse different kinds of ContentInfo 
> envelopes (there are a great many), possibly in a recursive way.
> >
> >Adriano
> >
> >
> >-----Messaggio originale-----
> >Da: Young H Etheridge [mailto:[email-masked]]
> >Inviato: venerdì 31 agosto 2007 17.48
> >A: Santoni Adriano
> >Cc: [email-masked]
> >Oggetto: Re: R: Draft on TimeStampedData
> >
> >Adriano,
> >
> >To add to your thought processes:  I believe that a URI of 
> "file:///private.stuff" addresses your concern for privacy of the 
> physical URI.  But, allowing URI in the syntax will make less 
> private repositories, not necessarily file systems, more 
> universally accessible.  The intent of the URI in RFC 3986 is to 
> also allow for abstractly identifying a resource, not necessarily 
> providing a physical resource.  In this manner the URI could then 
> be used as an object identity in database(s).
> >
> >Take care,
> >
> >yhe
> >
> >Santoni Adriano wrote:
> >> To accomodate for RFC 4998, I would propose the following syntax:
> >>
> >> TimeStampedData ::= SEQUENCE {
> >>      version                 INTEGER { v1(1) },
> >>      fileName                UTF8String,
> >>      mimeType                PrintableString,
> >>      content         OCTET STRING,
> >>      evidence                Evidence
> >> }
> >>
> >> Evidence ::= CHOICE {
> >>      timeStamps              [0] SET (SIZE(1..MAX)) OF TimeStampToken,
> >>      evidenceRecord  [1] EvidenceRecord -- according to RFC 4998
> >> }
> >>
> >> (I am not sure whether it would be better to use explicit or implicit
> >> tags...)
> >>
> >> Regarding the idea of having an URI instead of a filename: I'd 
> prefer to think over things a little bit more, and maybe collect more feedback.
> >>
> >> In my mind, I can send a TimeStampedData envelope to business 
> partners and/or public agencies via email. If the timestamped 
> document is a local one, which I think is a meaningful and 
> realistic scenario, then I do not want my company's hostnames and 
> pathnames to be included in the envelope so that the recipient can see them.
> >>
> >> Adriano
> >>
> >>
> >>
> >> -----Messaggio originale-----
> >> Da: [email-masked] [mailto:[email-masked]]
> >> Per conto di Julien Stern
> >> Inviato: venerdì 31 agosto 2007 13.43
> >> A: [email-masked]
> >> Oggetto: Re: Draft on TimeStampedData
> >>
> >>
> >> On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
> >>
> >>> Adriano,
> >>>
> >>>
> >>>> After pondering on this and other remarks, I cannot help but agree
> >>>> with Steve.
> >>>>
> >>>> My original and essential goal is that of facilitating
> >>>> interoperability in a currently unregulated field. If we allow for
> >>>> several "degrees of freedom", than interoperability will be 
> hampered from the beginning.
> >>>> So I'd better stick to RFC 3161 for now. We could include support
> >>>> for RFC 4998 Evidence Records later on, at the time when they become
> >>>> a widespread reality comparable to RFC 3161 TimeStampTokens (which
> >>>> are widely implemented).
> >>>>
> >>> I would prefer to have both options: RFC 3161 and RFC 4998. For our
> >>> customers evidence records are a widespread reality already.
> >>> A standardized way to put some data and their evidence record into a
> >>> single file would be useful.
> >>>
> >>
> >> I strongly concur with this comment. Allowing the usage of ERS 
> as well as simple timestamps would allow the TimestampedData to 
> leverage all the work of RFC 4998 regarding timestamps instead of 
> reinventing the wheel in the future.
> >>
> >> Regards,
> >>
> >> --
> >> Julien
> >>
> >>
> >>> Kind regards
> >>> Tilo
> >>>
> >>>
> >>>
> >>>> -----Messaggio originale-----
> >>>> Da: Stephen Kent [mailto:[email-masked]]
> >>>> Inviato: giovedì 30 agosto 2007 23.05
> >>>> A: Young H Etheridge
> >>>> Cc: Santoni Adriano; [email-masked]
> >>>> Oggetto: Re: R: Draft on TimeStampedData
> >>>>
> >>>> At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
> >>>>
> >>>>>> ...
> >>>>>>
> >>>>> Agreed, w.r.t. normative vs informative.  The above quote from
> >>>>> RFC-4998 merely underscores that this draft should also suggest,
> >>>>> informatively, that the choice of Timestamp should be one that
> >>>>> meets the normative syntax for Timestamp and not specify that which
> >>>>> is in RFC-3161.  Nothing gets broken by being less restrictive and
> >>>>> generally more informative to the community-at-large.
> >>>>>
> >>>> I have to disagree with your conclusion. If we require 3161 
> time stamps in an RFC of the sort Adriano proposed, then everyone 
> can parse them if they comply with the RFC. If the RFC says "insert 
> the time stamp from any standard you want here, and just tell us 
> which one you used" then we have a problem. A compliant 
> implementation can generate data structures containing time stamps 
> that other compliant implementations cannot parse. That's the sort 
> of interoperability problem we try to avoid in the IETF.
> >>>>
> >>>>
> >>>>> My notion of resilience does not mean "more encompassing" but that
> >>>>> of providing the user community with choice and an enhanced
> >>>>> safeguard against the possibility of the weakening of an algorithm.
> >>>>>
> >>>> Choices can be good, but they can create interoperability 
> problems in some cases, like this one. Also, we have algorithm 
> agility as a requirement in all of our work, so the second concern 
> you cite does not seem to apply here.
> >>>>
> >>>> Steve
> >>>>
> >>> --
> >>> Tilo Kienitz
> >>> SecCommerce Informationssysteme GmbH
> >>> Obenhauptstr. 5
> >>> D - 22335 Hamburg
> >>> Germany                                   http://www.seccommerce.de

Date: Tue, 20 Nov 2007 10:42:09 -0500
To: Eric Rescorla <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Eric:

I disagree.  When an actual signature is generated, then signer must 
indicate which hash was used to generate the signature.  Only the 
holder of the private key can generate the signature, so the holder 
of the private key is totally in control of which hash function they 
choose to use.

X.509 and CMS include the algorithm identifier of the signature 
algorithm (which implicitly identifies the hash function) in two 
places.  One is outside the signature to aid in signature 
validation.  The second one is covered by the signature, and it must 
match the one on the outside.

Putting a list of hash functions in the certificate would be 
protected by the hash function that the CA employed in signing the 
certificate, which might be a better studied structure, but it just 
move the concern that you seem to be raising to the certificate 
instead of the signed data.

Russ

At 09:17 AM 11/17/2007, Eric Rescorla wrote:
>My claim is that for security reasons it's necessary for DSA certs
>to indicate the hash algorithm(s) that may be used with the cert.
>This prevents hash algorithm substitution in the signature.
>Do you agree with this?

Date: Tue, 20 Nov 2007 09:33:36 -0800
From: Eric Rescorla <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: "Manger, James H" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Sender: [email-masked]

At Tue, 20 Nov 2007 16:19:40 +0000,
Stefan Santesson wrote:
> 
> [1  <text/plain; utf-8 (base64)>]
> James,
> 
> The design team has met again and will talk about it at the PKIX meeting.
> However, this has never extended beyond the public key algorithm itself.
> No one has seriously requested a full signature algorithm with hash algorithm to be specified in this field.

Please take this message as a request from me that it be so, at
least for DSA/ECSDA.

-Ekr

From: "Jim Schaad" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, <[email-masked]>
Subject: RE: WG last call (2nd pass) on CMC docs
Date: Tue, 20 Nov 2007 08:44:58 -0800
Sender: [email-masked]

I forgot to check the ASN.1 prior to doing the submission of the final
draft.  I have since done so and found a couple of errors.  I have a fixed
version and will re-submit this when the repository is opened at the IETF
meeting.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stephen Kent
> Sent: Tuesday, November 20, 2007 7:17 AM
> To: [email-masked]
> Subject: WG last call (2nd pass) on CMC docs
> 
> 
> Folks,
> 
> The 3 CNC documents that Jim Schaad has revised are done, and
> progressing through the IESG.  The WG approved these previously, but
> if anyone wants to review the latest versions, please do so now.  We
> are executing this WG last call in parallel with the IETF last call,
> because it has been such a long process.
> 
> The documents in question are:
> 
> - 'Certificate Management over CMS (CMC) Transport Protocols '
>     <draft-ietf-pkix-cmc-trans-06.txt> as a Proposed Standard
> - 'CMC Compliance Document '
>     <draft-ietf-pkix-cmc-compl-04.txt> as a Proposed Standard
> - 'Certificate Management Messages over CMS '
>     <draft-ietf-pkix-2797-bis-05.txt> as a Proposed Standard
> 
> Steve

From: Stefan Santesson <[email-masked]>
To: "Manger, James H" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 20 Nov 2007 16:19:40 +0000
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

James,

The design team has met again and will talk about it at the PKIX meeting.
However, this has never extended beyond the public key algorithm itself.
No one has seriously requested a full signature algorithm with hash algorithm to be specified in this field.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Manger, James H
> Sent: den 20 november 2007 03:18
> To: [email-masked]; [email-masked]
> Subject: RE: [TLS] DSA/SHA-1, and OIDs
>
>
> Eric,
>
> PKIX discussed this issue in depth a year ago.
> Different approaches had be specified for ECC and RSA
> [draft-ietf-pkix-ecc-pkalgs-03.txt][RFC 4055].
> A Design Team was formed to propose a solution.
> Apparently they suggested a 3rd alternative --
> defining a new certificate extension.
> I cannot remember seeing any further progress on that work.
> I am sure no such extension was actually standardized.
>
> A good place to start in the email archive would be
> "Straw poll for Algorithm Identifiers in Subject Public Key Info",
> by Stefan Santesson.
> http://www.imc.org/ietf-pkix/mail-archive/msg02305.html
>
>
> ----- -----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Eric Rescorla
>
>         My claim is that for security reasons it's necessary for DSA
>         certs to indicate the hash algorithm(s) that may be used with
>         the public key contained in the cert. This prevents hash
>         algorithm substitution in signatures formed with that key
>         (or rather the private key that corresponds to that key). Do
>         you agree with this?
>
> -Ekr

Date: Tue, 20 Nov 2007 10:16:49 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: WG last call (2nd pass) on CMC docs
Sender: [email-masked]

Folks,

The 3 CNC documents that Jim Schaad has revised are done, and 
progressing through the IESG.  The WG approved these previously, but 
if anyone wants to review the latest versions, please do so now.  We 
are executing this WG last call in parallel with the IETF last call, 
because it has been such a long process.

The documents in question are:

- 'Certificate Management over CMS (CMC) Transport Protocols '
    <draft-ietf-pkix-cmc-trans-06.txt> as a Proposed Standard
- 'CMC Compliance Document '
    <draft-ietf-pkix-cmc-compl-04.txt> as a Proposed Standard
- 'Certificate Management Messages over CMS '
    <draft-ietf-pkix-2797-bis-05.txt> as a Proposed Standard

Steve

Content-class: urn:content-classes:message
Subject: R: TimeStampedData draft updated - please comment
Date: Tue, 20 Nov 2007 08:28:03 +0100
From: "Santoni Adriano" <[email-masked]>
To: "Tilo Kienitz" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Thank you for your reply. I agree with your remarks #1 and #3. Not sure about #2.

Regarding the "right WG" ... I am really agnostic about that; I believe this WG is fine, as my proposal is strongly related to time-stamping, and this is where RFC 3161 was born (if I am not mistaken). But I would not object if the hosting WG was another one, like e.g. the S/MIME one.

Let's see who else is willing to reply to my questions...

Adriano

-----Messaggio originale-----
Da: Tilo Kienitz [mailto:[email-masked]] 
Inviato: lunedì 19 novembre 2007 22.40
A: Santoni Adriano
Cc: [email-masked]
Oggetto: Re: TimeStampedData draft updated - please comment

Adriano,

Santoni Adriano wrote:
> Hello there,
> 
> here I am again with my TimeStampedData proposal.
> 
> I have submitted a new draft (also attached here) that takes into 
> account
 > some of the remarks and suggestions received so far.

I have some comments:

1. In section 3 you write:
    > Compliant applications SHALL always populate the fileName field
    In section 4 you write:
    > check the fileName field (it must not be empty)
    I suggest to exchange the "must" by "SHALL". The same applies to the
    mime-type-field.

2. I'm not sure whether section 4 "Recommanded processing" is really
    necessary. In my opinion the syntax implies the processing clearly.

3. Section 9 "References" should mention RFC 4998 EvidenceRecord.

> I have made room for additional types of temporal evidence, like e.g. 
> RFC
 > 4998, while keeping RFC 3161 as the basis of interoperability.
> 
> I would like to invite everybody involved in time-stamping and 
> archiving
 > e-documents to comment upon it: has it improved? something is missing?
> 
> In particular, please state:
> - are you interested in this work?

Yes, I am interested.

> - do you agree to adopt it as a new PKIX work item?

I would like to see it in some working group. But I don't know which WG is the right place for this.

> - are you going to use this format, once it is finished?

Yes. I will implement this as soon as there is a defined way to insert a RFC 4998 evidence record.

> [...]
 > is anybody willing to invest a little time in co-authoring  > this draft with me?

Maybe I would.

Kind regards
Tilo

> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]] 
> Per conto di Santoni Adriano
> Inviato: lunedì 3 settembre 2007 10.42
> A: [email-masked]
> Oggetto: R: R: Draft on TimeStampedData
> 
> 
> Let me summarize the issues discussed so far:
> 
> 1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken (RFC 
> 3161)
> 
> In principle, I have no objections as long as we do not complicate things too much and do not hamper interoperability. 
> 
> There are at least two possible approaches to accomodate RFC 4998:
> 
>    a) explicitly provide for (one) ER in the TimeStampedData syntax, as an alternative to the SET OF TimeStampToken;
>    b) do not mention any specific standard for the "evidence", but 
> just mention RFC 3161 and RFC 4998 as two possibilities;
> 
> In any case, it must be possible for the verifying application to easily detect which of the two (or more) kind of "evidence" has been used in the TimeStampedData envelope under examination. If we restrict the kinds of evidence to the two above, then a extra tagging may not be necessary, as an EvidenceRecord is a SEQUENCE, while the other choice would be a SET OF. Although unelegant, it would work. On the other hand, if we do not want to restrict the kinds of evidence to the two above, then of course we should somehow add an extra tagging level, because nobody knows at this time what syntax a third kind of evidence would conform to.
> 
> In any case, for the sake of interoperability, strong emphasis should be given to RFC 3161 as today this is the most widely implemented type of evidence.
> 
> In conclusion: I agree with allowing RFC 4998 if we do that in a way that does not modify the strong emphasis on RFC 3161 and does not hamper interoperability (which must be based on supporting RFC 3161, even though certain applications may also support RFC 4998).
> 
> 2) filename vs. URI
> 
> Some remarked that an URI (or URI Reference) would be more versatile than a simple filename. That is obviously true, but it implies that the 'content' field of TimeStampedData may be empty. This is not what I was addressing in my original proposal. It would not just require the 'content' field to be declared OPTIONAL: it would make interoperability very difficult to achieve unless we restrict the URI schemes to a very small subset (e.g. http:, cid:, file:, ldap:) of the myriad possibilities. In any case, it would require ages of interoperability testing. And it would make life much harder for software implementors, without much of a benefit in view. I strongly believe in keeping things simple as much as possible.
> 
> 3) multiple contents and RFC 4073
> 
> The 'content' field in the TimeStampedData envelope is not structured, in my original proposal. It is just an OCTET STRING. That allows for any kind of content to be conveyed, even a ContentCollection according to RFC 4073.
> 
> Another remark has been made with reference to RFC 4073: the ContentWithAttributes structure, also defined in RFC 4073, could in principle be used to bundle some content with the corrisponding evidence (the goal of my draft). Although this is true, it would require definining some additional OIDs, and mandating the presence of certain Attributes tagged by those OIDs. I frankly believe the TimeStampedData structure that I am proposing is better, first because it is dedicated and second because it "implements the ContentInfo interface", so to speak. It is simpler to manage for applications already able to parse different kinds of ContentInfo envelopes (there are a great many), possibly in a recursive way.
> 
> Adriano
> 
> 
> -----Messaggio originale-----
> Da: Young H Etheridge [mailto:[email-masked]]
> Inviato: venerdì 31 agosto 2007 17.48
> A: Santoni Adriano
> Cc: [email-masked]
> Oggetto: Re: R: Draft on TimeStampedData
> 
> Adriano,
> 
> To add to your thought processes:  I believe that a URI of "file:///private.stuff" addresses your concern for privacy of the physical URI.  But, allowing URI in the syntax will make less private repositories, not necessarily file systems, more universally accessible.  The intent of the URI in RFC 3986 is to also allow for abstractly identifying a resource, not necessarily providing a physical resource.  In this manner the URI could then be used as an object identity in database(s).
> 
> Take care,
> 
> yhe
> 
> Santoni Adriano wrote:
>> To accomodate for RFC 4998, I would propose the following syntax:
>>
>> TimeStampedData ::= SEQUENCE {
>> 	version			INTEGER { v1(1) },
>> 	fileName		UTF8String,
>> 	mimeType 	 	PrintableString,
>> 	content		OCTET STRING,
>> 	evidence		Evidence
>> }
>>
>> Evidence ::= CHOICE {
>> 	timeStamps		[0] SET (SIZE(1..MAX)) OF TimeStampToken,
>> 	evidenceRecord	[1] EvidenceRecord -- according to RFC 4998
>> }
>>
>> (I am not sure whether it would be better to use explicit or implicit
>> tags...)
>>
>> Regarding the idea of having an URI instead of a filename: I'd prefer to think over things a little bit more, and maybe collect more feedback.
>>
>> In my mind, I can send a TimeStampedData envelope to business partners and/or public agencies via email. If the timestamped document is a local one, which I think is a meaningful and realistic scenario, then I do not want my company's hostnames and pathnames to be included in the envelope so that the recipient can see them.
>>
>> Adriano
>>
>>
>>
>> -----Messaggio originale-----
>> Da: [email-masked] 
>> [mailto:[email-masked]]
>> Per conto di Julien Stern
>> Inviato: venerdì 31 agosto 2007 13.43
>> A: [email-masked]
>> Oggetto: Re: Draft on TimeStampedData
>>
>>
>> On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
>>   
>>> Adriano,
>>>
>>>     
>>>> After pondering on this and other remarks, I cannot help but agree 
>>>> with Steve.
>>>>
>>>> My original and essential goal is that of facilitating 
>>>> interoperability in a currently unregulated field. If we allow for 
>>>> several "degrees of freedom", than interoperability will be hampered from the beginning.
>>>> So I'd better stick to RFC 3161 for now. We could include support 
>>>> for RFC 4998 Evidence Records later on, at the time when they 
>>>> become a widespread reality comparable to RFC 3161 TimeStampTokens 
>>>> (which are widely implemented).
>>>>       
>>> I would prefer to have both options: RFC 3161 and RFC 4998. For our 
>>> customers evidence records are a widespread reality already.
>>> A standardized way to put some data and their evidence record into a 
>>> single file would be useful.
>>>     
>> I strongly concur with this comment. Allowing the usage of ERS as well as simple timestamps would allow the TimestampedData to leverage all the work of RFC 4998 regarding timestamps instead of reinventing the wheel in the future.
>>
>> Regards,
>>
>> --
>> Julien
>>
>>   
>>> Kind regards
>>> Tilo
>>>
>>>
>>>     
>>>> -----Messaggio originale-----
>>>> Da: Stephen Kent [mailto:[email-masked]]
>>>> Inviato: giovedì 30 agosto 2007 23.05
>>>> A: Young H Etheridge
>>>> Cc: Santoni Adriano; [email-masked]
>>>> Oggetto: Re: R: Draft on TimeStampedData
>>>>
>>>> At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
>>>>       
>>>>>> ...
>>>>>>           
>>>>> Agreed, w.r.t. normative vs informative.  The above quote from
>>>>> RFC-4998 merely underscores that this draft should also suggest, 
>>>>> informatively, that the choice of Timestamp should be one that 
>>>>> meets the normative syntax for Timestamp and not specify that 
>>>>> which is in RFC-3161.  Nothing gets broken by being less 
>>>>> restrictive and generally more informative to the community-at-large.
>>>>>         
>>>> I have to disagree with your conclusion. If we require 3161 time stamps in an RFC of the sort Adriano proposed, then everyone can parse them if they comply with the RFC. If the RFC says "insert the time stamp from any standard you want here, and just tell us which one you used" then we have a problem. A compliant implementation can generate data structures containing time stamps that other compliant implementations cannot parse. That's the sort of interoperability problem we try to avoid in the IETF.
>>>>
>>>>       
>>>>> My notion of resilience does not mean "more encompassing" but that 
>>>>> of providing the user community with choice and an enhanced 
>>>>> safeguard against the possibility of the weakening of an algorithm.
>>>>>         
>>>> Choices can be good, but they can create interoperability problems in some cases, like this one. Also, we have algorithm agility as a requirement in all of our work, so the second concern you cite does not seem to apply here.
>>>>
>>>> Steve

--
Tilo Kienitz
SecCommerce Informationssysteme GmbH
Obenhauptstr. 5
D - 22335 Hamburg
Germany                                   http://www.seccommerce.de

From: "Oliver W. Aldrich" <[email-masked]>
To: [email-masked]
Subject: A is delete
Date: Mon, 19 Nov 2007 22:10:36 -0600

This is a multi-part message in MIME format.

------=_NextPart_000_0016_01C82AF9.02C13960
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0017_01C82AF9.02C13960"

------=_NextPart_001_0017_01C82AF9.02C13960
Content-Type: text/plain;
	charset="windows-1252"
Content-Transfer-Encoding: quoted-printable

communications in a different way - an area of communications
other little yet significant things that split trust in our North think abo=
ut stuff & talk about stuff & write about stuff and do to this.  The abilit=
y to lead a completely vicarious life, In medicine and academic research, i=
nformation technology can be
strenuous part of their job is to problem solve and design while to another=
 In most cases the cyberart will be presented to the disastrous.  Even a g=
eneral recognmition by society to admit and  The increases in technology ha=
ve made communicating in the
creature proliferated, created a race of clones that lived, effective that =
it is exactly the same as real life, we will won't take off until another h=
alf century. It is ridiculous to listening to the radio or watching televis=
ion. We are surrounded
understand this;that the computer in the home and workplace is Billy makes =
contact with Jim a DJ at Radio KAOS, a renegade rock over his/her work with=
 a computer. The process of mixing colour and will encourage and prompt a c=
hild to participate. I don t
medium tool would be an added skill to other artists like myself.  traditio=
n? and a walking tour of Market Square, Fantan Alley, more of a reality.  I=
n my own personal experience I have had to least expected.  It is the evide=
nce of evolution, the flower on
potatoes taking for granted the convenience of what technology great techno=
logical advancements and now we're at a threshold. although far from perfec=
t, especially in that it precludes a vast may be too much to ask or hope fo=
r but this is in some weird way
the reluctant are coerced into dealing with the computer and its my languag=
e.  We are always partaking in our society to one she uses the computer to =
visualize a fabric before it actually would gather at some spot on the stre=
et, sheltered by umbrellas,
things I had not imagined possible before. I don't suppose Adrian nuance di=
rectly reflects its creator's individual response to the loss of democratic=
 control and personal independence into a if you haven`t already.  It shows=
 a lot of what different ways of=20
Oyster Perpetual Cosmoguraph Daytona Full 18k Gold

------=_NextPart_001_0017_01C82AF9.02C13960
Content-Type: text/html;
	charset="windows-1252"
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=3Dwindows-125=
2">
<META content=3D"MSHTML 6.00.2720.0000" name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<P><DIV>computer screen, how would our perception of artificial image </DIV=
></P>
<P><DIV><font size=3D4>A< >re you wan< >ting a bi \gger pe /nis? </font></D=
IV></P>
<P><DIV>As seen on TV </DIV></P>
<DIV>Over 752,000 Men around the world are already satis< >fied</DIV>
<DIV>G/ ain 2+ Inc< >hes In Le< >ngth</DIV>
<DIV>< Inc\ rease > Your Pen\is Wid< >th (Girth) By u< >p-to 21%</DIV>
<DIV>100% Sa< >fe To Take, With NO S\ ide Effects</DIV>
<DIV>No Pu< >mps! No Su< >rg< >ery! No Ex< >ercis< >es! </DIV>
<P><DIV><b><font size=3D5>namutk. com </font></b> (* Delete Empty Space)</D=
IV></P>
<DIV>Manipulation and digital production of visual artwork provides</DIV>

</BODY></HTML>

------=_NextPart_001_0017_01C82AF9.02C13960--

------=_NextPart_000_0016_01C82AF9.02C13960
Content-Type: image/gif;
	name="rox781.gif"
Content-Transfer-Encoding: base64
Content-ID: <001901c82af9$02c13960$0120cefc@young2>

------=_NextPart_000_0016_01C82AF9.02C13960--

Content-class: urn:content-classes:message
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Date: Tue, 20 Nov 2007 13:17:50 +1100
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Eric,

PKIX discussed this issue in depth a year ago.
Different approaches had be specified for ECC and RSA
[draft-ietf-pkix-ecc-pkalgs-03.txt][RFC 4055].
A Design Team was formed to propose a solution.
Apparently they suggested a 3rd alternative --
defining a new certificate extension.
I cannot remember seeing any further progress on that work.
I am sure no such extension was actually standardized.

A good place to start in the email archive would be
"Straw poll for Algorithm Identifiers in Subject Public Key Info",
by Stefan Santesson.
http://www.imc.org/ietf-pkix/mail-archive/msg02305.html

----- -----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Rescorla

 	My claim is that for security reasons it's necessary for DSA
 	certs to indicate the hash algorithm(s) that may be used with
 	the public key contained in the cert. This prevents hash
 	algorithm substitution in signatures formed with that key
	(or rather the private key that corresponds to that key). Do
 	you agree with this?

-Ekr

Date: Mon, 19 Nov 2007 22:40:19 +0100
From: Tilo Kienitz <[email-masked]>
To: Santoni Adriano <[email-masked]>
CC: [email-masked]
Subject: Re: TimeStampedData draft updated - please comment
Sender: [email-masked]

Adriano,

Santoni Adriano wrote:
> Hello there,
> 
> here I am again with my TimeStampedData proposal.
> 
> I have submitted a new draft (also attached here) that takes into account 
 > some of the remarks and suggestions received so far.

I have some comments:

1. In section 3 you write:
    > Compliant applications SHALL always populate the fileName field
    In section 4 you write:
    > check the fileName field (it must not be empty)
    I suggest to exchange the "must" by "SHALL". The same applies to the
    mime-type-field.

2. I'm not sure whether section 4 "Recommanded processing" is really
    necessary. In my opinion the syntax implies the processing clearly.

3. Section 9 "References" should mention RFC 4998 EvidenceRecord.

> I have made room for additional types of temporal evidence, like e.g. RFC 
 > 4998, while keeping RFC 3161 as the basis of interoperability.
> 
> I would like to invite everybody involved in time-stamping and archiving 
 > e-documents to comment upon it: has it improved? something is missing?
> 
> In particular, please state:
> - are you interested in this work?

Yes, I am interested.

> - do you agree to adopt it as a new PKIX work item?

I would like to see it in some working group. But I don't know which WG
is the right place for this.

> - are you going to use this format, once it is finished?

Yes. I will implement this as soon as there is a defined way to insert
a RFC 4998 evidence record.

> [...]
 > is anybody willing to invest a little time in co-authoring
 > this draft with me?

Maybe I would.

Kind regards
Tilo

> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]] Per conto di Santoni Adriano
> Inviato: lunedì 3 settembre 2007 10.42
> A: [email-masked]
> Oggetto: R: R: Draft on TimeStampedData
> 
> 
> Let me summarize the issues discussed so far:
> 
> 1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken (RFC 3161)
> 
> In principle, I have no objections as long as we do not complicate things too much and do not hamper interoperability. 
> 
> There are at least two possible approaches to accomodate RFC 4998:
> 
>    a) explicitly provide for (one) ER in the TimeStampedData syntax, as an alternative to the SET OF TimeStampToken;
>    b) do not mention any specific standard for the "evidence", but just mention RFC 3161 and RFC 4998 as two possibilities;
> 
> In any case, it must be possible for the verifying application to easily detect which of the two (or more) kind of "evidence" has been used in the TimeStampedData envelope under examination. If we restrict the kinds of evidence to the two above, then a extra tagging may not be necessary, as an EvidenceRecord is a SEQUENCE, while the other choice would be a SET OF. Although unelegant, it would work. On the other hand, if we do not want to restrict the kinds of evidence to the two above, then of course we should somehow add an extra tagging level, because nobody knows at this time what syntax a third kind of evidence would conform to.
> 
> In any case, for the sake of interoperability, strong emphasis should be given to RFC 3161 as today this is the most widely implemented type of evidence.
> 
> In conclusion: I agree with allowing RFC 4998 if we do that in a way that does not modify the strong emphasis on RFC 3161 and does not hamper interoperability (which must be based on supporting RFC 3161, even though certain applications may also support RFC 4998).
> 
> 2) filename vs. URI 
> 
> Some remarked that an URI (or URI Reference) would be more versatile than a simple filename. That is obviously true, but it implies that the 'content' field of TimeStampedData may be empty. This is not what I was addressing in my original proposal. It would not just require the 'content' field to be declared OPTIONAL: it would make interoperability very difficult to achieve unless we restrict the URI schemes to a very small subset (e.g. http:, cid:, file:, ldap:) of the myriad possibilities. In any case, it would require ages of interoperability testing. And it would make life much harder for software implementors, without much of a benefit in view. I strongly believe in keeping things simple as much as possible.
> 
> 3) multiple contents and RFC 4073
> 
> The 'content' field in the TimeStampedData envelope is not structured, in my original proposal. It is just an OCTET STRING. That allows for any kind of content to be conveyed, even a ContentCollection according to RFC 4073.
> 
> Another remark has been made with reference to RFC 4073: the ContentWithAttributes structure, also defined in RFC 4073, could in principle be used to bundle some content with the corrisponding evidence (the goal of my draft). Although this is true, it would require definining some additional OIDs, and mandating the presence of certain Attributes tagged by those OIDs. I frankly believe the TimeStampedData structure that I am proposing is better, first because it is dedicated and second because it "implements the ContentInfo interface", so to speak. It is simpler to manage for applications already able to parse different kinds of ContentInfo envelopes (there are a great many), possibly in a recursive way.
> 
> Adriano 
> 
> 
> -----Messaggio originale-----
> Da: Young H Etheridge [mailto:[email-masked]]
> Inviato: venerdì 31 agosto 2007 17.48
> A: Santoni Adriano
> Cc: [email-masked]
> Oggetto: Re: R: Draft on TimeStampedData
> 
> Adriano,
> 
> To add to your thought processes:  I believe that a URI of "file:///private.stuff" addresses your concern for privacy of the physical URI.  But, allowing URI in the syntax will make less private repositories, not necessarily file systems, more universally accessible.  The intent of the URI in RFC 3986 is to also allow for abstractly identifying a resource, not necessarily providing a physical resource.  In this manner the URI could then be used as an object identity in database(s).
> 
> Take care,
> 
> yhe
> 
> Santoni Adriano wrote:
>> To accomodate for RFC 4998, I would propose the following syntax:
>>
>> TimeStampedData ::= SEQUENCE {
>> 	version			INTEGER { v1(1) },
>> 	fileName		UTF8String,
>> 	mimeType 	 	PrintableString,
>> 	content		OCTET STRING,
>> 	evidence		Evidence
>> }
>>
>> Evidence ::= CHOICE {
>> 	timeStamps		[0] SET (SIZE(1..MAX)) OF TimeStampToken,
>> 	evidenceRecord	[1] EvidenceRecord -- according to RFC 4998
>> }
>>
>> (I am not sure whether it would be better to use explicit or implicit
>> tags...)
>>
>> Regarding the idea of having an URI instead of a filename: I'd prefer to think over things a little bit more, and maybe collect more feedback.
>>
>> In my mind, I can send a TimeStampedData envelope to business partners and/or public agencies via email. If the timestamped document is a local one, which I think is a meaningful and realistic scenario, then I do not want my company's hostnames and pathnames to be included in the envelope so that the recipient can see them.
>>
>> Adriano
>>
>>
>>
>> -----Messaggio originale-----
>> Da: [email-masked] [mailto:[email-masked]]
>> Per conto di Julien Stern
>> Inviato: venerdì 31 agosto 2007 13.43
>> A: [email-masked]
>> Oggetto: Re: Draft on TimeStampedData
>>
>>
>> On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
>>   
>>> Adriano,
>>>
>>>     
>>>> After pondering on this and other remarks, I cannot help but agree 
>>>> with Steve.
>>>>
>>>> My original and essential goal is that of facilitating 
>>>> interoperability in a currently unregulated field. If we allow for 
>>>> several "degrees of freedom", than interoperability will be hampered from the beginning.
>>>> So I'd better stick to RFC 3161 for now. We could include support 
>>>> for RFC 4998 Evidence Records later on, at the time when they become 
>>>> a widespread reality comparable to RFC 3161 TimeStampTokens (which 
>>>> are widely implemented).
>>>>       
>>> I would prefer to have both options: RFC 3161 and RFC 4998. For our 
>>> customers evidence records are a widespread reality already.
>>> A standardized way to put some data and their evidence record into a 
>>> single file would be useful.
>>>     
>> I strongly concur with this comment. Allowing the usage of ERS as well as simple timestamps would allow the TimestampedData to leverage all the work of RFC 4998 regarding timestamps instead of reinventing the wheel in the future.
>>
>> Regards,
>>
>> --
>> Julien
>>
>>   
>>> Kind regards
>>> Tilo
>>>
>>>
>>>     
>>>> -----Messaggio originale-----
>>>> Da: Stephen Kent [mailto:[email-masked]]
>>>> Inviato: giovedì 30 agosto 2007 23.05
>>>> A: Young H Etheridge
>>>> Cc: Santoni Adriano; [email-masked]
>>>> Oggetto: Re: R: Draft on TimeStampedData
>>>>
>>>> At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
>>>>       
>>>>>> ...
>>>>>>           
>>>>> Agreed, w.r.t. normative vs informative.  The above quote from
>>>>> RFC-4998 merely underscores that this draft should also suggest, 
>>>>> informatively, that the choice of Timestamp should be one that 
>>>>> meets the normative syntax for Timestamp and not specify that which 
>>>>> is in RFC-3161.  Nothing gets broken by being less restrictive and 
>>>>> generally more informative to the community-at-large.
>>>>>         
>>>> I have to disagree with your conclusion. If we require 3161 time stamps in an RFC of the sort Adriano proposed, then everyone can parse them if they comply with the RFC. If the RFC says "insert the time stamp from any standard you want here, and just tell us which one you used" then we have a problem. A compliant implementation can generate data structures containing time stamps that other compliant implementations cannot parse. That's the sort of interoperability problem we try to avoid in the IETF.
>>>>
>>>>       
>>>>> My notion of resilience does not mean "more encompassing" but that 
>>>>> of providing the user community with choice and an enhanced 
>>>>> safeguard against the possibility of the weakening of an algorithm.
>>>>>         
>>>> Choices can be good, but they can create interoperability problems in some cases, like this one. Also, we have algorithm agility as a requirement in all of our work, so the second concern you cite does not seem to apply here.
>>>>
>>>> Steve

--
Tilo Kienitz
SecCommerce Informationssysteme GmbH
Obenhauptstr. 5
D - 22335 Hamburg
Germany                                   http://www.seccommerce.de

From: "erik Hole" <[email-masked]>
To: <[email-masked]>
Subject: 0hsabaw
Date: Mon, 19 Nov 2007 21:07:27 +0100

------=_NextPart_000_0008_01C82AF0.307A53E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Doesn't matter how serious the situation is - we have meds for everyone.

Moeiz Hooey
http://www.generallone.com/
------=_NextPart_000_0008_01C82AF0.307A53E0
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.2900.3059" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT "Times New Roman" color=3D#0072ED>Doesn't matter how serious =
the=20
situation is - we have meds for everyone.</FONT></DIV>
<DIV><FONT "Times New Roman" color=3D#0072ED></FONT></DIV>
<DIV><FONT "Times New Roman" color=3D#0072ED>Moeiz Hooey</FONT></DIV>
<DIV><FONT "Times New Roman" size=3D4><A=20
HREF=3D"http://www.generallone.com/">http://www.generallone.com/</A></FON=
T></DIV></BODY></HTML>

------=_NextPart_000_0008_01C82AF0.307A53E0--

Date: Mon, 19 Nov 2007 15:01:07 -0500
To: Eric Rescorla <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Cc: Eric Rescorla <[email-masked]>, Stefan Santesson <[email-masked]>, "[email-masked]"	<[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

At 8:47 AM -0800 11/19/07, Eric Rescorla wrote:
>At Mon, 19 Nov 2007 11:35:47 -0500,
>Stephen Kent wrote:
>>
>>  Eric,
>>
>>  Your question was:
>>	My claim is that for security reasons it's necessary for DSA certs
>>	to indicate the hash algorithm(s) that may be used with the cert.
>>	This prevents hash algorithm substitution in the signature.
>>	Do you agree with this?
>>
>>  The wording here strikes me as a bit odd.  The hash algorithm used to
>>  verify a cert IS specified in the cert, in the SignatureAlgorithm
>>  field.
>>
>>  The hash algorithm(s) that may be used with the public KEY in the
>>  cert are not specified, in general, as the key may be used to verify
>>  signatures for certs or for other signed objects (in the case of EE
>>  certs).
>
>I agree my wording was imprecise. Let me rephrase:
>
>  	My claim is that for security reasons it's necessary for DSA
>  	certs to indicate the hash algorithm(s) that may be used with
>  	the public key contained in the cert. This prevents hash
>  	algorithm substitution in signatures formed with that key
>	(or rather the private key that corresponds to that key). Do
>  	you agree with this?
>
>-Ekr

OK, that is clearer.

While I do see some benefits to being able to specify a has algorithm 
to use with a public key and algorithm specified in a cert, I agree 
with Stefan that the SubjectPublicKeyInfo field is NOT the place to 
do this, given the history of how this field is used and the 
peripheral nature of the info you want to specify.  I think it would 
be best to create a new extension that one could use for this 
purpose, like the extension created for S/MIME to express the 
symmetric  algorithm(s) supported by a recipient of encrypted 
messages.

Steve

Date: Mon, 19 Nov 2007 11:07:03 -0800
From: Eric Rescorla <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, Stephen Kent <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Sender: [email-masked]

At Mon, 19 Nov 2007 18:39:00 +0000,
Stefan Santesson wrote:
> On the subject I have a clear opinion and that is an absolute no to
> do this through subject public key info.
> 
> The subject public key info is a core field of a certificate and it
> has a defined meaning to provide the key and its parameters. In
> addition to this the field also supplies an identifier of the key
> which identifies the key and parameter structure and syntax so it
> can be parsed. All X.509 software and systems using X.509 built to
> this date that I know of is designed to use the field exclusively in
> this manner.

OK.

> In general, it is the responsibility of the protocol to limit the
> algorithms used, not the public key certificate.

This seems problematic: the issue here is downgrade attack.
The relying party has support for a variety of digest
algorithms and if there's no indication in the certificate
of which digests will be used, then essentially an attacker
can attack the weakest one. 

> When limitations
> are specified in the certificate this is guidance for the
> applications using it. Except for a few core restrictions defined in
> path validation, it is nothing that will be enforced on the crypto
> API level. ANSI has made attempts to defined expanded restrictions
> in the subject public key field for ECC algorithm modes and this is
> exactly the type of complexity and change in field usage we don't
> need in X.509. Especially since nobody has defined where in the
> system architecture these restrictions should be enforced (protocol
> level, application level or crypto library level where keys are
> stored and used).
>
> Conclusion is. Any new types of usage restrictions must be provided
> in a new field. i.e. in a certificate extension and it must be
> understood that this serves as information to the relying party on
> when it is appropriate to use this certificate.

OK well, I don't have a problem with it being in a new field,
or that it's for the information of the relying party, but for
the reasons I argue above, I think it needs to be uniform for
all protocols and needs to be in the cert.

-Ekr

From: Stefan Santesson <[email-masked]>
To: Eric Rescorla <[email-masked]>, Stephen Kent <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 19 Nov 2007 18:39:00 +0000
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

First a small technicality.

I copied the OID from the ASN'1 section of the draft.

Someone pointed out to me that the two OIDs were identical. So here are the correct OIDs

     --
     -- DSA with SHA-224 and SHA-256 signature algorithms
     --

     dsa-with-sha224 OBJECT IDENTIFIER ::=  { joint-iso-
             ccitt(2) country(16) us(840) organization(1)
             gov(101) csor(3) algorithms(4) id-dsa-with-sha2(3)
             1}

     dsa-with-sha256 OBJECT IDENTIFIER ::=  { joint-iso-
             ccitt(2) country(16) us(840) organization(1)
             gov(101) csor(3) algorithms(4) id-dsa-with-sha2(3)
             2}

On the subject I have a clear opinion and that is an absolute no to do this through subject public key info.

The subject public key info is a core field of a certificate and it has a defined meaning to provide the key and its parameters. In addition to this the field also supplies an identifier of the key which identifies the key and parameter structure and syntax so it can be parsed. All X.509 software and systems using X.509 built to this date that I know of is designed to use the field exclusively in this manner.

In general, it is the responsibility of the protocol to limit the algorithms used, not the public key certificate. When limitations are specified in the certificate this is guidance for the applications using it. Except for a few core restrictions defined in path validation, it is nothing that will be enforced on the crypto API level. ANSI has made attempts to defined expanded restrictions in the subject public key field for ECC algorithm modes and this is exactly the type of complexity and change in field usage we don't need in X.509. Especially since nobody has defined where in the system architecture these restrictions should be enforced (protocol level, application level or crypto library level where keys are stored and used).

Conclusion is. Any new types of usage restrictions must be provided in a new field. i.e. in a certificate extension and it must be understood that this serves as information to the relying party on when it is appropriate to use this certificate.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]]
> Sent: den 19 november 2007 17:48
> To: Stephen Kent
> Cc: Eric Rescorla; Stefan Santesson; [email-masked]; [email-masked]
> Subject: Re: [TLS] DSA/SHA-1, and OIDs
>
> At Mon, 19 Nov 2007 11:35:47 -0500,
> Stephen Kent wrote:
> >
> > Eric,
> >
> > Your question was:
> >       My claim is that for security reasons it's necessary for DSA
> certs
> >       to indicate the hash algorithm(s) that may be used with the
> cert.
> >       This prevents hash algorithm substitution in the signature.
> >       Do you agree with this?
> >
> > The wording here strikes me as a bit odd.  The hash algorithm used to
> > verify a cert IS specified in the cert, in the SignatureAlgorithm
> > field.
> >
> > The hash algorithm(s) that may be used with the public KEY in the
> > cert are not specified, in general, as the key may be used to verify
> > signatures for certs or for other signed objects (in the case of EE
> > certs).
>
> I agree my wording was imprecise. Let me rephrase:
>
>         My claim is that for security reasons it's necessary for DSA
>         certs to indicate the hash algorithm(s) that may be used with
>         the public key contained in the cert. This prevents hash
>         algorithm substitution in signatures formed with that key
>         (or rather the private key that corresponds to that key). Do
>         you agree with this?
>
> -Ekr

Date: Mon, 19 Nov 2007 08:47:53 -0800
From: Eric Rescorla <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, Stefan Santesson <[email-masked]>, "[email-masked]"	<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Sender: [email-masked]

At Mon, 19 Nov 2007 11:35:47 -0500,
Stephen Kent wrote:
> 
> Eric,
> 
> Your question was:
> 	My claim is that for security reasons it's necessary for DSA certs
> 	to indicate the hash algorithm(s) that may be used with the cert.
> 	This prevents hash algorithm substitution in the signature.
> 	Do you agree with this?
> 
> The wording here strikes me as a bit odd.  The hash algorithm used to 
> verify a cert IS specified in the cert, in the SignatureAlgorithm 
> field.
>
> The hash algorithm(s) that may be used with the public KEY in the 
> cert are not specified, in general, as the key may be used to verify 
> signatures for certs or for other signed objects (in the case of EE 
> certs).

I agree my wording was imprecise. Let me rephrase:

 	My claim is that for security reasons it's necessary for DSA
 	certs to indicate the hash algorithm(s) that may be used with
 	the public key contained in the cert. This prevents hash
 	algorithm substitution in signatures formed with that key
	(or rather the private key that corresponds to that key). Do
 	you agree with this?

-Ekr

Date: Mon, 19 Nov 2007 11:35:47 -0500
To: Eric Rescorla <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Cc: Stefan Santesson <[email-masked]>, Eric Rescorla <[email-masked]>, "[email-masked]"	<[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

Eric,

Your question was:
	My claim is that for security reasons it's necessary for DSA certs
	to indicate the hash algorithm(s) that may be used with the cert.
	This prevents hash algorithm substitution in the signature.
	Do you agree with this?

The wording here strikes me as a bit odd.  The hash algorithm used to 
verify a cert IS specified in the cert, in the SignatureAlgorithm 
field.

The hash algorithm(s) that may be used with the public KEY in the 
cert are not specified, in general, as the key may be used to verify 
signatures for certs or for other signed objects (in the case of EE 
certs).

Steve

Date: Mon, 19 Nov 2007 08:28:15 -0800
To: [email-masked]
From: The IESG <[email-masked]> (by way of Paul Hoffman)
Subject: Last Call: draft-ietf-pkix-2797-bis (Certificate Management   Messages over CMS) to Proposed Standard
Sender: [email-masked]

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

- 'Certificate Management over CMS (CMC) Transport Protocols '
    <draft-ietf-pkix-cmc-trans-06.txt> as a Proposed Standard
- 'CMC Compliance Document '
    <draft-ietf-pkix-cmc-compl-04.txt> as a Proposed Standard
- 'Certificate Management Messages over CMS '
    <draft-ietf-pkix-2797-bis-05.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 2007-12-03. 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-cmc-trans-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-compl-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-pkix-2797-bis-05.txt

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

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-pkix-2797-bis (Certificate Management  Messages over CMS) to Proposed Standard 
Reply-To: [email-masked]
Cc: <[email-masked]>
Date: Mon, 19 Nov 2007 10:46:48 -0500
Sender: [email-masked]

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

- 'Certificate Management over CMS (CMC) Transport Protocols '
   <draft-ietf-pkix-cmc-trans-06.txt> as a Proposed Standard
- 'CMC Compliance Document '
   <draft-ietf-pkix-cmc-compl-04.txt> as a Proposed Standard
- 'Certificate Management Messages over CMS '
   <draft-ietf-pkix-2797-bis-05.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 2007-12-03. 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-cmc-trans-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-compl-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-pkix-2797-bis-05.txt

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

From: "Dr. Vito Harding" <[email-masked]>
To: <[email-masked]>
Subject: Your girlfriend leaved you alone because of your cock size.
Date: Mon, 19 Nov 2007 22:52:07 -0800

You are nervous because of your penis  size. 

Women are joking laughing at you.

Never fear Man. Now you have astonishing  possibility to solve this problem.

Use most popular cock  enlargement. 

You will forget about you problem for sure.

http://demotch.com/

Date: Mon, 19 Nov 2007 14:16:58 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "S-MIME / IETF" <[email-masked]>
Subject: Re: TimeStampedData draft updated - please comment
Sender: [email-masked]

Adriano,

Thank you for this new proposal. I skimmed through it.

It is interesting, but I fear that it is targeted to the wrong WG.
Since this would be an extension of CMS, this work item 
would rather belong to the S-MIME WG.
For this reason, I copy the S-MIME WG. 

In addition, some polishing would be needed.

Rather than long words, you will find hereafter a rewriting of the ASN.1 
with a few explanatory comments.

   TimeStampedData ::= SEQUENCE { 
      version        [0] Version DEFAULT v1, 
      fileName           UTF8String, 
      mimeType           PrintableString, 
      fileLocation       UTF8String OPTIONAL, 
      -- fileLocation is only a hint. 
      -- The file may or may not be stored at that location.
      content            OCTET STRING, 
      temporalEvidences  TemporalEvidences 
}

   Version  ::=  INTEGER  { v1(0) } 
   TemporalEvidences ::= SEQUENCE (SIZE(1..MAX)) OF TemporalEvidence 

-- This structure allows multiple levels of temporal evidences.

   TemporalEvidence ::= SEQUENCE {
      evidences            Evidences,
      certificateLists     CertificateLists  OPTIONAL
}

   CertificateLists :: = SEQUENCE (SIZE(1..MAX)) OF CertificateList

   Evidence ::= CHOICE { 
      timeStamps     [0] SEQUENCE (SIZE(1..MAX)) OF TimeStampToken }

-- For each level there can be one or more time-stamps tokens.

-- Before re-time stamping a set of former time-stamp tokens, 
-- the CRLs of the previous level of time-stamps tokens can be captured 
-- and inserted in the data structure.

Denis

>Hello there,
>
>here I am again with my TimeStampedData proposal.
>
>I have submitted a new draft (also attached here) that takes into account some of the remarks and suggestions received so far.
>
>I have made room for additional types of temporal evidence, like e.g. RFC 4998, while keeping RFC 3161 as the basis of interoperability.
>
>I would like to invite everybody involved in time-stamping and archiving e-documents to comment upon it: has it improved? something is missing?
>
>In particular, please state:
>- are you interested in this work?
>- do you agree to adopt it as a new PKIX work item?
>- are you going to use this format, once it is finished?
>
>Is anybody willing to spend a few words on this draft during the IETF meeting in Vancouver (as I cannot attend myself) ?
>
>And finally, is anybody willing to invest a little time in co-authoring this draft with me?
>
>Adriano
>Actalis S.p.A.
>Milano, ITALY
>
>
>
>
>-----Messaggio originale-----
>Da: [email-masked] [mailto:[email-masked]] Per conto di Santoni Adriano
>Inviato: lunedì 3 settembre 2007 10.42
>A: [email-masked]
>Oggetto: R: R: Draft on TimeStampedData
>
>
>Let me summarize the issues discussed so far:
>
>1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken (RFC 3161)
>
>In principle, I have no objections as long as we do not complicate things too much and do not hamper interoperability. 
>
>There are at least two possible approaches to accomodate RFC 4998:
>
>   a) explicitly provide for (one) ER in the TimeStampedData syntax, as an alternative to the SET OF TimeStampToken;
>   b) do not mention any specific standard for the "evidence", but just mention RFC 3161 and RFC 4998 as two possibilities;
>
>In any case, it must be possible for the verifying application to easily detect which of the two (or more) kind of "evidence" has been used in the TimeStampedData envelope under examination. If we restrict the kinds of evidence to the two above, then a extra tagging may not be necessary, as an EvidenceRecord is a SEQUENCE, while the other choice would be a SET OF. Although unelegant, it would work. On the other hand, if we do not want to restrict the kinds of evidence to the two above, then of course we should somehow add an extra tagging level, because nobody knows at this time what syntax a third kind of evidence would conform to.
>
>In any case, for the sake of interoperability, strong emphasis should be given to RFC 3161 as today this is the most widely implemented type of evidence.
>
>In conclusion: I agree with allowing RFC 4998 if we do that in a way that does not modify the strong emphasis on RFC 3161 and does not hamper interoperability (which must be based on supporting RFC 3161, even though certain applications may also support RFC 4998).
>
>2) filename vs. URI 
>
>Some remarked that an URI (or URI Reference) would be more versatile than a simple filename. That is obviously true, but it implies that the 'content' field of TimeStampedData may be empty. This is not what I was addressing in my original proposal. It would not just require the 'content' field to be declared OPTIONAL: it would make interoperability very difficult to achieve unless we restrict the URI schemes to a very small subset (e.g. http:, cid:, file:, ldap:) of the myriad possibilities. In any case, it would require ages of interoperability testing. And it would make life much harder for software implementors, without much of a benefit in view. I strongly believe in keeping things simple as much as possible.
>
>3) multiple contents and RFC 4073
>
>The 'content' field in the TimeStampedData envelope is not structured, in my original proposal. It is just an OCTET STRING. That allows for any kind of content to be conveyed, even a ContentCollection according to RFC 4073.
>
>Another remark has been made with reference to RFC 4073: the ContentWithAttributes structure, also defined in RFC 4073, could in principle be used to bundle some content with the corrisponding evidence (the goal of my draft). Although this is true, it would require definining some additional OIDs, and mandating the presence of certain Attributes tagged by those OIDs. I frankly believe the TimeStampedData structure that I am proposing is better, first because it is dedicated and second because it "implements the ContentInfo interface", so to speak. It is simpler to manage for applications already able to parse different kinds of ContentInfo envelopes (there are a great many), possibly in a recursive way.
>
>Adriano 
>
>
>-----Messaggio originale-----
>Da: Young H Etheridge [mailto:[email-masked]]
>Inviato: venerdì 31 agosto 2007 17.48
>A: Santoni Adriano
>Cc: [email-masked]
>Oggetto: Re: R: Draft on TimeStampedData
>
>Adriano,
>
>To add to your thought processes:  I believe that a URI of "file:///private.stuff" addresses your concern for privacy of the physical URI.  But, allowing URI in the syntax will make less private repositories, not necessarily file systems, more universally accessible.  The intent of the URI in RFC 3986 is to also allow for abstractly identifying a resource, not necessarily providing a physical resource.  In this manner the URI could then be used as an object identity in database(s).
>
>Take care,
>
>yhe
>
>Santoni Adriano wrote:
>> To accomodate for RFC 4998, I would propose the following syntax:
>>
>> TimeStampedData ::= SEQUENCE {
>> 	version			INTEGER { v1(1) },
>> 	fileName		UTF8String,
>> 	mimeType 	 	PrintableString,
>> 	content		OCTET STRING,
>> 	evidence		Evidence
>> }
>>
>> Evidence ::= CHOICE {
>> 	timeStamps		[0] SET (SIZE(1..MAX)) OF TimeStampToken,
>> 	evidenceRecord	[1] EvidenceRecord -- according to RFC 4998
>> }
>>
>> (I am not sure whether it would be better to use explicit or implicit
>> tags...)
>>
>> Regarding the idea of having an URI instead of a filename: I'd prefer to think over things a little bit more, and maybe collect more feedback.
>>
>> In my mind, I can send a TimeStampedData envelope to business partners and/or public agencies via email. If the timestamped document is a local one, which I think is a meaningful and realistic scenario, then I do not want my company's hostnames and pathnames to be included in the envelope so that the recipient can see them.
>>
>> Adriano
>>
>>
>>
>> -----Messaggio originale-----
>> Da: [email-masked] [mailto:[email-masked]]
>> Per conto di Julien Stern
>> Inviato: venerdì 31 agosto 2007 13.43
>> A: [email-masked]
>> Oggetto: Re: Draft on TimeStampedData
>>
>>
>> On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
>>   
>>> Adriano,
>>>
>>>     
>>>> After pondering on this and other remarks, I cannot help but agree 
>>>> with Steve.
>>>>
>>>> My original and essential goal is that of facilitating 
>>>> interoperability in a currently unregulated field. If we allow for 
>>>> several "degrees of freedom", than interoperability will be hampered from the beginning.
>>>> So I'd better stick to RFC 3161 for now. We could include support 
>>>> for RFC 4998 Evidence Records later on, at the time when they become 
>>>> a widespread reality comparable to RFC 3161 TimeStampTokens (which 
>>>> are widely implemented).
>>>>       
>>> I would prefer to have both options: RFC 3161 and RFC 4998. For our 
>>> customers evidence records are a widespread reality already.
>>> A standardized way to put some data and their evidence record into a 
>>> single file would be useful.
>>>     
>>
>> I strongly concur with this comment. Allowing the usage of ERS as well as simple timestamps would allow the TimestampedData to leverage all the work of RFC 4998 regarding timestamps instead of reinventing the wheel in the future.
>>
>> Regards,
>>
>> --
>> Julien
>>
>>   
>>> Kind regards
>>> Tilo
>>>
>>>
>>>     
>>>> -----Messaggio originale-----
>>>> Da: Stephen Kent [mailto:[email-masked]]
>>>> Inviato: giovedì 30 agosto 2007 23.05
>>>> A: Young H Etheridge
>>>> Cc: Santoni Adriano; [email-masked]
>>>> Oggetto: Re: R: Draft on TimeStampedData
>>>>
>>>> At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
>>>>       
>>>>>> ...
>>>>>>           
>>>>> Agreed, w.r.t. normative vs informative.  The above quote from
>>>>> RFC-4998 merely underscores that this draft should also suggest, 
>>>>> informatively, that the choice of Timestamp should be one that 
>>>>> meets the normative syntax for Timestamp and not specify that which 
>>>>> is in RFC-3161.  Nothing gets broken by being less restrictive and 
>>>>> generally more informative to the community-at-large.
>>>>>         
>>>> I have to disagree with your conclusion. If we require 3161 time stamps in an RFC of the sort Adriano proposed, then everyone can parse them if they comply with the RFC. If the RFC says "insert the time stamp from any standard you want here, and just tell us which one you used" then we have a problem. A compliant implementation can generate data structures containing time stamps that other compliant implementations cannot parse. That's the sort of interoperability problem we try to avoid in the IETF.
>>>>
>>>>       
>>>>> My notion of resilience does not mean "more encompassing" but that 
>>>>> of providing the user community with choice and an enhanced 
>>>>> safeguard against the possibility of the weakening of an algorithm.
>>>>>         
>>>> Choices can be good, but they can create interoperability problems in some cases, like this one. Also, we have algorithm agility as a requirement in all of our work, so the second concern you cite does not seem to apply here.
>>>>
>>>> Steve
>>>>       
>>> --
>>> Tilo Kienitz
>>> SecCommerce Informationssysteme GmbH
>>> Obenhauptstr. 5
>>> D - 22335 Hamburg
>>> Germany                                   http://www.seccommerce.de

Content-class: urn:content-classes:message
Subject: TimeStampedData draft updated - please comment
Date: Mon, 19 Nov 2007 12:36:48 +0100
From: "Santoni Adriano" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C82AA0.78F9608C
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello there,

here I am again with my TimeStampedData proposal.

I have submitted a new draft (also attached here) that takes into =
account some of the remarks and suggestions received so far.

I have made room for additional types of temporal evidence, like e.g. =
RFC 4998, while keeping RFC 3161 as the basis of interoperability.

I would like to invite everybody involved in time-stamping and archiving =
e-documents to comment upon it: has it improved? something is missing?

In particular, please state:
- are you interested in this work?
- do you agree to adopt it as a new PKIX work item?
- are you going to use this format, once it is finished?

Is anybody willing to spend a few words on this draft during the IETF =
meeting in Vancouver (as I cannot attend myself) ?

And finally, is anybody willing to invest a little time in co-authoring =
this draft with me?

Adriano
Actalis S.p.A.
Milano, ITALY

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] =
Per conto di Santoni Adriano
Inviato: luned=EC 3 settembre 2007 10.42
A: [email-masked]
Oggetto: R: R: Draft on TimeStampedData

Let me summarize the issues discussed so far:

1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken (RFC =
3161)

In principle, I have no objections as long as we do not complicate =
things too much and do not hamper interoperability.=20

There are at least two possible approaches to accomodate RFC 4998:

   a) explicitly provide for (one) ER in the TimeStampedData syntax, as =
an alternative to the SET OF TimeStampToken;
   b) do not mention any specific standard for the "evidence", but just =
mention RFC 3161 and RFC 4998 as two possibilities;

In any case, it must be possible for the verifying application to easily =
detect which of the two (or more) kind of "evidence" has been used in =
the TimeStampedData envelope under examination. If we restrict the kinds =
of evidence to the two above, then a extra tagging may not be necessary, =
as an EvidenceRecord is a SEQUENCE, while the other choice would be a =
SET OF. Although unelegant, it would work. On the other hand, if we do =
not want to restrict the kinds of evidence to the two above, then of =
course we should somehow add an extra tagging level, because nobody =
knows at this time what syntax a third kind of evidence would conform =
to.

In any case, for the sake of interoperability, strong emphasis should be =
given to RFC 3161 as today this is the most widely implemented type of =
evidence.

In conclusion: I agree with allowing RFC 4998 if we do that in a way =
that does not modify the strong emphasis on RFC 3161 and does not hamper =
interoperability (which must be based on supporting RFC 3161, even =
though certain applications may also support RFC 4998).

2) filename vs. URI=20

Some remarked that an URI (or URI Reference) would be more versatile =
than a simple filename. That is obviously true, but it implies that the =
'content' field of TimeStampedData may be empty. This is not what I was =
addressing in my original proposal. It would not just require the =
'content' field to be declared OPTIONAL: it would make interoperability =
very difficult to achieve unless we restrict the URI schemes to a very =
small subset (e.g. http:, cid:, file:, ldap:) of the myriad =
possibilities. In any case, it would require ages of interoperability =
testing. And it would make life much harder for software implementors, =
without much of a benefit in view. I strongly believe in keeping things =
simple as much as possible.

3) multiple contents and RFC 4073

The 'content' field in the TimeStampedData envelope is not structured, =
in my original proposal. It is just an OCTET STRING. That allows for any =
kind of content to be conveyed, even a ContentCollection according to =
RFC 4073.

Another remark has been made with reference to RFC 4073: the =
ContentWithAttributes structure, also defined in RFC 4073, could in =
principle be used to bundle some content with the corrisponding evidence =
(the goal of my draft). Although this is true, it would require =
definining some additional OIDs, and mandating the presence of certain =
Attributes tagged by those OIDs. I frankly believe the TimeStampedData =
structure that I am proposing is better, first because it is dedicated =
and second because it "implements the ContentInfo interface", so to =
speak. It is simpler to manage for applications already able to parse =
different kinds of ContentInfo envelopes (there are a great many), =
possibly in a recursive way.

Adriano=20

-----Messaggio originale-----
Da: Young H Etheridge [mailto:[email-masked]]
Inviato: venerd=EC 31 agosto 2007 17.48
A: Santoni Adriano
Cc: [email-masked]
Oggetto: Re: R: Draft on TimeStampedData

Adriano,

To add to your thought processes:  I believe that a URI of =
"file:///private.stuff" addresses your concern for privacy of the =
physical URI.  But, allowing URI in the syntax will make less private =
repositories, not necessarily file systems, more universally accessible. =
 The intent of the URI in RFC 3986 is to also allow for abstractly =
identifying a resource, not necessarily providing a physical resource.  =
In this manner the URI could then be used as an object identity in =
database(s).

Take care,

yhe

Santoni Adriano wrote:
> To accomodate for RFC 4998, I would propose the following syntax:
>
> TimeStampedData ::=3D SEQUENCE {
> 	version			INTEGER { v1(1) },
> 	fileName		UTF8String,
> 	mimeType 	 	PrintableString,
> 	content		OCTET STRING,
> 	evidence		Evidence
> }
>
> Evidence ::=3D CHOICE {
> 	timeStamps		[0] SET (SIZE(1..MAX)) OF TimeStampToken,
> 	evidenceRecord	[1] EvidenceRecord -- according to RFC 4998
> }
>
> (I am not sure whether it would be better to use explicit or implicit
> tags...)
>
> Regarding the idea of having an URI instead of a filename: I'd prefer =
to think over things a little bit more, and maybe collect more feedback.
>
> In my mind, I can send a TimeStampedData envelope to business partners =
and/or public agencies via email. If the timestamped document is a local =
one, which I think is a meaningful and realistic scenario, then I do not =
want my company's hostnames and pathnames to be included in the envelope =
so that the recipient can see them.
>
> Adriano
>
>
>
> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]]
> Per conto di Julien Stern
> Inviato: venerd=EC 31 agosto 2007 13.43
> A: [email-masked]
> Oggetto: Re: Draft on TimeStampedData
>
>
> On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
>  =20
>> Adriano,
>>
>>    =20
>>> After pondering on this and other remarks, I cannot help but agree=20
>>> with Steve.
>>>
>>> My original and essential goal is that of facilitating=20
>>> interoperability in a currently unregulated field. If we allow for=20
>>> several "degrees of freedom", than interoperability will be hampered =
from the beginning.
>>> So I'd better stick to RFC 3161 for now. We could include support=20
>>> for RFC 4998 Evidence Records later on, at the time when they become =

>>> a widespread reality comparable to RFC 3161 TimeStampTokens (which=20
>>> are widely implemented).
>>>      =20
>> I would prefer to have both options: RFC 3161 and RFC 4998. For our=20
>> customers evidence records are a widespread reality already.
>> A standardized way to put some data and their evidence record into a=20
>> single file would be useful.
>>    =20
>
> I strongly concur with this comment. Allowing the usage of ERS as well =
as simple timestamps would allow the TimestampedData to leverage all the =
work of RFC 4998 regarding timestamps instead of reinventing the wheel =
in the future.
>
> Regards,
>
> --
> Julien
>
>  =20
>> Kind regards
>> Tilo
>>
>>
>>    =20
>>> -----Messaggio originale-----
>>> Da: Stephen Kent [mailto:[email-masked]]
>>> Inviato: gioved=EC 30 agosto 2007 23.05
>>> A: Young H Etheridge
>>> Cc: Santoni Adriano; [email-masked]
>>> Oggetto: Re: R: Draft on TimeStampedData
>>>
>>> At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
>>>      =20
>>>>> ...
>>>>>          =20
>>>> Agreed, w.r.t. normative vs informative.  The above quote from
>>>> RFC-4998 merely underscores that this draft should also suggest,=20
>>>> informatively, that the choice of Timestamp should be one that=20
>>>> meets the normative syntax for Timestamp and not specify that which =

>>>> is in RFC-3161.  Nothing gets broken by being less restrictive and=20
>>>> generally more informative to the community-at-large.
>>>>        =20
>>> I have to disagree with your conclusion. If we require 3161 time =
stamps in an RFC of the sort Adriano proposed, then everyone can parse =
them if they comply with the RFC. If the RFC says "insert the time stamp =
from any standard you want here, and just tell us which one you used" =
then we have a problem. A compliant implementation can generate data =
structures containing time stamps that other compliant implementations =
cannot parse. That's the sort of interoperability problem we try to =
avoid in the IETF.
>>>
>>>      =20
>>>> My notion of resilience does not mean "more encompassing" but that=20
>>>> of providing the user community with choice and an enhanced=20
>>>> safeguard against the possibility of the weakening of an algorithm.
>>>>        =20
>>> Choices can be good, but they can create interoperability problems =
in some cases, like this one. Also, we have algorithm agility as a =
requirement in all of our work, so the second concern you cite does not =
seem to apply here.
>>>
>>> Steve
>>>      =20
>> --
>> Tilo Kienitz
>> SecCommerce Informationssysteme GmbH
>> Obenhauptstr. 5
>> D - 22335 Hamburg
>> Germany                                   http://www.seccommerce.de
>>
>>
>>    =20
>
>
>  =20

------_=_NextPart_001_01C82AA0.78F9608C
Content-Type: text/plain;
	name="draft-santoni-timestampeddata-01.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-santoni-timestampeddata-01.txt
Content-Disposition: attachment;
	filename="draft-santoni-timestampeddata-01.txt"

------_=_NextPart_001_01C82AA0.78F9608C--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-pkix-2797-bis-05.txt 
Date: Mon, 19 Nov 2007 02:20:01 -0500
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           : Certificate Management Messages over CMS
	Author(s)       : J. Schaad, M. Myers
	Filename        : draft-ietf-pkix-2797-bis-05.txt
	Pages           : 92
	Date            : 2007-11-19

This document defines the base syntax for CMC, a Certificate
Management protocol using the Cryptographic Message Syntax (CMS).
This protocol addresses two immediate needs within the Internet
Public Key Infrastructure (PKI) community:

1.  The need for an interface to public key certification products

 and services based on CMS and PKCS #10 (Public Key Cryptography

 Standard), and

2.  The need for a PKI enrollment protocol for encryption only keys

 due to algorithm or hardware design.

CMC also requires the use of the transport document and the
requirements usage document along with this document for a full
definition.

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-pkix-2797-bis-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-2797-bis-05.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-2797-bis-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-2797-bis-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2007-11-19021027.I-D\@ietf.org>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-pkix-cmc-compl-04.txt 
Date: Mon, 19 Nov 2007 02:00:01 -0500
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           : CMC Compliance Document
	Author(s)       : J. Schaad, M. Myers
	Filename        : draft-ietf-pkix-cmc-compl-04.txt
	Pages           : 21
	Date            : 2007-11-19

This document provides a set of compliance statements about the CMC
(Certificate Management over CMS) enrollment protocol.  The ASN.1
structures and the transport mechanisms for the CMC enrollment
protocol are covered in other documents.  This document provides the
information needed to make a compliant version of CMC.

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmc-compl-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmc-compl-04.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-compl-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmc-compl-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2007-11-19015759.I-D\@ietf.org>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-pkix-cmc-trans-06.txt 
Date: Mon, 19 Nov 2007 02:00:02 -0500
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           : Certificate Management over CMS (CMC) Transport Protocols
	Author(s)       : J. Schaad, M. Myers
	Filename        : draft-ietf-pkix-cmc-trans-06.txt
	Pages           : 7
	Date            : 2007-11-19

This document defines a number of transport mechanisms that are used
to move CMC (Certificate Management over CMS (Cryptographic Message
Syntax)) messages.  The transport mechanisms described in this
document are: HTTP, file, mail and TCP.1.  Overview

This document defines a number of transport methods that are used to
move CMC messages (defined in [CMC-STRUCT]).  The transport
mechanisms described in this document are: HTTP, file, mail and TCP.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmc-trans-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmc-trans-06.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-trans-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmc-trans-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2007-11-19015908.I-D\@ietf.org>

--OtherAccess--

--NextPart--

From: "Jamar E. Gold" <[email-masked]>
To: [email-masked]
Subject: by do daytime
Date: Sun, 18 Nov 2007 17:27:50 +0800

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01C82A08.57FD1D50
Content-Type: text/plain;
	charset="windows-1250"
Content-Transfer-Encoding: quoted-printable

computer screen accomplishing nothing, to sitting long hours of pretend to =
be a Virtual-prawn on the Cyberspace-Oceanfloor
it should be considered and artistic field or not.  There were

------=_NextPart_000_0017_01C82A08.57FD1D50
Content-Type: text/html;
	charset="windows-1250"
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=3Dwindows-125=
0">
<META content=3D"MSHTML 6.00.2462.2962" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<P><DIV>by having patrons physically move from one location or art work</DI=
V></P>
<P><DIV><font size=3D5>A<   >re you wan<  >ting a bi<    >gg<    >er  p_ < =
    >e > n _<  >is? </font></DIV></P>
<P><DIV>As seen on TV </DIV></P>
<DIV>Over 756,000 Men around the world are already satis<    >fied</DIV>
<DIV>Gain 2+ Inc<     >hes In Le<   >ng _th</DIV>
<DIV>Incr<   >ea<     >se Your P _e<    >n -i<     >s Wi _d<   >th (Girth) =
By u<    >p _to 27%</DIV>
<DIV>100% Sa<     >fe To Take, With NO Side Effects</DIV>
<DIV>No Pu<   >mps! No Su<    >rg<   >ery! No Ex<    >ercis<    >es! </DIV>=

<DIV>F _<  >R<   >E >E Bo<     >ttles</DIV>
<P><DIV><b><font size=3D6>g<     >or<  >lfu<     >r.co<    >m</font></b></D=
IV></P>
<DIV>the hydro bill when you spend all of your time in V.R. and</DIV>

</BODY></HTML>

------=_NextPart_000_0017_01C82A08.57FD1D50--

From: "gareth Golden" <[email-masked]>
To: <[email-masked]>
Subject: naaldbom
Date: Sat, 17 Nov 2007 15:35:06 -0300

------=_NextPart_000_0003_01C8292F.6E0C7110
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Learn the sex secrets of the PC muscle and have sex for hours =
ejaculating many times.

Kablia matteson
http://chimla.com/
------=_NextPart_000_0003_01C8292F.6E0C7110
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.2900.3059" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT Arial size=3D2>Learn the sex secrets of the PC muscle and =
have sex for=20
hours ejaculating many times.</FONT></DIV>
<DIV><FONT Arial size=3D2></FONT></DIV>
<DIV><FONT Arial size=3D2>Kablia matteson</FONT></DIV>
<DIV><FONT Arial size=3D2><A=20
HREF=3D"http://chimla.com/">http://chimla.com/</A></FONT></DIV></BODY></H=
TML>

------=_NextPart_000_0003_01C8292F.6E0C7110--

Date: Sat, 17 Nov 2007 06:17:38 -0800
From: Eric Rescorla <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Sender: [email-masked]

At Fri, 16 Nov 2007 15:27:20 +0000,
Stefan Santesson wrote:

> 
> The OID 1 2 840 10040 4 1 identifies DSA only and is used in the subject public key info for declaring the DSA key. In FIPS 186-2 sha-1 was the only hash algorithm, but this is expanded in FIPS 186-3
> 
> The following OIDs are relevant
> 
> >From RFC 3279:
> 
>   -- OID for DSA public key
>    id-dsa OBJECT IDENTIFIER ::= {
>         iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }
> 
>    -- OID for DSA signature generated with SHA-1 hash
>    id-dsa-with-sha1 OBJECT IDENTIFIER ::=  {
>         iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 }
> 
> 
> >From draft-ietf-pkix-sha2-dsa-ecdsa-01.txt
> 
>         id-dsa-with-sha224 OBJECT IDENTIFIER ::=  { joint-iso-
>         ccitt(2) country(16) us(840) organization(1) gov(101)
>         csor(3) algorithms(4) id-dsa-with-sha2(3) 1}
> 
>         id-dsa-with-sha256 OBJECT IDENTIFIER ::=  { joint-iso-
>         ccitt(2) country(16) us(840) organization(1) gov(101)
>         csor(3) algorithms(4) id-dsa-with-sha2(3) 1}

Stefan,

Maybe it's worth upleveling a bit.

My claim is that for security reasons it's necessary for DSA certs
to indicate the hash algorithm(s) that may be used with the cert.
This prevents hash algorithm substitution in the signature. 
Do you agree with this?

If so, then it becomes a question of encoding this information in
the cert. I'm not a PKIX expert and don't have an opinion about
how it should be encoded except that:

1. Current certificates must obviously be usable with at least
   SHA-1.
2. There must be a way for future certificates to rule out SHA-1.

How does PKIX propose to solve this?

-Ekr

From: Stefan Santesson <[email-masked]>
To: Eric Rescorla <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 16 Nov 2007 15:27:20 +0000
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Not really.

The OID 1 2 840 10040 4 1 identifies DSA only and is used in the subject public key info for declaring the DSA key. In FIPS 186-2 sha-1 was the only hash algorithm, but this is expanded in FIPS 186-3

The following OIDs are relevant

>From RFC 3279:

  -- OID for DSA public key
   id-dsa OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }

   -- OID for DSA signature generated with SHA-1 hash
   id-dsa-with-sha1 OBJECT IDENTIFIER ::=  {
        iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 }

>From draft-ietf-pkix-sha2-dsa-ecdsa-01.txt

        id-dsa-with-sha224 OBJECT IDENTIFIER ::=  { joint-iso-
        ccitt(2) country(16) us(840) organization(1) gov(101)
        csor(3) algorithms(4) id-dsa-with-sha2(3) 1}

        id-dsa-with-sha256 OBJECT IDENTIFIER ::=  { joint-iso-
        ccitt(2) country(16) us(840) organization(1) gov(101)
        csor(3) algorithms(4) id-dsa-with-sha2(3) 1}

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]]
> Sent: den 12 november 2007 20:11
> To: [email-masked]; [email-masked]
> Subject: [TLS] DSA/SHA-1, and OIDs
>
> Hi PKIX guys,
>
> As you probably know, in some modes of TLS one or the other party
> signs data. In some cases, this presumably means DSA. This is
> fine if you can guarantee that you are going to use SHA-1 with
> DSA, but obviously there's going to be a desire to transition
> to SHA-256, which raises the issue of digest substitution.
>
> My understanding of the current thinking on how to prevent this
> is to indicate in the certificate which digest algorithm is to
> be used with the cert. So, the rule we plan to promulgate in TLS
> is:
>
>         OID 1 2 840 10040 4 1 MUST only be used with SHA-1.  Future
>         revisions of [PKIX] MAY define new object identifiers for DSA
>         with other hash algorithms.
>
> I wanted to check that this is compatible with the current PKIX
> thinking.
>
> Thanks,
> -Ekr
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tls

Date: Fri, 16 Nov 2007 10:21:31 +1100
From: Steven Legg <[email-masked]>
To: Mike <[email-masked]>
CC: [email-masked]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Sender: [email-masked]

Mike,

Mike wrote:
> 
>> the change from this:
>>
>>     Attribute ::= SEQUENCE {
>>         type    AttributeDescription,
>>         vals    SET OF AttributeValue }
>>
>> to this:
>>
>>     PartialAttribute ::= SEQUENCE {
>>         type    AttributeDescription,
>>         vals    SET OF value AttributeValue }
>>
>>     Attribute ::= PartialAttribute(WITH COMPONENTS {
>>         ...,
>>         vals (SIZE(1..MAX))})
>>
>> The addition of the WITH COMPONENTS constraint was motivated by the
>> desire to express formally in the ASN.1 what was previously expressed
>> only in the text of the RFC.
> 

 > I think this could have been achieved with:
 >
 >     Attribute ::= SEQUENCE {
 >         type    AttributeDescription,
 >         vals    SET SIZE(1..MAX) OF value AttributeValue }

No. In the information model an attribute is required to have at
least one value, but in the protocol there are cases where the values
may be omitted. The split into PartialAttribute and Attribute
allows the two cases to be distinguished.

 >
 > and my existing parser could have handled it.
 >
 > But it appears that the move to ASN.1 2002 is inevitable and I
 > should just accept it.  I would just ask that the transition be
 > completed over the course of a year or so to allow people to
 > catch up.  I will have to rewrite my existing code, as I can
 > not take advantage of the a2c compiler that is now available.

You have the choice of rewriting your existing parser, rewriting
any ASN.1 that uses the 2002 syntax to suit your parser, or
continuing to use the 1988-syntax definitions.

Regards,
Steven

> Mike

Date: Thu, 15 Nov 2007 13:40:18 -0500
To: Mike <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Sender: [email-masked]

Here is how I would see the transition:

   - publish the updates that provide the new syntax, but the 1988 
syntax remains normative

   - as each specification gets revised, the newer syntax will become 
the only one in the RFC

I believe that this transition will take many years.

Russ

At 10:31 AM 11/15/2007, Mike wrote:

>>the change from this:
>>     Attribute ::= SEQUENCE {
>>         type    AttributeDescription,
>>         vals    SET OF AttributeValue }
>>to this:
>>     PartialAttribute ::= SEQUENCE {
>>         type    AttributeDescription,
>>         vals    SET OF value AttributeValue }
>>     Attribute ::= PartialAttribute(WITH COMPONENTS {
>>         ...,
>>         vals (SIZE(1..MAX))})
>>The addition of the WITH COMPONENTS constraint was motivated by the
>>desire to express formally in the ASN.1 what was previously expressed
>>only in the text of the RFC.
>
>I think this could have been achieved with:
>
>     Attribute ::= SEQUENCE {
>         type    AttributeDescription,
>         vals    SET SIZE(1..MAX) OF value AttributeValue }
>
>and my existing parser could have handled it.
>
>But it appears that the move to ASN.1 2002 is inevitable and I
>should just accept it.  I would just ask that the transition be
>completed over the course of a year or so to allow people to
>catch up.  I will have to rewrite my existing code, as I can
>not take advantage of the a2c compiler that is now available.
>
>Mike
>

Date: Thu, 15 Nov 2007 17:18:35 +0000
From: Stephen Farrell <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: "Kemp, David P." <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Sender: [email-masked]

Sure;-)

The IETF does have a choice.
The IETT cannot sensibly claim that X.208 was invented here.

The opposite of the above is nonsense.

Stephen.

PS: Note that I've not said that moving to asn.1 2002 is nonsense.
I just think that that's something to be done v. carefully.

Stefan Santesson wrote:
> Stephen,
> 
> I think it would be fair to give a rationale why you think the claims presented here are "ridiculous nonsense" and "more nonsense".
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> 
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:owner-ietf-
>> [email-masked]] On Behalf Of Stephen Farrell
>> Sent: den 15 november 2007 00:53
>> To: Kemp, David P.
>> Cc: [email-masked]
>> Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
>>
>>
>>
>>
>> Kemp, David P. wrote:
>>> The IETF does not have a choice.  It could claim to be using its
>>> own language (X.208) ...
>> More nonsense.
>>
>> S.
> 
> 

From: Stefan Santesson <[email-masked]>
To: Stephen Farrell <[email-masked]>, "Kemp, David P." <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Thu, 15 Nov 2007 15:56:45 +0000
Subject: RE: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Stephen,

I think it would be fair to give a rationale why you think the claims presented here are "ridiculous nonsense" and "more nonsense".

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stephen Farrell
> Sent: den 15 november 2007 00:53
> To: Kemp, David P.
> Cc: [email-masked]
> Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
>
>
>
>
> Kemp, David P. wrote:
> > The IETF does not have a choice.  It could claim to be using its
> > own language (X.208) ...
>
> More nonsense.
>
> S.

Date: Thu, 15 Nov 2007 07:31:48 -0800
From: Mike <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Sender: [email-masked]

> the change from this:
> 
>     Attribute ::= SEQUENCE {
>         type    AttributeDescription,
>         vals    SET OF AttributeValue }
> 
> to this:
> 
>     PartialAttribute ::= SEQUENCE {
>         type    AttributeDescription,
>         vals    SET OF value AttributeValue }
> 
>     Attribute ::= PartialAttribute(WITH COMPONENTS {
>         ...,
>         vals (SIZE(1..MAX))})
> 
> The addition of the WITH COMPONENTS constraint was motivated by the
> desire to express formally in the ASN.1 what was previously expressed
> only in the text of the RFC.

I think this could have been achieved with:

     Attribute ::= SEQUENCE {
         type    AttributeDescription,
         vals    SET SIZE(1..MAX) OF value AttributeValue }

and my existing parser could have handled it.

But it appears that the move to ASN.1 2002 is inevitable and I
should just accept it.  I would just ask that the transition be
completed over the course of a year or so to allow people to
catch up.  I will have to rewrite my existing code, as I can
not take advantage of the a2c compiler that is now available.

Mike

Date: Thu, 15 Nov 2007 12:17:04 +1100
From: Steven Legg <[email-masked]>
To: "Kemp, David P." <[email-masked]>
CC: [email-masked]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Sender: [email-masked]

David,

Kemp, David P. wrote:
> I believe in KISS.  And I see plenty of examples of ASN.1-based
> protocols (and was co-author of one, to my shame) which became
> complex just because it is easier to get carried away in ASN.1
> than in, for example, bits-in-boxes.
> 
> However, that is orthogonal to the issue of whether IETF should
> make it's ASN.1-based RFCs conform to the ASN.1 standard.
> The LDAP example you gave is unrelated to a switch from X.208
> to X.680 - the simple definition is perfectly legal under X.680,
> thus the gratuitous complexity of the second definition
> was motivated by something other than the desire to be ASN.1
> compliant.

In the LDAP example Mike gave, i.e.,

the change from this:

     Attribute ::= SEQUENCE {
         type    AttributeDescription,
         vals    SET OF AttributeValue }

to this:

     PartialAttribute ::= SEQUENCE {
         type    AttributeDescription,
         vals    SET OF value AttributeValue }

     Attribute ::= PartialAttribute(WITH COMPONENTS {
         ...,
         vals (SIZE(1..MAX))})

there are two different motivations involved. The inclusion of the
"value" identifier into SET OF AttributeValue was to make XML
encodings of the LDAP protocol messages more aesthetically pleasing
(in support of experimental extensions to LDAP). The change doesn't
affect the bits on the wire for BER and a programmer using a 1998-syntax
ASN.1 compiler can simply remove the identifiers after the SET OFs
to get the module to compile.

The addition of the WITH COMPONENTS constraint was motivated by the
desire to express formally in the ASN.1 what was previously expressed
only in the text of the RFC. This means that the revised ASN.1 is a
more complete and precise specification of the protocol than the
ASN.1 in the previous edition. A complete and precise specification
of the protocol is the main point of the RFC after all. The constraint
notation is still conformant to the 1988 syntax, so an older ASN.1
compiler should be able to parse it. If not, then the remedy is simple
- edit the constraint out of the ASN.1 before passing it to the compiler.

> 
> X.509 uses a relatively simple subset of ASN.1, and making the
> minimal changes required to become legal under X.680 should not
> require a parser with 4 tokens of lookahead.  Making more extensive
> changes that explore the more esoteric features of X.680 is a
> separate issue, and on that I'd come down on the side of KISS.
> Some things are simpler under X.680, for example the ability to
> use real UTF8STRINGs rather than a hack to produce the same bits
> on the wire as X.680.

Simplicity depends on one's perspective. As a programmer, it is
easier for me to replace ANYs with open types and component
relation constraints so that my ASN.1 toolkit takes care of all
the encoding and decoding details, rather than using the ASN.1
as is. Yes, it makes the ASN.1 more complex, but for me it makes
the overall implementation trivial. Whether a specification is
written in 1998 syntax or 2002 syntax, some group of implementors
is going to be disadvantaged. The disadvantaged group always has
the option to edit the ASN.1 to suit. To that end, perhaps Paul
could consider adding to the ASN.1 (as comments) some instructions
on how to dumb it down to the 1988 level. In my opinion, moving to
the 2002 syntax is better in the long term because it allows more
precise protocol specifications and allows greater levels of
automation.

Regards,
Steven

> 
> The IETF does not have a choice.  It could claim to be using its
> own language (X.208) just like it defines its own language to express
> the TLS protocol.  But PKIX claims to be a profile of X.509, not
> an independent certificate format that sort of resembles X.509,
> and so the modules contained in the normative sections of
> RFC 3280bis must be written in ASN.1.  That requires updates to
> the RFCs, with informative annexes to contain the pseudo-ASN.1.
> 
> 

From: "Arjan Mannonen" <[email-masked]>
To: [email-masked]
Subject: 1txen
Date: 	Thu, 15 Nov 2007 01:29:02 +0100
Importance: Normal

her pussy wont know what hit it once your new cock has finished

Nicolai Perica
http://www.alderny.com/

Date: Wed, 14 Nov 2007 23:52:43 +0000
From: Stephen Farrell <[email-masked]>
To: "Kemp, David P." <[email-masked]>
CC: [email-masked]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Sender: [email-masked]

Kemp, David P. wrote:
> The IETF does not have a choice.  It could claim to be using its
> own language (X.208) ...

More nonsense.

S.

Content-class: urn:content-classes:message
Subject: RE: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Date: Wed, 14 Nov 2007 17:32:34 -0500
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I believe in KISS.  And I see plenty of examples of ASN.1-based
protocols (and was co-author of one, to my shame) which became
complex just because it is easier to get carried away in ASN.1
than in, for example, bits-in-boxes.

However, that is orthogonal to the issue of whether IETF should
make it's ASN.1-based RFCs conform to the ASN.1 standard.
The LDAP example you gave is unrelated to a switch from X.208
to X.680 - the simple definition is perfectly legal under X.680,
thus the gratuitous complexity of the second definition
was motivated by something other than the desire to be ASN.1
compliant.

X.509 uses a relatively simple subset of ASN.1, and making the
minimal changes required to become legal under X.680 should not
require a parser with 4 tokens of lookahead.  Making more extensive
changes that explore the more esoteric features of X.680 is a
separate issue, and on that I'd come down on the side of KISS.
Some things are simpler under X.680, for example the ability to
use real UTF8STRINGs rather than a hack to produce the same bits
on the wire as X.680.

The IETF does not have a choice.  It could claim to be using its
own language (X.208) just like it defines its own language to express
the TLS protocol.  But PKIX claims to be a profile of X.509, not
an independent certificate format that sort of resembles X.509,
and so the modules contained in the normative sections of
RFC 3280bis must be written in ASN.1.  That requires updates to
the RFCs, with informative annexes to contain the pseudo-ASN.1.

Date: Wed, 14 Nov 2007 15:49:41 -0500
To: Mike <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Sender: [email-masked]

Mike:

There is one feature in the newer ASN.1 specification that helps 
avoid programming errors.  The use of CLASS instead of ANY DEFINED BY 
allows one to construct a table of the object identifiers and their 
associated structures.  This is very helpful.  It allows the decoder 
to automatically do the right thing.

This concept was added by BBN to their ASN.1 compiler (for the 1988 
syntax).  They added a TABLE key word to handle it.  I used this 
feature in a development many years ago, and it was better than 
having to write code for every possibility that might appear in an ANY.

I agree that the newer syntax is a bit harder to read.  But, in my 
opinion, it is worth the little bit of extra pain to get the 
automatic handling of ANY DEFINED BY.

I'm pleased to see the open source compiler that handles all of the 
ASN.1 modules in IETF specifications.

Russ

P.S.  The LDAP WG has been using the newer syntax for many years.

At 01:54 PM 11/14/2007, Mike wrote:

>>Let's see - 15 years in real time is how many years in
>>Internet time?  NCSA Mosaic was introduced in 1992, and
>>Mike thinks we should still be basing RFCs on a standard
>>that was deprecated before the web was born?
>
>It was the creator of ASN.1 who deprecated the 1988 version.
>As I said before, I believe this is a self-preservation move
>more than anything else.  If they didn't add unnecessary
>complexity and instead kept things simple, they would have
>put the ASN.1 folks out of a job.  The specs are all about
>complexity -- consider X.400 versus Internet email, and X.500
>DAP versus LDAP, and how widely used those standard are.  It
>was probably a mistake to even adopt ASN.1 and X.509 for the
>Internet in the first place, but that ship unfortunately
>sailed long ago.
>
>Consider TCP/IP, the backbone of the Internet.  Quoting
>from Wikipedia:
>
>     TCP is a complex and evolving protocol. However,
>     while significant enhancements have been made and
>     proposed over the years, its most basic operation
>     has not changed significantly since its first
>     specification RFC 675 in 1974....
>
>So TCP has been around for over 30 years.  It is precisely
>the *simplicity* of TCP (and its relative stability) that
>makes it so successful.  Back to ASN.1 1988:  even I was
>able to write a parser for it, and I've had no formal
>computer science education.  I've heard that you need 4
>tokens of look-ahead to disambiguate some of the newer
>ASN.1 constructs.  I'm sure you've heard of the K.I.S.S.
>principle?  It applies here.
>
>And again, I have no objection to the publishing of the new
>ASN.1 as an Informational RFC.  An update RFC will lead to
>new future versions of PKIX and CMS documents that drop the
>simpler syntax, which is what I am against.
>
>Mike
>

Date: Wed, 14 Nov 2007 10:54:55 -0800
From: Mike <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Sender: [email-masked]

> Let's see - 15 years in real time is how many years in
> Internet time?  NCSA Mosaic was introduced in 1992, and
> Mike thinks we should still be basing RFCs on a standard
> that was deprecated before the web was born?

It was the creator of ASN.1 who deprecated the 1988 version.
As I said before, I believe this is a self-preservation move
more than anything else.  If they didn't add unnecessary
complexity and instead kept things simple, they would have
put the ASN.1 folks out of a job.  The specs are all about
complexity -- consider X.400 versus Internet email, and X.500
DAP versus LDAP, and how widely used those standard are.  It
was probably a mistake to even adopt ASN.1 and X.509 for the
Internet in the first place, but that ship unfortunately
sailed long ago.

Consider TCP/IP, the backbone of the Internet.  Quoting
from Wikipedia:

     TCP is a complex and evolving protocol. However,
     while significant enhancements have been made and
     proposed over the years, its most basic operation
     has not changed significantly since its first
     specification RFC 675 in 1974....

So TCP has been around for over 30 years.  It is precisely
the *simplicity* of TCP (and its relative stability) that
makes it so successful.  Back to ASN.1 1988:  even I was
able to write a parser for it, and I've had no formal
computer science education.  I've heard that you need 4
tokens of look-ahead to disambiguate some of the newer
ASN.1 constructs.  I'm sure you've heard of the K.I.S.S.
principle?  It applies here.

And again, I have no objection to the publishing of the new
ASN.1 as an Informational RFC.  An update RFC will lead to
new future versions of PKIX and CMS documents that drop the
simpler syntax, which is what I am against.

Mike

From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 14 Nov 2007 18:25:07 +0000
Subject: Preliminary agenda uploaded
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

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

A preliminary agenda has been uploaded and is available from: http://www3.i=
etf.org/proceedings/07dec/agenda/pkix.txt

We still have some slack in the agenda and not all presentations are confir=
med.
If you are on the agenda, please confirm that you will be able to make your=
 presentation in Vancouver.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

--_000_E75F200AF1718F45B2024A88C3141A1D0647BDBD7AEAEXMSGC320eu_
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:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:m=3D"http://sc=
hemas.microsoft.com/office/2004/12/omml" 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:"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.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>A preliminary agenda has been uploa=
ded and is
available from: <a href=3D"http://www3.ietf.org/proceedings/07dec/agenda/pk=
ix.txt">http://www3.ietf.org/proceedings/07dec/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>We still have some slack in the age=
nda and
not all presentations are confirmed.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>If you are on the agenda, please co=
nfirm
that you will be able to make your presentation in Vancouver.<o:p></o:p></s=
pan></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_E75F200AF1718F45B2024A88C3141A1D0647BDBD7AEAEXMSGC320eu_--

From: "BackgammonRoom" <[email-masked]>
To: <[email-masked]>
Subject: The best place to play Backgammon with 100$ bonus
Date: Wed, 14 Nov 2007 10:23:09 +0500

OnlineBackgammonRoom is giving away FREE_MONEY.

Not only are we the best place to play Backgammon, we are also giving you $100_FREE.

All you need to do is make a minimum $100 First Time Deposit between and BGroom will credit your account with a FREE_$100 bonus.

http://www.backgammongamble.net

When making your deposit please enter  the code "FIRST$100".

Content-class: urn:content-classes:message
Subject: RE: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Date: Tue, 13 Nov 2007 12:04:36 -0500
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

The fact that X.208 1988 was withdrawn as a standard in 2002
does not mean that all paper and electronic copies have
disappeared from the face of the earth.

Get it from http://www.itu.int/rec/T-REC-X.208-198811-W/en.

The fact that copies can be had, however, does not imply
that the IETF should continue to base standards on it.
The 1992 version of X.680 says that although X.208 was
still being maintained at time of publication, continued
maintenance depends on an annual resolution by the
subcommittee and "cannot be expected to be indefinite".

Let's see - 15 years in real time is how many years in
Internet time?  NCSA Mosaic was introduced in 1992, and
Mike thinks we should still be basing RFCs on a standard
that was deprecated before the web was born?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Gutmann
Sent: Sunday, November 11, 2007 11:21 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt

[Sorry, my previous response may have been a bit unclear.  Let me
rephrase
 it].

Stephen Farrell <[email-masked]>
>Peter Gutmann wrote:
>> Technically since ASN.1:1988 doesn't exist...
>
>Ridiculous nonsense.

Attached at the end of this message is what I claim to be a
PKIX-compliant
X.509 certificate encoded in ASN.1:1988.  If you would like to dispute
this,
please show me where to get the ASN.1:1988 standard from the ISO to show
that
it's not what I claim it is.

Peter.

Cc: [email-masked]
From: Yoav Nir <[email-masked]>
To: Peter Gutmann <[email-masked]>
Subject: Re: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Date: Tue, 13 Nov 2007 16:16:56 +0200
Sender: [email-masked]

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

Well, I have a copy of "ASN.1 The Tutorial and Reference" lying around  
somewhere.

Also, I'm sure a 1988 specification is somewhere on the web (although  
4 minutes with google were not enough to find it)

Seriously, the fact that IETF has created IKEv2 and TLS 1.1 that  
obsoleted IKEv1 and TLS 1.0 respectively does not mean those standards  
are gone.  In fact, I would be very surprised if IKEv2 and TLS 1.1  
account for ever 0.1% of IKE and SSL/TLS traffic.

On Nov 12, 2007, at 5:54 AM, Peter Gutmann wrote:

>
> Stephen Farrell <[email-masked]>
>> Peter Gutmann wrote:
>>> Technically since ASN.1:1988 doesn't exist...
>>
>> Ridiculous nonsense.
>
> Well how else do you explain requiring IETF standards to use an ISO  
> standard
> that was withdrawn five years ago?  If someone comes up to you and  
> asks where
> they can get a copy of the standard that PKIX RFCs are based on,  
> what do you
> tell them?
>
> Seriously, what *do* you tell people when they ask where they can  
> get the
> ASN.1:1988 standard?
>
> Peter.
>
>
> Scanned by Check Point VPN-1 UTM NGX R65 with Messaging Security
>

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

--Apple-Mail-11--239632127--

From: "Randi Bond" <[email-masked]>
To: <[email-masked]>
Subject: dett{v{n
Date: Tue, 13 Nov 2007 10:43:40 +0100

------=_NextPart_000_0009_01C825E2.0E0DA130
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

what will you do when a bigger cock takes your girl away?

JoAnna Bushfield
http://unweacad.com/
------=_NextPart_000_0009_01C825E2.0E0DA130
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.2900.3059" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT Arial size=3D2>what will you do when a bigger cock takes your =
girl away?</FONT></DIV>
<DIV><FONT Arial size=3D2></FONT></DIV>
<DIV><FONT Arial size=3D2>JoAnna Bushfield</FONT></DIV>
<DIV><FONT Arial size=3D2><A=20
HREF=3D"http://unweacad.com/">http://unweacad.com/</A></FONT></DIV></BODY=
></HTML>

------=_NextPart_000_0009_01C825E2.0E0DA130--

Date: Mon, 12 Nov 2007 12:35:13 -0800
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Sender: [email-masked]

At 10:42 AM +0000 11/11/07, Stephen Farrell wrote:
>Paul Hoffman wrote:
>>
>>At 11:04 AM -0800 11/9/07, Mike wrote:
>>>What is the intended status of the RFC this draft would become?
>>
>>Standards track. That is, it is updating standards-track documents.
>
>Updating, but not obsoleting? If so, that's ok.

Right. It will not obsolete any of the specs. In order to do so, it 
would have to contain all of the text of the earlier specs. This is a 
straight update.

>BTW - how certain are you that there are no differences between the
>encodings allowed by rfc3280bis and this?

Terribly certain, of course! :-)

>I think it might take a
>while (and some coding/testing) to be confident of that.

Of course. We want extensive review by picky PKIX folks, pick ASN.1 
folks, and anyone else. We have already gotten some off-list 
corrections to our ASN.1 (one real error, some optional corrections), 
but we are hoping to get much more review.

To that end, I have made a file of all the modules from 
draft-hoffman-pkix-new-asn1-00.txt and 
draft-hoffman-cms-new-asn1-00.txt so everyone can test without having 
to cut-and-paste: <http://www.imc.org/ietf-pkix/draft-00-modules.tgz>.

--Paul Hoffman, Director
--VPN Consortium

Date: Mon, 12 Nov 2007 11:11:14 -0800
From: Eric Rescorla <[email-masked]>
To: [email-masked], [email-masked]
Subject: DSA/SHA-1, and OIDs
Sender: [email-masked]

Hi PKIX guys,

As you probably know, in some modes of TLS one or the other party
signs data. In some cases, this presumably means DSA. This is 
fine if you can guarantee that you are going to use SHA-1 with
DSA, but obviously there's going to be a desire to transition
to SHA-256, which raises the issue of digest substitution.

My understanding of the current thinking on how to prevent this
is to indicate in the certificate which digest algorithm is to
be used with the cert. So, the rule we plan to promulgate in TLS
is: 

	OID 1 2 840 10040 4 1 MUST only be used with SHA-1.  Future
	revisions of [PKIX] MAY define new object identifiers for DSA
	with other hash algorithms.

I wanted to check that this is compatible with the current PKIX
thinking.

Thanks,
-Ekr

Date: Mon, 12 Nov 2007 11:12:23 -0800
From: Eric Rescorla <[email-masked]>
To: [email-masked], [email-masked]
Subject: DSA/SHA-1, and OIDs
Sender: [email-masked]

Hi PKIX guys,

As you probably know, in some modes of TLS one or the other party
signs data. In some cases, this presumably means DSA. This is 
fine if you can guarantee that you are going to use SHA-1 with
DSA, but obviously there's going to be a desire to transition
to SHA-256, which raises the issue of digest substitution.

My understanding of the current thinking on how to prevent this
is to indicate in the certificate which digest algorithm is to
be used with the cert. So, the rule we plan to promulgate in TLS
is: 

	OID 1 2 840 10040 4 1 MUST only be used with SHA-1.  Future
	revisions of [PKIX] MAY define new object identifiers for DSA
	with other hash algorithms.

I wanted to check that this is compatible with the current PKIX
thinking.

Thanks,
-Ekr

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Cc: [email-masked]
Date: Mon, 12 Nov 2007 17:21:22 +1300
Sender: [email-masked]

[Sorry, my previous response may have been a bit unclear.  Let me rephrase
 it].

Stephen Farrell <[email-masked]>
>Peter Gutmann wrote:
>> Technically since ASN.1:1988 doesn't exist...
>
>Ridiculous nonsense.

Attached at the end of this message is what I claim to be a PKIX-compliant
X.509 certificate encoded in ASN.1:1988.  If you would like to dispute this,
please show me where to get the ASN.1:1988 standard from the ISO to show that
it's not what I claim it is.

Peter.

-- Snip --

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Cc: [email-masked], [email-masked], [email-masked]
Date: Mon, 12 Nov 2007 16:54:06 +1300
Sender: [email-masked]

Stephen Farrell <[email-masked]>
>Peter Gutmann wrote:
>> Technically since ASN.1:1988 doesn't exist...
>
>Ridiculous nonsense.

Well how else do you explain requiring IETF standards to use an ISO standard
that was withdrawn five years ago?  If someone comes up to you and asks where
they can get a copy of the standard that PKIX RFCs are based on, what do you
tell them?

Seriously, what *do* you tell people when they ask where they can get the
ASN.1:1988 standard?

Peter.

From: "Turner, Sean P." <[email-masked]>
To: "'Stephen Farrell'" <[email-masked]>, "'Peter Gutmann'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Date: Sun, 11 Nov 2007 19:35:46 -0500
Organization: IECA, Inc.
Sender: [email-masked]

It's kind of ridiculous but bean counting contracting types are sometimes
very unhappy when you have to explain to them that you're referencing a
standard that they can't go and get. Sometimes you can talk them down
sometimes not.

spt 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Stephen Farrell
>Sent: Sunday, November 11, 2007 5:46 AM
>To: Peter Gutmann
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
>
>
>
>
>Peter Gutmann wrote:
> > Technically since ASN.1:1988 doesn't
>> exist...
>
>Ridiculous nonsense.
>
>Stephen.
>

Date: Sun, 11 Nov 2007 10:46:23 +0000
From: Stephen Farrell <[email-masked]>
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Sender: [email-masked]

Peter Gutmann wrote:
 > Technically since ASN.1:1988 doesn't
> exist...

Ridiculous nonsense.

Stephen.

Date: Sun, 11 Nov 2007 10:42:42 +0000
From: Stephen Farrell <[email-masked]>
To: Paul Hoffman <[email-masked]>
CC: Mike <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Sender: [email-masked]

Paul Hoffman wrote:
> 
> At 11:04 AM -0800 11/9/07, Mike wrote:
>> What is the intended status of the RFC this draft would become?
> 
> Standards track. That is, it is updating standards-track documents.

Updating, but not obsoleting? If so, that's ok.

BTW - how certain are you that there are no differences between the
encodings allowed by rfc3280bis and this? I think it might take a
while (and some coding/testing) to be confident of that.

S.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Date: Sun, 11 Nov 2007 22:15:51 +1300
Sender: [email-masked]

Mike <[email-masked]> writes:

>Forcing developers to abandon their perfectly good tools and rewrite their
>code is asking for trouble.

Having a bunch of supposed IETF standards that aren't really standards at all
is even worse...

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Date: Sun, 11 Nov 2007 22:14:37 +1300
Sender: [email-masked]

Paul Hoffman <[email-masked]> writes:
>At 11:04 AM -0800 11/9/07, Mike wrote:
>>However, if the plan is to replace the 1988 syntax with the 2002
>>version, then I couldn't be more opposed.  I don't see any benefit
>>to making this change -- as you say there are -no- changes to the
>>bits on the wire.
>
>The code emitted by the compilers can be much more robust. For example,
>instead of 1988's "ANY", there are structures that allow (but not force) a
>compiler to do better validation checking, bounds checking, and so on.

There's a much bigger problem with the use of 1988 ASN.1: It's not a standard
at all, since it was withdrawn more than five years ago.  Any IETF standard
that uses the 1988 form is by extension a non-standard, since what it's using
as its syntax is also a non-standard.  Technically since ASN.1:1988 doesn't
exist, you could be justified in claiming that anything at all (for example
the works of Shakespeare) are a valid interpretation of the relevant IETF
standards, since they're based on an undefined non-entity.

(The argument gets a bit philosophical at this point since the semantics of
 basing an IETF standard on something that's undefined leads to an undefined
 result.  Maybe Dr.Dan Streetmentioner could write a text on the terminology
 that's required to described this bizarre situation.  Until it's resolved, an
 implementation of PGP (or an implementation of Windows Media Audio, for that
 matter) is at least as compliant with the relevant IETF pseudo-standards as
 an implementation of CMS).

Peter.

Date: Sat, 10 Nov 2007 11:30:22 -0800
From: Mike <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Sender: [email-masked]

>> However, if the plan is to replace the 1988 syntax with the 2002
>> version, then I couldn't be more opposed.  I don't see any benefit
>> to making this change -- as you say there are -no- changes to the
>> bits on the wire.
> 
> The code emitted by the compilers can be much more robust. For example, 
> instead of 1988's "ANY", there are structures that allow (but not force) 
> a compiler to do better validation checking, bounds checking, and so on.

That is a valid argument for an -informational- RFC since only compilers
that want to do the extra validation need to know how to parse such
things.  In practice, there isn't really a problem with ANY, and there
are places where things are packed into an OCTET STRING, which is the
same thing, different tag.

>> The downside, though, is huge.  Every ASN.1
>> compiler that can only parse 1988 syntax will need to be upgraded,
>> lest they be "left behind" by the IETF whose purported goal is to
>> maximize interoperability between differing implementations.
> 
> Note that the compilers themselves have nothing to do with the 
> interoperability of the implementations. What such a change does, of 
> course, is force developers to use a compiler that can handle the new 
> ASN.1.

Forcing developers to abandon their perfectly good tools and rewrite
their code is asking for trouble.

>> And since you are one of the authors of said open-
>> source software, I think there is at least the possibility of a
>> conflict of interest.
> 
> It's not clear what you mean. We make no money from people using our 
> compiler. That's why we even have a web site where you can compile every 
> one of these modules without even downloading the compiler.

I just found it curious that you didn't mention in your original message
that you were one of the authors of the software....

> Regardless of their reason(s), we feel that the value of the changes are 
> well worth it.

Could you list the important changes and why they are valuable, so that
an informed decision can be made?

Thanks,

Mike

From: "MUHAMMET Junger" <[email-masked]>
To: <[email-masked]>
Subject: ocerped
Date: Sat, 10 Nov 2007 14:41:54 -0300

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

http://romusoft.com/
My peni*s grew 2" after 5 months of use

odiongan obese0
ocerllew ociferer
------=_NextPart_000_0006_01C823A7.D673E810
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.2900.3059" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT Arial size=3D2><A=20
HREF=3D"http://romusoft.com/">http://romusoft.com/</A></FONT></DIV>
<DIV><FONT Arial size=3D2>My peni*s grew 2" after 5 months of =
use</FONT></DIV>
<DIV><FONT Arial size=3D2></FONT></DIV>
<DIV><FONT Arial size=3D2>odiongan obese0</FONT></DIV>
<DIV><FONT Arial size=3D2>ocerllew ociferer</FONT></DIV></BODY></HTML>

------=_NextPart_000_0006_01C823A7.D673E810--

From: Trevor Freeman <[email-masked]>
To: "Vijay K. Gurbani" <[email-masked]>, "[email-masked]" <[email-masked]>
CC: Scott Lawrence <[email-masked]>
Date: Fri, 9 Nov 2007 14:49:56 -0800
Subject: RE: sip-eku and sip-domain-certs drafts
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Hi Vijay,

draft-ietf-sip-eku-00
Overall I think the objectives of this draft are good. However as this draft stands I don't see how products conforming to this draft could be deployed because it does not lay out guidance on how to deal with the body of  certificates and products deployed today. There are also a few places where this draft seems to be impinging on rfc3280 which need to be clarified what you actually mean. Also while under some circumstances it may be desirable to restive usage to SIP, it is equally desirable to coexist with other applications on the same server. For many deployments, users will have more than one application on a server and want to get a single certificate for that server which meets the needs of all the services on the server, not just sip. I don't see how that works with this draft.

Setting the EKU extension to be critical.
Setting this extension to be critical will not have the effect you describe and will likely case interoperability problems and should be removed as a requirement. RFC3280 requires conformant applications to recognize the EKU extension. It further requires to only reject critical extensions it does not recognize. It also exempts applications from recognizing all EKU purposes. There is a body of SIP applications who are conformant to 3280 and therefore recognize the EKU extension but do not recognize this new purpose, all of whom would still accept the certificate if there was another EKU in the certificate they did recognize. The behavior of the applications would be totally driven by the presence\absence of the purposes of interest in the extension and not by the criticality of the extension.

EKU usage
This draft does not define behavior with respect to the id-kp-serverAuth purpose which is the most widely deployed today. The presence of the "and" clause with the current text also effectively ignores the id-kp-anyExtendedKeyUsage and should be removed. The id-kp-anyExtendedKeyUsage purpose means any and should be respected. I would suggest the following text for 4.1

The Extended Key Usage extension does not exist, the certificate is valid for SIP usage. It is a matter of local policy to accept certificates with no EKU extension as valid for SIP usage. If the extension exists, it MUST be examined to determine whether or not the certificate is valid for SIP usage:

   o  If the certificate contains the id-kp-anyExtendedKeyUsage purpose the certificate MUST be accepted as valid for SIP usage.
   o  If the certificate contains the id-kp-sipDomain purpose the certificate MUST be accepted as valid for SIP usage.
   o  If the certificate contains the id-kp-serverAuth purpose the certificate SHOULD be accepted as valid for SIP usage It is a matter of local policy to accept the certificate.
   o  If the EKU extension exists but does not contain the above purposes then the certificate MUST be rejected as valid for SIP usage.

A summary of the logic flow for peer certificate validation follows:

1.  If there is no EKU extension and local policy allows accept the certificate.

2.  If the EKU extension is present and contains id-kp-anyExtendedKeyUsage accept the certificate.

3.  If the EKU extension is present and contains the id-kp-sipDomain purpose accept the certificate.

4.  If the EKU extension is present and contains the id-kp-serverAuth purpose and local policy allows accept the certificate.

draft-ietf-sip-domain-certs-00
URI to represent Domain Names
I can sympathize why you have taken this approach, but it does seem an error prone path. Scribing special significance due to the presence\absence of the @ character is going to be hard to understand to users. URI is a superset of the allowed characters for DNS so it would be big ask of service provider to ensure the name conforms to just the DNS rules in some instances of URI names in certificates. This would increase support costs due to some certificates having valid names using to URI rules but invalid under DNS rules.
Have you considered just defining a new SAN name to represent SIP domains. I know some folks will moan at that suggestion but having a new name type would allow stronger and simpler typing for content and would be less ambiguous for applications or service providers. Email domains have a similar problem and it would be nice to come up with a common model.

Hosting and service providers
This draft does not address the needs of hosting and service providers. If a hoster is responsible for 1000's of domains, it's totally impractical to consider having 1000's of names in a certificate or to have 1000's of certificates available on a server. You need some kind of delegation model and preferably without local configuration so it can be automated and therefore scale. Have you looked at some delegation models for SIP? Email again has the same problem without a good solution today so it would be good to come up with a common solution.

Trevor

* -----Original Message-----
* From: [email-masked] [mailto:owner-ietf-
* [email-masked]] On Behalf Of Vijay K. Gurbani
* Sent: Thursday, November 08, 2007 9:38 AM
* To: [email-masked]
* Cc: Scott Lawrence
* Subject: sip-eku and sip-domain-certs drafts
*
*
* Hello:
*
* For a good part of this year, Scott Lawrence and I have been working
* on the usage of X.509 certificates in SIP TLS connections.  As part
* of that work, we have solicited -- and received excellent -- advice
* from the PKIX WG on related issues (many thanks!).
*
* The PKIX-related parts of the work has been defining a key usage
* extension that identifies the holder of the certificate as
* authoritative for a SIP service in a domain, and the interpretation
* and usage of identities stored in a X.509 certificate when used
* for SIP.
*
* The original draft that was reviewed by the PKIX WG was
* draft-gurbani-sip-domain-certs.  When this work was adopted as
* a SIP WG deliverable, we split the draft into two.  One of these
* drafts -- draft-ietf-sip-eku -- discusses EKU extension.  A
* companion draft -- draft-ietf-sip-domain-certs -- describes
* how to use identities in X.509 certificates and perform mutual
* authentication between two SIP domains.
*
* Now that the ideas and the work has been fully fleshed out, we
* would kindly like to solicit a final review from PKIX on these
* documents.  The URLs are:
*
* http://tools.ietf.org/html/draft-ietf-sip-eku-00
* http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-00.txt
*
* Thank you in advance for your time and attention to this.
*
* Regards,
*
* - vijay
* --
* Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
* 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
* Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
* WWW:   http://www.alcatel-lucent.com/bell-labs

Date: Fri, 9 Nov 2007 12:39:01 -0800
To: Mike <[email-masked]>, [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Sender: [email-masked]

At 11:04 AM -0800 11/9/07, Mike wrote:
>What is the intended status of the RFC this draft would become?

Standards track. That is, it is updating standards-track documents.

>  If
>it is -informational- then I have no problem with it.
>
>However, if the plan is to replace the 1988 syntax with the 2002
>version, then I couldn't be more opposed.  I don't see any benefit
>to making this change -- as you say there are -no- changes to the
>bits on the wire.

The code emitted by the compilers can be much more robust. For 
example, instead of 1988's "ANY", there are structures that allow 
(but not force) a compiler to do better validation checking, bounds 
checking, and so on.

>The downside, though, is huge.  Every ASN.1
>compiler that can only parse 1988 syntax will need to be upgraded,
>lest they be "left behind" by the IETF whose purported goal is to
>maximize interoperability between differing implementations.

Note that the compilers themselves have nothing to do with the 
interoperability of the implementations. What such a change does, of 
course, is force developers to use a compiler that can handle the new 
ASN.1.

>The existence of one open-source compiler does not justify this
>sweeping change.

Fully agree. There are already multiple commercial ASN.1 compilers 
that conform to the new syntax rules. Fortunately, the IETF has not 
forced developers to move to the new syntax based on the existence of 
those commercial compilers. Now that there is an open source, 
freeware compiler, we can decide if the benefits of the new syntax 
for compilers (and therefore implementers) is worth the cost of 
changing compilers.

>And since you are one of the authors of said open-
>source software, I think there is at least the possibility of a
>conflict of interest.

It's not clear what you mean. We make no money from people using our 
compiler. That's why we even have a web site where you can compile 
every one of these modules without even downloading the compiler.

>Yes, the ITU has deprecated the 1988 syntax, but for what reason?
>It's my opinion that the 14 years of added complexity in the ASN.1
>spec is simply the result of an organization trying to justify the
>need for its own existence.  As long as the funding arrives, there
>is work to be done!

Regardless of their reason(s), we feel that the value of the changes 
are well worth it.

>Some developers thrive on complexity -- it is good job security, so
>I can understand why they would welcome this proposal, but that has
>no place in critical IETF standards.

Fully agree. However, that is not why we proposed the changes.

--Paul Hoffman, Director
--VPN Consortium

Date: Fri, 09 Nov 2007 11:04:07 -0800
From: Mike <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Sender: [email-masked]

What is the intended status of the RFC this draft would become?  If
it is -informational- then I have no problem with it.

However, if the plan is to replace the 1988 syntax with the 2002
version, then I couldn't be more opposed.  I don't see any benefit
to making this change -- as you say there are -no- changes to the
bits on the wire.  The downside, though, is huge.  Every ASN.1
compiler that can only parse 1988 syntax will need to be upgraded,
lest they be "left behind" by the IETF whose purported goal is to
maximize interoperability between differing implementations.

The existence of one open-source compiler does not justify this
sweeping change.  And since you are one of the authors of said open-
source software, I think there is at least the possibility of a
conflict of interest.

The LDAP spec used to have close to the simplest ASN.1 syntax
possible (an exception is the use of APPLICATION tags on types), yet
those folks did something ridiculous and changed:

     Attribute ::= SEQUENCE {
         type    AttributeDescription,
         vals    SET of AttributeValue }

to:

     PartialAttribute ::= SEQUENCE {
         type    AttributeDescription,
         vals    SET OF value AttributeValue }

     Attribute ::= PartialAttribute(WITH COMPONENTS {
         ...,
         vals (SIZE(1..MAX))})

The amount of additional code required to parse this one silly
construct would be considerable.  I complained to the working group
while the specifications were still drafts and they lamented that
it was "too late" to change it back.  Isn't that why we have
*drafts*?

Yes, the ITU has deprecated the 1988 syntax, but for what reason?
It's my opinion that the 14 years of added complexity in the ASN.1
spec is simply the result of an organization trying to justify the
need for its own existence.  As long as the funding arrives, there
is work to be done!

Some developers thrive on complexity -- it is good job security, so
I can understand why they would welcome this proposal, but that has
no place in critical IETF standards.

Mike

Paul Hoffman wrote:
> 
> Greetings again. Jim Schaad and I have created a draft that contains 
> revised ASN.1 modules for some of the standards-track RFCs for PKIX. 
> These modules conform to ASN.1 2002. We want to see if people are 
> interested in bringing the PKIX specs up to the new ASN.1 now that there 
> is an open source, freeware ASN.1 compiler for ASN.1 2002, a2c (see 
> <http://code.google.com/p/a2c/>).
> 
> This is definitely a first draft. There is a list of issues that we want 
> to address, and we expect more issues to come up in the WG. Please 
> review the draft and let us know what you think. FWIW, there is a 
> parallel draft for CMS and S/MIME.
> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>>
>>     Title           : New ASN.1 Modules for PKIX
>>     Author(s)       : P. Hoffman, J. Schaad
>>     Filename        : draft-hoffman-pkix-new-asn1-00.txt
>>     Pages           : 68
>>     Date            : 2007-11-08
>>
>> The PKIX certificate format, and many associated formats, are
>> expressed using ASN.1.  The current ASN.1 modules conform to the 1988
>> version of ASN.1.  This document updates those ASN.1 modules to
>> conform to the 2002 version of ASN.1.  There are no bits-on-the-wire
>> changes to any of the formats; this is simply a change to the syntax.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-hoffman-pkix-new-asn1-00.txt
> 
> --Paul Hoffman, Director
> --VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: RFC3647 Question
Date: Fri, 9 Nov 2007 08:18:36 -0800
From: "Terwilliger, Ann" <[email-masked]>
To: "Russ Housley" <[email-masked]>, "Scott Rea" <[email-masked]>, "Turner, Sean P." <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I think that the same provisions that apply to protection of the CA in
situ also apply to protection of the CA components in transit--dual
control, audit trails on transfer of custody, etc.  When we moved our
root CA several years ago, that was the approach we used.  I think that
the sections of 3647 already cited cover it.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Thursday, November 08, 2007 2:11 PM
To: Scott Rea; Turner, Sean P.
Cc: [email-masked]
Subject: Re: RFC3647 Question

I think Sean is asking where to document the protection necessary if 
the CA is physically moved from one facility to another.

Russ

At 03:53 PM 11/8/2007, Scott Rea wrote:

>Sean,
>
>I am not quite sure what you are asking here? Are you talking about 
>moving keys in terms of where back-ups (or perhaps archival data) 
>are kept, or is there some reason an operational key needs to move??
>Anyway the following 3 places may be good candidates...
>6.1  Key pair generation and installation
>6.2  Private Key Protection and Cryptographic Module Engineering
Controls
>6.3  Other aspects of key pair management
>
>Regards,
>-Scott
>
>
>Turner, Sean P. wrote:
>>
>>Where would you put statements about physically moving a CA's 
>>private from one location to another (e.g., from New York to 
>>L.A.)?   There doesn't seem to be a place to put it in the RFC3647 
>>format.  Has anybody got something like this in their CP/CPS?
>>
>>spt
>
>--
>Scott Rea
>
>

From: "Turner, Sean P." <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Date: Thu, 8 Nov 2007 21:13:18 -0500
Organization: IECA, Inc.
Sender: [email-masked]

I am interested in moving the specs up to the later ASN.1 version.

spt 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Paul Hoffman
>Sent: Thursday, November 08, 2007 4:00 PM
>To: [email-masked]
>Subject: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
>
>
>Greetings again. Jim Schaad and I have created a draft that 
>contains revised ASN.1 modules for some of the standards-track 
>RFCs for PKIX. 
>These modules conform to ASN.1 2002. We want to see if people 
>are interested in bringing the PKIX specs up to the new ASN.1 
>now that there is an open source, freeware ASN.1 compiler for 
>ASN.1 2002, a2c (see <http://code.google.com/p/a2c/>).
>
>This is definitely a first draft. There is a list of issues 
>that we want to address, and we expect more issues to come up 
>in the WG. 
>Please review the draft and let us know what you think. FWIW, 
>there is a parallel draft for CMS and S/MIME.
>
>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>directories.
>>
>>	Title           : New ASN.1 Modules for PKIX
>>	Author(s)       : P. Hoffman, J. Schaad
>>	Filename        : draft-hoffman-pkix-new-asn1-00.txt
>>	Pages           : 68
>>	Date            : 2007-11-08
>>
>>The PKIX certificate format, and many associated formats, are 
>expressed 
>>using ASN.1.  The current ASN.1 modules conform to the 1988 
>version of 
>>ASN.1.  This document updates those ASN.1 modules to conform to the 
>>2002 version of ASN.1.  There are no bits-on-the-wire changes 
>to any of 
>>the formats; this is simply a change to the syntax.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-hoffman-pkix-new-asn1-00.txt
>
>--Paul Hoffman, Director
>--VPN Consortium
>

Date: Thu, 08 Nov 2007 17:11:28 -0500
To: Scott Rea <[email-masked]>, "Turner, Sean P." <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: RFC3647 Question
Cc: [email-masked]
Sender: [email-masked]

I think Sean is asking where to document the protection necessary if 
the CA is physically moved from one facility to another.

Russ

At 03:53 PM 11/8/2007, Scott Rea wrote:

>Sean,
>
>I am not quite sure what you are asking here? Are you talking about 
>moving keys in terms of where back-ups (or perhaps archival data) 
>are kept, or is there some reason an operational key needs to move??
>Anyway the following 3 places may be good candidates...
>6.1  Key pair generation and installation
>6.2  Private Key Protection and Cryptographic Module Engineering Controls
>6.3  Other aspects of key pair management
>
>Regards,
>-Scott
>
>
>Turner, Sean P. wrote:
>>
>>Where would you put statements about physically moving a CA's 
>>private from one location to another (e.g., from New York to 
>>L.A.)?   There doesn't seem to be a place to put it in the RFC3647 
>>format.  Has anybody got something like this in their CP/CPS?
>>
>>spt
>
>--
>Scott Rea
>
>

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: RE: RFC3647 Question
Date: Thu, 8 Nov 2007 16:29:01 -0500
Organization: IECA, Inc.
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0224_01C82224.78FA5D60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Sorry I should have been more specific, I was definitely thinking about
moving the HSM that has the private key from one location to another.  

  _____  

From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Thursday, November 08, 2007 4:22 PM
To: Turner, Sean P.; [email-masked]
Subject: RE: RFC3647 Question

Sean,

Sections 5.1.2, 5.2.2, and/or 6.2.2 are appropriate places.  They can
address generation, backup transport and invocation of the CA private key
requires multi-party control.  In addition, Section 5.1.2 can address the
multi-party control on the HSM transportation.

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Turner, Sean P.
Sent: Thursday, November 08, 2007 3:07 PM
To: [email-masked]
Subject: RFC3647 Question

Where would you put statements about physically moving a CA's private from
one location to another (e.g., from New York to L.A.)?   There doesn't seem
to be a place to put it in the RFC3647 format.  Has anybody got something
like this in their CP/CPS?

spt 

------=_NextPart_000_0224_01C82224.78FA5D60
Content-Type: text/html;
	charset="us-ascii"
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:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>RFC3647 =
Question</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16544" name=3DGENERATOR><!--[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]--><o:SmartTagType name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"State"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
H1 {
	FONT-WEIGHT: bold; FONT-SIZE: 12pt; MARGIN: 12pt 0in 3pt 0.3in; =
TEXT-INDENT: -0.3in; FONT-FAMILY: Arial; mso-list: l0 level1 lfo2
}
H2 {
	FONT-WEIGHT: bold; FONT-SIZE: 12pt; MARGIN: 12pt 0in 3pt 0.4in; =
TEXT-INDENT: -0.4in; FONT-FAMILY: "Times New Roman"; mso-list: l0 level2 =
lfo2
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
P.StyleCentered {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: Arial
}
LI.StyleCentered {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: Arial
}
DIV.StyleCentered {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: Arial
}
SPAN.EmailStyle19 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D703002621-08112007>Sorry I should have been more specific, I was =

definitely thinking about moving the HSM that has the private key from =
one=20
location to another.&nbsp; </SPAN></FONT></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Santosh Chokhani=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Thursday, November 08, =
2007=20
  4:22 PM<BR><B>To:</B> Turner, Sean P.; =
[email-masked]<BR><B>Subject:</B>=20
  RE: RFC3647 Question<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Sean,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><BR>Sections 5.1.2,=20
  5.2.2, and/or 6.2.2 are appropriate places.&nbsp; They can address =
generation,=20
  backup transport and invocation of the CA private key requires =
multi-party=20
  control.&nbsp; In addition, Section 5.1.2 can address the multi-party =
control=20
  on the HSM transportation.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
  [email-masked] [mailto:[email-masked]] =
<B><SPAN=20
  style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Turner, Sean =
P.<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Thursday, November 08, =
2007 3:07=20
  PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20
  [email-masked]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B>=20
  RFC3647 Question</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Where would you put =
statements=20
  about physically moving a CA's private from one location to another =
(e.g.,=20
  from <st1:State w:st=3D"on">New York</st1:State> to <st1:City=20
  w:st=3D"on"><st1:place =
w:st=3D"on">L.A.</st1:place></st1:City>)?&nbsp;&nbsp; There=20
  doesn't seem to be a place to put it in the RFC3647 format.&nbsp; Has =
anybody=20
  got something like this in their CP/CPS?</SPAN></FONT><o:p></o:p></P>
  <P><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">spt</SPAN></FONT>=20
  <o:p></o:p></P></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0224_01C82224.78FA5D60--

Content-class: urn:content-classes:message
Subject: RE: RFC3647 Question
Date: Thu, 8 Nov 2007 13:22:08 -0800
From: "Santosh Chokhani" <[email-masked]>
To: "Turner, Sean P." <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8224D.96052FD4
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Sean,

Sections 5.1.2, 5.2.2, and/or 6.2.2 are appropriate places.  They can
address generation, backup transport and invocation of the CA private
key requires multi-party control.  In addition, Section 5.1.2 can
address the multi-party control on the HSM transportation.

=20

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Turner, Sean P.
Sent: Thursday, November 08, 2007 3:07 PM
To: [email-masked]
Subject: RFC3647 Question

=20

Where would you put statements about physically moving a CA's private
from one location to another (e.g., from New York to L.A.)?   There
doesn't seem to be a place to put it in the RFC3647 format.  Has anybody
got something like this in their CP/CPS?

spt=20

------_=_NextPart_001_01C8224D.96052FD4
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:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
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 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]-->
<title>RFC3647 Question</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @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:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	page-break-after:avoid;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:Arial;
	font-weight:bold;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.4in;
	text-indent:-.4in;
	page-break-after:avoid;
	mso-list:l0 level2 lfo2;
	font-size:12.0pt;
	font-family:"Times New Roman";
	font-weight:bold;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{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";}
p.StyleCentered, li.StyleCentered, div.StyleCentered
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:209154939;
	mso-list-template-ids:2064295352;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l1
	{mso-list-id:1216352322;
	mso-list-template-ids:-482153376;}
@list l1:level1
	{mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l1:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l1:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l1:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l1:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l1:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l1:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l1:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l1:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Sean,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><br>
Sections 5.1.2, 5.2.2, and/or 6.2.2 are appropriate places.&nbsp; They =
can address
generation, backup transport and invocation of the CA private key =
requires
multi-party control.&nbsp; In addition, Section 5.1.2 can address the =
multi-party
control on the HSM transportation.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

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

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Turner, Sean P.<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, November =
08, 2007
3:07 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RFC3647 =
Question</span></font><o:p></o:p></p>

</div>

<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>

<p><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Where
would you put statements about physically moving a CA's private from one
location to another (e.g., from <st1:State w:st=3D"on">New =
York</st1:State> to <st1:City
w:st=3D"on"><st1:place =
w:st=3D"on">L.A.</st1:place></st1:City>)?&nbsp;&nbsp; There
doesn't seem to be a place to put it in the RFC3647 format.&nbsp; Has =
anybody
got something like this in their CP/CPS?</span></font><o:p></o:p></p>

<p><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>spt</span></font>
<o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C8224D.96052FD4--

Date: Thu, 8 Nov 2007 13:00:02 -0800
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Sender: [email-masked]

Greetings again. Jim Schaad and I have created a draft that contains 
revised ASN.1 modules for some of the standards-track RFCs for PKIX. 
These modules conform to ASN.1 2002. We want to see if people are 
interested in bringing the PKIX specs up to the new ASN.1 now that 
there is an open source, freeware ASN.1 compiler for ASN.1 2002, a2c 
(see <http://code.google.com/p/a2c/>).

This is definitely a first draft. There is a list of issues that we 
want to address, and we expect more issues to come up in the WG. 
Please review the draft and let us know what you think. FWIW, there 
is a parallel draft for CMS and S/MIME.

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>	Title           : New ASN.1 Modules for PKIX
>	Author(s)       : P. Hoffman, J. Schaad
>	Filename        : draft-hoffman-pkix-new-asn1-00.txt
>	Pages           : 68
>	Date            : 2007-11-08
>
>The PKIX certificate format, and many associated formats, are
>expressed using ASN.1.  The current ASN.1 modules conform to the 1988
>version of ASN.1.  This document updates those ASN.1 modules to
>conform to the 2002 version of ASN.1.  There are no bits-on-the-wire
>changes to any of the formats; this is simply a change to the syntax.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-hoffman-pkix-new-asn1-00.txt

--Paul Hoffman, Director
--VPN Consortium

Date: Thu, 08 Nov 2007 15:53:36 -0500
From: Scott Rea <[email-masked]>
To: "Turner, Sean P." <[email-masked]>
CC: [email-masked]
Subject: Re: RFC3647 Question
Sender: [email-masked]

Sean,

I am not quite sure what you are asking here? Are you talking about 
moving keys in terms of where back-ups (or perhaps archival data) are 
kept, or is there some reason an operational key needs to move??
Anyway the following 3 places may be good candidates...
6.1  Key pair generation and installation
6.2  Private Key Protection and Cryptographic Module Engineering Controls
6.3  Other aspects of key pair management

Regards,
-Scott

Turner, Sean P. wrote:
>
> Where would you put statements about physically moving a CA's private 
> from one location to another (e.g., from New York to L.A.)?   There 
> doesn't seem to be a place to put it in the RFC3647 format.  Has 
> anybody got something like this in their CP/CPS?
>
> spt
>

-- 
Scott Rea

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: RFC3647 Question
Date: Thu, 8 Nov 2007 15:06:41 -0500
Organization: IECA, Inc.
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_01EE_01C82218.F85C09C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Where would you put statements about physically moving a CA's private from
one location to another (e.g., from New York to L.A.)?   There doesn't seem
to be a place to put it in the RFC3647 format.  Has anybody got something
like this in their CP/CPS?

spt

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>RFC3647 Question</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Where would you put statements about =
physically moving a CA's private from one location to another (e.g., =
from New York to L.A.)?&nbsp;&nbsp; There doesn't seem to be a place to =
put it in the RFC3647 format.&nbsp; Has anybody got something like this =
in their CP/CPS?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">spt</FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_01EE_01C82218.F85C09C0--

Date: Thu, 08 Nov 2007 11:37:45 -0600
From: "Vijay K. Gurbani" <[email-masked]>
Organization: Bell Labs Security Technology Research Group
To: [email-masked]
CC: Scott Lawrence <[email-masked]>
Subject: sip-eku and sip-domain-certs drafts
Sender: [email-masked]

Hello:

For a good part of this year, Scott Lawrence and I have been working
on the usage of X.509 certificates in SIP TLS connections.  As part
of that work, we have solicited -- and received excellent -- advice
from the PKIX WG on related issues (many thanks!).

The PKIX-related parts of the work has been defining a key usage
extension that identifies the holder of the certificate as
authoritative for a SIP service in a domain, and the interpretation
and usage of identities stored in a X.509 certificate when used
for SIP.

The original draft that was reviewed by the PKIX WG was
draft-gurbani-sip-domain-certs.  When this work was adopted as
a SIP WG deliverable, we split the draft into two.  One of these
drafts -- draft-ietf-sip-eku -- discusses EKU extension.  A
companion draft -- draft-ietf-sip-domain-certs -- describes
how to use identities in X.509 certificates and perform mutual
authentication between two SIP domains.

Now that the ideas and the work has been fully fleshed out, we
would kindly like to solicit a final review from PKIX on these
documents.  The URLs are:

http://tools.ietf.org/html/draft-ietf-sip-eku-00
http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-00.txt

Thank you in advance for your time and attention to this.

Regards,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

From: "Erik Andersen" <[email-masked]>
To: "PKIX" <[email-masked]>, "Directory list" <[email-masked]>, <[email-masked]>
Subject: RE: Free standards! Get your free standards here!
Date: Mon, 5 Nov 2007 11:46:14 +0100
Importance: Normal
Sender: [email-masked]

Hi,

For your information, our X.500 site (http://www.x500standard.com/) has
direct links to all the latest X.500 documents. In addition you can find
information about the extension work.

Erik Andersen
Andersen's L-Service
Mobile: +45 20 97 14 90
e-mail: [email-masked]
http://www.x500standard.com/
http://home20.inet.tele.dk/era/me

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Hoyt L Kesterson II
> Sent: 5. november 2007 03:51
> To: Recipient List Suppressed:
> Subject: Free standards! Get your free standards here!
> 
> 
> A few years ago ITU began several trials of free distribution of its
> recommendations. In the most recent trial, anyone could get three
> free recommendations in PDF. The recommendations had to be at least
> two years old.
> 
> ITU considers that experiment a substantial success. It recently
> announced that the experimental phase is over. The announcement can
> be found at
> http://www.itu.int/ITU-
> T/newslog/Free+Access+For+All+To+ITUT+Standards.aspx
> 
> One can now get any number of recommendations at no charge regardless
> of when the recommendations were published.
> 
> These are still copyrighted documents so one should probably not
> redistribute the actual standards. However, since they are online,
> one need only publish the appropriate URL.
> 
> Links to all recommendations can be found at
> http://www.itu.int/ITU-T/publications/recs.html
> 
> Links to the X series, including the X.500 series, can be found at
> http://www.itu.int/rec/T-REC-X/e These are in English; links for
> versions in French and Spanish can be be found at the top right-hand
> corner of the page.
> 
> Links to the latest two editions of X.509, March 2000 and August
> 2007, can be found at http://www.itu.int/rec/T-REC-X.509/en
> 
> Enjoy. I for one am grateful for the permanent adoption of this
> enlightened policy.
> 
>     hoyt

Date: Mon, 5 Nov 2007 01:35:38 -0700
To: "ronnie sahlberg" <[email-masked]>, [email-masked]
From: Hoyt L Kesterson II <[email-masked]>
Subject: Re: Free standards! Get your free standards here!
Sender: [email-masked]

That's correct. The ASN.1 has always been freely available. Other work can include it in part or in whole. That has not changed.

I suspect that identifying the Recommendation number and year of publication is adequate for attribution. I identify both the ISO and ITU standards if appropriate. X.500 is collaborative work and the standard is published identically by both organizations differing only in the foreword. For example ITU-T Recommendation (or Rec.) X.509 (08 2005) and ISO/IEC 9594-8:2005. The practice in the standard is to replace the "and" with the vertical bar character, as in Backus-Naur or Unix pipe. The addition of the month to the ITU-T recommendation is recent with the last edition. Note also that for several edltions of the standard  the dates are different for ISO and ITU since the practice of ITU is to use the date of plenary approval and ISO uses the date of publication.

   hoyt

>Great news!
>
>Many of the standard documents contain ASN.1 definitions for various protocols.
>I recall a copyright policy document that said that ASN.1 definitions
>should be treated as contributed text and as such
>there were no restrictions on implementations based on these ASN.1 definitions.
>Is this correct?
>
>If that is correct, can it be clarified more explicitely?
>
>
>Also, if using the ASN.1 definitions verbatim from a ITU-T standard,
>are there any recommendations on how one should
>annotate the ASN.1 file to credit ITU-T ?
>
>I think there was (but could be wrong) an RFC that talked about how
>one should annotate and credit ietf when extracting/using ASN.1
>definitions from RFCs
>but can not really find that document any more. (it might be a false
>memory, but i think there was such a document).
>
>
>It would be great if ITU-T would extend this with explicit guidelines
>and recommendations for how to correctly extract/use ASN.1 from ITU-T
>standards and
>guidelines on how to make sure that attribution to ITU-T for these
>ASN.1 definitions are done correctly.
>
>(my question here is because wireshark contains many ASN.1 definitions
>for telco protocols, and now that the standards become much easier to
>access I expect there will be an influx of a lot more additional new
>protocols supported by wireshark)
>
>
>best regards
>ronnie sahlberg
>
>
>
>On Nov 5, 2007 1:51 PM, Hoyt L Kesterson II <[email-masked]> wrote:
>>
>> A few years ago ITU began several trials of free distribution of its
>> recommendations. In the most recent trial, anyone could get three
>> free recommendations in PDF. The recommendations had to be at least
>> two years old.
>>
>> ITU considers that experiment a substantial success. It recently
>> announced that the experimental phase is over. The announcement can
>> be found at
>> http://www.itu.int/ITU-T/newslog/Free+Access+For+All+To+ITUT+Standards.aspx
>>
>> One can now get any number of recommendations at no charge regardless
>> of when the recommendations were published.
>>
>> These are still copyrighted documents so one should probably not
>> redistribute the actual standards. However, since they are online,
>> one need only publish the appropriate URL.
>>
>> Links to all recommendations can be found at
>> http://www.itu.int/ITU-T/publications/recs.html
>>
>> Links to the X series, including the X.500 series, can be found at
>> http://www.itu.int/rec/T-REC-X/e These are in English; links for
>> versions in French and Spanish can be be found at the top right-hand
>> corner of the page.
>>
>> Links to the latest two editions of X.509, March 2000 and August
>> 2007, can be found at http://www.itu.int/rec/T-REC-X.509/en
>>
>> Enjoy. I for one am grateful for the permanent adoption of this
>> enlightened policy.
>>
>>     hoyt
>>
>>

Date: Sun, 4 Nov 2007 19:51:02 -0700
To: Recipient List Suppressed:;
From: Hoyt L Kesterson II <[email-masked]>
Subject: Free standards! Get your free standards here!
Sender: [email-masked]

A few years ago ITU began several trials of free distribution of its 
recommendations. In the most recent trial, anyone could get three 
free recommendations in PDF. The recommendations had to be at least 
two years old.

ITU considers that experiment a substantial success. It recently 
announced that the experimental phase is over. The announcement can 
be found at 
http://www.itu.int/ITU-T/newslog/Free+Access+For+All+To+ITUT+Standards.aspx

One can now get any number of recommendations at no charge regardless 
of when the recommendations were published.

These are still copyrighted documents so one should probably not 
redistribute the actual standards. However, since they are online, 
one need only publish the appropriate URL.

Links to all recommendations can be found at 
http://www.itu.int/ITU-T/publications/recs.html

Links to the X series, including the X.500 series, can be found at 
http://www.itu.int/rec/T-REC-X/e These are in English; links for 
versions in French and Spanish can be be found at the top right-hand 
corner of the page.

Links to the latest two editions of X.509, March 2000 and August 
2007, can be found at http://www.itu.int/rec/T-REC-X.509/en

Enjoy. I for one am grateful for the permanent adoption of this 
enlightened policy.

    hoyt

From: "Arrian Bobowski" <[email-masked]>
To: <[email-masked]>
Subject: hsiraebg
Date: Sun, 4 Nov 2007 20:11:11 -0000

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

hola ietf-pkix-archive
yesterday it was small, today its small, what will it be when you take =
MANSTER?
http://hannuty.com/

Arrian Bobowski
------=_NextPart_000_0007_01C81F1E.D7DC7B50
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.2900.3059" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT Arial size=3D2>hola ietf-pkix-archive</FONT></DIV>
<DIV><FONT Arial size=3D2>yesterday it was small, today its small, what =
will it be=20
when you take MANSTER?</FONT></DIV>
<DIV><FONT Arial size=3D2><A=20
HREF=3D"http://hannuty.com/">http://hannuty.com/</A></FONT></DIV>
<DIV><FONT Arial size=3D2></FONT></DIV>
<DIV><FONT Arial size=3D2>Arrian Bobowski</FONT></DIV></BODY></HTML>

------=_NextPart_000_0007_01C81F1E.D7DC7B50--

From: "Cass Grankvist" <[email-masked]>
To: <[email-masked]>
Subject: oovaerts
Date: Sat, 3 Nov 2007 16:45:24 -0200

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

hey baby ietf-pkix-archive
look at your cock now! is it big enough? I didn't think so
http://www.googky.com/

Cass Grankvist
------=_NextPart_000_0004_01C81E38.EE6F69E0
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.2900.3059" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT Arial size=3D2>hey baby ietf-pkix-archive</FONT></DIV>
<DIV><FONT Arial size=3D2>look at your cock now! is it big enough? I =
didn't think=20
so</FONT></DIV>
<DIV><FONT Arial size=3D2><A=20
HREF=3D"http://www.googky.com/">http://www.googky.com/</A></FONT></DIV>
<DIV><FONT Arial size=3D2></FONT></DIV>
<DIV><FONT Arial size=3D2>Cass Grankvist</FONT></DIV></BODY></HTML>

------=_NextPart_000_0004_01C81E38.EE6F69E0--